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