Subject: [INDEP] comments on draft-klensin-rfc-independent-05

From: Jari Arkko <[email-masked]>
Date: Tue, 23 Jan 2007 15:59:00 +0200

John,

I read this draft a few days ago, and was generally very
happy with it. A few comments, however:

1. There is no mention of IANA rules that sometimes
dictate what kind of documents may allocate new
numbers. While the rules and their use is defined
in other documents (the actual protocol RFCs,
RFC 2434, RFC 3932), it would seem useful to
mention the issue here as well. If not for other
reasons, at least for the benefit of folks who
consider making an independent submission.

2. I would like to synchronize draft-iesg-sponsoring-
guidelines and this draft. Here's what this draft
currently says:
>    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.  In any
>       event, these documents are published for the historical record.
and here's my planned text for the next revision
of the IESG draft wrt. AD sponsoring historical
record RFCs:

> Relevance
>
>       ...
>
>       A document specifying a particular vendor's proprietary protocol
>       is typically more suitable as an independent submission than being
>       sponsored by an AD.  A document specifying an alternate approach
>       to an existing Standards Track solution is typically not a likely
>       candidate either.  But this is a judgment call.  For instance, if
>       there is general agreement in a WG for publishing a "road not
>       followed" document for the record, but the WG itself considers it
>       out of scope, AD sponsoring might be appropriate.
>
>    History
>
>       Sometimes the IETF, IESG, and the WG has more information about
>       the history of the document than the RFC Editor.  This is the case
>       with the "road not followed" documents mentioned above as well as
>       with other documents recently seriously considered in the IETF.
>       If the publication of these documents is appropriate, they are
> likely
>       more suitable as individual submissions than as independent
>       submissions.
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.

Any guidance from this list on this matter?

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.

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]),
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".
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.
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.
>
> 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.

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.
Jari

_______________________________________________
INDEPENDENT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/independent

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Jan 2007 10:04:25 -0500

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-masked]> wrote:

> guidelines and this draft. 
>...
> [This] seems generally aligned, but the IESG draft is slightly
> less strict, leaving some room for interpretation.
> 

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.

>>    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.

>>    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.
>> 
>>    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

> 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.

>>    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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 23 Jan 2007 18:06:10 +0200

John,
> review of an IETF conclusion or inability to reach a conclusion.
This sounds reasonable to me.
> ...  However, many of us believe that it is very important
Sure. But I was not commenting on the lack of veto
power. I was commenting on the inconsistency between
two document parts. I think its fine if the RFC Editor
makes its own decision about the publication, having gotten
IESG's input. That's what "independent" means.
But your Section 4.8 and the current RFC 3932
implies that the IESG has the ability to provide the "DNP"
input. I think that ability should be retained, and reflected
in the same manner in Sections 2 and 4.8.
> then this text can be removed after appropriate other text is
Ok.
> And, yes, that implies a mini-review prior to a formal request
Ok.
> that text. 
OK
> However, during earlier discussions, there was a
Right. It is important that we settle on what the
general direction is. I believe very much in transparency,
ability to challenge bad decisions, etc. But I'm not sure
adding significant community review is compatible with
the idea of an independent submission process, at
least if the community ~ the people who also attend
the IETF.

Anyway, we are discussing about philosophy while
the actual change that I suggested was fairly small...

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jan 2007 17:13:57 +0100

> <[email-masked]> wrote:

<snip>

> review of an IETF conclusion or inability to reach a conclusion.

That seems to exclude publication of simply dissenting views.
Is that the intention? Personally I am generally in favour
of the IETF publishing "road not followed" documents, but we do
have various instances of such things not getting published.
Should we exclude independent submission as a backstop mechanism?

> That requirement implies not giving the IESG any sort of "DNP"

I didn't read Jari's comment as asking for that. But it does seem
fair to stipulate that the RFC Editor is expected to do the right
thing in flagrant cases (e.g. documents that infringe explicit
IANA considerations). That is, after all, why 3932 was written
in the first place.

<snip>

> then this text can be removed after appropriate other text is

I don't object to this text, but it's true that the fewer such
cross-references we have, the easier it is to make orthogonal
document updates.

<snip>

> formality.  The community needs to make up its collective mind.

Personal opinion: I want the ISR process to be as transparent as
possible. If it's to be a backstop for any untoward behaviour
in the IETF process, it needs to be at least as transparent as the
IETF process, where we have an increasing tendency towards public
reviews (e.g. http://www.alvestrand.no/ietf/gen/art/gen-art.html).
But I don't think we need rules here so much as an agreed principle
of openness, and practical steps to implement it, such as public
email archives whenever possible.

    Brian

---

From: Craig Partridge <[email-masked]>
Date: Tue, 23 Jan 2007 12:10:50 -0500

>Should we exclude independent submission as a backstop mechanism?

Since the IESG was created, the issue of coordinating the RFC Editor's
decisions with the IESG has been something of a third rail.  And
labeling the independent RFC series as a place to document "road
not followed" (or more vigorously dissenting opinions) in defiance of
the IESG seems an invitation to institutional conflict.

I agree this creates a challenge, namely, that one can present a road
not followed provided it never appears in a WG, but actually participating
in a WG may cause the idea to be unpublishable as an RFC (assuming
a sufficiently unreasonable AD -- I assume a reasonable AD is happy to
allow such publications).  But on balance, the current plan seems the
better of two evils.  Here's my logic.

    If the RFC Editor gets to publish road not followed documents
    over IESG objections, we have institutional clashes if either
    the RFC Editor is unreasonable or an AD is unreasonable.

    If the IESG gets to determine if road not followed documents
    are published, then the only clash is unreasonable AD with
    authors.

Thanks!

Craig

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Jan 2007 14:12:51 -0500

> in the same manner in Sections 2 and 4.8.

We agree that it should be fixed. 

I was just trying to stimulate some discussion about what the
fix should be.

    john

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Jan 2007 14:33:31 -0500

--On Tuesday, 23 January, 2007 17:13 +0100 Brian E Carpenter
<[email-masked]> wrote:

> ...
>> 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.
> 

Certainly not, at least IMO, but I may have coded a bit too much
into "critical review".  If the IESG is unwilling to take
responsibility for publishing a "road not followed" document
that is connected to IETF outputs or processes, I'm suggesting a
slightly higher standard for independent submission RFC
publication.  To vastly oversimplify the problem, suppose that
the IETF has agreed upon, and published, a standards-track
document that says "when there is a conflict, the packet that
arrives on the higher-bandwidth connection should be preferred
and forwarded".  I believe that is wrong and that the packet
that arrives on the lower-bandwidth connection should be given
preference.    Assuming I'd like my views published, I can
generate two types of documents:

	(1) A document that simply parallels the standards-track
	one except that it reaches the opposite conclusion.
	This is a "dissenting view".    Presumably the IESG asks
	the RFC Editor to slap warning labels all over the thing
	and maybe even requests non-publication.
	
	(2) A document that reviews the IETF decision in some
	careful and critical way (I know you know this, but, for
	the benefit of others, remember "critical" doesn't imply
	negative) and that explains why, in the opinion of the
	author, the decision may have been the wrong one.

Now I contend that the first document is historically nearly
useless: it has no value other than to document the fact that
there was not complete consensus in the IETF.  The second
document, however, if it is competent, should be published even
if it make the IESG unhappy... perhaps _especially_ if it makes
the IESG unhappy, because the dissenting position is likely to
be historically useful and possibly even important.

>>> 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
>> 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
>...

> IANA considerations). That is, after all, why 3932 was written

IMO, the RFC Editor is _always_ expected to do the right thing.
It is not clear to me that making a list of specific cases does
much more than brand the omitted cases as one in which the
community doesn't care whether the RFC Editor does the right
thing or not.  To paraphrase a remark Jari made elsewhere in his
note, we probably do not need more rules and procedures here.

But, if someone has specific language they would like in the
document to describe these situations, please propose it and
I'll happily let the IAB figure out what to do with it :-).

>>> 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.
>> 

>> 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.
> 
> IETF process, where we have an increasing tendency towards
> public reviews (e.g.
> http://www.alvestrand.no/ietf/gen/art/gen-art.html).
> of openness, and practical steps to implement it, such as
> public email archives whenever possible.

That difference of opinion is why the text is the way it is,
more or less.  As I tried to say, there is a tension among
reasonable objectives.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Jan 2007 17:16:31 +0100

Let me clarify that I have no objection to the
present text - I was just looking for a way to handle
Jari's comments. Generally, I agree with John's responses.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Jan 2007 17:27:33 +0100

On 2007-01-23 18:10, Craig Partridge wrote:
> decisions with the IESG has been something of a third rail.

I believe, from personal observations, that formalizing the
procedure via RFC 3932 has actually removed most of the third
rail effect. (I recognize that some people don't like the
boilerplate notes as they appear in 3932, but that is relatively
speaking a detail.)

>  And

But look at the appeal paths in both cases. A clash within
the IETF may end up with the IAB. A clash with the RFC Editor
may end up with an IAB review. So I'm not sure that there is that
much practical difference (once people start being unreasonable).

However, this isn't a showstopper issue for me. I'd rather
get this done soon, and trust people to be reasonable.

    Brian