A few observations on this, mostly in my personal capacity.
I'll leave the rest to list discussion and will start making
changes when Olaf tells me to.
--On Tuesday, 23 January, 2007 15:59 +0200 Jari Arkko
<[EMAIL PROTECTED]> wrote:
>...
> 2. I would like to synchronize draft-iesg-sponsoring-
> guidelines and this draft.
>...
> [This] seems generally aligned, but the IESG draft is slightly
> less strict, leaving some room for interpretation.
>
> Note that "considered by a WG" is not an exact definition.
As you may know, there was recently an extended discussion on
this general topic. A position has developed that is not
reflected exactly by either of the above sets of definitions,
but that may be more workable if the IESG is willing to agree.
I won't claim any consensus, but where some of us stand on this
could probably be summarized as follows:
If a document is the result of an IETF process, then we
would prefer that the IESG consider it and render an
opinion of some sort before it is submitted to the RFC
Editor. That opinion might be a decision by an AD to
sponsor the document, it might be similar to any of the
comments or categories called out in RFC 3932, it might
be some less formal comment. But the expectation is
that the initial responsibility for a document emerging
from an IETF process lies with the IESG and its members.
An author or other proponent of such a document who
submits it to the RFC Editor (as an independent
submission) will be expected to present evidence that he
or she made a diligent effort to obtain IESG review or
comments.
We believe that, in general, if the IESG wants something
published (as normative, historical, or anything in
between), then the IESG should say so. The condition of
an AD telling someone, about a document that resulted
from an IETF process, "the IESG doesn't care about this
enough to even consider it, why don't you try the RFC
Editor" has the odor of encouraging forum-shopping and
should be very rare.
The term "resulting from an IETF process" is
(deliberately) even more vague than "considered by a WG"
but is a superset of it that includes products of
formally-constituted design teams, reports on the
conclusions of BOFs, etc.
For documents that result from IETF processes that the
IESG does not decide to sponsor, the RFC Editor will
consider the IESG's comments, if any, as part of the
review process. IESG recommendations and comments (or a
decision to not comment, even on the degree of
historical importance) will be given especially strong
consideration when the relevant document is related to
IETF processes rather than having strong technical or
operational content.
The net result of this model is that, if a document results from
an IETF process, it is unlikely to be published as an RFC unless
it receives either sponsorship or, at least a positive review
and recommendation, from the IESG _or_ it represents a critical
review of an IETF conclusion or inability to reach a conclusion.
> 3. At the end of Section 2, you explain how the RFC Editor and
> the IESG work together with regards to conflicts with the IETF
> standards process. But this explanation only talks about
> delays and IESG notes, not the possibility of not publishing
> at all which Section 4.8 lists also as a possibility. Please
> update Section 2.
I would encourage some discussion of this subject on-list. The
general assumption underlying the document is that the RFC
Editor and independent submission process is actually
independent. Under that model of independence and subject only
to constraints the IESG imposes on itself (e.g., with RFC 3932
and its successors), the IESG can recommend anything it likes,
including publishing a document in PDF format with gold trim
along the edges of every page, specific changes or additions to
text, or a public burning of the document at the next IETF
social event. The RFC Editor may then take the advice, modify
it, or ignore it as seems appropriate. Since the RFC Editor
and, presumably all future RFC Editors, hold the opinions of the
IESG in high regard, it is unlikely that advice will be lightly
ignored. However, many of us believe that it is very important
that the RFC Editor be permitted to publish documents that are
highly critical of IETF conclusions and, indeed, of the IETF.
That requirement implies not giving the IESG any sort of "DNP"
veto power.
> 4. Is the below reference correct, or should you simply be
> pointing to RFC 2026? (Draft-iab-rfc-editor refers to RFC 2026
> and draft-iesg- sponsoring-guidelines when it talks about the
> IETF stream.)
>> o Documents considered by IETF Working Groups but not
>> standardized. While many documents of this type are
>> published via the IESG approval path (see RFC 3932,
>> Section 1 [RFC3932]),
The reference was intentional although, of course, if the IAB
wants it changed, I will change it. The discussion above may
have some impact on this question.
> 5. I cannot find this reference, even after searching for it
> from the set of old drafts:
>> [RFC3932upd]
>> Klensin, J., Ed., "IESG Notes on Independent
>> Submissions to the RFC Editor".
It has never been posted. It is more or less the material that
appeared in earlier versions of draft-klensin-rfc-independent
that suggested modifications in 3932. I should probably remove
the reference since I have been encouraged to not post it until
this document is settled. In addition, if the principle of
"advice, not control" that is outlined above is agreed, that
document may become largely irrelevant.
> 6. It was not obvious to me what the issues mentioned below
> are. It also seems more appropriate to deal with those issues
> in the RFC 3932bis work, than here. Or are they so deeply
> related that we cannot talk about them separately?
>> This document contains text that, if agreed to by the
>> community, may suggest a reexamination of and a
>> corresponding update to RFC 3932 [RFC3932]. Those issues,
>> and proposals for changes, are discussed in a different
>> document [RFC3932upd], but they are semi-independent of
>> the content of this document, which focuses on the review
>> and approval process for independent submissions.
See above. If there is concensus about "advice, not control",
then this text can be removed after appropriate other text is
developed.
> 7. I am not sure that the second step may be taken out
> of order below. If it was taken out of order, would it
> imply that the RFC Editor is performing reviews
> etc. even before the request for publication comes
> in?
>> ... at the
>> discretion of the RFC Editor, steps after the first may be
>> taken out of order.
As with almost everything else associated with the IETF and much
of the Internet community, there are times in which informal
inquiries and informal processes can save everyone a good deal
of time and energy. I can't speak for how much it has happened
in the past (and the answers for the recent past and the more
distant past may differ) but I certainly would not want to
prevent the RFC Editor from responding, informally, to an
inquiry about whether or not a document with some particular
outline or subject matter would be acceptable for publication.
And, yes, that implies a mini-review prior to a formal request
for publication.
>> 4.1. Posting of Draft
>>
>> The author(s) or editor(s) of a document post it as an
>> Internet Draft.
>>
>> 4.2. Request for Publication
> 8. I am somewhat concerned that we're building quite a lot
> of process for the independent submission path. I like the
> transparency, use of reviewers, ability to escalate a problem
> to the IAB, etc, but we should not attempt to build a
> process which is similar to the IETF. In particular, Section
> 4.8 says:
>> ... comments on conflicts can be sent to the IESG
>> with copies to the RFC Editor. Additional mechanisms may
>> be developed from time to time to inform a community that
>> a document is entering formal prepublication review.
>> Comments not directly related to IETF procedures or
>> conflicts may be sent directly to the author(s) and RFC
>> Editor.
> I hope we are not developing an "RFC Editor Last Call"
> procedure where the same community of Internet experts is
> expected to provide feedback to both IETF and independent
> submissions. Yet another mailing list to subscribe for
> everyone; yet more documents to look at in a situation where
> we already get too little LC review per document. I like the
> independent submission process very much, and have a lot of
> trust in the RFC editor and their selected reviewers for doing
> competent publication decisions. But I think one of the values
> of this system is that is indeed run by an independent set of
> people, not calling for the general community
> review in the same manner as IETF does.
> I would suggest deleting the text in question.
Personally, I share your concerns and would be happy to remove
that text. However, during earlier discussions, there was a
great deal of interest expressed in more transparency, more
community review and input, etc. There is obviously a tradeoff
in this: if one wants more assurance of transparency and
community review, then it is difficult to avoid more process and
formality. The community needs to make up its collective mind.
> 9. Are these two text excerpts consistent:
>> o Documents considered by IETF Working Groups but not
>> standardized. While many documents of this type are
>> published via the IESG approval path (see RFC 3932,
>> Section 1 [RFC3932]), the independent submission path
>> has traditionally been open to them. Because of their
>> intimate connection to the IETF Standards Process and WG
>> activites and the consequent sensitivity to exact
>> statements of relationships and to timing, there is
>> reason to believe that all such documents should be
>> published only at IESG request.
>> However, the RFC Editor
>> prefers that documents created through IETF processes
>> (e.g., working group output) be considered by the IESG and
>> submitted using this path only if a working group, or the
>> IESG, decline to publish it.
Please see the discussion above, which this text more or less
predicted but did not resolve. As far as consistency is
concerned, the statements indicate that a policy shift in
underway... a shift from "the RFC Editor has certainly published
many IETF products as independent submissions in the past" to
"maybe that is a bad idea in today's context and, in general,
the only such documents that should be handled as independent
submissions are explicit critiques of IETF results or
non-results.
regards,
john
_______________________________________________
INDEPENDENT mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/independent
