Subject: Re: Gen-ART review of draft-ietf-rmt-bb-lct-revised-09

From: "Watson, Mark" <[email-masked]>
Date: Tue, 12 May 2009 16:17:51 -0700

Spencer, all,

Thanks for the review. My comments and proposed actions are inline below.

Best,

Mark

On 4/27/09 1:46 PM, "Spencer Dawkins" <[email-masked]> wrote:

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

Ok.

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

Ok. Easy enough!

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

Actually, I'm not sure the statement about the RMT's intent is appropriate
for the actual standard - it was there to explain why the draft existed when
the process started. So I suggest rewording this paragraph as follows:

"[RFC3451], which was published in the "Experimental" category and which is
obsoleted by this document, contained a previous version of the protocol."

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

Agreed. I suggest removing both.

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

I do not know the history of this text, but I suggest replacing this last
sentence with:

"In either case, receivers SHOULD use packet authentication mechanisms to
mitigate such attacks (See <reference sections where this is discussed in
more detail>.)"

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

This was text from the Experimental RFC, but I agree it does not make sense.
I would suggest deleting this paragraph since Security Considerations
associated with congestion control are an issue for the congestion control
scheme being used.