Well, when the question (ION v. informational) came up
within the IESG's discussion of the document, this
is what I offered:
On the ION v. RFC question -- I think this is *really*
teetering on the edge! I've copied below the
relevant section of draft-iab-rfc-editor-03. On
the one hand, this document very clearly does not
change the outcome of publish/don't publish decisions
by the IESG (approvals). From that perspective, I think
it describes a process and could reasonably be an
ION if the IESG so desires.
On the other hand, however, it does provide guidance and
opinions about how proposed documents should be handled
in individual or independent streams. Put another way:
it's normative for the "individual" part of the
IETF stream of RFCs. From that perspective, it should
be published as an informational RFC as part of the
suite of RFCs that provide the definition of the RFC
series.
In brief: if it's just IESG process within stated
boundaries of IETF-stream documents, it can be an ION.
If it affects the substance of what fits in that stream,
I believe it fits under the umbrella of draft-iab-rfc-editor.
Per the latter document, the IAB gets a say in determining
community consensus when it comes to changing RFC series
documents. The IAB isn't about to monitor IESG process
pages (IONs); it'd have to be an RFC.
So -- which is it?
(I'm updating draft-iab-rfc-editor now, as it has finished
its 4-weeks call for input; I'd like to know if I'm
referencing an RFC-to-be or not :-) ).
Leslie.
P.S.: Again, copying the relevant bit from
draft-iab-rfc-editor-03:
From draft-iab-rfc-editor-03:
> 5.1. RFC Approval Processes
>
> Processes for approval of documents (or requirements) for each stream
> are defined by the community that defines the stream. The IAB is
> charged with the role of verifying that appropriate community input
> has been sought and that the changes are consistent with the RFC
> Series mission and this overall framework.
>
> The RFC Editor is expected to publish all documents passed to it
> after appropriate review and approval in one of the identified
> streams.
>
> 5.1.1. IETF Document Stream
>
> The IETF document stream includes IETF WG documents as well as
> "individual submissions" sponsored by an IESG area director. Any
> document being published as part of the IETF standards process must
> follow this stream -- no other stream can approve Standards track or
> Best Current Practice (BCP) RFCs.
>
> Approval of documents in the IETF stream is defined by
>
> o the IETF standards process (RFC2026, [3], and its successors).
>
>
>
>
>
> Daigle & Internet Architecture Board Expires July 15, 2007 [Page 14]
>
> Internet-Draft draft-iab-rfc-editor-03 January 2007
>
>
> o the IESG process for sponsoring individual submissions (RFC XXXX,
> [9]).
>
> Changes to the approval process for this stream are made by updating
> the IETF standards process documents.
John C Klensin wrote:
--On Thursday, 08 February, 2007 10:19 -0500 Sam Hartman
<hartmans-ietf(_at_)mit(_dot_)edu> wrote:
John> Sure. But my point in that area was obviously not
clear. John> Prior to the announcement of the Last Call,
there was no
That sort of depends on what's going on here.
Is Jari's draft an internal procedure of the IESG sent out for
community review because the IESG believes it has an
obligation to seek input on its procedures and to document
them?
If so, then a two week last call seems fine?
Alternatively, is this an IETF community process document that
will bind the IESG in the future unless it is updated by the
community? If so, then it should be a BCP and a four week
last call.
My understanding was that RFC 2026 was normative here
(although it says basically nothing) and that the IESG was
documenting its procedures.
If the community believes that this topic is important enough
that it should be a community decision not an IESG decision,
that seems entirely fine to me. But then this should not be
an informational document.
Sam, I think we pretty much agree, and that is why my initial
note wasn't much more aggressive. But it raises the issue that
others have raised: if this meets the criteria for "IETF
documenting its procedures" and, as you have described it above,
"informational", then why not publish it as an ION given that
series was designed for just those sorts of things? Please
take that as a question, not a position, but it is a very
serious one.
More generally, and independent of this particular document, it
seems to me that, with IONs in the mix, publishing something
that is informational about IESG procedures requires some
explanation. Procedural BCPs do not, IONs do not, but
informational documents of this variety have now become sort of
an odd case. And, IMO, if something that could reasonably be
published as an ION is proposed for publication as an Info RFC
instead, then that ought to imply a decision that serious
community discussion is in order, not just comments on a
collection of IESG decisions.
Put differently, I think the existence of IONs implicitly raises
the bar on Info publication of procedural docs, especially ones
that are just IESG statements of IESG procedures.
I think that is essentially the same question that Spencer and
others have raised.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf