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

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

 



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)" <nurit.sprecher@xxxxxxx> 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


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