I support the allocation of an ACH code point to G.8113.1, and I agree with Russ's comment. In addition, to avoid the same argument after the ITU-T's decision, I suggest we should clearly conclude that a code point be available if ITU-T will make consensus on G.8113.1, during this last call. This conclusion should be immediately informed to ITU-T. Best regards, zhenlong > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Russ Housley > Sent: Friday, March 02, 2012 8:52 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon) > Cc: IETF > Subject: Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt> (Allocationof anAssociated Channel Code Point for Use > by ITU-T EthernetbasedOAM) 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