ALC and LCT

All,

I have submitted updates to the ALC and LCT drafts. The only changes were to
update the references for the publication of the FEC Building Block. I
believe these drafts are ready for Working Group Last Call.

There is, however, one topic I would like to raise regarding LCT Header
Extensions. The draft requires ³IETF Consensus² to register a new LCT header
extension, meaning publication of a new RFC. I am currently involved in some
work in DVB on multicast content delivery in which context there is a desire
to specify a mechanism for a multicast FLUTE sender to poll the active
receivers to determine how long the session should continue. An LCT Header
Extension has been proposed as the mechanism to communicate this ³poll²
message within the FLUTE session.

Whilst there is no objection in DVB to proposing this mechanism to IETF for
publication as an RFC, the DVB timescale for this activity is rather shorter
than the timescale for RFC publication.

Since one of our objectives is to publish protocols which actually get used,
and since different users of a protocol often have a desire to extend/adapt
it slightly to their application, I¹d like to propose that we relax slightly
the rules for assignment of LCT Header Extension IDs. My propose is
³Specification Required² which means that a public specification of the
Header Extension must be available in order to register a new ID with IANA.
Another possibility would be to allocate a range of values for ³private²
use, but this is in some sense weaker, since the usage is then not publicly
known.

Perhaps we could discuss this issue at the Vancouver meeting ?

Regards,

Mark

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