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(_dot_)sprecher(_at_)nsn(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf