ietf
[Top] [All Lists]

Re: draft-housley-iesg-rfc3932bis and theoptional/mandatory nature of IESG notes

2009-09-02 11:45:59
---- Original Message ----- 
From: "John C Klensin" <john-lame(_at_)jck(_dot_)com>
Sent: Monday, August 31, 2009 4:33 PM

--On Monday, August 31, 2009 16:29 +0300 Jari Arkko
<jari(_dot_)arkko(_at_)piuha(_dot_)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.


a) is my preference.

I am not persuaded by references to history, that the RFC Editor
function came first - cuckoos do take over nests (not that the
IETF is a cuckoo:-)

I do think it is a question of checks and balances, that being able
to submit and have reviewed an RFC, independently of the views
of the current IESG, is a valuable outlet for ideas and not one I 
want to see compromised.

John, below, outlines an appeal mechanism which allows the IESG
to take the issue to the IAB should it consider that justified and, 
assuming you agree that that is possible, then I see no case for 
anything other than a)

Tom Petch

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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • Re: draft-housley-iesg-rfc3932bis and theoptional/mandatory nature of IESG notes, Tom.Petch <=