--On Thursday, August 14, 2008 9:16 PM +0800 Fred Baker
<fred@xxxxxxxxx> wrote:
I seem to be in the minority, but I object.
This results, if I understand correctly, from the dispute that
JCK had with the IESG a little while ago. Basically, someone
on the IESG felt that rules of this sort should apply, an
update to an existing specification didn't conform, and they
objected to an update to an existing RFC on the basis of
personal opinion. This attempts to enshrine that opinion in
legislation.
And you know what? I think there are two cases here.
yes
In one case, you have an entirely new document. On that case,
no argument. If this is the rule we want, let it be, and I am
willing to see the rule.
Me too, although I've been persuaded by others that there are
still some reasonable exception cases and that those who think
they have them should be able to make that case to the community.
In the case the discussion was over, that seems like a big
change from the document being updated, and the editor would
have to be pretty about how s/he did it to make sure s/he
didn't change anything unintentionally. The usage in the past
documents hasn't been confusing to engineers in the past, and
a change to it might introduce confusion.
In the latter case - the case under dispute - I disagree with
the sense of this rule. I think the important thing is
clarity, and clarity is enhanced by not changing text whose
sense isn't actually being changed.
What I anticipated when I wrote the text that Bert picked up was
that the document editor in this case would simply write a short
note that said more or less exactly what you say above. In a
reasonable world filled with reasonable people, the community
would accept that argument, the IESG would respond by saying
"yep, hasn't done any demonstrable harm in years and the
community seems ok with it", and that would be the end of the
story (other than the RFC Editor removing the note before
publication). If an IESG said, instead, something equivalent
to "nah, nah, we have this rule and we don't care about
explanations", then we would have a problem that I-D checklists
aren't going to fix and, especially since I hope that outcome is
unlikely, is not worth further consideration in this context.
And oh yes, I agree with Eric's comment that including this in
an erratum stored separate from the document isn't very
helpful. I think it will come as a surprise to most people
when it is enforced, and this kind of thing doesn't want
surprises.
Yep. The use of non-2606 names also should _never_ be an
error. It should be an explicit decision made by authors and
agreed to by the community, just like everything else in an
IETF-track RFC.
john
p.s. this whole discussion moves us back toward "checklist as a
source of definitive rules" rather than "checklist as a general
guide and source of suggestions". If it is the former (which I
believe neither Bert nor I (nor at least some others) want),
then I think that any reasonable interpretation of our
procedures require an I-D, Last Call, community consensus, and,
since the IESG decided that IONs were not needed, publication of
a BCP.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf