[Rmt] Re: draft-ietf-rmt-bb-fec-rs-04 LC comments

[Vincent Roca <[e-mail]>]

Hello,

We just received these comments concerning our Reed-Solomon I-D
from Alfred.
Cheers,

  Vincent


Alfred Hoenes wrote:
> Hello,
> after studying the Internet-Draft in IETF LC authored by you,
>                 draft-ietf-rmt-bb-fec-rs-04,
> I'd like to submit a few comments, pointing out a few textual
> flaws I found in that memo that should be addressed before
> publicaton as an RFC.
> 
> The items below are presented in textual order.
> To give more context, sometimes I quote larger blocks of text
> literally and show the replacement proposed using the shorthand
> notation:
> 
>    <original draft text>
> ---
>    <modified text>
> 
> I use change bars ('|' in column 1) and occasionally
> up/down pointing marker lines ('^^^'/'vvv') to emphasize
> the location of textual issues and/or proposed corrections.
> Modified text has been re-adjusted to match RFC formatting
> rules, where appropriate.
> 
> 
> (1)  Section 1 -- word omission
> 
> In the 4th paragraph, put in the missing verb, "is" :
> 
>        The goal of the present document to specify ...
> ---
>        The goal of the present document is to specify ...
>                                         ^^^
> 
> (2)  Section 4.2.4.2 -- clarification of potentially misleading text
> 
> The last paragraph of Section 4.2.4.2 says:
> 
> |  After Base64 encoding, the 2 bytes of the FEC OTI Scheme Specific
>    Information are transformed into a string of 4 printable characters
> |  (in the 64-character alphabet) and added to the FEC-OTI-Scheme-
>    Specific-Info attribute.
> 
> a) In the first line, "After" is misleading; "During" would be
>    appropriate; I propose to use "Via" for brevity.
> b) In the third line, "and added" does not give the sentence the
>    proper sense; I porpose to use "that is added" instead.
> 
> Taking altogether, the paragraph should say:
> 
> |  Via Base64 encoding, the 2 bytes of the FEC OTI Scheme Specific
>    Information are transformed into a string of 4 printable characters
> |  (in the 64-character alphabet) that is added to the FEC-OTI-Scheme-
>    Specific-Info attribute.
> 
> 
> (3)  Section 5.1 -- typo/grammar
> 
> The last sentence above Figure 5 does not parse; please change
> 
>    This FEC Payload ID refer to ...
> ---                         ^
>    This FEC Payload ID refers to ...
>                             ^^
> 
> (4)  Section 8.1 -- text simplification
> 
> Near the end of the first paragraph of Section 8.1, the draft says:
> 
>                                                           ... the
>    multiplication is the multiplication modulo a given irreducible
> |  polynomial over GF(2) of degree m with coefficients in GF(2).  [...]
>               ^^^^^^^^^^             ^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Actually, "over GF(2)" and "with coefficients in GF(2)" mean exactly
> the same.  This equivalence is already explaned a few lines above,
> in the same paragraph.
> Hence, this redundancy should be removed, one of the two marked parts
> should be deleted; I leave it to your choice, which to choose!
> 
> 
> (5)  Section 8.1 -- clarification
> 
> The second paragraph of Section 8.1 says:
> 
> |  A finite field GF(2^^m) is completely characterized by the
>    irreducible polynomial.  [...]
> 
> The preceding paragraph already has stated more precisely that this
> is a polynomial *representation* of the structurally unique field.
> The polynomial characterizes this representation.
> For the sake of mathematical precision, I therefore recommend to
> improve the wording of that sentence to say:
> 
> |  The choosen polynomial representation of the finite field GF(2^^m)
>    is completely characterized by the irreducible polynomial.  [...]
> 
> 
> (6)  Section 8.4 -- textual improvement
> 
> The second paragraph of Section 8.4 says:
> 
>    [...]  If some of the source symbols contain less than S elements,
> |  they MUST be virtually padded with zero elements (it can be the
>    case for the last symbol of the last block of the object).
>    [...]
> 
> It should better say:
> 
>    [...]  If some of the source symbols contain less than S elements,
> |  they MUST be virtually padded with zero elements (this can be the
>    case for the last symbol of the last block of the object).
>    [...]                                             ^^^^
> 
> 
> (7)  Section 8.4 -- confusing overloading of the named index 'j'
> 
> Up to and including Figure 7, the index j (from {0..S01}) is used
> to select a particular m-bit element from each source symbol or
> encoding symbol, i.e. it is a column index in the upper and the
> bottom part of Figure 7.
> 
> Confusingly, 'j' is overloaded in the last paragraph of the Section
> with a very different meaning, as a row index in the bottom part
> of Figure 7.  This should be avoided; in that context, 'j' should
> be replaced by another variable name not yet used, e.g. 'i'.
> 
> Hence, the final paragraph of Section 8.4 should be changed to say:
> 
>    Another asset is that the n-k repair symbols can be produced on
>    demand.  For instance, a sender can start by producing a limited
>    number of repair symbols and later on, depending on the observed
>    erasures on the channel, decide to produce additional repair symbols,
> |  up to the n-k upper limit.  Indeed, to produce the repair symbol e_i,
>               v                                                       ^
> |  where k <= i < n, it is sufficient to multiply the S source vectors
> |  with column i of GM.
>                ^
> 
> (8)  Section 12.2 -- outdated reference
> 
> Apparently, ref. [9] has been published as RFC 5053 in September,
> long before the current draft revision has been posted.
> 
> 
> Best regards,
>   Alfred Hoenes.
> 
> +------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
> | Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
> | D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
> +------------------------+--------------------------------------------+


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