Subject: [Rmt] AD comments on draft-ietf-rmt-bb-fec-raptor-object-07

From: Magnus Westerlund <[email-masked]>
Date: Thu, 29 Mar 2007 17:01:57 +0200

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

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

---

From: Mark Watson <[email-masked]>
Date: Thu, 29 Mar 2007 09:10:40 -0700

Hi Magnus,

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

Regards,

Mark

> 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

Ok.
 
> There are two symbols G defined. Please fix this ambiguity.

Ok.

> 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.
 
> choosing a row in A. Only an indication of failure. I would suggest to

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

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

> document for finding out what the risks are.

Ok, I will cut and paste.

>     (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 ;-)
 
> changed and what is misunderstandings from my side.

Sure.

Regards,

Mark

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 30 Mar 2007 09:55:25 +0200

Things looks good.

> Ok, I will cut and paste.

Please, check that all are applicable to Raptor.

Cheers

Magnus Westerlund