[rfc-i] path forward with RFC 3932bis
harald at alvestrand.no
Tue Sep 22 09:37:08 PDT 2009
Aaron Falk wrote:
> The draft says:
> The RFC Editor reviews Independent Submission Stream submissions for
> suitability for publication as RFCs. As described in RFC 4846 [I3],
> the RFC Editor asks the IESG to review the documents for conflicts
> with the IETF standards process or work done in the IETF community.
> Similarly, documents intended for publication as part of the IRTF
> Stream are sent to the IESG for review for conflicts with the IETF
> standards process or work done in the IETF community [I2].
> I'm concerned about the phrase "or work done in the IETF community."
> Unbound it can cover much, much more than IETF standards work. In fact,
> one could make the case that it covers the IRTF (since much IRTF work is
> done in the standards community. I don't believe IESG review should
> cover conflicts in the IRTF (or IAB or IETF Trust or ISOC or with other
> Independent Submissions authors...) The IESG's authority in this
> paragraphs derives from RFC2026 which is pretty clear:
> To ensure that the non-standards track Experimental and Informational
> designations are not misused to circumvent the Internet Standards
> Process, the IESG and the RFC Editor have agreed that the RFC Editor
> will refer to the IESG any document submitted for Experimental or
> Informational publication which, in the opinion of the RFC Editor,
> may be related to work being done, or expected to be done, within the
> IETF community.
> I'd like to see the phrase in question removed or perhaps clarified (say
> to include planned standards work or some such).
That phrase was also present in RFC 3932, and, as you note, in RFC 2026.
I'm concerned that in our eagerness to make the perfect document, we
might be making too many changes, especially at what's hopefully a late
stage in the process of getting that revised.
If I remember rightly (but vaguely) from the writing of 3932, the phrase
was kept that way because we didn't want to be unable to speak about a
document just because the WG wasn't chartered yet, or the work was
processed through independent submissions to the IESG, or any of the
other multitude of ways work gets done in the IETF without invoking
excessive procedural overhead.
That said, the IESG notes in 3932 were tailored for conflict with WGs
specifically - it was also the desire of the IESG-at-the-time that the
note to the RFC Editor needed to *identify* the work it conflicted with,
not just a vague "there's work in this area".
More information about the rfc-interest