|
|
| [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