--On Wednesday, September 02, 2009 17:23 -0400 Russ Housley
<housley(_at_)vigilsec(_dot_)com> wrote:
I'd like to keep this discussion focused on the question that
Jari asked. While changes to the Independent Stream can be
discussed, that seems like rfc4846bis, not this document ...
Several people have said that the RFC Editor already has the
authority we are discussing here. Sadly, it is not that
simple. The words cited below from RFC 3932 cloud this issue.
I think they conflict with the words in the RFCs cited by John.
They do indeed and I'm not sure how helpful it is to spend a lot
of time exploring this. I'd much rather just get 3932bis
approved and move on. But...
RFC 3932 says:
The IESG may return five different responses, any of which
may be
accompanied by an IESG note to be put on the document if
the RFC
Editor wishes to publish.
I think that "... to be put on the document if the RFC Editor
wishes to publish" is the heart of the matter. RFC 3932
leaves the RFC Editor with the final say on publication, but
if the document is published, the note must be included.
The question isn't about what 3932 says (about which we agree)
but from where the IESG derives the authority to say such
things. Nothing in 2026 or any other defining documents gives
the IESG the authority to make such demands on the RFC Editor.
Nothing that I can find even gives an IETF Community consensus
process the ability to impose such a requirement.
Sam and Pasi have already pointed out that the RFC Editor can
appeal the action taken by the IESG if they think the note is
off base. In practice, the RFC Editor has asked the IESG to
reconsider the text of one note, and the IESG has done so.
There have not been any appeals on this topic since the
publication of RFC 3932.
Some of us considered appealing the language in 3932 discussed
above when it was under review and decided not to because of the
degree to which 3932, in toto, seemed like an improvement over
its predecessor and because we didn't dream at the time that the
sample notes would be interpreted as rigid and prescriptive
text. Similarly, while there were a few specific notes on a a
few documents that I think the RFC Editor should have appealed,
I don't think it is reasonable to infer "acceptance of the
IESG's authority" from "no appeals".
To use a deliberately silly and unlikely example, the RFC Editor
(and the IAB) have accepted the notion that the IESG can take an
IETF-track document and insist that it be published and
published without alteration. Let's suppose the IESG put a
document over that transom that claimed BCP status, said
"publish and publish as-is", and whose content said "the earth
is flat and the moon is made of green cheese". I assume it
would be published as an RFC and entered into the index as a
BCP. I assume that it wouldn't have much effect on the shape
of the earth or composition of the moon. The IESG's approving a
document that says "if we supply a 'note', the RFC Editor can
either publish with that note or not publish at all" should not
be considered as much more effective.
Whatever authority 3932 has in this area derives from the very
general IAB statement that makes up Section 6. But the IAB has
subsequently (as that paragraph contemplates) made its position
on this subject very clear in the stream-defining RFC 4844 and
the provisions of RFC 4846. As one of Olaf's notes indicated,
that IAB conclusion didn't favor mandatory notes across streams.
Please, let's try to answer this one question on this thread:
When the IESG performs review of an Independent stream or IRTF
stream document and provides an IESG Note, does the RFC Editor
have the authority (without a request for reconsideration or
an appeal) to publish the document without the IESG Note?
It should be clear from the above that my answer is "yes, the
RFC Editor does... and always has, regardless of what 3932 says
or appears to say, and that nothing the IESG does in terms of
document-writing or approval can change that". Given its
responsibility to supervise the RFC Editor function, a decision
by the IAB might, of course, be another matter.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf