So to clarify: is 3452 wrong about the RFC, so that IETF (currently RMT)
consensus is enough? (And, what is the mechanism for documenting the
consensus in case of arguments after a race condition?
(Note, doing the RFC is definitely a useful thing in anycase).
Since the Raptor I-D exists, and the I-D has had email and meeting
discussion - whereas the "oma null fec" has not yet been presented in
the IEFT - I think it makes sense to rapidly form an RMT consensus that
1 holds for Raptor (reserved until IANA assignment or RMT decision not
to assign Raptor - which doesn't make sense and I can not imagine
happening). Anyone not support this?
Since the IETF doesn't normally do the liaison statement stuff, it's
really individual responsibility to communicate to OMA-BCAST (and
anywhere else) that a request to temporarily hold an ID number would
need to be made to RMT if IANA race conditions are to be avoided. (Short
of receiving tens of such requests, I guess this scales).
In the meantime, we're also aware of triangle and staircase codes so
maybe there are 4 new fully specified numbers on the radar. (Vincent -
fully specified or underspecified?)
And finally, this raises an interesting question of reuse of RMT work
outside the IETF (especially outside the IETF culture). It seems to make
sense to allocate an "experimental fec id" (probably one fully
specified, one underspecified) so new work doesn't need to go
underground when implementations are tested before IANA allocation. This
way the actual code allocation is not rushed while the code is still
under work. This should also make it clearer that codes which have not
been IANA registered yet should not be the basis of non-IANA decisions.
(127 and 255 "feel right" for such use). Opinions?
Cheers, Rod.
>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On
>Behalf Of ext Lorenzo Vicisano
>Sent: 21 September, 2005 08:21
>To: Michael Luby
>Cc: Vedantham Ramakrishna (Nokia-NRC/Dallas); Paila Toni
>(Nokia-M/Espoo); [email protected]
>Subject: Re: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call
>
>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
>
>On Tue, Sep 20, 2005 at 04:36:18PM -0700, Michael Luby wrote:
>> 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 protected] [mailto:[email protected]] On
>Behalf Of
>> [email protected]
>> Sent: Tuesday, September 20, 2005 4:21 PM
>> To: [email protected]; [email protected]
>> Cc: [email protected]
>> Subject: RE: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG
>Last Call
>>
>> 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/Pe
>> rmanen 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.
>>
>> 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 protected] [mailto:[email protected]]On Behalf Of
>> ext Lorenzo Vicisano
>> Sent: Tuesday, September 13, 2005 6:54 PM
>> To: Michael Luby
>> Cc: Walsh Rod (Nokia-NRC/Tampere); [email protected]
>> 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 protected]
>[mailto:[email protected]]On Behalf
>> > > Of Lorenzo Vicisano
>> > > Sent: Tuesday, September 13, 2005 11:31 AM
>> > > To: [email protected]
>> > > Cc: [email protected]
>> > > 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 protected] 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 protected] [mailto:[email protected]] On
>> > > > >Behalf Of ext Lorenzo Vicisano
>> > > > >Sent: 12 September, 2005 09:34
>> > > > >To: [email protected]
>> > > > >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 protected]
>> > > > >https://www1.ietf.org/mailman/listinfo/rmt
>> > > > >
>> > >
>> > > _______________________________________________
>> > > Rmt mailing list
>> > > [email protected]
>> > > https://www1.ietf.org/mailman/listinfo/rmt
>> > >
>>
>> _______________________________________________
>> Rmt mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/rmt
>>
>> _______________________________________________
>> Rmt mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/rmt
>
>_______________________________________________
>Rmt mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmt
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.