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

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

 



Dave:

You have the motivations for rfc3932bis completely confused. The IESG is not the source for the proposed changes to RFC 3932. RFC 3932 as it stands works fine for the IESG, and the IESG continues to operate under it. The Independent submission stream and IRTF stream do not like the IESG notes that are mandated by RFC 3932. The approval of draft-iab-streams-headers-boilerplates by the IAB offers an opportunity to revisit this question. So, you seem to be reviewing this discussion with the wrong context.

Below, I'll respond to each of you assumptions and assertions....

I think everyone agree that the IAB has an oversight role here. Many of the people on this list have already advocated the need for an appeals process to resolve disagreements about the content of notes suggested by the IESG. This is not about the content of the document itself. If it were, then I could understand your concern, but it is only about the content of the note.

While the tenacity that you and the IESG are showing, and the apparent motivation for it, are admirable, the effort seems to be based on some assumptions that should be reconsidered.

The document that was brought to Last Call did not have a section on appeals. It was added because of the Last Call discussion. I find it most interesting that the people voicing the strongest concerns on both sides of the issue are former IESG members.

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.

This repeats points that were made in the Last Call discussion.

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.

This repeats points that were made in the Last Call discussion; however, several people wanted to include a path for dispute resolution before it was needed, not in the heat of the dispute.

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.

I disagree with this characterization. The IESG is supposed to ensure that the non-IETF streams are not used as an end run around the IETF standards process or the IANA registration process for any IETF-related registries. The whole point of RFC 3932 was to make this situation clear, and define process for it. The IESG is not responsible for the quality of the content for RFCs outside the IETF stream. The appeal path being discussed is about the content of an IESG note, not the content of the RFCs outside the IETF stream.

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.

This point was not in the Last Call discussion. If your earlier assumption is correct, then this appeal path will never be exercised. Others have stated that they expect it will be exercised quite soon.

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?

How can you call this an assumption? I think Jari was very clear in his note, but I do not see it as an assumption. Again, neither the IAB nor the IESG would be making any decision regarding the content of the published document.

The assertion that there is community support for adding this new appeal path is apparently based a non-zero number of supporting posts, rather than on satisfying the rather more stringent requirement to achieve rough consensus support, or anything even close to it. In other words, you got "some" support, and based on that are claiming that it's the preferred solution.

The suggestion for this approach came from the Last Call discussion. Neither of the document authors came up with the idea.

Before adding more management layers, to solve a questionable problem, any claim of community support ought to have stronger evidence than we have so far seen.

The IETF has a long history with how to handle calls for change: Has it achieved rough consensus? In the absence of rough consensus the status is supposed to remain quo.

The IESG is demanding a change. The IESG has failed to achieve community rough consensus for that change, but the IESG is still claiming a mandate for change.

The IESG is not demanding a change. Quite the contrary. The Independent submission stream and IRTF stream do not like the IESG notes that are mandated by RFC 3932. The goal of rfc3932bis is to provide greater flexibility in this area, making IESG notes the exception.

One of the problems with our having rules is that we really are supposed to follow them.

Personally, I'd be happy to go back to an earlier version of rfc3932bis that does not include an appeal process. However, that version of the document did not have community consensus (either).

Russ

_______________________________________________

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]