> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Karl Auer > Sent: Monday, July 30, 2012 6:46 PM > To: [email protected] > Subject: RE: question about draft-ietf-6man-rfc3484bis-06.txt and > CommonPrefixLen() > > On Tue, 2012-07-31 at 00:28 +0000, Dave Thaler wrote: > > The bits in the interface identifier are not indicative of goodness or > > appropriateness or whatever. > > Firstly, thanks for the extensive explanation. > > I realise now that I was confusing two comparisons - the comparison of an > address with a prefix in the policy table and the comparison of two addresses > with each other. > > Comparing an address with a prefix in the policy table must continue for as > many bits as are specified for the prefix in the policy table. > > Is that understanding correct?
That is correct. The CommonPrefixLen(). algorithm is only relevant in the context of rules that explicitly say so. Prefix policy table lookups are not in that category > If so, given the redefinition of > CommonPrefixLen(), do the definitions of Label() and Precedence() need to > make this point explicit? My opinion: no, it already seems explicit enough to me. > > 1) explicitly add Rule 9 which is already implied. > > Is it? In the fourth paragraph of Section 5, the draft says > > If the eight rules fail to choose a single address, > the tie-breaker is implementation-specific. True. I forgot that, so no editorial change is needed, it's already explicit as you point out. > I suppose one could say that since the draft does not specify an initial > ordering, the ordering is implementation-specific, so therefore the tie- > breaker is implementation specific :-) but that's not really the point. If the > draft wants the ordering to be the tie-breaker I think it has to say so > explicitly, as that would then exclude other tie-breaking mechanisms. > > It seems to me that the draft should be left as it is in this respect, and > thus > allow an implementation to use the original ordering if it wants to, but not > demand it or expect it. Agreed. So the only editorial change we could consider is adding a sentence to Appendix B noting the source rule was affected by the change as well. -Dave > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~~~~ > Karl Auer ([email protected]) > http://www.biplane.com.au/kauer > http://www.biplane.com.au/blog > > GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old > fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
