[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
  Web www.spinics.net

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


Ietf mailing list

[IETF Annoucements]     [IETF Obscurity Interest]     [IETF]     [IP Storage]     [Yosemite News]     [Linux]     [Pilates]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]

Add to Google