AD comments on draft-ietf-rmt-bb-fec-revised-04

Hi,

Sorry for the delay in reviewing. However here are some comments.

1. The draft needs to in the following 3 places provide explicit mention 
that this document obsoletes RFC 3452: In the left side of the first 
page header: Obsoletes: RFC 3452 (if approved), the abstract, and in the 
introduction. Even if redundant this is what is required to be clear.

2. The abstract: I think the abstract is unclear on what framework this 
document relates to. The abstract indicates that the information present 
in the document applies to any data transport. I think this is a bit 
more generic than the reality of the RMT framework. I would appreciate 
some clearer pointers to the RMT framework.

3. A question on status of discussion. If I remember correctly there has 
been some discussion about changing the FEC payload ID from a globally 
unique Integer per FEC scheme to be a dynamically mapped identifier for 
a longer name. Are all these discussion put on the shelf for the moment? 
I don't see any strict need to do this currently, as the publication 
rate of FEC schemes has be relative low. It is definitely not comparable 
with payload formats in RTP.

4. Section 6.2.4:
"Maximum-Source-Block-Length:  a non-negative integer indicating the
       maximum number of source symbols in a source block"

Isn't this wrongly named. It is only implicitly a length, the current 
definition is a maximum number of source symbols and should much more 
appropriately be called "Max-Number-Source-Symbols"

5. Section 11. To me this document seems to incorrectly cover the need 
for both source authentication and packet integrity for any FEC symbols. 
The draft makes a large push for integrity, while integrity without 
source authentication still allows an attacker to insert erroneous 
symbols into any block.

6. Section 12.1.:

   "This document defines a name-space for FEC Encoding IDs named:
                               ietf:rmt:fec:encoding

    The values that can be assigned within the "ietf:rmt:fec:encoding"
    name-space are numeric indexes in the range [0, 255], boundaries
    included.  Assignment requests are granted on a "IETF Consensus"
    basis as defined in [2]."

I think that one should point out that this document in general provides 
restrictions on what is acceptable for documents going for registration. 
As IANA or someone looking in the registry may start by looking at the 
IANA rules in this document a self reference regarding the existence of 
rules in this document makes sense.

7. Lorenzo needs to update his address information.

Cheers

Magnus Westerlund

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