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