Robert Elz <[EMAIL PROTECTED]> writes: > Date: Wed, 31 Jul 2002 15:12:18 -0400 > From: Thomas Narten <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]>
> | Section 4 has some "mays", some of which might better be > | should/SHOULDs. I.e., an admin SHOULD set a low priority if the router > | doesn't reach the internet (due to connectivity or firewall). > Thomas, the point of the SHOULD etc words is to tell the implementor > what to implement. They're not at all effective in attempting to control > how people actually configure the equipment. SHOULD (or should) are used both to tell implementors what to implement and to make recommendations on how stuff ought to be configured/deployed/used. A goal of having shoulds on how things should be configured is to prevent ill-thought settings from being used by default. We do this all the time. Its prudent damage-avoidance. > And in any case, this is certainly not the doc to be attempting to tell > people how to do that - if you want a BCP on setting up IPv6 routers in > nice ways, then get someone to write one (as well as what prefs to set, > and when, it could go into what lifetimes to use in various situations, etc). Its common to mix applicability stuff in with a protocol standard. We do it far more often than writing a separate standalone applicability document. > But none of that belongs here (or not pretending to be any more than general > commentary so the implementor can understand what the user might want to > do with the implementation). > | Does it ever make sense to advertise a high preference in the absence > | of more detailed knowledge of the topology? > "None of your business." In other words, are you saying the document should provide no guidance to admins on how they should configure things, because that is by definition out of scope in a protocol docuent? If so, I disagree. > I will configure the preferences of the routers I manage in the way > that makes my net work for me. All that is needed of the IETF is > to provide the tool for me to use (and if you also want to give some > "good usage" advice, that's OK as well, but it should not be as part > of the protocol spec). Noone is saying you can't configure things the way you want. A SHOULD means, do this unless you understand what you are doing, understand the consequences of doing something different, but want to do something different anyway. > | Also, in chatting with Erik Nordmark, he indicated that at one point > | there were some discussions about adding a client capability to have a > | map table that mapped received preferences into other values, to > | handle situations where the received preferences didn't have the > | desired result. Would that be a useful thing to have? > Maybe. But this is a quality of implementation issue. I think this kind > of thing only matters when one is attempting to specify things like "if > I see any normal or high pref routers on interface A, that's what I want > to use as my default, but if all I see is low, and there is a high pref > router on interface B, then use that one" ... > All this is really beyond the scope of the protocol of router prefs though. You seem to be making it sound like a protocol spec should document only the on-the-wire part, and things relating to configuration are out-of-scope. If this is your point, I disagree on principle. > | One problem with the above is you assume that the implementor has > | knowledge about the enivironments in which technology will be > | deployed, and can thus make such tradeoffs. > Naturally. This applies to all implementation choices in just about > everything, from how much RAM is (and can be) installed, to what protocols > are supported. > If the implementor hasn't implemented the protocols with the features > that are required, or in the way that makes sense for a particular > environment, then that implementation should not be used there. You are assuming that an end user will have the choice of not using a feature. If the device is (say) a PDA, you might not have the ability to turn it off or otherwise control its usage. For better or worse, I think there are fewer and fewer places where the implementor really has a good idea of where something will be deployed. Consequently, we have to assume things will be deployed in the general internet, not in some sort of restricted environment (or include an applicability statement saying where something shouldn't be used). > | It would be better if the spec did not allow poor implementation > | choices (that have undesirable consequences on the internet) to be > | considered "in conformance with the standard". > If they actually have undesirable consequences for the internet, I'd > agree. But I don't see that here, only possibly undesirable consequences > for the customer who installed the equipment. Given that, thanks for > caring, but I want to be able to acquire cheap implementations when those > are adequate for my purposes. My text relates to flushing the entire ND cache and losing associated cached PMTU information. Are you saying this is OK to do this and doesn't have harmful consequences? Thomas -------------------------------------------------------------------- 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] --------------------------------------------------------------------
