Robert,

Not disagreeing there is affect to address selection.  But no one should assume 
address selection will be widely deployed at this time.  That remains to be seen.  I 
think it will personally.

My issue is what we do with a deprecated address in our stacks regarding behavior and 
that resolution is not driven by address selection.  That is all.

regards,
/jim

> -----Original Message-----
> From: Robert Elz [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 27, 2002 9:30 AM
> To: Bound, Jim
> Cc: Richard Draves; [EMAIL PROTECTED]; Atsushi Onoe;
> [EMAIL PROTECTED]
> Subject: Re: need clarification of "deprecated" address 
> 
> 
>     Date:        Mon, 26 Aug 2002 13:50:27 -0400
>     From:        "Bound, Jim" <[EMAIL PROTECTED]>
>     Message-ID:  
> <[EMAIL PROTECTED]
> qcorp.net>
> 
> Jim, all of this was pretty much settled almost a week ago, 
> all that remains
> is to get the text modified (but as I don't think there's a 
> new version of
> this doc in the works right now, I'm not sure when that will happen).
> 
> Even the new text has been agreed, I believe.   But ...
> 
>   | this has nothing to do with default address selection in 
> the IP layer
> 
> The address selection draft is more than that, but "this" had 
> everything
> to do with address selection - the "default" case is the one where not
> using a deprecated address is the correct answer, in other 
> cases it isn't,
> and that's why perhaps mention about not using deprecated 
> addresses might
> be better in the default addr selection doc, and no-where else.
> Unfortunately while putting it there is easy (for Rich) that 
> doesn't by
> itself get rid of the text from 2462.   And that text was the problem.
> 
>   | Also the discussion is for incoming transport layer 
> connections for TCP,
> 
> Yes, but that was influenced by a decision made about what 
> was legal for
> outgoing connections, based upon one reading of the doc.   
> The implementation
> has been fixed since, and new text for the doc to avoid it in 
> future agreed.
> 
>   | SCTP, and I think we need to consider connectionless too.
> 
> Yes, all the same issues (approximately) apply to connectionless.
> 
>   | Sure for applications but I don't think that is the discussion.  
> 
> They were part of it.    You probably needed to read all of 
> the messages,
> more carefully, before replying.
> 
> kre
> 
> 

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to