Being a relatively short-term IETF participant, I lack the history that
many on this list have, but since Jari asked for comments, I'll provide
some.
Stated briefly, I agree with Steve Kent, Adam Roach, Ben Campbell, and
others that it makes sense to have IESG notes be mandatory for the ISE
to include in independent stream RFCs.
Stated at more length:
What is clearly going on here is that our branding is out of sync with
the expectations of our customers. Whatever their historical meaning,
RFCs are now interpreted by the broad community as documents that have
the been reviewed and approved, to a greater or lesser degree, by the
Internet community. I think we all agree that documents that go through
the IETF or the IAB can more or less legitimately claim that imprimatur.
Independent submissions clearly cannot. Given that, it's not clear to
me why the independent stream exists at all, other than for historical
reasons.
Given that the abolition of the independent stream doesn't seem to be an
option at this point, the next best thing to do is to require that
independent-stream RFCs alert the reader to two things:
1. That this is not a document that has received IETF or IAB review, and
2. If the Internet community has any serious concerns, what they are
Clearly the first point is an issue for Headers and Boilerplates. The
second point is represented in the current process by IESG notes; if the
Internet community has concerns about a document, they can be included
in the document as an IESG note. Given that the IESG is selected
through a community process, I'm comfortable with this delegation,
though requiring IETF consensus would clearly add some assurance.
The other implication of the above paragraph is that the *absence* of an
IESG note indicates to the reader that the community has no serious
concerns, which means that enabling the ISE to reject IESG notes
effectively enables the ISE to speak on behalf of the community. Given
the choice, I would prefer the IESG to speak for me than the ISE.
So I agree with Jari's option (b), that IESG notes should be something
that is always applied to the published RFC.
--Richard
Jari Arkko wrote:
I would like to get some further input from the community on this draft.
But first some background. This draft was brought to a second last call
in June because several IESG members felt uncomfortable with the IESG
notes being used only in exceptional circumstances. I asked Russ to
prepare the -07 version. This version allowed notes to be used at the
IESG's discretion and suggested that the linkage (or lack thereof) to
IETF work would typically be explained in the note. This version was
taken to the second last call.
While the number of comments we received was small, after the last call
was over I determined that the consensus was against this change. As a
result, I asked Russ to prepare the -08 version. This version goes back
to the "exceptional" wording from -06, but incorporated a number of
editorial corrections that had been made in interim. I also took the
draft back to the IESG telechat last week. The IESG was not extremely
pleased with the new version, but my understanding is that they were
willing to accept the changes. However, a new issue was brought up: one
of the changes that Russ and I felt was editorial highlighted the fact
that the document makes the IESG notes a recommendation to the RFC
Editor, not something that would automatically always be applied to the
published RFC. Some IESG members were concerned about this, and
preferred the latter.
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.
(For the record my own slight preference is b. But I have to say that I
think the document has been ready to be shipped from version -06, and
its unfortunate that we're not there yet, particularly since this
document is holding up the implementation of the new headers and
boilerplates system for independent submissions, IRTF submissions and
IETF submissions. I will exhaust all possible means of getting this
approved in the next meeting, as soon as I know what the community
opinion is.)
Jari Arkko
_______________________________________________
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