John, Jari -
I was one of the folks expressing the concern Jari points to below,
and it's
a small facet of a larger worry I have about a potential (and I think
likely)
unintended consequence of the header/boilerplate changes. To capture
that
in this thread (with apologies for walking through old discussions) :
specifically,
I think we're making it even harder for people who are not deeply
steeped in
IETF arcana to tell the difference between the output of a working group
(or any other IETF product) and the output of an individual. By
downplaying
that distinction, we are also making it easier for people with the
motivation
to champion technologies that compete with IETF products to convince
those
non IETF-arcana-steeped folks around them to follow.
But, that's water under the headers and boilerplate consensus building
bridge.
I think it should be more _routine_ than we are making it for _some_
body
representing IETF consensus to shine a light on that distinction when
necessary. The escalation process you point to is a fairly high bar
and it
puts providing the required energy on the wrong parties. I'm sensitive
to
the 'how it has always been' argument, but we are exactly in the process
of changing to a new RFC-editor model.
I've also been asking a few regular contributors and some chairs what
they thought about this, and am very frustrated with how little
attention
the entire change this small conversation is part of appears to have
received in the greater community. I don't know what to do to improve
that
beyond what we're doing now (through calls like this and through
individual
prodding).
RjS
On Aug 31, 2009, at 9:37 AM, John C Klensin wrote:
--On Monday, August 31, 2009 16:29 +0300 Jari Arkko
<jari.ar...@piuha.net> wrote:
I would like to get some further input from the community on
this draft.
...
And now back to the input that I wanted to hear. I would like
to get a sense from the list whether you prefer (a) that any
exceptional IESG note is just a recommendation to the RFC
Editor or (b) something that is always applied to the
published RFC. Please reply before the next IESG meeting on
September 10. Some e-mails on this topic have already been
sent in the Last Call thread -- I have seen those and there is
no need to resend.
Jari,
I've said this before, but not during the recent Last Call, so,
to get a note on the record...
Any IESG note or comment, exceptional or otherwise, has always
("always" == "since the IESG was created and long before it
started writing notes") been an recommendation to the RFC
Editor. That position is reflected in long-term precedent, in
RFC 4844, and in the new RFC Editor Model document. Under the
new model, should the RFC Editor decide to not accept a proposed
IESG note, the IESG can raise the issue with the RSE and, if
necessary, with the IAB, presumably causing a wider community
review of the proposed note itself. That level of protection
(which goes beyond that historically available) should be both
necessary and sufficient for the IESG's purposes.
Procedurally, should the IESG wish to change that position, I
believe it would require the approval of the IAB (because it
changes the RFC Editor role and relationship) and a review of
the Headers and Boilerplates document, the RFC Editor Model
document, and perhaps some of the statements of work associated
with the new RFC Editor contracts and appointments. I have
reason to believe that the IAB would insist on community review
before granting such approval, so trying to change things in
this area at this late date is not consistent with rapid
progress and may be inconsistent with having a fully-functional
RFC Editor function in place at the beginning of January.
More broadly, as the community has discussed extensively, the
IESG should not have the right to deprecate or denigrate the
contents of any document from another stream without broad
community consensus. Nothing in any community-approved IETF
procedural document from RFC 2026 forward gives the IESG such
authority (or authority for doing much of anything else other
than steering/managing) without community approval and
consensus. Even the claim in the original version of 3932 that
a document has not been reviewed in the IETF is inappropriate
unless such review has actually not occurred (whether or not
consensus was reached).
So I believe that your clarifying change was, in fact, editorial
and that it should remain.
...
regards,
john
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
