I would like to add that at the London IETF meeting the majority of the discussion on this draft was on this issue (i.e., whether to split the source address selection document into two documents). At the end of the discussion, there was a general consensus to not split the document as doing so would harm interoperability. This was captured in the minutes for the meeting.
Bob > > > > So I would have like to re-iterate my suggestion to split > > the document in two: > > framework, obvious rules... goes standard track > > other rules, values in various tables goes BCP > >I think it would be rather awkward to have the specification split into >two documents. Part of the problem with the current situation is that >the information and rules for different kinds of addresses(deprecated vs >non-deprecated, scoping, temporary addresses, native vs transition >addresses, etc, etc) is spread across many documents and it is not >obvious how to handle conflicting requirements. The relative priority of >the different requirements is not clear when the specification is broken >up into pieces. > >When someone invents a new kind of address a year from now, then their >specification can say how it should be handled (modify Rule N as >follows, or insert rule N.5 between rule N and N+1) wrt the standard >framework for address selection. And at some point "Default Address >Selection v2" can collect up any changes & improvements and progress as >an upgrade to the original standard. The original Default Address >Selection might make it to DS while the v2 version could be cycled at >draft or PS. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
