[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On 2007-01-23 16:04, John C Klensin wrote: 
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
<jari.arkko at piuha.net> wrote:


<snip>

	
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?

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.


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>

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.


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>

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.


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

_______________________________________________
INDEPENDENT mailing list
INDEPENDENT at ietf.org
https://www1.ietf.org/mailman/listinfo/independent