----- Original Message -----
From: "Eliot Lear" <lear(_at_)cisco(_dot_)com>
To: "t.petch" <daedulus(_at_)btconnect(_dot_)com>
Cc: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>;
<stbryant(_at_)cisco(_dot_)com>; <ietf(_at_)ietf(_dot_)org>
Sent: Tuesday, March 06, 2012 12:46 PM
Hi,
I speak now as an individual and in no other capacity with no other hats on.
On 3/6/12 11:31 AM, t.petch wrote:
I am finding myself with some unfamiliar bedfellows on this issue, but yes,
it
should be approved - see inline.
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.
Our responsibility is to ourselves first and foremost, and to see that
our process is followed. That process exists to, amongst other things,
insure safe use and interoperable use of our own protocols.
Which, Eliot, is where we part company. Given the interest in and uptake
of MPLS outside the original definition, we have a wider responsibility,
as we have in, say, managing the IP address or domain name space. As
with the last two, if we do not consider the needs of all parties, and not just
ourselves, we may lose our influence in these matters. Yes we must follow our
processes but in the interests of a wider community than just ourselves.
Tom Petch
Here the process for approval of a codepoint calls for IETF review.
That is this. IETF Review is defined as follows in RFC-5226:
IETF Review - (Formerly called "IETF Consensus" in
[IANA-CONSIDERATIONS]) New values are assigned only through
RFCs that have been shepherded through the IESG as AD-
Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The
intention is that the document and proposed assignment will
be reviewed by the IESG and appropriate IETF WGs (or
experts, if suitable working groups no longer exist) to
ensure that the proposed assignment will not negatively
impact interoperability or otherwise extend IETF protocols
in an inappropriate or damaging manner.
In addition, we have spoken on what it means for other SDOs to request
code points in RFC-4775 Section 3.2, which says, in part:
Experience shows that the importance of this is often underestimated
during extension design; designers sometimes assume that a new
codepoint is theirs for the asking, or even simply for the taking.
This is hazardous; it is far too likely that someone just taking a
protocol value will find that the same value will later be formally
assigned to another function, thus guaranteeing an interoperability
problem.
Our processes direct us to consider a codepoint assignment in this
light. Finally:
There is no reason not to approve the allocation of a code point
The purpose of this review is to determine whether or not there is
reason *not* to approve. Others disagree with you.
Eliot
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf