[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
  Web www.spinics.net

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


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.

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

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.


Ietf mailing list

[IETF Annoucements]     [IETF Obscurity Interest]     [IETF]     [IP Storage]     [Yosemite News]     [Linux]     [Pilates]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]

Add to Google