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
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.
_______________________________________________
Gen-art mailing list
Gen-art@xxxxxxxx
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf