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 ;-)
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf