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

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 8 Apr 2009 14:54:09 -0500

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.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 21 Apr 2009 14:44:42 -0500

Just to let people know, version 10 of this specification addressed my 
questions from version 09, and I didn't see any new issues in text that was 
added in this version.

Thanks,

Spencer

> Spencer (minor): I'm guessing s/inactivity has/inactivity timeout has/, 
> but something needs help here...
>
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
>