[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> (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 Annoucements]     [IETF Obscurity Interest]     [IETF]     [IP Storage]     [Yosemite News]     [Linux]     [Pilates]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]

Add to Google