[EMAIL PROTECTED] writes:
> >How about changing:
> > (e.g.,the opening of a new TCP connection)
> >to
> > (e.g., an active open of a new TCP connection)
> >I'm assuming that "active open" vs. "passive open" terminology is
> >well-understood (I think it's in RFC 1122).
> it certainly make things better. i would like to see description
> in page 3 much shortened to avoid (possible) inconsistencies.
I'd prefer not shortening this text, as it is explanatory/introductory
for the novice reader. But, it should not be the definitive text.
Looking further in the document, there is specific text that says:
> 5.5.4. Address Lifetime Expiry
>
> A preferred address becomes deprecated when its preferred lifetime
> expires. A deprecated address SHOULD continue to be used as a source
> address in existing communications, but SHOULD NOT be used in new
> communications if an alternate (non-deprecated) address is available
> and has sufficient scope. IP and higher layers (e.g., TCP, UDP) MUST
> continue to accept datagrams destined to a deprecated address since a
> deprecated address is still a valid address for the interface. An
> implementation MAY prevent any new communication from using a
> deprecated address, but system management MUST have the ability to
> disable such a facility, and the facility MUST be disabled by
> default.
>
> An address (and its association with an interface) becomes invalid
> when its valid lifetime expires. An invalid address MUST NOT be used
> as a source address in outgoing communications and MUST NOT be
> recognized as a destination on a receiving interface.
I would prefer clarifying the text here. How about changing the first
paragraph as follows:
A preferred address becomes deprecated when its preferred lifetime
expires. A deprecated address SHOULD continue to be used as a
source address in existing communications, but SHOULD NOT be used
to initiate new communications if an alternate (non-deprecated)
address of sufficient scope can easily be used instead. Note that
the feasibility of initiating new communication using a
non-deprecated address may be an application-specific decision, as
only the application may have knowledge about whether the (now)
deprecated address was (or still is) in use by the application.
IP and higher layers (e.g., TCP, UDP) MUST continue to accept and
process datagrams destined to a deprecated address as normal since
a deprecated address is still a valid address for the
interface. In the case of TCP, this means TCP SYN segments sent to
a deprecated address are responded to using the deprecated address
as a source address in the corresponding SYN-ACK (if the
connection would otherwise be allowed). An implementation MAY
prevent any new communication from using a deprecated address, but
system management MUST have the ability to disable such a
facility, and the facility MUST be disabled by default.
Would this address your concerns?
Thomas
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
