Subject: Re: 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 based OAM) to Informational RFC

From: Julien Meuric <[email-masked]>
Date: Fri, 02 Mar 2012 18:21:17 +0100

Hi.

It looks like the candidate process is clear: the IETF and the IANA are 
capable of holding a document and the associated allocation until 
normative references are published.

I would like to come back to the original topic: the aforementioned I-D 
and the last call in progress. I have a few issues to add to the list.
1/ The I-D asks for a code point named "Ethernet based OAM" (starting 
form the title itself). That phrase may suit to Y.1731, targeted at 
Ethernet networks, but the I-D is clearly scoped within the MPLS 
context; so is the title of G.8113.1. This lack of clarity for such a 
controversial topic tends to make me think that the I-D is not mature 
and that the associated speech requires more exactness at this stage.
2/ The I-D has an explicit reference to 
draft-sprecher-mpls-tp-oam-considerations: acknowledging, inside the 
document, the existence of opposition does not solve the corresponding 
issues.
3/ It looks like that the I-D falls into the scope of RFC 4775 and RFC 
4929. Both could be quoted largely. Do they still have precedence in the 
current context?

Regards,

Julien

Le -10/01/-28163 20:59, John C Klensin a écrit :
>  --On Thursday, March 01, 2012 19:38 +0100 "Sprecher, Nurit (NSN -
>  IL/Hod HaSharon)" <[email-masked]> wrote:
>
> > 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!
>
>  Actually, we do that fairly regularly. Have a look at the RFC
>  Editor queue, see how many documents have a status that includes
>  "MISSREF", and you will get an idea of how many recent ones there
>  are. Of course, for that analogy to hold, draft-betts itself must
>  be complete and competent. But a forward normative reference is not
>  a problem: it just goes into the RFC Editor queue and, normally, IANA
>  doesn't start doing any assignments on the basis of such documents
>  until the problems/ references are resolved and the RFC Editor is
>  editing.
>
> > 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.
>
>  IMO, that should not be part of the IETF's problem. It is part of
>  the forward reference. As far as I can tell, Russ is not suggesting
>  actually allocating a code point until (and unless) G.8113.1 is
>  formally approved and hence complete and "hiding" nothing.
>
>  john
>