Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks
draft-ietf-ancp-framework-13

[Ballot comment]
More minor comments:

Section 3.2 should expand or explain OPEX

I have no idea what an "element management interface" is

Not sure how the shutdown notification requirement is justified

[Ballot discuss]
I entered some DISCUSS text by the telechat where this was discussed, but as I started with a few open questions, unfortunately this is going to have to be updated and I'll have to get feedback to make it fully actionable.

Sometimes requirements discussions are used basically to document consensus decisions that have already been made on a concrete solution.  I'm OK with that; the waterfall model has always been an extremely rough model for design, and collaborative protocol design in particular involves many cycles between refining the requirements and designing the actual solution.


OTOH, if there is not a concrete consensus solution already far along development, then the requirements in this document seem too limiting.  The assumptions about a request/response form, atomicity, adjacency and synchronization all assume a particular solution model.  These requirements, as written, preclude certain kinds of solutions that meet the use cases perfectly well. 

I'm hoping for some expert information on the progress of the work in developing ANCP and what decisions have already been made about an ANCP solution.

[Ballot comment]
Section 3.2 should expand or explain OPEX

I have no idea what an "element management interface" is

Not sure how the shutdown notification requirement is justified

[Ballot discuss]
I'd like to discuss how far along the specific proposals in this space are -- the requirements sound like a specific solution is in mind, particularly assuming adjacency and synchronization rather than other possible models, and requiring a request/response atomic model

[Ballot comment]
Section 3.2 should expand or explain OPEX

I have no idea what an "element management interface" is

Not sure how the shutdown notification requirement is justified

[Ballot discuss]
1. I cannot relate section 2.4 and especially section 2.4.1 with the management requirements as listed in section 6. The purpose of the policy servers mentioned there is confusing and the issue of multiplemanagers is just mentioned, without any solution being discussed as far as I can see.

2. I believe that the keywords in section 6 need to be capitalized.

[Ballot comment]
Nits

Abstract and Section 1
s/OSS systems/Operational Support Systems (OSSes)./

Section 1
Expand ONU, NAS, and OSS on first use.

Section 1.2
Expand RS on first use.

Section 2.1
Expand CPE and HGW somewhere near the figure.

ITU-T G.993.2 should be included as a reference.

[Ballot discuss]
This is a trivial discuss but -- the edit proposed by Pat Cain in his secdir review and
agreed to by the authors does not appear in this draft or an RFC Editor Note.  As Pat noted,
draft-ietf-ancp-security-threats also develops a number of security requirements that are
not reproduced in this framework document.  The security considerations text should alert
readers to their inclusion in draft-ietf-ancp-security-threats.

[Ballot discuss]
Please consider the three reviews that all arrived on 29 June 2009:
  - Gen-ART review by Ben Campbell;
  - TSV Directorate review by Scott Brader; and
  - Security Directorate review by Pat Cain.

  Each of the reviews offers important opporunitites for improvement.
  Taken together, the document should probably be updated prior to
  approval.

[Ballot comment]
* Editorial nit - it's worth a comment as it's either a pretty noticeable typo or I'm pretty confused.

In Figure 1, should the label "Aggreg. Node" actually read "Aggreg. Network"?

* In section 4.1, second bullet list: the sentence
      This MUST allow
      to retrieve statistics and alarms (e.g. via SNMP) about the
is missing some words

* RFC 2119 terminology is not uniformly capitalized; for example, in section 4.2:

  o  The ANCP MUST support providing multicast conditional access
      information to Access Ports on an Access Node, using Black, Grey
      and White lists.

  o  The ANCP MUST support binding a particular Black, Grey and White
      List to a given Access Port.

  o  Upon receiving a join to a multicast flow which matches the Grey
      List the ANCP MUST allow the AN to query the NAS to request an
      admission decision for replicating that multicast flow to a
      particular Access Port.

  o  The ANCP MUST allow the NAS to send an admission decision to the
      AN indicating whether or not a multicast flow may be replicated to
      a particular Access Port.

  o  The ANCP must allow the NAS to indicate to the AN whether or not
      Admission Control is needed for some multicast flows on a given
      Access Port and where needed whether or not the Access Node is
      authorized to perform Admission Control itself (i.e. whether or
      not AN Bandwidth Delegation applies).

  o  In case of Admission Control without AN Bandwidth Delegation, the
      ANCP must allow the NAS to reply to a query from the AN indicating
      whether or not a multicast flow may be replicated to a particular
      Access Port.

  o  In case of Admission Control with AN Bandwidth Delegation, the
      ANCP must allow the NAS to delegate a certain amount of bandwidth
      to the AN for a given Access Port for multicast services only.

* Section 4.7.8: expand acronym "LAC"

Updated proto shepherd doc...



  (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?

Wojciech Dec (wdec@cisco.com).
Yes, I have reviewed the document and I believe it is ready for
forwading 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 received in
depth review from five reviewers nominated by the WG as well as comments
during WG last call.



  (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.


  (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?

The document represents WG consensus and has been reviewed by a good
number of active WG participants. The WG has arrived at a state of
consus regarding the content of this document.


  (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 satisfies all ID nits and uses a pre-5378 boilerplate
because it was originally submitted prior to the change in boilerplate
requirements.
This is an informational framework document and as such it was not
subject to MIB doctor or other detailed technology reviews, but it has
been reviewed by the WG.



  (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. The security considerations
includes a reference to a draft intendeded to progress in parallel,
draft-ietf-ancp-security-threats, that will need to be updated as both
documents get published.



  (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 esists and is consient with the content
of the document. No requests to IANA are required.

  (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

  The Access Node Control Protocol (ANCP) aims to communicate QoS-
  related, service-related and subscriber-related configurations and
  operations between a Network Access Server (NAS) and an Access Node
  (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)).  The
  main goal of this protocol is to allow the NAS to configure, manage
  and control access equipments including the ability for the access
  nodes to report information to the NAS.
  The draft lays down a framework for the protocol. It describes the
use-cases and likely deployment scenarios as well as outlining the
functionality that the protocol will have to provide to support these.
The document is INFORMATIONAL and is a product of the ANCP working
group.

Working Group Summary

The origin of the draft can be traced back to the WT-147 "Layer 2
Control Protocol" document from the Broadband Forum. The WG spent some
time in revising that draft and fine-tuning use-cases and terminology. A
fair bit of WG discussions occurred regarding the scope of the
"multicast control use-cases", and how these relate to a policy system
architecture. In this, debate mainly focused on the bandwidth admission
control functionality aspects of the Access Node and the NAS. So as to
arrive at rough consensus a number of options ended up being described
in the draft.

Document Quality

The document is a protocol framework, with the protocol being specified
in a separate WG draft (draft-ietf-ancp-protocol). The latter has a
number of implementations.

  (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?

Wojciech Dec (wdec@cisco.com).
Yes, I have reviewed the document and I believe it is ready for
forwading 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 received in
depth review from five reviewers nominated by the WG as well as comments
during WG last call.



  (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.


  (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?

The document represents WG consensus and has been reviewed by a good
number of active WG participants. The WG has arrived at a state of
consus regarding the content of this document.


  (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 satisfies all ID nits and uses a pre-5378 boilerplate
because it was originally submitted prior to the change in boilerplate
requirements.
This is an informational framework document and as such it was not
subject to MIB doctor or other detailed technology reviews, but it has
been reviewed by the WG.



  (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. The security considerations
includes a reference to a draft intendeded to progress in parallel,
draft-ietf-ancp-security-threats, that will need to be updated as both
documents get published.



  (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 esists and is consient with the content
of the document. No requests to IANA are required.

  (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:

  The Access Node Control Protocol (ANCP) aims to communicate QoS-
  related, service-related and subscriber-related configurations and
  operations between a Network Access Server (NAS) and an Access Node
  (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)).  The
  main goal of this protocol is to allow the NAS to configure, manage
  and control access equipments including the ability for the access
  nodes to report information to the NAS.

The present document lays down an informational framework for the
protocol to follow. It describes the ANCP use-cases and likely usage
scenarios as well as outlining the functionality that the protocol will
have to provide to support these.

  This document is a product of the ANCP working group.

  This document is INFORMATIONAL.