Subject: [Rmt] [Fwd: Gen-ART review of draft-ietf-rmt-bb-lct-revised-09]

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Apr 2009 14:47:09 +0200

For your information.

I do expect the authors to take also these comments into account and
respond to the reviewer.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

Subject: Gen-ART review of draft-ietf-rmt-bb-lct-revised-09
From: "Spencer Dawkins" <[email-masked]>
To: "Michael Luby" <[email-masked]>, "Mark Watson" <[email-masked]>, "Lorenzo Vicisano" <[email-masked]>
Cc: <[email-masked]>, "General Area Review Team" <[email-masked]>, "Magnus Westerlund" <[email-masked]>, "Brian Adamson" <[email-masked]>
Date: Mon, 27 Apr 2009 15:46:16 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-rmt-bb-lct-revised-09
Reviewer: Spencer Dawkins
Review Date: 2009-04-27
IETF LC End Date: 2009-04-15 (sorry! "along with any other LATE Last Call 
comments...")
IESG Telechat date: (not known)

Summary: This specification is almost ready for publication as a Proposed 
Standard. I have a couple of minor questions (below). I've also included a 
small number of nits, but this draft is very clean on that score.

Comments:

Abstract

   Layered Coding Transport (LCT) provides transport level support for
   reliable content delivery and stream delivery protocols.  LCT is
   specifically designed to support protocols using IP multicast, but
   also provides support to protocols that use unicast.  LCT is
   compatible with congestion control that provides multiple rate
   delivery to receivers and is also compatible with coding techniques
   that provide reliable delivery of content.  This document obsoletes
   RFC3451

Spencer (nit): it would be great if the abstract used the word "building 
block"... OBTW, there's a missing period after "RFC3451".

1.  Introduction

   Layered Coding Transport provides transport level support for

Spencer (nit): it would be good to provide "Layered Coding Transport (LCT)" 
somewhere around here - the next section of the document just starts using 
the abbreviation with no expansion...

   reliable content delivery and stream delivery protocols.  Layered
   Coding Transport is specifically designed to support protocols using
   IP multicast, but also provides support to protocols that use
   unicast.  Layered Coding Transport is compatible with congestion
   control that provides multiple rate delivery to receivers and is also
   compatible with coding techniques that provide reliable delivery of
   content.

   RFC3451 [RFC3451], which is obsoleted by this document, contained a
   previous versions of the protocol.  RFC3451 was published in the

Spencer (nit): s/versions/version/? but this section of the document wobbles 
back and forth between singular ("this document") and plural ("these 
specifications") - maybe clear to someone who's followed the working group 
for a while, but less clear to me...

   "Experimental" category.  It was the stated intent of the RMT working
   group to re-submit these specifications as an IETF Proposed Standard
   in due course.

4.  Applicability

   Before joining a session, the receivers MUST obtain enough of the
   session description to start the session.  This MUST include the

Spencer (minor): I don't think this two are 2119 MUSTs ... based on the 
previous sentence, I'd just s/MUST// the first one completely, but they 
should be at least lower-cased...

   relevant session parameters needed by a receiver to participate in
   the session, including all information relevant to congestion
   control.  The session description is determined by the sender, and is
   typically communicated to the receivers out-of-band.  In some cases,
   as described later, parts of the session description that are not
   required to initiate a session MAY be included in the LCT header or
   communicated to a receiver out-of-band after the receiver has joined
   the session.

4.1.  Environmental Requirements and Considerations

   LCT channels and SSM channels coincide, and thus the receiver will
   only receive packets sent to the requested LCT channel.  With ASM,
   the receiver joins an LCT channel by joining a multicast group G, and
   all packets sent to G, regardless of the sender, may be received by
   the receiver.  Thus, SSM has compelling security advantages over ASM
   for prevention of denial of service attacks.  In either case,
   receivers SHOULD use mechanisms to filter out packets from unwanted
   sources.

Spencer (minor): I'm confused by this. I would have thought that ASM wasn't 
so easily filtered in many cases (SSM, sure) - based on the source address, 
which could be coming from anywhere? Is this a membership check?

8.3.  Congestion control issues

   A receiver with an incorrect implementation of a multiple rate
   congestion control building block may affect health of the network in
   the path between the sender and the receiver, and may also affect the
   reception rates of other receivers joined to the session.

   Protocol Instantiations could address this issue by requiring
   receivers to identify themselves as legitimate before they receive
   the Session Description needed to join the session.

Spencer (minor): I'm sorry, but I don't understand what's being suggested 
here. Could you provide any guidance about how a sender could "identify a 
receiver as legitimate"? Is this authentication? If so, what's being 
authenticated - an implementation? I may not understand how this would 
address the issue of incorrect implementations, either, but let's start with 
the first question ;-)