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

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

 



Draft-betts asks a code point for a document which is not mature and not
agreed yet. Usually we do not issue last call for a document in such a
condition!
And in addition, draft-betts has many issues that must be resolved
first. 
For example it must be clear for what the code point is requested.
Draft-betts indicates that G.8113.1 is subjected to revisions...they may
add more messages to G.8113.1 that will be hidden behind the code point,
etc.  

-----Original Message-----
From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of
ext John C Klensin
Sent: Thursday, March 01, 2012 8:29 PM
To: Russ Housley; Loa Andersson
Cc: ietf@xxxxxxxx
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



--On Thursday, March 01, 2012 13:02 -0500 Russ Housley
<housley@xxxxxxxxxxxx> wrote:

> Loa:
> 
> 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.
 
   john




_______________________________________________
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]