ietf
[Top] [All Lists]

Flame on random process documents (was: Re: new text for ID_Checklist sect 3, item 6)

2008-08-15 10:19:03
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>