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

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.

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

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

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

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.

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.

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.

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.

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


I am expecting an revised ID after having resolved what needs to be 
changed and what is misunderstandings from my side.

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