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
