RE: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt> (Allocationof an Associated Channel Code Point for Use by ITU-T EthernetbasedOAM) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Russ hi,
I think many concerns were raised on draft-betts itself, so I think we
should first look at these comments....
Concerning G.8113.1, as mentioned before as it was disapproved, it is
clear that there was no consensus. It will be good to understand what
are the issues...the code point was not the main issue, as indicated by
John.
Best regards,
Nurit
 
P.S. Concerning the chances of the document to be approved in WTSA,
please note that I do not think the members of WTSA have the technical
expertise to discuss the technical aspects of the document, and I
believe they would like to encourage SG15 to stick with the ITU's
culture of negotiation and consensus-building and have technical
standards developed by the industry members based on consensus. The
logical step would be to send the document back to SG15 to resolve the
issues and get consensus. 


-----Original Message-----
From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of
ext Russ Housley
Sent: Saturday, March 03, 2012 8:11 PM
To: John E Drake
Cc: IETF
Subject: Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>
(Allocationof an Associated Channel Code Point for Use by ITU-T
EthernetbasedOAM) 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 mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]