RE: draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call

Thanks for the clarification. My comments are inline (starting with **RV**)
 
-------------------------
Section 5.5.2.3
Old:	g[j,k] denote the jth element, j=0, 1, 2, ..., of the subsequence of
g[i] whose elements have exactly k non-zero bits in their binary
representation.
New:	g[j,k] denote the jth element, j=0, 1, 2, ..., of the subsequence of
g[j] whose elements have exactly k non-zero bits in their binary
representation.

*** It seems that the parameter "j" is already scoped in the context of
"g[j,k] denote the jth element, j=0, 1, 2, ...," and that reusing "j" as the
parameter in the function "g[]" is overscoping j.  Perhaps instead use
"g[.]" instead of either "g[i]" or "g[j]"?

**RV** I understand it better now. 
g[] was used both as a single dimensional array as well as a two-dimensional array. 
That caused some confusion(to me) when the correspondence between g[.] and g(.,.] was missing.

You might as well use a different letter e.g., m[j,k] to avoid confusion.
The alternative wording is as follows:
"Let m[k] denote the subsequence of g[.] whose elements have exactly k non-zero bits in their binary representation.
Let m[j,k] denote the jth element of the subsequence m[k], where j=0,1,2,..... "

-------------------------
Optional: For clarity, you may consider replacing "choose(i,j)" with more
familiar "nchoosek(i,j)".

*** It seems confusing to have the function called "nchoosek", where the
parameters "n" and "k" are part of the function name, and then have the
actual parameters be "i" and "j".  I suggest leaving the text here as is.

**RV** I am ok with choose(i,j).


Regards,
Ramakrishna Vedantham.



-----Original Message-----
From: ext Michael Luby [mailto:[email protected]]
Sent: Tuesday, September 20, 2005 6:46 PM
To: Vedantham Ramakrishna (Nokia-NRC/Dallas); [email protected];
[email protected]
Cc: [email protected]
Subject: RE: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call


Good catches.  Some minor comments on these (start with *** below).

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

Hi,

Here are some minor editorial corrections to this draft.

Sub-section 5.4.1.2
Old:	The symbol alignment parameter Al ensures that sub-symbols are
always a multiple of A bytes.
New:	The symbol alignment parameter Al ensures that sub-symbols are
always a multiple of Al bytes.

Sub-section 5.5.1
Old_	This process can be can be realized by a Raptor decoding process.
New:	This process can be realized by a Raptor decoding process.

Section 5
The phrases "source triples" and "source symbol triples" are used
interchangeably. 
At other places the phrase "repair symbol triples" is used.
For consistency, please replace the phrase "source triples" with "source
symbol triples" everywhere.

Section 5.5.1
Old:	Each repair symbol group is associated with an Encoding Symbol ID
(ESI) and a number, G, of encoding symbols.
New:	Each repair symbol group is associated with an Encoding Symbol ID
(ESI) and a number, G, of repair symbols.


Old:	The ESI is used to generate a triple of three integers, (d, a, b)
for each repair symbol, again using the Trip[] generator as described in
Section 5.4.2. 
New:	The ESI is used to generate a triple of three integers, (d, a, b)
for each repair symbol, again using the Trip[] generator as described in
Section 5.4.2.2. 


Section 5.5.2.3
Old:	g[j,k] denote the jth element, j=0, 1, 2, ..., of the subsequence of
g[i] whose elements have exactly k non-zero bits in their binary
representation.
New:	g[j,k] denote the jth element, j=0, 1, 2, ..., of the subsequence of
g[j] whose elements have exactly k non-zero bits in their binary
representation.

*** It seems that the parameter "j" is already scoped in the context of
"g[j,k] denote the jth element, j=0, 1, 2, ...," and that reusing "j" as the
parameter in the function "g[]" is overscoping j.  Perhaps instead use
"g[.]" instead of either "g[i]" or "g[j]"?

Section 5.3.
Replace "Principle" with "Principal".

Optional: For clarity, you may consider replacing "choose(i,j)" with more
familiar "nchoosek(i,j)".

*** It seems confusing to have the function called "nchoosek", where the
parameters "n" and "k" are part of the function name, and then have the
actual parameters be "i" and "j".  I suggest leaving the text here as is.

Thank you,

Ramakrishna Vedantham
Nokia Research Center

----------------------------------------------------------------------
Nokia                 		| Phone +1-972-374-1922
6000 Connection Dr,           | Fax   +1-972-894-5937
Irving, TX 75039, USA		| mailto: [email protected]
www.nokia.com/openness
----------------------------------------------------------------------





-----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