ietf
[Top] [All Lists]

Re: Should the IESG manage or not?

2005-06-30 18:12:37


On Thursday, June 30, 2005 06:50:30 PM -0400 John C Klensin <john-ietf(_at_)jck(_dot_)com> wrote:

It seems to me that the key text in 3932 is

                In March 2004, the IESG decided to make a major change
                in this review model.  The new review model will have
                the IESG take responsibility ONLY for checking for
                conflicts between the work of the IETF and the documents
                submitted; soliciting technical review is deemed to be
                the responsibility of the RFC Editor.

That doesn't give the IESG even the authority to say "this needs
technical review" at all.   All the IESG can do is say
"conflicts with work in the IETF"... or not.

Except that depending on context, "conflicts with work in the IETF" could be something that could be resolved through IETF review or participation in the already-ongoing work, or it could be something that cannot be reconciled. The text you quoted doesn't prevent the IESG from distinguishing between these cases or suggesting that the author bring the document to the IETF for review; what it does do is prevent the IESG from spending time reviewing documents and finding reviewers for documents which haven't been through any part of the IETF process.

Note that I would consider it entirely reasonable for the IESG to say that something "conflicts with work in the IETF" on the grounds that its deployment would break the Internet, since preserving the stability of the Internet is a fundamental part of _all_ IETF work.


I can cite other examples from BCPs where these two issues are
separated.  In a not identical but similar veign, our liaison
statement processes do not require us to conduct review
requested by other standards organizations; they explicitly
require us to respond to the request.  However one of the
responses can be that we choose not to conduct the review in
question.

Absolutely.  But, if you do not choose to conduct or manage a
review, the other body would presumably feel justified in doing
whatever it pleases, assuming that the IETF has no input of
substance.  The IETF, and still less the IESG, can't both
control external behavior and refuse to comment substantively on
it.

I don't think it is reasonable for the IETF to tell another SDO "That space belongs to us, so you shouldn't do any work there, but we don't feel like doing any either, so it should just be ignored".

I do think it is reasonable for the IETF (or the IESG) to tell another SDO "That space belongs to us, and we have active work there. The work you propose conflicts such that we would not charter it within the IETF, and we don't believe you should do it either." Whether such a statement can be expected to have the desired effect would depend a lot on the nature of the proposed work, the nature of the liason relationship involved, how much the other SDO already had invested in the proposal, etc.

And of course, I think it is reasonable (though unfortunate) for the IESG to say "We really think that should be reviewed within the IETF, but don't have the resources to do such a review right now. We wish you would wait until we do, but will understand if your timeline doesn't allow that." This should be uncommon in practice, as I believe the IETF typically fast-tracks things when doing so allows us to meet another SDO's schedule on joint work.


And then proceeded to indicate, albeit in quite convoluted
language, that it thought such review was pointless.  That is
where we are having a disagreement.  I believe, and various
other writers believe, that can, and should, approve these "IESG
approval" registration requests when they seem reasonable.
Conversely, we do not believe that the IESG should be able to
block a registration without at least some minimal level of
community review and consensus.  If I correctly understand your
comments and those of others, the IESG disagrees and believes
that the community has given it the authority, nay the
responsibility, to block registrations when it finds the
protocols inappropriate for any reason.

I don't think that is the case here. The IESG is not blocking the registration; it is simply declining to allow it without community review and consensus. Yes, the IESG has indicated that it does not believe the registration should be made at all, but if the community disagrees, then an attempt to register via the "IETF Consensus" path should succeed.

Now, I the situation might be somewhat different if "IESG Approval" were the only available choice. But even in that case, I don't think there's a problem, because my interpretation of RFC2434 has always been that "Standards Action" and "IETF Consensus" are strictly higher bars, and that anything that passed them could be automatically assumed to also meet the lower bar of "IESG Approval".


So, ok, we disagree.  That should not be a problem once we
understand what we are disagreeing about.  The normal IETF way
to deal with such a disagreement is to write a draft clarifying
the rules (one way or the other), discuss it in the community,
and see which interpretation gets consensus.  When we get
through that process, presumably there will be no further
ambiguity or differences in interpretation.   I don't see that
as a problem; I see it as progress.   And it was exactly for
that purpose that Vint, Scott, and I wrote and posted
draft-klensin-iana-reg-policy-00.txt.

You must have mentioned this document 4 or 5 times in the last few days.
I really should get around to reading it already. Apparently other people should, too, since I've seen no comments at all...



But the key issue here has nothing to do with the "it needs
technical review and we don't want to allocate the resources"
path down which we seem, again, to be going.  The question is
"if party X intended to allocate protocol Y on the Internet,
with or without IETF approval, and has the resources,
implementations, and support to do so, is it appropriate that
the IETF ignore that effort or should we, instead, try to devise
some mechanism for recognizing their method so it can be
prevented from interfering with other things".

Some of us consider the "the try to ignore it" path to be naive
and dangerous, especially if its advocates assume that ignoring
it will cause it to go away.   There is at least one, well-known
and well-established, technical method for preventing conflicts
between options that are mutually unknown.   That method is to
assign both appropriate codes so that receiving systems can
accept one, the other, or neither without fear of ambiguity.
That particular mechanism of using registrations and options
doesn't need technical review; we have years of successful
experience with it.  If the IESG wants to propose an alternative
for community review, that would be fine too, but such an
alternative would require technical review.

Put differently, I think the IETF has a moral obligation to
either accept registrations of methods and options that are
technically plausible (to determine that, we could use the
traditional tests of operational implementations and passing
laugh tests, neither of which are "technical review" or to
propose some alternative.  "We don't like it so you don't get
it" is both impolite and almost certainly ineffective.   Whether
it is worth doing the other work or the registration should be
accepted by default is a subject on which I hope that IESG would
have an opinion which it would express clearly to the community.



 Someone
could write an internet draft allocating the codepoint; if
they believe that we should allocate the codepoint without
technical review of the proposal, then they could contain few
details on that draft about the proposal but instead reference
the existing specification.

That would be reasonable except for the fact that the IESG has
appeared to send a clear message that the response to such an
I-D would be the statement that it needed technical review and,
presumably, that the IESG was not willing to try to seek or
allocate resources to get it done.   That would take us back
around the loop we are in now, but with an action that would be
more easily appealed.  I don't think either of us want to see
management by appeal.

I'd hope that if someone wrote up such a document and took it to the appropriate working groups, that it would get some review. I would hope that if there were support in those WG's to spend time on this, that the responsible AD(s) would not try to block that.

But, I also think the IESG's advice is at least partly accurate. Reviewing something of this size and complexity in the IETF is likely to take quite some time. It would likely result in changes, some incompatible, and some parts might be scrapped altogether. I'm not in a position to evaluate the argument that it would probably not gain community consensus, and I'm beginning to believe the IESG should not have said that -- not because of whether it's true or not, and not because of the resulting controversy, but because of the chilling effect created.



 If they believe the technical
details are important, they could include those details;
presumably reviewing the technical details would require the
support of Dr. Robrets.

If people believe that the guidelines
in RFC 2780 should encourage the IESG to assign options
whenever the use is sufficiently specified and there is likely
to be a significant deployment, then they could propose
revising RFC 2780 with those requirements.

Which is, in essence, what draft-klensin-iana-reg-policy-00.txt
proposes to do, although in a slightly different style and with
more flexibility than the way you state the issue above.  The
interesting question is what will happen with that document.
There are people who agree with it.  There are people who
disagree with it.  Sooner or later, that balance will need to be
resolved via a Last Call.   And the process by which the IESG
handles the Last Call request will be interesting in the extreme.

I don't expect it to be all that interesting. But then, the handling of process-related things has been a bit controversial itself, lately.



-- Jeff

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf