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

Magnus,

Thanks for your comments and apologies for the delay in replying!

1. Ok
2. I have updated this to refer to "bulk data transfer over IP multicast".
"bulk data transfer" is the phrase used in RFC 2887 ("The Reliable Multicast
Design Space for Bulk Data Transfer")
3. I don't think there has been any recent discussion of this possibility. I
agree with you that it does not seem necessary to have dynamically
assignable FEC Payload ID types.
4. Strictly, of course, you are right. However, the terms "length" and
"size" are commonly (ab)used to refer to things measured in bytes or
multiples of bytes and (more importantly) this term is already embedded in
several other standards (3GPP and DVB). I'd prefer to leave the term as it
is if we can to avoid confusion.
5. I didn't quite follow the comment: The section recommends object
integrity and source authentication for the object and then recommends
packet authentication (e.g. TESLA). It doesn't refer to packet integrity
checking without authentication.
6. Ok
7. Ok

...Mark


On 1/31/07 5:35 AM, "Magnus Westerlund" <[email protected]>
wrote:

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