Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)
draft-ietf-ancp-pon-05

[Ballot comment]
Thanks for fixing the Comments from my previous review. Looking at this version I found one thing that you might think about...

In Section 12

    Sharing
    the same IP address between VoIP and ANCP may have other network
    implications on traffic routing.

I can well imagine! But don't you think the I-D should make some more
comments about those "other implications".

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ancp-pon-04, which is currently in Last
Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.

[Ballot comment]

- I agree with Sean's discuss.

- Perhaps expand PON in the abstract.

- section 3, 1st para: " Encryption is used on the PON to
prevent eavesdropping." I wondered about details. Maybe a
reference would be good.

- 4.2.1, says: "It should be noted that some applications are
expected to require extensions. Such extensions are expected
to be outside of ANCP scope, and may need to be defined by the
ITU-T." Extensions to what? ANCP or OMCI or both? The 2nd
sentence is also odd since the ANCP WG will cease to exist so
did you mean the IETF really?

- 4.2.1, what's "UNI"?

- p18, Aren't you missing a reference for IGMP? (Is RFC 3376
correct for that?)

- p18, "IGMP snooping": I'm not sure if there are any relevant
confidentiality mechansims for IGMP, but if there were, then
turning those on would presumably muck up the snooping you'd
like to do. Are there or is AH the only security option for
IGMP?

- p20, Isn't there a possible privacy issue with storage or
logging of channel selections/video-conferencing with
multi-cast joins? If a bad actor could get access to logs
recording that then that could be bad. I'd say that's worth
noting as a security consideration if its not elsewhere in
some other ANCP document.

- p33, what's GWR?

- p35, what's OSS here?

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Applicability of Access Node Control Mechanism to PON based Broadband Networks) to Informational RFC


The IESG has received a request from the Access Node Control Protocol WG
(ancp) to consider the following document:
- 'Applicability of Access Node Control Mechanism to PON based Broadband
  Networks'
  as Informational RFC

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 2013-02-19. 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.

Abstract


    The purpose of this document is to provide applicability of the
    Access Node Control mechanism to PON-based broadband access. The
    need for an Access Node Control mechanism between a Network
    Access Server (NAS) and an Access Node Complex (a combination of
    Optical Line Termination (OLT) and Optical Network Termination
    (ONT) elements) is described in a multi-service reference
    architecture in order to perform QoS-related, service-related and
    Subscriber-related operations. The Access Node Control mechanism
    is also extended for interaction between components of the Access
    Node Complex (OLT and ONT). The Access Node Control mechanism
    will ensure that the transmission of information between the NAS
    and Access Node Complex (ANX) and between the OLT and ONT within
    an ANX does not need to go through distinct element managers but
    rather uses a direct device-to-device communication and stays on
    net. This allows for performing access link related operations
    within those network elements to meet performance objectives.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1734/

There was a late IPR declaration, #1734, on this document just after the IETF last call completed.  Along with resolving a couple of Discuss positions, this document will need to be reconsidered by the ancp WG and then go through another IETF last call.

[Ballot comment]
I agree with Adrian's comment: 2119 language is unnecessary in this document and should be removed.

I also agree with regard to Stephen's DISCUSS; this must be re-last-called with a pointer to the IPR disclosure.

I must say that I'm of two minds about this document, neither of them good. On the one hand, the document seems to be applying ANCP to a particular technology (in this case PON), and I therefore don't understand why it isn't going for Standards Track. On the other hand, from up here in the nosebleed section of the layers, the entirety of this document looks like it is either all layer 2 stuff or is a big giant walking layer violation. I really don't understand why the IETF is devoting WG time to working on technology like this. I was sorely tempted to simply Abstain on this document. I don't see what it adds to our document series. Perhaps someone can explain.

[Ballot discuss]
1) It's entirely possible this is somewhere in the other ancp specs and I missed it.  The draft claims:

Fundamental to leveraging the broadcast capability on the PON for
multicast delivery is the ability to assign a single encryption key
for all PON frames carrying all multicast channels or a key per set
of multicast channels that correspond to service packages, or none.

Is this referring to the key used for IPsec/IKEv2 as required by RFC 6320?  How are you distributing the keys to everybody?  It seems (to my untrained eye) like stream access in ancp is done through a join request and white/grey/black list checking not based on any kind of key material.

[Ballot comment]
s11: Maybe strike the first used and add protocol after signalling in the following:

Here an appropriate mechanism to protect the used signalling
needs to be used.

NEW:

Here an appropriate mechanism to protect the signalling protocol
needs to be used.

[Ballot comment]
I second Stephen's DISCUSS: Thomas Haag is both an editor on the document and an inventor on the disclosed patent.

Also:
The ToC and the section numbers appear to be confused: Section 9, Security Considerations, on page 31, comes after section 10, Access Loop Configuration.  There's another Section 10 following it, and neither of those sections are in the ToC.  Also, Section 13, Acknowledgments, is empty... that's OK if it's right, but is there really no one you want to acknowledge here?

[Ballot discuss]

The IETF LC announcement appears to have been missing the IPR
declaration, which is RAND with possibly fee, and was only filed on
March 27th 3 days before the end of IETF LC.  I think this one has
to go around the loop again, or am I missing something?

[Ballot comment]
Please don't include citations in the Abstract.

---

I found just one use of RFC 2119 langauge in this document. I suggest
fixing it to lower case and removing Section 1.

---

It would be nice to havesome citations in the Introduction and
Terminology sections.

---

I was slightly confused as to whether this is intended as an
applicablity statement (how you use SNCP for PON) or the definition
of the extension of ANCP to PON (see Section 4). It might be nice
to harmonize the language across the document.

---

You are to be commended for your skill with ASCII-art. I will use your
document as evidence that no other graphics tools are needed!

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:  (Applicability of Access Node Control Mechanism to PON based Broadband Networks) to Informational RFC





The IESG has received a request from the Access Node Control Protocol WG

(ancp) to consider the following document:

- 'Applicability of Access Node Control Mechanism to PON based Broadband

  Networks'

  as an Informational RFC



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 2012-03-30. 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.



Abstract





    The purpose of this document is to provide applicability of the

    Access Node Control Mechanism, as described in [RFC5851],

    to PON based broadband access. The need for an Access Node Control

    Mechanism between a Network Access Server (NAS) and an Access Node

    Complex (a combination of Optical Line Termination (OLT) and

    Optical Network Termination (ONT) elements) is described in a

    multi-service reference architecture in order to perform QoS-

    related, service-related and Subscriber-related operations. The

    Access Node Control Mechanism is also extended for interaction

    between components of the Access Node Complex (OLT and ONT). The

    Access Node Control mechanism will ensure that the transmission of

    information between the NAS and Access Node Complex (ANX) and

    between the OLT and ONT within an ANX does not need to go through

    distinct element managers but rather uses a direct device-to-

    device communication and stays on net. This allows for performing

    access link related operations within those network elements to

    meet performance objectives. 









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/ballot/





No IPR declarations have been submitted directly on this I-D.

draft-ietf-ancp-pon-02.txt

Document Shepard Write-Up


(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 wihtin the WG and reviewed over a period of a number
of IETFs.


(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 are no IPR disclosures.


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

Yes.

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



(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. There are no requests
for IANA allocatons.


(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 purpose of this document is to provide applicability of the
Access Node Control Mechanism, as described in [RFC5851],
to PON based broadband access. The need for an Access Node Control
Mechanism between a Network Access Server (NAS) and an Access Node
Complex (a combination of Optical Line Termination (OLT) and
Optical Network Termination (ONT) elements) is described in a
multi-service reference architecture in order to perform QoS-
related, service-related and Subscriber-related operations. The
Access Node Control Mechanism is also extended for interaction
between components of the Access Node Complex (OLT and ONT).

This document is a product of the ANCP working group.

This document is Informational.

Working Group Summary

The ANCP working group was originally chartered only to cover DSL access
technologies. It's application to PON was only added as a result of this
draft being introduced. However, there were no issues with reaching consensus
for this change and, indeed, there was significant support within the working
group.

Document Quality

The document describes the application of an existing technology (ANCP) to
a new access technology type (PON). ANCP is deployed for DSL access networks
today, but is sufficiently generic and extensible to be applicable to other
access technologies. I do not know of deployments of ANCP for PON.
I have no other concerns about the quality of the document.