Subject: [Rmt] I-D Action:draft-ietf-rmt-pi-norm-revised-10.txt

From: [email-masked]
Date: Mon, 20 Apr 2009 14:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title           : NACK-Oriented Reliable Multicast Protocol
	Author(s)       : B. Adamson, et al.
	Filename        : draft-ietf-rmt-pi-norm-revised-10.txt
	Pages           : 90
	Date            : 2009-04-20

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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-revised-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Apr 2009 14:42:43 +0200

Hi,

I hope that the WG has noticed the new IANA rules. These needs to be
reviewed.

What are the rules for addition to this registry?

7.1.3.  NORM_CMD Message Sub-types

   This document defines a namespace for "NORM_CMD" Message Sub-types
   named:

   "ietf:rmt:norm:command"

   It is possible that specifications extending NORM may wish to define
   additional "NORM_CMD" messages to enhance protocol functionality.
   The "NORM_CMD" sub-type field is an 8-bit value.  Note that the
   specification already provides for an "application-defined"
   "NORM_CMD" message sub-type that may be used at the discretion of
   individual applications using NORM for transport.  These
   "application-defined" commands may be suitable for many application-
   specific purposes and do not require standards action.  In any case,
   such additional messages SHALL be subject to the same congestion
   control constraints as the existing NORM sender message set.

   The current specification defines a number of "NORM_CMD" message sub-
   types that senders can use to signal the receivers in various aspects
   of NORM protocol operation.  This specification registers the
   following "NORM_CMD" Message Sub-types:

         +-------+-------------------------+--------------------+
         | Value | Name                    | Reference          |
         +-------+-------------------------+--------------------+
         | 1     | "NORM_CMD(FLUSH)"       | This specification |
         | 2     | "NORM_CMD(EOT)"         | This specification |
         | 3     | "NORM_CMD(SQUELCH)"     | This specification |
         | 4     | "NORM_CMD(CC)"          | This specification |
         | 5     | "NORM_CMD(REPAIR_ADV)"  | This specification |
         | 6     | "NORM_CMD(ACK_REQ)"     | This specification |
         | 7     | "NORM_CMD(APPLICATION)" | This specification |
         +-------+-------------------------+--------------------+

Then there is the ID nits that should be looked into. Please use the
tools webpage nits so you get all the nits. The submission tool does
only do a limited set of the checks.

  Miscellaneous warnings:

----------------------------------------------------------------------------

  == The document seems to lack the recommended RFC 2119 boilerplate,
even if
     it appears to use RFC 2119 keywords -- however, there's a paragraph
with
     a matching beginning. Boilerplate error?

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).

  Checking references for intended status: Proposed Standard

----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative
references
     to lower-maturity documents in RFCs)

  == Unused Reference: 'RFC1112' is defined on line 4013, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC2119' is defined on line 4016, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5226' is defined on line 4035, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC2357' is defined on line 4071, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3048' is defined on line 4078, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3269' is defined on line 4083, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3940' is defined on line 4106, but no explicit
     reference was found in the text

3. Then there is a downref to the congestion control. Personally I am
fine with that, but I do have to do a new IETF last call with it being
explicitly mentioned.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------