Re: AD comments on draft-ietf-rmt-bb-fec-raptor-object-07

Hi Magnus,

Thanks for the thorough review (as always!). All your comments are fine -
responses below.

Regards,

Mark


On 3/29/07 8:01 AM, "Magnus Westerlund" <[email protected]>
wrote:

> Hi,
> 
> I have reviewed and have a number of comments that needs to be addressed.
> 
> 1. section 3.2.3.
> 
> There is no textual description of how many bits the fields for Z, N or
> Al is. Please include that.
> 

Ok, I will add something.

> 2. Section 3.2.3. No explanation of what Al is.
>

Ok.
 
> 3. Section 4.2. Please provide an explanation in the text what symbols
> T, Kt and G is.
>

Ok.
 
> 4.  Section 5.1.2:
> There are two symbols G defined. Please fix this ambiguity.
> 

Ok.

> 5. Section 5.3.2, fourth paragraph:
>    "In the case that the last source symbol in a source packet includes
>     padding bytes added for FEC encoding purposes then these bytes need
>     not be included in the packet."
> 
> I don't think I have seen any statement in the decoder part that
> converts this into a normative requirement for the decoder to padd any
> encoding symbol that is not full length with 0. Unless they actually
> implement that one can't use this. Thus I would appreciate seeing a
> statement in the decoder description to this affect.
>

The decoder is informative - the code is defined by the encoder description.
So options at the encoder must be supported by decoders. But in any case I
can add something to the decoder to avoid confusion.
 
> 6. Section 5.5.2.2, last bullet on page 29:
> 
> The whole bullet seems to be out of place. It is basically a repeat of a
> sentence three sentences earlier. In addition it is not a method for
> choosing a row in A. Only an indication of failure. I would suggest to
> reword this.

Ok. I suggest removing the bullet and re-wording the introductory sentence
as "Whenever there are non-zero rows in V, then the next step starts by
choosing a row of A as follows:"

> 
> 7. Section 5.5.2.3, First bullet, second sub-bullet page 30.
>       "*  If r = 2 then choose any row with exactly 2 ones in V that is
>           part of a maximum size component in the graph defined by X."
> 
> What is "X" in this context. It seems undefined.
>

It's a typo - should be "V" (note that this has already been fixed in other
appearances of this description in 3GPP and DVB).

> 8. Section 6.
> 
> referencing a security consideration section in another RFC is somewhat
> problematic. Actually moving all the applicable text into this
> specification will result in less problems with comments from the
> security area. I understand the prime reasons as: First it will be fully
> applicable to this document, no need to disregard parts because of not
> being applicable. Secondly you don't need to go look into another
> document for finding out what the risks are.
> 

Ok, I will cut and paste.

> 9. Section 8.
> 
> Please remove it.
> 
>  From RFC 3979 (BCP 79)
> 11.  No IPR Disclosures in IETF Documents
> 
>     IETF and RFC Editor Documents must not contain any mention of
>     specific IPR.  All specific IPR disclosures must be submitted as
>     described in Section 6.  Specific IPR disclosures must not be in the
>     affected IETF and RFC Editor Documents because the reader could be
>     misled.  The inclusion of a particular IPR disclosure in a document
>     could be interpreted to mean that the IETF, IESG, or RFC Editor has
>     formed an opinion on the validity, enforceability, or applicability
>     of the IPR.  The reader could also be misled to think that the
>     included IPR disclosures are the only IPR disclosures the IETF has
>     received concerning the IETF document.  Readers should always refer
>     to the on-line web page to get a full list of IPR disclosures
>     received by the IETF concerning any Contribution.
>     (http://www.ietf.org/ipr/)
>

Ok. We left this only because we have been concerned to be clear at all
times about the IPR situation. We knew it would have to go before
publication and were just waiting for you to ask ;-)
 
> 
> I am expecting an revised ID after having resolved what needs to be
> changed and what is misunderstandings from my side.
>

Sure.

Regards,

Mark
 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email protected]
> ----------------------------------------------------------------------