Subject: RE: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call

From: [email-masked]
Date: Tue, 20 Sep 2005 18:20:33 -0500

Hi,

Has the FEC Encoding ID = 1 been already reserved for Raptor FEC?

The latest version of OMA BCAST SG http://member.openmobilealliance.org/ftp/Public_documents/BAC/BCAST/Permanent_documents/OMA-TS-BCAST_ServiceGuide-V1_0_0-20050910-D.zip
defines another null-FEC scheme with FEC Encoding ID = 1. This has to be registered with IANA by the proponents. 

But it is not clear who is ahead of the race to IANA, IETF RMT or OMA BCAST.

Would you please clarify this issue?

(Thanks to Naveen of Qualcomm to point this out after the last SA4 meeting.)

Regards,
Ramakrishna Vedantham.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
Lorenzo Vicisano
Sent: Tuesday, September 13, 2005 6:54 PM
To: Michael Luby
Cc: Walsh Rod (Nokia-NRC/Tampere); [email-masked]
Subject: Re: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call

Mike,

the two WGLCs are overlapped: both drafts are in
right now and feedback is welcome for both of them,
we jsut moved the deadline for Raptor by one week.

Considering the normal IETF times, this is unlikely to have
an impact in the date of publication of the RFC.

> wglc back by a week, and there are some good reasons why it would be good to
> have the FEC bb and the Raptor wglcs finished by the end of the week of
> September 26.  I've never seen another IETF wg that tried to keep the wglcs

please state the reasons.

Note that this is a fairly informal process: if needed we can
delay asking the IESG to review the FEC BB.. in case something
comes up to require another WGLC. Also note that other FEC IDs
are behind and still have to enter WGLC.

	thanks,
	Lorenzo

On Tue, Sep 13, 2005 at 04:24:27PM -0700, Michael Luby wrote:
> All,
> I don't understand this.  Rod admittedly is going to do his wglc review at
> the last minute on the last day, and for this the Raptor wglc is pushed back
> a week?  I don't understand why this is a reasonable argument to push the
> non-overlapped, and if I remember correctly the first time around the FEC
> bb, the LCT bb and the ALC pi were all in wglc at exactly the same time and
> all finished wglc at exactly the same time within the RMT wg.
> Mike
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Lorenzo Vicisano
> > Sent: Tuesday, September 13, 2005 11:31 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call
> >
> >
> > Rod,
> >
> > this is reasonable: let's make October 3rd the feedback deadline for
> > draft-ietf-rmt-bb-fec-raptor-object-02.
> >
> > 	thanks,
> > 	Lorenzo
> >
> > On Tue, Sep 13, 2005 at 04:53:04PM +0300, [email-masked] wrote:
> > > Hi Lorenzo et al.
> > >
> > > Is there any chance of shifting the raptor date back one week so we
> > > don't have to do two reviews at the last minute on the same day?
> > >
> > > (Yes I feel ashamed for openly admitting to leaving reviews to the last
> > > minute - I know I'm not the only one though :)
> > >
> > > Cheers, Rod.
> > >
> > >
> > >
> > > >-----Original Message-----
> > > >From: [email-masked] [mailto:[email-masked]] On
> > > >Behalf Of ext Lorenzo Vicisano
> > > >Sent: 12 September, 2005 09:34
> > > >To: [email-masked]
> > > >Subject: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call
> > > >
> > > >Please be advised that this email starts RMT working group
> > > >last-call for draft-ietf-rmt-bb-fec-raptor-object-02.
> > > >
> > > >Please provide your comments by Monday September 26th, if any.
> > > >
> > > >	thank you,
> > > >	Lorenzo Vicisano
> > > >
> > > >_______________________________________________
> > > >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

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

---

From: "Michael Luby" <[email-masked]>
Date: Tue, 20 Sep 2005 16:36:18 -0700

Wow, that's amazing!  Didn't anybody at OMA read the FEC building block
before trying to hand out FEC Encoding IDs?  Perhaps the OMA numbering space
is completely different than the IETF FEC Encoding ID space?  Anyway, as is
clearly stated in the FEC building block (RFC3452, and also in the new FEC
building block that is in IETF RMT wglc), the ONLY way to get an FEC
Encoding ID is to have an IETF RFC, and clearly OMA didn't do that, and the
Raptor specification is in IETF RMT wglc with FEC Encoding ID 1 specified,
so I guess that answers who is ahead and following the established
procedures.

Thanks for pointing this out, Ramakrishna (and Naveen).
Best, Mike 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, September 20, 2005 4:21 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call

Hi,

The latest version of OMA BCAST SG
http://member.openmobilealliance.org/ftp/Public_documents/BAC/BCAST/Permanen
t_documents/OMA-TS-BCAST_ServiceGuide-V1_0_0-20050910-D.zip
defines another null-FEC scheme with FEC Encoding ID = 1. This has to be
registered with IANA by the proponents. 

Regards,
Ramakrishna Vedantham.

-----Original Message-----

Mike,

	thanks,
	Lorenzo

---

From: Lorenzo Vicisano <[email-masked]>
Date: Tue, 20 Sep 2005 22:21:00 -0700

All,

RFC 3452 is clear about the assignmet of FEC Enc IDs:

"  An IETF RFC MUST exist and specify the FEC Payload ID fields and
   formats as well as the FEC Object Transmission Information for the
   value of "ietf:rmt:fec:encoding" (FEC Encoding ID) being assigned
   by IANA.. "

Unfortunatly RFC 3452 is incorrect in citing "Specification
Required" from RFC 2434, it should say "IETF Consensus" [this got
corrected in the current draft]

.. nevertheless the intention of RFC 3452 is very clear, both from
the verse above and the rest of the specification.

This process allow for race conditions, and IANA is supposed to
detect/solve conficts. Note that currently race conditions are
unlikely, given that RMT is the only place in the IETF where FEC IDs
are specificed [this migth change in the future].

On the specifics of Raptor vs OMA: technically Raptor hasn't grabbed
anything until it becomes an RFC and its ID is registered with IANA.
.. on the other side there is not any other fully specified ID being
worked on in our WG [apart from 0], so there are no conflicts yet.

If we start working on another fully specified scheme, I hope that we
will avoid conflicts even if raptor hasn't become an RFC yet ..

Note that this last part of RMT trying to do comflict avoidance is
just my opinion .. seems common sense 'though.

	Lorenzo