Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)
RFC 6934

Note: This ballot was opened for revision 02 and is now closed.

(Ralph Droms) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2013-02-19 for -04)
No email
send info
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".

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-02-15 for -04)
No email
send info
- 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?

(Brian Haberman) No Objection

(Russ Housley) No Objection

(Barry Leiba) No Objection

Comment (2012-04-11 for -02)
No email
send info
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?

(Pete Resnick) No Objection

Comment (2012-04-11 for -02)
No email
send info
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.

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2013-03-06)
No email
send info
Thanks for dealing with my discuss.