I have pretty much the same view as Brian has below. Indeed, explanation of SHOULDs is often very useful. For instance, we have seen many cases where IPv6 or some other technology is misapplied by folks who interpret SHOULDs without complete understanding of what the implications are.
However, adding those explanations is always a judgment call. And often we might only know that omitting the action does not cause major breakage, but at the same time we would not be able to explain why someone would omit the action. Age of the spec is also an input in the judgment call. (As a point of formality, I'm NOT requiring the authors or the WG to add the explanations for this particular spec unless they want to. I would like to see the other issues addressed/ discussed from the review, though. It would be great if you could converge that part of the discussion in the next day or two, because we have this document on the Thursday telechat agenda.) --Jari Brian E Carpenter kirjoitti: > A couple of thoughts here. > > 1. It is true that both Gen-ART and the IESG have probably been > looking more critically at SHOULDs. I personally believe that some > SHOULDs are fine without any qualification (i.e. the default words > in 2119 are sufficient guidance) and others need supporting text. > For example, if a timer value is defined as "SHOULD be set to > 30 seconds", I think a discussion of when it might be set to > less or more would often be appropriate, not to mention defining > a minimum and maximum. But it's a judgement call, and it seems that > Scott's judgement is different from the authors' in these cases. > > 2. OTOH, I'd be very surprised if qualifying the SHOULDs would > introduce interoperability problems, if the statement that the > protocol works regardless of the SHOULDs is true. > > 3. However, I'm quite sensitive to the fact that this is old text > that has been debated for a very long time in the WG, and that for > the PS->DS transition we are above all supposed to look at proven > interoperability. > > 4. So, bottom line, I don't feel I can challenge the WG consensus > on the current language. > > Brian > > Scott W Brim wrote: >> On 11/22/2006 15:46 PM, Bob Hinden allegedly wrote: >> >>> Gentlemen, >>> >>> This document is being recycled at Draft standard. It has been >>> previously reviewed, IESG approved, RFC-Editor edited, and published at >>> Proposed and Draft Standard. It is very widely deployed. Any issues >>> regarding the meaning of SHOULD, MUST, etc. have been already dealt >>> with. >>> >>> I am having a hard time not reading most of the comments in this review >>> as a "make work" project. There isn't an implementations problem that >>> is being solved. This is already widely implemented. In deciding to >>> recycle the Draft the IPv6 w.g. was trying to clarify some issues that >>> have come up based on the deployment experience todate. Many of the >>> changes from the previous document were finely crafted in a lot of >>> working group discussion. I think it is very inappropriate to change >>> them. >>> >>> Further, making these changes will likely cause confusion in the people >>> who have implemented this standard as they might wonder if they have to >>> change anything. So I think this attempt to clarify the text, might >>> well have the effect of reducing interoperability. >> >> >> I am not going to argue that you should accept the changes I proposed. >> I will object to almost everything you say because I think your >> rhetoric is bogus, and there are implicit accusations that are >> unjustified. >> >> I thought seriously before sending out this review. Technical tweaks >> were never an issue. However -- as I said then -- since this is a >> significant protocol, clarity in documentation is very important for >> implementors. You said it yourself just now. Why did you open up the >> RFC? For clarity. If you have been through five revisions in the >> last year to get the text clear, what is wrong with someone pointing >> out clarity issues you missed? Oh, I know it's hard to send something >> back to the Working Group. How inconvenient. But you can't say that >> the questions I asked were invalid. If the goal is a clear >> specification, see if you can find the answers to the questions I >> asked in the specification or any supporting RFC. For example, when >> is it all right for me to include a source address, but omit a link >> layer address even if I know it, in a neighbor solicitation? Right >> now there is no information, and in that vacuum an implementor is left >> with no resort but to treat the SHOULD as a MUST. Thus that SHOULD -- >> and some of the others I listed -- is really a de facto MUST. If >> that's what you intend, that's fine but you should tighten up the >> documentation and explicitly say so. Claiming that things are already >> perfectly clear is just not supportable because they are not clear to >> me, and I do know something about protocols. This is why we have >> non-WG reviewers. >> >> You say previous implementors might be confused by adding >> justifications for SHOULDs, and yet you also say you have made many >> changes from the previous document. Did you think previous >> implementors might be confused by the many changes you made? For >> example adding documentation of when it assumptions about DHCPv6 are >> implied? How could previous implementors be confused by your changes >> but not the little things I asked about? Conversely, if you are >> confident you had every previous implementor sign off on every change, >> then you can do it again. Do you want your cake or do you want to eat >> it? You can't have a double standard. >> >> Saying all issues "have already been dealt with" is simply arrogant, >> because if they had, you could just simply answer my questions. No >> one ever catches everything. Do you really mean you don't want to go >> through another iteration? Please be straightforward. >> >> The IETF can make a decision to ignore those small ambiguities, but >> that decision should be made honestly, with a clear statement that >> they aren't big enough to require fixing. Refusing to acknowledge >> them is not a good path to follow. >> >> As to whether mature documents should be reviewed at all ... External >> reviews serve different purposes at different times in a document >> lifecycle. Early reviews can make dramatic changes in not only a >> protocol but the whole system concept. Even at this late stage, an >> external review is useful because it validates the Working Group's >> (and IESG's) assumptions about clarity. >> >> It's fine with me if you say you understand there are some issues but >> you explicitly choose to ignore them. That's what I expected when I >> sent in the review. Just don't claim that everything is clear, or >> that all issues "have already been dealt with". >> >> Scott >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www1.ietf.org/mailman/listinfo/gen-art >> > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
