Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt

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

 



Dave,

I'd like to address some of the points you made in your message to Russ re 3932bis:

...

The first assumption is that there is a real problem to solve here.  Given 40
years of RFC publication, without any mandate that the RFC Editor must include a note from the IESG, and without any critical problems resulting, we have yet to
see any real case made for changing the current rule, which makes inclusion of
an IESG note optional.

As ads for financial products remind us "Past performance is not a guarantee of future performance." Since we have been making changes in IETF functions over time, including the RFC Editor function, I don't think it is unreasonable to formalize this aspect of the relationship between the IESG and the RFC Editor, before a problem arises.

The second assumption is that an IESG note is sometimes, somehow essential.  I
believe you will be very hard-pressed to make an empirical case for that
assumption, and the problem with trying to make only a logical case is that a
competing logical case is always available.  In other words, in 40 years of
RFCs, the damage that was caused by not having a note added by an authority that is separate from the author, or the damage that was prevented by adding one, is almost certainly absent. That does not make it a bad thing to add notes, but it
makes the case for /mandating/ such notes pretty flimsy.

I believe that most folks recognize that the public, in general, does not distinguish between RFCs that are the product of IETF WGs, individual submissions, independent submissions, etc. I think the IESG has a legitimate role in ensuring that RFCs that are not the product of WGs are appropriate labelled, and inclusion of an IESG note is a reasonable way to do that.

When the RFC series was first established, the need for archival, searchable, open publication of Internet-related documents was a good argument for the autonomy of the RFC Editor function. Moreover, the RFC Editor function pre-dates the existence of the IETF and the IESG, by many years. But, times change. The availability of search engines like Google make it possible for essentially anyone to publish material that is widely accessible, relatively easy to find, and more or less archival. Also, the vast majority of the RFCs published for many years are documents approved by the IESG. Thus it seems reasonable to revisit the degree of autonomy the RFC Editor enjoys relative to the IESG. The current proposal does not change the relationship very much in practice, but I understand that it is an important issue in principle, and the IETF membership has debated it in this context, extensively.

The third assumption is that the real locus of control, here, needs to be the
IESG.  Even though you are now promoting an appeal path, it's a fallback
position that derives from the assumption that the IESG should be the ultimate
arbiter of all quality assessment, not just for IETF RFCs but for all RFCs. For
independent submissions, this distorts the original model, which is that the
IESG is merely to be consulted for conflicting efforts, not general-purpose
commentary on the efficacy or dangers of an independent document. Really, Russ, it's OK for some things to proceed without having the IESG act as a gatekeeper.

My comment above addresses this issue as well.

The fourth assumption is that an added layer of mechanism, in the form of an
appeal path, is worth the cost. An honest consideration of those costs has been
absent, yet they are significant.

I think the biggest cost of an appeal mechanism is incurred when appeals arise, although there are costs associated with defining the mechanism. Since you argued above that we ought not expend a lot of effort to deal with problems that have not arisen, maybe we ought not worry about the costs of appeals that have not yet arisen :-).

The fifth assumption is the odd view that Jari put forward, namely that creating
an appeal path somehow "retains the independence of the editor".  In other
words, impose a mechanism designed to reverse decisions by the editor, but say
that the editor retains independence.  Confusing, no?

I agree that the quote cited above is not a good way to characterize the value of an appeals process. Perhaps a better way to state the value of the appeal process is to say that it provides a way for the Editor to address a situation when it believe that the IESG has insisted on inserting an inappropriate note.

I support 3932bis, with the appeal provision.

Steve
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]