Subject: [Rmt] FEC Encoding ID allocation

From: "Michael Luby" <[email-masked]>
Date: Thu, 8 Dec 2005 08:39:14 -0800

Colleagues,

The conditions under which an FEC Encoding ID is allocated is still open,
and thus I'm sending another email to spur discussion and hopefully close
this issue soon, as it is holding up progress.  Before I expressed a
preference for option A, but upon further reflection I think the following
is the right way to proceed:

(1)     Option B for Fully-Specified FEC Encoding IDs. 

(2)     Option B for Under-Specified FEC Encoding IDs.

a.       FEC Instance IDs associated with an Under-Specified FEC Encoding ID
are registered according to the current FEC building block specification
(which I think are even weaker than Option C)

Thus, as the name implies Fully-Specified means a full written specification
that has undergone IETF scrutiny and is under the control of the IETF, which
is what Option B provides.   There will probably be less of these, since the
process for getting one of these approved is quite a bit of work, and thus
it may turn out that having space for 128 of these is sufficient, but only
time will tell.  

The rationale for Under-Specified FEC Encoding IDs is that one must remember
that these don't actually specify an FEC scheme, the Under-Specified FEC
Encoding ID only provides the packet framework and FEC OTI framework
(leaving room for interpretation and further scheme specific information on
a FEC scheme specific basis).  The idea is that the same FEC Encoding ID can
(and should) be reused by many many FEC schemes, and these FEC schemes can
be easily registered with IANA (obtain an FEC Instance ID) by outside
bodies/individual/parties without any IETF scrutiny, providing very little
information (a reference to a product, or a public document, etc.).  Thus,
having the Under-Specified FEC Encoding IDs adhere to Option B in no way
impedes other commercial standardization bodies from very easily registering
their own FEC schemes (by registering a FEC Instance ID) without any IETF
scrutiny, and recall that there are up to 65536 FEC Instance IDs that can be
registered with each Under-Specified FEC Encoding ID.  On the other hand,
since a Under-Specified FEC Encoding ID can and should be reused for many
many FEC schemes, it makes sense for the specification of Under-Specified
FEC Encoding IDs to have a full written specification that has undergone
IETF scrutiny and is under the control of the IETF, which is what Option B
provides.   Note that there can be up to 128 Under-Specified FEC Encoding
IDs, and for each one there can be up to 65536 FEC Instance IDs (and thus a
total of around 8 million FEC schemes), and thus I think for the time being
the name spaces are large enough, but again only time will tell.  .

Mike

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: [email-masked]
Date: Fri, 9 Dec 2005 12:18:39 +0200

The bone of contention about B and C is in the string "and is under the control of the IETF". Under-specified doesn't "feel right" for fully specified codes which just don't have an RFC number (maybe I'll change my mind with more debate). Whereas a fast conclusion on this will unblock it in RMT, if we go other-than-C there's total-blockage potential if RFC is now required for fully specified codes which are in standards elsewhere.
 
BTW, sorry for complicating things further but: what about Instance IDs? I guess the "authority" who owns the IANA registered under-specified code ID also is responsible for allocating those Instance IDs. However, if IANA owns such a code ID (e.g. underspecified work comes from an IETF RFC), then I guess whatever we decide for fully specified codes also applies to the Instance IDs of ÍANA owned under specified codes?
 
I also think the review period needs stating. The normal 2 week wouldn't be enough for a newly introduced spec - external or I-D. (Normally our I-Ds hang about long enough´ before LC to make 2 weeks reasonable). 4 or more weeks wounds appropriate for external specs if time from a range of experts is expected.
 
Cheers, Rod.
 
PS (A) would be equally happy with Informational, Experimental and Standards Track RFCs. (B) enforces standards track only. (C) Also allows for full frozen specification outside an RFC, providing "IETF consensus" is reached (AD,  RMT and FECFRAME review/LC period is a natural interpretation). My take on (C) is that if "IETF consensus" is that the spec is not well written enough it can back-off to an (A) approach requiring a well-written RFC (naturally if the spec is well written but just bad, then it would simply be rejected with technical comments).

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Michael Luby
	Sent: 08 December, 2005 18:39
	To: [email-masked]
	Cc: [email-masked]
	Subject: [Rmt] FEC Encoding ID allocation

	Colleagues,

	The conditions under which an FEC Encoding ID is allocated is still open, and thus I'm sending another email to spur discussion and hopefully close this issue soon, as it is holding up progress.  Before I expressed a preference for option A, but upon further reflection I think the following is the right way to proceed:

	a.       FEC Instance IDs associated with an Under-Specified FEC Encoding ID are registered according to the current FEC building block specification (which I think are even weaker than Option C)

	Thus, as the name implies Fully-Specified means a full written specification that has undergone IETF scrutiny and is under the control of the IETF, which is what Option B provides.   There will probably be less of these, since the process for getting one of these approved is quite a bit of work, and thus it may turn out that having space for 128 of these is sufficient, but only time will tell.  

	The rationale for Under-Specified FEC Encoding IDs is that one must remember that these don't actually specify an FEC scheme, the Under-Specified FEC Encoding ID only provides the packet framework and FEC OTI framework (leaving room for interpretation and further scheme specific information on a FEC scheme specific basis).  The idea is that the same FEC Encoding ID can (and should) be reused by many many FEC schemes, and these FEC schemes can be easily registered with IANA (obtain an FEC Instance ID) by outside bodies/individual/parties without any IETF scrutiny, providing very little information (a reference to a product, or a public document, etc.).  Thus, having the Under-Specified FEC Encoding IDs adhere to Option B in no way impedes other commercial standardization bodies from very easily registering their own FEC schemes (by registering a FEC Instance ID) without any IETF scrutiny, and recall that there are up to 65536 FEC Instance IDs that can be registered with each Under-Specified FEC Encoding ID.  On the other hand, since a Under-Specified FEC Encoding ID can and should be reused for many many FEC schemes, it makes sense for the specification of Under-Specified FEC Encoding IDs to have a full written specification that has undergone IETF scrutiny and is under the control of the IETF, which is what Option B provides.   Note that there can be up to 128 Under-Specified FEC Encoding IDs, and for each one there can be up to 65536 FEC Instance IDs (and thus a total of around 8 million FEC schemes), and thus I think for the time being the name spaces are large enough, but again only time will tell.  .

	Mike