Draft-betts asks a code point for a document which is not mature and not agreed yet. Usually we do not issue last call for a document in such a condition! And in addition, draft-betts has many issues that must be resolved first. For example it must be clear for what the code point is requested. Draft-betts indicates that G.8113.1 is subjected to revisions...they may add more messages to G.8113.1 that will be hidden behind the code point, etc. -----Original Message----- From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of ext John C Klensin Sent: Thursday, March 01, 2012 8:29 PM To: Russ Housley; Loa Andersson Cc: ietf@xxxxxxxx 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 --On Thursday, March 01, 2012 13:02 -0500 Russ Housley <housley@xxxxxxxxxxxx> wrote: > Loa: > > 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. john _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf