Subject: [Rmt] Re: AD comments on draft-ietf-rmt-bb-fec-revised-04

From: Mark Watson <[email-masked]>
Date: Wed, 21 Feb 2007 18:11:16 -0800

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Feb 2007 17:37:25 +0100

> Design Space for Bulk Data Transfer")

Okay

> assignable FEC Payload ID types.

This is okay. If we see us consuming a lot of the space then one can fix 
this. But so far there is no mad rush for FEC Payload ID numbers.

> is if we can to avoid confusion.

I can buy that argument.

> checking without authentication.

Re-reading section 11. My interpretation of this is that although the 
text mention source authentication is that it doesn't put enough stress 
on the need for authentication.

Cheers

Magnus Westerlund

---

From: Mark Watson <[email-masked]>
Date: Thu, 22 Feb 2007 12:12:53 -0800

Magnus,

Ok, I will beef up the text on authentication.

...Mark

---

From: Brian Adamson <[email-masked]>
Date: Thu, 22 Feb 2007 15:43:59 -0500

Hello,

The "draft-ietf-rmt-bb-fec-basic-schemes-revised" is expired and 
needs to be resubmitted or otherwise resurrected if possible.

Will one of the authors volunteer to do this?   I don't think the 
document requires any updating.  It has simply expired due to lack of 
action.  If we can revive it, I think it is more than ready for last 
call ...

-- 
Brian

Brian Adamson
<[email-masked]>

---

From: Mark Watson <[email-masked]>
Date: Thu, 22 Feb 2007 14:00:12 -0800

Brian,

I resubmitted it just an hour ago.

Also ALC and LCT, as well as the Raptor draft and the updated FEC Building
Block with Magnus' comments addressed. You should see them shortly.

...Mark