ietf
[Top] [All Lists]

Gen-ART review of draft-ietf-rmt-pi-norm-revised-09

2009-04-08 15:56:37
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-pi-norm-revised-09
Reviewer: Spencer Dawkins
Review Date: 2009-04-08
IETF LC End Date: 2009-04-15
IESG Telechat date: (not known)

Summary: This specification is almost ready for publication as a Proposed Standard. I have one minor issue that I'm pretty sure is just a missing word, but it's in a normative sentence, so clearly should be fixed before publication.

(Please note - this is a previously-published Experimental specification going to Proposed Standard, so I spent most of my review cycle looking at NEW text)

Major issues: None noted.

Minor issues:

4.2.3.1.  NORM_CMD(FLUSH) Message

  Note that receivers also employ a timeout mechanism to self-initiate
  NACKing (if there are outstanding repair needs) when no messages of
  any type are received from a sender.  This inactivity timeout is
  related to the "NORM_CMD(FLUSH)" and "NORM_ROBUST_FACTOR" and is
  specified in Section 5.3.  Receivers SHALL self-initiate the NACK
  repair process when the inactivity has expired for a specific sender

Spencer (minor): I'm guessing s/inactivity has/inactivity timeout has/, but something needs help here...

  and the receiver has pending repairs needed from that sender.  With a
  sufficiently large "NORM_ROBUST_FACTOR" value, data content is
  delivered with a high assurance of reliability.  The penalty of a
  large "NORM_ROBUST_FACTOR" value is the potential transmission of
  excess "NORM_CMD(FLUSH)" messages and a longer inactivity timeout for
  receivers to self-initiate a terminal NACK process.


Nits/editorial comments:

Abstract

  This document describes the messages and procedures of the Negative-
  ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) Protocol.
  This protocol is designed to provide end-to-end reliable transport of
  bulk data objects or streams over generic IP multicast routing and
  forwarding services.  NORM uses a selective, negative acknowledgment
  mechanism for transport reliability and offers additional protocol
  mechanisms to allow for operation with minimal a priori coordination
  among senders and receivers.  A congestion control scheme is
  specified to allow the NORM protocol to fairly share available
  network bandwidth with other transport protocols such as Transmission
  Control Protocol (TCP).  It is capable of operating with both
  reciprocal multicast routing among senders and receivers and with
  asymmetric connectivity (possibly a unicast return path) between the
  senders and receivers.  The protocol offers a number of features to
  allow different types of applications or possibly other higher level
  transport protocols to utilize its service in different ways.  The
  protocol leverages the use of FEC-based repair and other IETF
  reliable multicast transport (RMT) building blocks in its design.
  This document obsoletes RFC 3940.

Spencer (nit) - Requirements language is described before the table of contents - the RFC has it after the table of contents, which is where I would have expected it.

Requirements Language

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
  NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
  this document are to be interpreted as described in [RFC2119].

This also isn't quite the suggested boilerplate for 2119, according to idnits 2.11.08, but the difference is that the draft text specifies "[RFC2119]", not "RFC 2119" - that should be fine.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>