Subject: RE: [Rmt] FEC ID allocation

From: [email-masked]
Date: Fri, 2 Dec 2005 12:24:56 +0200

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-masked] [mailto:[email-masked]] On 
>Behalf Of ext Michael Luby
>Sent: 30 November, 2005 00:33
>To: 'Lorenzo Vicisano'; [email-masked]
>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-masked] [mailto:[email-masked]] On 
>Behalf Of Lorenzo Vicisano
>Sent: Wednesday, November 23, 2005 9:47 AM
>To: [email-masked]
>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-masked]
>https://www1.ietf.org/mailman/listinfo/rmt
>
>
>_______________________________________________
>Rmt mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/rmt
>

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 02 Dec 2005 15:30:35 +0100

Hi,

Sorry for not responding earlier.

I think C is the way to go to ensure that we don't raise the bar to high 
for other standardization organizations that desires to use the 
framework. Having registered FEC encoding ID without collisions is a 
fundamental requirement to establish which FEC code is used as the RMT 
framework is defined today. Having used longer names and mapped them to 
IDs could have made the issues less. Maybe something to consider in the 
future. AVT changed the rules in AVP when around a quarter of the space 
of 127 values where used. Having other organizations grabbing ids 
without registering will result in serious problems down the road. And 
that will happen if they can't quickly and easily register things.

Cheers

Magnus

Lorenzo Vicisano wrote:
> 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.
> 
>      requested information (see draft-ietf-rmt-fec-bb-revised-02) and that
> One alternative proposal on the table was to transform IETF consensus into
> 
>      i.e. allow also non IETF specification to assign IDs subject to Expert
>      Review.
> 
> Note that the strategy for allocating FEC Instance IDs is "First Come
> First Served" and is not being discussed here.
> 
> 	thank you,
> 	Lorenzo
>      
> 

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]