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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]