Hi all, I agree with Russ and support the allocation of an ACH codepoint to G.8113.1.
Yuxia [email protected] 写于 2012-03-02 07:52:04: > 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: [email protected] [mailto:[email protected]] 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf >
