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