----- Original Message ----- From: "Eliot Lear" <lear@xxxxxxxxx> To: "t.petch" <daedulus@xxxxxxxxxxxxx> Cc: "John C Klensin" <john-ietf@xxxxxxx>; <stbryant@xxxxxxxxx>; <ietf@xxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf