John,
I'm not sure whether I agree with your proposal or not, but I think
the most concrete way forward would be a proposal for specific
wording for draft-narten-iana-considerations-rfc2434bis, which
Harald left on my plate and I left for Russ.
Brian
On 2007-06-12 17:11, John C Klensin wrote:
--On Tuesday, June 12, 2007 07:11 -0700 Dave Crocker <dhc2@xxxxxxxxxxxx>
wrote:
To obtain "IETF approval", there needs to be a sponsoring AD.
Sam explained why he feels he cannot fill that role any
longer. Whether some other AD feels can can serve in his
stead is their individual decision. We do not have any rules
that compel an AD to sponsor a submission. Indeed, being able
to obtain a willing sponsor is considered part of the IETF
vetting process.
Nothing prevents the document from being submitted directly to
the RFC Editor, for publication as a non-IETF document.
That is the avenue I would prefer, but it raises another issue (which I
think would fall into the category Eliot referred to as <a corner in the
process>). As Sam points out, the actual use of this as a protocol
requires IANA registration of parameters and current procedures for TLS
extensions and many other things require IETF consensus for such
registrations and hence for publication of any document that specifies,
or requests IANA registration of, such parameters.
There may be things that make this particular case special, but, for the
general case, I have gradually come to think that model is broken. The
problem is that the IETF cannot _prevent_ someone from making up a
parameter and using it, registered or not, nor can we punish someone who
does so. So, by preventing registration, we do little but increase the
odds that one unregistered and unapproved extension will use the same
parameter keywords as another, causing interoperability problems.
Preventing publication and registration does not necessarily reduce the
odds that the extension will be used; it merely reduces the odds that a
system encountering that extension will be able to properly identify it
and easily determine what it is attempting to do.
Consequently, I believe that many of the <IETF Consensus required>
registration requirements should be changed to permit an alternate lower
threshold of:
(1) There has been IETF review and discussion, but the
IETF did not conclude that the idea was wise, or even
perhaps concluded that it was a bad idea. Note that
this is very different from "not reviewed in the
IETF".
(2) There is a reasonable basis for concluding that the
protocol has been, or is likely to be, deployed.
For that class of situation, I now believe that it should be possible to
make an independent submission and, if the RFC Editor judges that the
document is of adequate interest and technical and editorial quality, be
published and the registrations made. Of course, the document should,
at that stage, be very clear that it is not an IETF-approved protocol
and should ideally explain the reasons why the IETF did not approve
it. Similarly, the registration should be made in the interest of
interoperability but both the "IANA Considerations" section of the
document and the registration itself should clearly indicate that the
registration is to prevent interoperability problems only and does not
imply approval or endorsement.
Our pretending that a protocol extension will simply go away because we
don't like it --or because we can't agree that we do like it-- does not
make the Internet work better.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf