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.