[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Rmt] I-D Action:draft-ietf-rmt-pi-norm-revised-10.txt
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: magnus.westerlund at ericsson.com
----------------------------------------------------------------------