[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    Re: new text for ID_Checklist sect 3, item 6
From:       John C Klensin <john-ietf () jck ! com>
Date:       2008-08-15 17:05:25
Message-ID: 3C177A202EB1629BD2F8E871 () [192 ! 168 ! 1 ! 110]
[Download RAW message or body]



--On Thursday, August 14, 2008 9:16 PM +0800 Fred Baker 
<fred@cisco.com> 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 mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
[prev in list] [next in list] [prev in thread] [next in thread]