Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-17

[Ballot comment]
Thanks for working on my Discuss issues. I believe you have done enough for me to Clear. However, can I suggest that with the new version number scheme you change the Abstract as:

OLD
  ANCP is based on GSMPv3 (RFC 3292), but with many modifications and
  extensions, to the point that the two protocols are not
  interoperable.
NEW
  ANCP is based on GSMPv3 (RFC 3292), but with many modifications and
  extensions, to the point that the two protocols are not
  interoperable and so a new protocol version number is used.
END.

---

In my original Discuss I asked about co-existence. This has been taken to mean "co-existence within the same network" and work has been done in the I-D (thanks) to prevent clashes of protocol version numbers and protect against future versions, etc.

It is still not quite clear to me how an implementation that supported ANCP and GSMP would work out which code component was bound to the port etc. But I suspect this case is unlikely to arise.

[Ballot comment]
[I am taking over this COMMENT from Alexey Melnikov]

5.1.1.  Control Context (Informative)

  Aside from its use in ANCP signalling, access line identification is
  also used in DHCP transactions involving hosts served by DSL.  Either
  the AN or the NAS can serve as a DHCP relay node.  [TR-101] requires
  the AN or NAS in this role to add access line identification in
  Option 82 (Information) to each DHCP request it forwards to the DHCP
  server.  It is desirable for efficiency that the identification used
  in this signalling should be the same as the identification used in
  ANCP messages.

An informative reference to DHCP is needed here.

[Ballot discuss]
The relationship between this specification and RFC 3292 is unclear and confusing.

On the one hand, this document notes that modifies the GSMPv3 adjacency message format, the base GSMPv3 message format, the GSMPv3 Event message format, and the Port Management message format; therefore it appears to update RFC 3292. However, the specification does not indicate that it updates RFC 3292.

On the other hand, this document points implementers to Sections 3.1.1, 9, and 11 of RFC 3292 for aspects of the protocol, thus introducing a normative dependency on parts of RFC 3292 while at the same time it updates other parts; why not simply copy the relevant text to this specification so that all the documentation is in one place, thus enabling us to remove the normative dependency on RFC 3292?

[The rest of this DISCUSS is copied from that of Alexey Melnikov because I am taking over his DISCUSS]

3.1.  Protocol Version

  GSMPv3 messages contain an 8-bit protocol version field.  As
  described below, ANCP subdivides this into two 4-bit sub-fields, for
  version and sub-version.  Implementations of this version of the ANCP
  specification MUST set the version sub-field to 3 and the sub-version
  sub-field to 1.  That is, the hexadecimal representation of the value
  of the complete protocol version field MUST be 0x31.

What is the meaning and semantics of version and subversion? The document is not
clear on why the separation into version and subversion is needed.

3.2.  ANCP Transport

  Identifier:  This 2-byte field identifies a GSMP or ANCP message.
      The type code for GSMP and ANCP messages is 0x880C (i.e., the same
      as GSMP's Ethertype).

Is it wise to reuse the same identifier, considering the statement elsewhere
in the document that the 2 protocols are not really compatible?

  The NAS MUST listen for incoming connections from the Access Nodes.
  Port 6068 is used for TCP connection.

Does this need to be listed in the IANA Considerations section?

4.5.  Status-Info TLV

      Error Message:  Human-readable string providing information about
        the warning or error condition.  Padded with zeroes as
        necessary to extend to a four-byte word boundary.

Typically human readable strings need some language tagging information.
Please
see  for
more details.

8.5.1.  OAM-Loopback-Test-Parameters TLV

        Byte 2: Timeout.  Upper bound on the time in seconds that the
        NAS will wait for a response from the DSLAM.  The value 0 MAY
        be used, but has a special meaning.

What is the special meaning of 0?

10.  Security Considerations

  Security of the ANCP protocol is discussed in [RFC5713].  A number of
  security requirements on ANCP are stated in Section 8 of that
  document.  Those applicable to ANCP itself are listed here:

  o  The protocol solution MUST offer authentication of the AN to the
      NAS.

  o  The protocol solution MUST offer authentication of the NAS to the
      AN.

This section is a bit think on TLS-specific details. In particular it doesn't
describe how these requirements can be achieved with TLS (Note that TLS client
authentication to the TLS server is optional, so not every ciphersuite is
suitable to satisfy these requirements).

[Ballot comment]
RFC EDITOR'S NOTE: please change the value of sub-version in the
  above paragraph to 2 (respectively a version field value of 0x32) in
  the published specification.  For an explanation see the Introduction
  above.

I understand the need to rev this field, but not why it is done via an embedded Editors note

----------

[Ballot comment]
I support the DISCUSSes by Adrian and Alexey concerning the version number and the DISCUSS from Peter concerning the relationship with RFC 3292.

[Ballot discuss]
In section 3.6.1.4:

> In addition to any suggested action in the text which follows, the
  Code value SHOULD be logged in a MIB. 

If I was writing the MIB module and/or the instrumentation for MIB module I would not know what to do, What needs to be logged in a MIB module? (or MIB object? which of these?). The fact that the code value is supported? Each sending of a request? Each receive of a Request? Something else?

[Ballot discuss]
#1) DISCUSS-DISCUSS

I have to admint I'm completely out of my element here:

If ANCP and GSMPv3 do kind of the same thing. Has there been thought to retiring GSMPv3?  Are the two protocols going to gracefully co-exist?

#2) Sec 10 includes security considerations from RFC 5713 with an informative reference.  If these are the security considerations of ANCP aren't they normative?  Unfortunately, RFC 5713 is informative and this would then be a DOWNREF.

[Ballot discuss]
The relationship between this specification and RFC 3292 is unclear and confusing.

On the one hand, this document notes that modifies the GSMPv3 adjacency message format, the base GSMPv3 message format, the GSMPv3 Event message format, and the Port Management message format; therefore it appears to update RFC 3292. However, the specification does not indicate that it updates RFC 3292.

On the other hand, this document points implementers to Sections 3.1.1, 9, and 11 of RFC 3292 for aspects of the protocol, thus introducing a normative dependency on parts of RFC 3292 while at the same time it updates other parts; why not simply copy the relevant text to this specification so that all the documentation is in one place, thus enabling us to remove the normative dependency on RFC 3292?

[Ballot comment]
I found the "must" convention distracting, and am skeptical of it's effectiveness as a way to communicate requirements to another SDO (which is what I understand its purpose to be based on the author's response to the genart review). If this remains in the document, please follow up and ensure it had the desired effect before trying the convention again.

Section 3.6.1.6 speaks of incrementing transaction IDs linearly when I think it's really trying to say "by one". (If there's ever a chance of an intermediary being introduced in the path of these messages, it would help to say something now about whether recipients should care about gaps in the sequence they receive.)

[Ballot discuss]
Allowing ACNP agents to use any Code values from the (about to be modified) GSMPv3 Failure Response Message Name Space registry "if they appear applicable" seems underspecified. Could some guidance about when a code would NOT be applicable be added? Would an exhaustive list of applicability of the codes already registered (in the IETF Consensus ranges) be hard to produce?  I take it from Tom's responses to some of the review comments that you do not expect GSMPv3 focused codes to be added to the registry, but if one ever were added (with a value below 256) that really was targeting GSMP and not ANCP, why not ask the registrant say so and capture it in the registry?

Can the document explain when it might be reasonable to not follow the SHOULD in 3.6.1.7?

[Ballot discuss]
I have two issues related to version numbering that I would like to
Discuss. Additionally, if time permits, I intend to return with a more
in depth review of the protocol

---

I am trying to work out how ANCP will co-exist with GSMP. It seems they
both use the same port (6068) so I assume disambiguation happens on
version number negotiation. But...

A GSMP version number is an 8 bit number, with 0x03 being the current
version. Since the GSMP version number is not currently tracked by IANA,
there is a risk that a future version of GSMP will decide that 0x32
(i.e., version 50) will be used.

I strongly suggest, therefore, that you need a new registry for the
"GSMP and ANCP version Numbers". This will need some careful words to
indicate that GSMP version 4 is allowed. You will also want to track
ANCP sub-versions (but see below).

[This point relates to part of Alexey's Discuss]

---

I am really not happy about the lengths that are being gone to to
support pre-standard implementations. I think this document should at
least state that version 3.1 is not allowed. That is, it should not
allow downward version negotiation from 3.2. Furthermore, sub-version
1 should be shown in the IANA registry as "reserved - not available for
allocation".

Furthermore, I see no reason to require the RFC Editor to make the
various changes you request with respect to the version numbering. You
should make these changes now.

[Ballot comment]
The Gen-ART Review by Ben Campbell on 9-Mar-2011 raised a few minor
  points.  Tom Taylor responded; he seems to agree with some of them. 
  However, the document has not been updated yet.  Please do so before
  approval.

[Ballot discuss]
[Updated: added one more issue in the DISCUSS section (look at the end of it)]

This is a well written document and I don't have objections to its publication. However I would like to discuss the following issues before recommending its approval:

3.1.  Protocol Version

  GSMPv3 messages contain an 8-bit protocol version field.  As
  described below, ANCP subdivides this into two 4-bit sub-fields, for
  version and sub-version.  Implementations of this version of the ANCP
  specification MUST set the version sub-field to 3 and the sub-version
  sub-field to 1.  That is, the hexadecimal representation of the value
  of the complete protocol version field MUST be 0x31.

What is the meaning and semantics of version and subversion? The document is not clear on why the separation into version and subversion is needed.

3.2.  ANCP Transport

  Identifier:  This 2-byte field identifies a GSMP or ANCP message.
      The type code for GSMP and ANCP messages is 0x880C (i.e., the same
      as GSMP's Ethertype).

Is it wise to reuse the same identifier, considering the statement elsewhere
in the document that the 2 protocols are not really compatible?

  The NAS MUST listen for incoming connections from the Access Nodes.
  Port 6068 is used for TCP connection.

Does this need to be listed in the IANA Considerations section?


4.5.  Status-Info TLV

      Error Message:  Human-readable string providing information about
        the warning or error condition.  Padded with zeroes as
        necessary to extend to a four-byte word boundary.

Typically human readable strings need some language tagging information.
Please see  for more details.

8.5.1.  OAM-Loopback-Test-Parameters TLV

        Byte 2: Timeout.  Upper bound on the time in seconds that the
        NAS will wait for a response from the DSLAM.  The value 0 MAY
        be used, but has a special meaning.

What is the special meaning of 0?

10.  Security Considerations

  Security of the ANCP protocol is discussed in [RFC5713].  A number of
  security requirements on ANCP are stated in Section 8 of that
  document.  Those applicable to ANCP itself are listed here:

  o  The protocol solution MUST offer authentication of the AN to the
      NAS.

  o  The protocol solution MUST offer authentication of the NAS to the
      AN.

This section is a bit think on TLS-specific details. In particular it doesn't describe how these requirements can be achieved with TLS (Note that TLS client authentication to the TLS server is optional, so not every ciphersuite is suitable to satisfy these requirements).

[Ballot comment]
5.1.1.  Control Context (Informative)

  Aside from its use in ANCP signalling, access line identification is
  also used in DHCP transactions involving hosts served by DSL.  Either
  the AN or the NAS can serve as a DHCP relay node.  [TR-101] requires
  the AN or NAS in this role to add access line identification in
  Option 82 (Information) to each DHCP request it forwards to the DHCP
  server.  It is desirable for efficiency that the identification used
  in this signalling should be the same as the identification used in
  ANCP messages.

An informative reference to DHCP is needed here.

[Ballot discuss]
This is a well written document and I don't have objections to its publication. However I would like to discuss the following issues before recommending its approval:

3.1.  Protocol Version

  GSMPv3 messages contain an 8-bit protocol version field.  As
  described below, ANCP subdivides this into two 4-bit sub-fields, for
  version and sub-version.  Implementations of this version of the ANCP
  specification MUST set the version sub-field to 3 and the sub-version
  sub-field to 1.  That is, the hexadecimal representation of the value
  of the complete protocol version field MUST be 0x31.

What is the meaning and semantics of version and subversion? The document is not clear on why the separation into version and subversion is needed.

3.2.  ANCP Transport

  Identifier:  This 2-byte field identifies a GSMP or ANCP message.
      The type code for GSMP and ANCP messages is 0x880C (i.e., the same
      as GSMP's Ethertype).

Is it wise to reuse the same identifier, considering the statement elsewhere
in the document that the 2 protocols are not really compatible?

  The NAS MUST listen for incoming connections from the Access Nodes.
  Port 6068 is used for TCP connection.

Does this need to be listed in the IANA Considerations section?


4.5.  Status-Info TLV

      Error Message:  Human-readable string providing information about
        the warning or error condition.  Padded with zeroes as
        necessary to extend to a four-byte word boundary.

Typically human readable strings need some language tagging information.
Please see  for more details.

8.5.1.  OAM-Loopback-Test-Parameters TLV

        Byte 2: Timeout.  Upper bound on the time in seconds that the
        NAS will wait for a response from the DSLAM.  The value 0 MAY
        be used, but has a special meaning.

What is the special meaning of 0?

[Ballot comment]
3.2.  ANCP Transport

  The NAS MUST listen for incoming connections from the Access Nodes.
  Port 6068 is used for TCP connection.

Does this need to be listed in the IANA Considerations section?

4.1.  Provisioning Message

  The Provisioning message is sent by the NAS to the AN to provision
  information of global scope (i.e., not associated with specific
  access lines) on the AN.  The Provisioning message has the format
  shown in Figure 8.  Support of the Provisioning message is OPTIONAL
  unless the ANCP agent claims support for a capability that requires
  its use.

Is any such capability defined?

5.1.1.  Control Context (Informative)

  Aside from its use in ANCP signalling, access line identification is
  also used in DHCP transactions involving hosts served by DSL.  Either
  the AN or the NAS can serve as a DHCP relay node.  [TR-101] requires
  the AN or NAS in this role to add access line identification in
  Option 82 (Information) to each DHCP request it forwards to the DHCP
  server.  It is desirable for efficiency that the identification used
  in this signalling should be the same as the identification used in
  ANCP messages.

An informative reference to DHCP is needed here.

[Ballot discuss]
This is a well written document and I don't have objections to its publication. However I would like to discuss the following issues before recommending its approval:

3.1.  Protocol Version

  GSMPv3 messages contain an 8-bit protocol version field.  As
  described below, ANCP subdivides this into two 4-bit sub-fields, for
  version and sub-version.  Implementations of this version of the ANCP
  specification MUST set the version sub-field to 3 and the sub-version
  sub-field to 1.  That is, the hexadecimal representation of the value
  of the complete protocol version field MUST be 0x31.

What is the meaning and semantics of version and subversion? The document is not clear on why the separation into version and subversion is needed.

3.2.  ANCP Transport

  Identifier:  This 2-byte field identifies a GSMP or ANCP message.
      The type code for GSMP and ANCP messages is 0x880C (i.e., the same
      as GSMP's Ethertype).

Is it wise to reuse the same identifier, considering the statement elsewhere
in the document that the 2 protocols are not really compatible?

4.5.  Status-Info TLV

      Error Message:  Human-readable string providing information about
        the warning or error condition.  Padded with zeroes as
        necessary to extend to a four-byte word boundary.

Typically human readable strings need some language tagging information.
Please see  for more details.

8.5.1.  OAM-Loopback-Test-Parameters TLV

        Byte 2: Timeout.  Upper bound on the time in seconds that the
        NAS will wait for a response from the DSLAM.  The value 0 MAY
        be used, but has a special meaning.

What is the special meaning of 0?

IANA understands that, upon approval of this document, there are nine
IANA Actions that need to be completed.

First, in the GSMPv3 Message Type Name Space registry located at:

http://www.iana.org/assignments/gsmpv3-message

IANA will create a new message category.  The name of the new message
category is: "Access Network Control Protocol (ANCP) Messages".  The
initial values for this new message category are:

+------------------+----------------+--------+-----------+
| Message Name    | Message Number | Status | Reference |
+------------------+----------------+--------+-----------+
| Generic Response | 91            |        | RFC-to-be |  |
| Provisioning    | 93            |        | RFC-to-be |
+------------------+----------------+--------+-----------+

Second, in the Global Switch Management Protocol version 3 (GSMPv3)
Result Type Name Space located at:

http://www.iana.org/assignments/gsmpv3-result/gsmpv3-result.xml

IANA will make a single change to the existing registry.  The
registration for Result Value zero will be changed as follows:

+--------------+-----------------------+-----------+
| Result Value | Result Type Name      | Reference |
+--------------+-----------------------+-----------+
| 0            | Ignore (was Reserved) | RFC-to-be |
+--------------+-----------------------+-----------+

Third, IANA will make a series of modifications to the Global Switch
Management Protocol version 3 (GSMPv3) Failure Response Message Name
Space located at:

http://www.iana.org/assignments/gsmpv3-failure/gsmpv3-failure.xml

The following note will be added to the beginning of the registry:

"This registry is shared with the Access Node Control Protocol (ANCP)
[RFC-to-be].  GSMPv3 [RFC3292] allows values up to a maximum of 255.
ANCP extends this maximum to 4095.  Hence values above 255 are
applicable to ANCP only."

The table of registration procedures will be modified to include the
following line:

+----------+------------------------+---------------+
| Range    | Registration Procedure | Notes        |
+----------+------------------------+---------------+
| 256-4095 | IETF Consensus        | ANCP use only |
+----------+------------------------+---------------+

The registry of failure response messages will be modified so that the
following values are added to the appropriate lines of the registry:

+-------+----------------------------------------------+-----------+
| Value | Failure Response Message Name                | Reference |
+-------+----------------------------------------------+-----------+
| 81    | Request message type not implemented (0x51)  | RFC-to-be |
| 83    | Malformed message (0x53)                    | RFC-to-be |
| 84    | Mandatory TLV missing (0x54)                | RFC-to-be |
| 85    | Invalid value in TLV (0x55)                  | RFC-to-be |
| 1280  | Specified access line does not exist (0x500) | RFC-to-be |
| 1281  | Loopback test timed out (0x501)              | RFC-to-be |
| 1282  | Reserved (0x502)                            | RFC-to-be |
| 1283  | DSL line status showtime (0x503)            | RFC-to-be |
| 1284  | DSL line status idle (0x504)                | RFC-to-be |
| 1285  | DSL line status silent (0x505)              | RFC-to-be |
| 1286  | DSL line status training (0x506)            | RFC-to-be |
| 1287  | DSL line integrity error (0x507)            | RFC-to-be |
| 1288  | DSLAM resource not available (0x508)        | RFC-to-be |
| 1289  | Invalid test parameter (0x509)              | RFC-to-be |
+-------+----------------------------------------------+-----------+

The ranges of unassigned codes at the end of the failure response
message name table will be modified as follows:


+-----------+-------------------------------+-----------+
| Value    | Failure Response Message Name | Reference |
+-----------+-------------------------------+-----------+
| 8-9      | Unassigned                    |          |
| 47-59    | Unassigned                    |          |
| 86-127    | Unassigned                    |          |
| 160-255  | Unassigned                    |          |
| 256-1279  | Unassigned (ANCP use only)    |          |
| 1290-4095 | Unassigned (ANCP use only)    |          |
+-----------+-------------------------------+-----------+

Fourth, a new registry will be created for ANCP Port Management Function
Names. Values in this registry will be managed through IETF Consensus.
Values in the registry may range from 0 to 255 inclusive. 

The registry will include the following note: "Future extensions of ANCP
may need to establish sub-registries of permitted X-Function values for
specific values of Function."

The initial values in this registry are:

+----------------+-----------------------------------+-----------+
| Function Value | Function Name                    | Reference |
+----------------+-----------------------------------+-----------+
| 0              | Reserved                          | RFC-to-be |
| 1-7            | Unassigned                        |          |
| 8              | Configure Connection Service Data | RFC-to-be |
| 9              | Remote Loopback                  | RFC-to-be |
| 10-255        | Unassigned                        |          |
+----------------+-----------------------------------+-----------+

Fifth, a new registry will be created for ANCP Versions.  Values in this
registry will be managed through IETF Consensus.

The initial values in this registry are:

+---------+-------------+--------------+-----------+
| Version | Sub-Version | Name        | Reference |
+---------+-------------+--------------+-----------+
| 3      | 1          | Pre-standard |          |
| 3      | 2          | ANCPv1      | RFC-to-be |
+---------+-------------+--------------+-----------+

Sixth, a new registry will be created for ANCP Technology Types. Values
in this registry will be managed through IETF Consensus.

The initial values in this registry are:

+-----------------+----------------+-----------+
| Tech Type Value | Tech Type Name | Reference |
+-----------------+----------------+-----------+
| 0              | Any technology | RFC-to-be |
| 1              | PON            | RFC-to-be |
| 2-4            | Unassigned    |          |
| 5              | DSL            | RFC-to-be |
| 6-254          | Unassigned    |          |
| 255            | Reserved      | RFC-to-be |
+-----------------+----------------+-----------+

Seventh, a new registry will be created for ANCP Command Codes. Values
in this registry will be managed through IETF Consensus.

The initial values in this registry are::

+--------------------+-----------------------------+-----------+
| Command Code Value | Command Code Directive Name | Reference |
+--------------------+-----------------------------+-----------+
| 0                  | Reserved                    | RFC-to-be |
+--------------------+-----------------------------+-----------+

Eigth, a new registry will be created for ANCP TLV Types. Values may
range from 0x0000 to 0xFFFF.  New assignments should be in the range of
values from 0x0100 upwards. Values in this registry will be managed
through IETF Consensus.

The initial values in thie registry are:

+---------------+--------------------------------------------+-----------+
| Type Code    | TLV Name                                  | Reference |
+---------------+--------------------------------------------+-----------+
| 0x0000        | Reserved                                  | RFC-to-be |
| 0x0001        | Access-Loop-Circuit-ID                    | RFC-to-be |
| 0x0002        | Access-Loop-Remote-Id                      | RFC-to-be |
| 0x0003        | Access-Aggregation-Circuit-ID-ASCII        | RFC-to-be |
| 0x0004        | DSL-Line-Attributes                        | RFC-to-be |
| 0x0005        | Service-Profile-Name                      | RFC-to-be |
| 0x0006        | Access-Aggregation-Circuit-ID-Binary      | RFC-to-be |
| 0x0007        | OAM-Loopback-Test-Parameters              | RFC-to-be |
| 0x0008        | Opaque-Data                                | RFC-to-be |
| 0x0009        | OAM-Loopback-Test-Response-String          | RFC-to-be |
| 0x000a-0x0010 | Unassigned                                |          |
| 0x0011        | Command                                    | RFC-to-be |
| 0x0012-0x0080 | Unassigned                                |          |
| 0x0081        | Actual-Net-Data-Upstream                  | RFC-to-be |
| 0x0082        | Actual-Net-Data-Rate-Downstream            | RFC-to-be |
| 0x0083        | Minimum-Net-Data-Rate-Upstream            | RFC-to-be |
| 0x0084        | Minimum-Net-Data-Rate-Downstream          | RFC-to-be |
| 0x0085        | Attainable-Net-Data-Rate-Upstream          | RFC-to-be |
| 0x0086        | Attainable-Net-Data-Rate-Downstream        | RFC-to-be |
| 0x0087        | Maximum-Net-Data-Rate-Upstream            | RFC-to-be |
| 0x0088        | Maximum-Net-Data-Rate-Downstream          | RFC-to-be |
| 0x0089        | Minimum-Net-Low-Power-Data-Rate-Upstream  | RFC-to-be |
| 0x008A        | Minimum-Net-Low-Power-Data-Rate-Downstrea  | RFC-to-be |
| 0x008B        | Maximum-Interleaving-Delay-Upstream        | RFC-to-be |
| 0x008C        | Actual-Interleaving-Delay-Upstream        | RFC-to-be |
| 0x008D        | Maximum-Interleaving-Delay-Downstream      | RFC-to-be |
| 0x008E        | Actual-Interleaving-Delay-Downstream      | RFC-to-be |
| 0x008F        | DSL-Line-State                            | RFC-to-be |
| 0x0090        | Access-Loop-Encapsulation                  | RFC-to-be |
| 0x0091        | DSL-Type                                  | RFC-to-be |
| 0x092-0x0105  | Unassigned                                |          |
| 0x0106        | Status-Info                                | RFC-to-be |
| 0x0107-0x0FFF | Unassigned                                |          |
| 0x1000        | Target (single access line variant)        | RFC-to-be |
| 0x1001 -      | Reserved for Target variants              | RFC-to-be |
| 0x1020        |                                            |          |
| 0x1021-0xFFFF | Unassigned                                |          |
+---------------+--------------------------------------------+-----------+


Ninth, a new registry will be created for ANCP Capabilities.  Values may
range from 0 to 255.  The specification for a given capability MUST
indicate whether it applies to a specific access technology or applies
to all access technologies.  The specification MUST further indicate
whether the capability is associated with any capability data. Values in
this registry will be managed through IETF Consensus.

Initial values in the new registry will be:

+-------+-------------------+------------+--------------+-----------+
| Value | Capability Type  | Technology | Capability  | Reference |
|      | Name              |            | Data        |          |
+-------+-------------------+------------+--------------+-----------+
| 0    | Reserved          |            |              | RFC-to-be |
| 1    | DSL Topology      | DSL        | None        | RFC-to-be |
|      | Discovery        |            |              |          |
| 2    | DSL Line          | DSL        | None        | RFC-to-be |
|      | Configuration    |            |              |          |
| 3    | Reserved          |            |              | RFC-to-be |
| 4    | DSL Line Testing  | DSL        | None        | RFC-to-be |
| 5-255 | Unassigned        |            |              |          |
+-------+-------------------+------------+--------------+-----------+

IANA understands that these nine actions are all that are required upon
approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Protocol for Access Node Control Mechanism in Broadband Networks) to Proposed Standard


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'
  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@ietf.org mailing lists by 2011-03-09. Exceptionally, comments may be
sent to iesg@ietf.org 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/

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Matthew Bocci (matthew.bocci@alcatel-lucent.com)
Yes, I have reviewed the document and I believe it is ready for
forwarding to the IESG.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, the document has received adequate review. The document
has been developed over long period within the WG and received
extensive review over several years, as well as two WG last calls.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No specific concerns. There is one IPR disclosure, 1124, which is
also claimed to apply to draft-ietf-ancp-framework-08 (now
RFC5851). The IPR disclosure was highlighted during WG last call,
but no concerns were raised.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

I am comfortable that the document represents WG consensus and has
been reviewed by a reasonable number of active WG participants.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

None indicated.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?


The document satisfied ID nits. No further formal reviews are
required.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, the references are split appropriately. There is one reference
to the ANCP framework, that will need to be updated as both documents
should be published together.



(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists and makes appropriate
requests.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no sections that use a formal language.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document describes the Access Node Control Protocol (ANCP).
ANCP operates between a Network Access Server (NAS) and an Access
Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in
a multi-service reference architecture in order to perform QoS-
related, service-related and subscriber-related operations. Use
cases for ANCP are documented in RFC 5851. As well as describing the
base ANCP protocol, this document specifies capabilities for Digital
Subscriber Line (DSL) topology discovery, line configuration, and
remote line connectivity testing. The design of ANCP allows for
protocol extensions in other documents if they are needed to support
other use cases and other access technologies.

ANCP is based on GSMPv3 (RFC 3292), but with many modifications and
extensions, to the point that the two protocols are not
interoperable.

This document is a product of the ANCP working group.

This document is Standards Track.

Working Group Summary

The origin of the working group can be traced back to the WT-147 "Layer 2 Control Protocol"
document from the Broadband Forum. The ANCP protocol developed in the ANCP working group
as a result of that document is typically used in the access and aggregation portions of a broadband
access network, and also in inter-provider
environments. This draft specifies the base protocol for ANCP, which is n itself derived from GSMP.

Document Quality

The document specifies the base protocol for ANCP which has a number of implementations.

Personnel
Who is the Document Shepherd for this document?

Matthew Bocci (matthew.bocci@alcatel-lucent.com)

Who is the Responsible Area Director?
Ralph Droms