Re: [Gen-art] Gen-ART review of draft-ietf-rmt-bb-lct-revised-10

["Spencer Dawkins" <[e-mail]>]

This revised draft addresses all of my comments from v09, and has a much 
stronger Security Considerations section than v09. Ready for publication as 
Proposed Standard.

Thanks,

Spencer


>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 ;-)
>
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art
>