Thomas, I think it is good to have this discussion of link quality on the list to serve as a permanent (?) record for those developers who might want to implement a default router selection strategy based on factors not explicitly called out in the spec. To your specific question:
> Again, exactly what problem would adding "etc." actually fix? adding the "etc." could not possibly do any harm, and could possibly inform developers of the fact that they have some degrees of freedom in their default router selection strategy (i.e., it can't hurt and might help). Moreover, it could go as a simple AUTH48 update so I don't think its fair to draw a parallel between this and the M&O discussions. To prove it, I will make this my final submission on this topic. Fred [EMAIL PROTECTED] -----Original Message----- From: Thomas Narten [mailto:[EMAIL PROTECTED] Sent: Thursday, April 20, 2006 5:11 PM To: Templin, Fred L Cc: Soliman, Hesham; ipv6@ietf.org Subject: Re: RFC2461(bis), section 6.3.6 > Yes, this is the passage I am concerned with. The point is > that (in some environments) not all routers on the link will > be equivalent, e.g., some routers may exhibit better QoS than > others due to different signal-to-noise ratios, queue lengths, > etc. > In those cases, hosts may prefer some routers over others > for reasons that are not related to: "...in the INCOMPLETE > state, or for which no Neighbor Cache entry exists". Adding > the "etc" allows for other cases in which reachability of > some routers is "suspect". Not to sound too grumpy, but IMO, this sort of degree of wordsmithing is what leads to the exact sort of discussion we have had with the M&O bits. Nothing in the current wording says you can't take link quality into consideration (or the phase of the moon - if an implementation somehow thought that was useful). More to the point, what is your _real_ concern with the current wording? That if you did take into consideration link quality, that the result would be a "non conformant" implementation (whatever that means)? Who would actually notice and complain about this? Is this a result of overly-rigorous compliance testing suites that have been developed? Whatever happened to an implementor excercising a little common sense? None of our specs are so detailed and precise to take into consideration all factors, especially ones that were not even taken into considerations at the time a spec was written. And again (just like with the M&O discussion), the sentence at issue has a SHOULD in it. You SHOULD do X, unless you know what you are doing and understand the implications of not following the should. If you take link quality into considerations (at least, assuming the algorithm you use made sense!), that IMO would be perfectly in spirit with the intent of that sentence says. Again, here is what SHOULD actually means, per 2119: > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. Again, exactly what problem would adding "etc." actually fix? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
