Hello,
Let me comment the IANA consideration section of this document.
IANA is requested to implement the following modification to the
General Switch Management Protocol version 3 (GSMPv3) Result Type
Name Space registry:
+--------------+-----------------------+-----------+
| Result Value | Result Type Name | Reference |
+--------------+-----------------------+-----------+
| 0 | Ignore (was Reserved) | RFCXXXX |
+--------------+-----------------------+-----------+
In the registry you are modifying the value 0 is now Reserved. RFC 5226
says:
Reserved: Not to be assigned. Reserved values are held for
special uses, such as to extend the namespace when it become
exhausted. Reserved values are not available for general
assignment.
Therefore it is not permitted to register reserved values. Moreover,
this document says that you shouldn't have mentioned exact values you
want to register - see Section 5.1 of RFC 5226 (the same applies to
another registry modifications, as one might notice).
Next,
IANA is requested to create a new ANCP Port Management Function Name
registry, with the following initial entries. Additions to this
registry will be by IETF Consensus.
You should have here the reference to RFC 5226, shouldn't you? (This
also applies to other registry descriptions)
Values may range from 0 to 255.
[ . . . ]
What is more,
IANA is requested to create a new ANCP Version registry, with
additions by IETF consensus. The initial entries are as follows:
+---------+-------------+--------------+-----------+
| Version | Sub-Version | Name | Reference |
+---------+-------------+--------------+-----------+
| 3 | 1 | Pre-standard | |
| 3 | 2 | ANCPv1 | RFCXXXX |
+---------+-------------+--------------+-----------+
This description is obviously missing the definition of values' format,
or at least key values.
Moreover,
IANA is requested to create a new ANCP Command Code registry, with
additions by IETF Consensus. The initial entry is as follows:
+--------------------+-----------------------------+-----------+
| Command Code Value | Command Code Directive Name | Reference |
+--------------------+-----------------------------+-----------+
| 0 | Reserved | RFCXXXX |
+--------------------+-----------------------------+-----------+
The same as above applies. Moreover, does this registry consists of
only one values, that is reserved and therefore cannot be assigned, per
RFC 5226? This is at least impossible.
Finally,
IANA is requested to create a new ANCP TLV Type registry, with
additions by IETF Consensus. Values may range from 0x0000 to 0xFFFF.
New assignments should be in the range of values from 0x0100 upwards.
The initial entries are as follows:
Here you should have mentioned that values are hexadecimal, for clarity.
Thank you for considering my comments in advance.
All the best,
Mykyta Yevstifeyev
23.02.2011 18:57, The IESG wrote:
The IESG has received a request from the Access Node Control Protocol WG
(ancp) to consider the following document:
- 'Protocol for Access Node Control Mechanism in Broadband Networks'
<draft-ietf-ancp-protocol-15.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2011-03-09. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ancp-protocol/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ancp-protocol/
The following IPR Declarations may be related to this I-D:
/ipr/1124/
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf