|
|
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
John: If G.8113.1 never gets approved, then draft-betts- will sit in the RFC Editor queue until someone acknowledges this situation. I do not want anyone to use the IETF as a reason for or against achieving consensus in the ITU-T. Such consensus is left completely to ITU-T member states and sector members. Russ On Mar 3, 2012, at 12:58 PM, John E Drake wrote: > Hi, > > I agree with the proposal that Russ Housley made, below, but before even provisionally granting G.8113.1 a code point by placing draft-betts in the RFC editor's queue until G.8113.1 is approved, I would like to understand whether there is a reasonable chance for it to be approved at WTSA next fall. > > Draft-betts was already in the IETF approval process at the time that G.8113.1 was disapproved, so I don't see why lack of a code point was given as a reason for its disapproval. > > It is my understanding that it is very unusual to send a document to WTSA for approval, so would the authors please indicate the other issues causing G.8113.1 to be disapproved and the plan by which the ITU will address these issues? > > Thanks, > > John > >> -----Original Message----- >> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of >> Russ Housley >> Sent: Thursday, March 01, 2012 3:52 PM >> 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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf