Subject: Re: Last Call: <draft-ietf-ancp-protocol-15.txt> (Protocol for Access Node Control Mechanism in Broadband Networks) to Proposed Standard

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 23 Feb 2011 20:20:19 +0200

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
> [email-masked] mailing lists by 2011-03-09. Exceptionally, comments may be
> sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>