Having thought about this for some time, I think I concur with Russ' reasoning and the allocation should be made. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > Russ Housley > Sent: Freitag, 2. März 2012 00:52 > To: Sprecher, Nurit (NSN - IL/Hod HaSharon) > Cc: IETF > 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 > > Nurit: > > Some people are using the lack of a code point as the reason that the > cannot support the ITU-T document. My approach tells the ITU-T that a > code point is available to them IFF they are able to reach consensus. > The removes IETF from the discussion. This creates a situation where > G.8113.1 succeeded or fails based on the ITU-T members actions, with no > finger pointing at the IETF. This is completely a Layer 9 > consideration, and it has noting to do with the technical content of > the document. > > Russ > > > On Mar 1, 2012, at 2:33 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) > wrote: > > > Russ, > > I propose to simply re-discuss it when and IFF G.8113.1 is mature and > > approved... > > Best regards, > > Nurit > > > > > > -----Original Message----- > > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf > > Of ext Russ Housley > > Sent: Thursday, March 01, 2012 9:12 PM > > To: IETF > > 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 > > > >>>> Right now, there is no ITU-T approved document to reference. > >>>> I am certainly not an expert on ITU-T process, but my > understanding > >>>> is that earliest that we could see an approved > >>>> G.8113.1 is December 2012. My point is that we don't want to > >>>> assign a code point until the ITU-T approves their document. > >>>> However, if we are willing to assign a code point to G.8113.1 once > >>>> it is approved, then this would be an approach where the code > point > >>>> assignment would block on the approval of the normative reference. > >>>> > >>>> I like this approach from the political point of view. With this > >>>> approach the IETF tells the ITU-T that if and only if they are > able > >>>> to achieve consensus on G.8113.1, then a code point will be > >>>> assigned. > >>> FWIW, this seems entirely appropriate to me. If we do it this way, > >>> I think it is important to note --for the benefit of those more > >>> historically involved with the ITU and others-- that we routinely > >>> block our own documents on normative references to work that is > >>> still in progress and, usually, do not do related code point > >>> allocations until the blocking referenced documents are ready. > Once > >>> the present I-D is judged to be sufficiently ready, this approach > >>> would therefore be IETF approval and a formal guarantee to the ITU > >>> that a code point will be allocated if an when G.8113.1 is approved > >>> and published, but not assignment of that code point until the > >>> referenced base document is finished. > >>> > >>> Completely normal procedurally. > >>> > >> To be clear John our normal requirement would be that the technical > >> community achieved consensus that the base document was ready. I > have > >> never seen ITU-T consensus on the contents of G.8113.1 at any > meeting > >> that I have observed. What in your view is the criteria for > >> determining that G.8113.1 has achieved consensus? > > > > > > This is not an IETF problem, and I do not think that the IETF ought > to > > be discussing the internal workings of the ITU-T process. The point > > is to come up with a mechanism that allows the code point to be > > assigned if and only if the ITU-T does come to a consensus by > whatever > > means is allowed by their own process. > > > > Russ > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf