> I missed this part of the IPng discussion on source address > selection/ destination address ordering. > > There were two points I would have like to make: > > 1- Some of this text is clearly in the scope of standard track. > e.g. deprecated vs non deprecated > Some other parts are more questionable, are would better > fit in a Best Current Practise (BCP) document. > e.g privacy extension, 6to4, other non-native addresses.... > We have recently discovered some issues with ISATAP > that ended up in modified text in the draft. I'm sure such > other similar problems will be discovered in the future. > It will be much easier to reissue the BCP part than > to modify the complete RFC if it ever reach DS status. > > 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. > 2. The current draft does longest prefix match on 128 bits. > In the case of a dual-rail network where each hosts has > 2 interfaces See my previous email. Thanks, Rich -------------------------------------------------------------------- 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] --------------------------------------------------------------------
