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" <spencer@xxxxxxxxxxxxxxxxx> 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. > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf