I am finding myself with some unfamiliar bedfellows on this issue, but yes, it
should be approved - see inline.
Tom Petch
----- Original Message -----
From: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>
To: <stbryant(_at_)cisco(_dot_)com>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Friday, March 02, 2012 12:04 AM
Subject: Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt> (Allocation
of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to
Informational RFC
<snip>
(2) Whether it is reasonable or appropriate for the IETF to use
our responsibility for code point assignments and consequent
relationship with IANA to try to keep protocols that are not
consistent with our design judgment and aesthetics --no matter
how grounded in experience and good engineering-- off the
Internet. That is the "Internet gatekeeper" function about
which, as you know, I've expressed concern in other contexts. I
think the answer has got to be "we can, should, and always will
exercise quality control on stable specifications and normative
references but, unless we can justify being sure of our own
infallibility, we cannot and should not try to prevent another
body from deploying a specification on the Internet by using our
control of the registration model". Telling people why we
think their ideas are sub-optimal is fine, as is identifying any
risks we see in appropriate and visible places, but telling
another group what they can't do because the IETF doesn't like
the idea isn't.
We claim ownership of the name space on behalf of all parties, all SDOs
governments, NGOs, anyone and anything, and this gives us a special
responsibility to exercise that wisely. We should beware of imposing
our ideas of correctness of any kind on another SDO - that is up to
them to decide, not us.
Of course, one open technical solution to a problem is best but the RFC
Series is suitable cluttered with instances of the IETF failing to achieve
that so any argument based on those grounds is hypocritical.
A stable, approved reference is ideal, but we have been told of the
widespread deployment of this approach using an experimental
code point so the running code very much exists. If that is camping
on something that it would be better if it were not, then that is
something to fix, and something we can fix.
There is no reason not to approve the allocation of a code point
and furthermore, I believe we should do it now, to facilitate the migration
of the existing boxes to an approved solution. If that leaves another
SDO with an incompatability between what is working and what
their documents say, well, the IETF has been there too; not a
good place to be, but it is up to the SDO to resolve that, not
the IETF.
Tom Petch
And I think that distinction is entirely consistent with Russ's
suggestion.
best,
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf