Subject: [midcom] Fwd: Impending publication: draft-iab-unsaf-considerations-01.txt

From: Melinda Shore <[email-masked]>
Date: Wed, 03 Apr 2002 10:09:43 -0500

Read and pay heed.  All of our pre-midcom work is going to be
expected to directly address the questions raised in section 4.
Comments on the document should be sent by 15 April to Leslie 
or to the IETF discussion mailing list.

Melinda

>To: IETF-Announce: ;
>From: "Leslie Daigle" <[email-masked]>
>Subject: Impending publication:  draft-iab-unsaf-considerations-01.txt
>Date: Wed, 03 Apr 2002 09:49:29 -0500
>Sender: [email-masked]
>
>The IAB is ready to ask the IESG to publish
>
>     IAB Considerations for UNilateral Self-Address Fixing (UNSAF)
>                 draft-iab-unsaf-considerations-01.txt
>
>as an Informational RFC.  This document is part survey of issues,
>and part advice for IETF protocol development.  The IAB would
>like to ensure that the IETF community has had an opportunity to
>read it and comment before its publication.
>
>The IAB solicits comments by April 15, 2002.  Please send 
>comments to the IAB, care of the document editor 
>([email-masked]), or to [email-masked].  The document can be 
>found at 
>
>http://www.ietf.org/internet-drafts/draft-iab-unsaf-considerations-01.txt
>
>Leslie Daigle
>For the IAB
>
>ABSTRACT
>
>   With current NA[P]T middleboxes, individual networks using different
>   address realms are bridged.  However, as a side effect of address
>   translation, communicating endpoints on either side of the middlebox
>   do not know how to refer to themselves using addresses that are
>   applicable in the other realm -- the address translation is locked
>   within the middlebox.  Various proposals have been made for
>   "UNilateral Self-Address Fixing (UNSAF)" processes.  These are
>   processes whereby some originating process attempts to determine  or
>   fix the address (and port) by which it is known to another process --
>   e.g., to be able to use address data in the protocol exchange, or to
>   advertise a public address from which it will receive connections.
>
>   This document outlines the reasons for which these proposals can be
>   considered at best as short term fixes to specific problems, and the
>   specific issues to be carefully evaluated before creating an UNSAF
>   proposal.

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom