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
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
