RE: FEC ID allocation

To be frank, with only an IETF-cap on I strongly prefer A.

However, as Mike pointed out standards bodies are rarely aligned in
culture and it works both ways. Requiring all IANA registered FEC IDs
are completely specified in an RFC is great in the IETF world. However,
it introduces a strong risk of discouraging harmonisation since it means
all non-IETF bodies interested in FEC over RMT should basically forget
their own efforts and do all the work in the IETF - an organisation that
doesn't even know how to handle representation-by-affiliation and
liaison statements! ;>

So it boils down to how far the IETF is willing to go to spread the net
of harmony and what attrition rate of badly used FEC IDs without IANA
registration we can accept. Since this is an IETF-only forum (no
delusions), it's fairly pointless preaching the virtues of encouraging
non-IETF bodies to do their own work: but we shouldn't engineer problems
we can foresee. (I'm not the only one in RMT who has worked hard to
write specifications in other-than-IETF WGs rather than RMT-first.
Though I can't personally take the credit for anything but no code FEC
adoption - not that tricky as it's mandatory in FLUTE :)

For the foreseeable future, LCT, ALC and FLUTE success depends on
deployment on dedicated broadcast systems much more than on deployment
on the public Internet, hence making the effort to reach out to those
organisations is essential.

RMT's No code FEC was sufficiently specified in time to allow simple
adoption to DVB, 3GPP and elsewhere. Clearly Raptor (and others) were
not; hence we have to ensure that IETF spec is aligned (e.g. we don't
want 3GPP usage of Raptor using the same IETF Raptor FEC ID but
less-than-100% interoperable spec, and (A) would mean that any backwards
compatibility flaws in IETF Raptor are bugs to be fixed - as a separate
3GPP Raptor FEC ID isn't one of the options). Putting this job only in
the hands of the I-D authors relies on the non-IETF standards WG giving
those authors the mandate, trust and ensuring their work is reviewed in
that WG - as well as eventually depreciating their spec in favour of
referencing the eventual standards track RFC. It is rarely asked of
non-IETF WG leaders to understand IETF Tao (or even the niche Taos of
certain WGs), just as it would be unfair to ask our IETF WG leaders to
understand the Tao of all the various 3GPP, DVB, OMA, 3GPP2, ... WGs in
relation to RMT. Choosing (A) without further consideration is a giant
leap of faith.

Hence, I'm extremely worried that (C) is being so easily dismissed
(irrespective of my own understanding of the virtues of both A and C).
There's too little debate, and it's coming only from the RMT heartland -
no one has contributed to the thread who is primarily non-IETF. Maybe we
should make the process experimental with later promotion to "IANA
track" :)

Cheers, Rod.

PS Oh how I would love to be writing thinks to make me more loved -
seems that's not my calling in RMT nowadays - the end is nigh! :)

PPS This is all too stressful - bring on the smilies :::)))

 

>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On 
>Behalf Of ext Michael Luby
>Sent: 30 November, 2005 00:33
>To: 'Lorenzo Vicisano'; [email protected]
>Subject: RE: [Rmt] FEC ID allocation
>
>I prefer strategy A after reading through all the discussion 
>so far on the mailing list on this topic so far (thanks Rod, 
>Mark, Lorenzo!), and really don't like strategy C (for the 
>reasons Lorenzo gave -- backed by some evidence of other 
>standards groups trying to define "standard" FEC schemes and 
>producing results that were incompatible with the FEC building 
>block, even though the attempts were to be compliant).
>
>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On 
>Behalf Of Lorenzo Vicisano
>Sent: Wednesday, November 23, 2005 9:47 AM
>To: [email protected]
>Subject: [Rmt] FEC ID allocation
>
>At the Vancouver meeting we had a discussion on possibly 
>revising the strategy for allocating FEC Encoding IDs. The 
>discussion was inconclusive and hence it was decided to bring 
>this issue to the list, starting a 1-week WG last-call on it.
>
>The current strategy for allocating FEC Encoding IDs is
>
>  A) IETF-Consensus, i.e. requiring an IETF RFC that specifies all the
>     requested information (see 
>draft-ietf-rmt-fec-bb-revised-02) and that
>     instructs IANA to assign a specific ID.
>
>One alternative proposal on the table was to transform IETF 
>consensus into
>
>  B) Standard Action, i.e. requiring a Standard-Track IESG approved
>     RFC
>
>Another was:
>
>  C) IETF-Consensus OR [ Specification-Required AND Expert Review ],
>     i.e. allow also non IETF specification to assign IDs 
>subject to Expert
>     Review.
>
>I would like to hear any opinion on these options by Wed November 30th.
>Please check the meeting minutes for additional background information.
>
>Note that the strategy for allocating FEC Instance IDs is 
>"First Come First Served" and is not being discussed here.
>
>	thank you,
>	Lorenzo
>     
>
>_______________________________________________
>Rmt mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmt
>
>
>_______________________________________________
>Rmt mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmt
>