---- Original Message -----
From: "John C Klensin" <john-lame@xxxxxxx>
Sent: Monday, August 31, 2009 4:33 PM
> --On Monday, August 31, 2009 16:29 +0300 Jari Arkko
> <jari.arkko@xxxxxxxxx> 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf