I seem to be in the minority, but I object.
...
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.
+1
For what it's worth, I also agree with Fred's point. It was very significant
to me that the document under discussion wasn't I-D->PS, it was PS->DS, and
the distinction that applies in "the latter case" is being ignored here.
I will omit a much longer snotty comment about us not being very good at
advancing beyond PS because it happens so rarely, but those familiar with
the topic can fill in details for themselves.
ps. I guess this all settles the question about whether the Checklist
mandates its own set of formal requirements on RFC content. This entire
discussion is about something that is not mandated anywhere else. No other
BCP, RFC, or RFC Editor document.
I've been forcing myself not to reply to an earlier (but less forceful)
point along these lines from Dave, and from Robert's follow-up that provided
another part of the jigsaw puzzle, but with this clear statement of Dave's
objection, I don't think silence is appropriate.
Flame on.
We have a sense that we should have community consensus for process
requirements, and our track record on trying to achieve and declare
consensus on process requirements is appallingly bad.
Brian wrote a lovely draft that included a number of statements that are in
our process BCPs that we have NEVER enforced - "periodic review of all
standards-track documents that haven't reached full standard status yet"
being my personal favorite, but YMMV - but we don't know what to do with
that draft, or any suggestions made in that draft, and in the absence of
doing anything, there our process BCPs lie, describing rules in consensus
documents we don't enforce.
Since the IESG can't obey the letter of our process BCPs, and we can't
figure out how to change the letter of those BCPs, they enforce rules that
aren't described in BCPs, because they are trying to do what the IESG does
(manage the standards process). If we published the rules they enforce as
BCPs, we'd know we have community consensus behind those rules, but we
don't, because we can't figure out how to make that happen.
Russ sponsored the PUFI BOF at IETF 71
(http://www.ietf.org/proceedings/08mar/pufi.html). I've heard Russ
characterize that BOF's results several times as "people want to do things,
but we don't have consensus to do anything". No one has contradicted him
within my hearing.
Some of us Had Hoped that ISDs slapped around our process BCPs would have
given the IESG a way to keep our precious-but-frozen BCPs up-to-date
reflecting what the IESG actually does (among many other advantages of
ISDs). ISDs didn't happen.
So ...
o Dave's absolutely right in pointing out that documents like the ID-nits
checklist have no BCP standing,
o We're wedged on coming up with a way to publish process BCPs (even a
process BCP that says "the IESG can publish documents like ID-nits
checklist" would be more indication of community consensus than we've got
behind the ID-nits checklist now), and
o This is a problem.
I said at the IETF 72 plenary mike that the IESG does not have time to solve
this problem. The ADs I talked to afterwards said the acoustics weren't good
for the IESG, but no one from the community got up and said that the IESG
DOES have time to solve this problem.
Does the larger community have any suggestions on how to move beyond
o not enforcing the rules we describe in BCP documents, and
o not describing the rules we enforce in BCP documents?
Flame off. Have a lovely weekend.
Spencer
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf