--On Tuesday, 23 January, 2007 17:13 +0100 Brian E Carpenter
<[EMAIL PROTECTED]> 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.
>
> 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?
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
>> 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
>...
> 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.
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 :-).
>...
>>> 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
>...
>>> 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.
>
> 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.
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
_______________________________________________
INDEPENDENT mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/independent
