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

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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf