ietf
[Top] [All Lists]

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

2012-03-03 12:04:24
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(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] 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(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>