[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

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



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



[IETF Annoucements]     [IETF Obscurity Interest]     [IETF]     [IP Storage]     [Yosemite News]     [Linux]     [Pilates]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]

Add to Google