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