[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 an Associated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC



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


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

Add to Google