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
On 2007-01-23 20:33, John C Klensin wrote:
--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
_______________________________________________
INDEPENDENT mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/independent
