Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)
draft-ietf-ancp-pon-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-06-14
|
05 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-04-22
|
05 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-04-15
|
05 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-03-08
|
05 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2013-03-08
|
05 | (System) | RFC Editor state changed to EDIT |
2013-03-08
|
05 | (System) | Announcement was received by RFC Editor |
2013-03-07
|
05 | (System) | IANA Action state changed to No IC |
2013-03-07
|
05 | Amy Vezza | State changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2013-03-07
|
05 | Amy Vezza | IESG has approved the document |
2013-03-07
|
05 | Amy Vezza | Closed "Approve" ballot |
2013-03-07
|
05 | Amy Vezza | Ballot approval text was generated |
2013-03-07
|
05 | Amy Vezza | Ballot writeup was changed |
2013-03-06
|
05 | Sean Turner | [Ballot comment] Thanks for dealing with my discuss. |
2013-03-06
|
05 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2013-02-24
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-02-24
|
05 | Nabil Bitar | New version available: draft-ietf-ancp-pon-05.txt |
2013-02-21
|
04 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead |
2013-02-20
|
04 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2013-02-20
|
04 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-02-20
|
04 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-02-19
|
04 | Adrian Farrel | [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 … [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". |
2013-02-19
|
04 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2013-02-19
|
04 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-02-19
|
04 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-02-15
|
04 | Pearl Liang | 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 … 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. |
2013-02-15
|
04 | Stephen Farrell | [Ballot comment] - I agree with Sean's discuss. - Perhaps expand PON in the abstract. - section 3, 1st para: " Encryption is used on … [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? |
2013-02-15
|
04 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2013-02-13
|
04 | Martin Stiemerling | Request for Early review by TSVDIR Completed: Ready. Reviewer: Allison Mankin. |
2013-02-05
|
04 | Amy Vezza | 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 … 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/ |
2013-02-05
|
04 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-02-05
|
04 | Amy Vezza | Last call announcement was generated |
2013-02-05
|
04 | Ralph Droms | Telechat date has been changed to 2013-02-21 from 2012-04-12 |
2013-02-05
|
04 | Ralph Droms | Last call was requested |
2013-02-05
|
04 | Ralph Droms | State changed to Last Call Requested from AD Evaluation::AD Followup |
2013-02-05
|
04 | Ralph Droms | Ballot writeup was changed |
2013-01-21
|
04 | Matthew Bocci | IETF state changed to Submitted to IESG for Publication from In WG Last Call |
2013-01-21
|
04 | Matthew Bocci | Annotation tag Doc Shepherd Follow-up Underway cleared. |
2013-01-21
|
04 | Matthew Bocci | Annotation tag Doc Shepherd Follow-up Underway set. |
2013-01-21
|
04 | Matthew Bocci | Changed protocol writeup |
2012-12-19
|
04 | Nabil Bitar | New version available: draft-ietf-ancp-pon-04.txt |
2012-08-28
|
03 | Matthew Bocci | IETF state changed to In WG Last Call from Submitted to IESG for Publication |
2012-08-28
|
03 | Matthew Bocci | Annotation tag Other - see Comment Log set. |
2012-07-16
|
03 | Matthew Bocci | Second last call due to IPR declaration. |
2012-07-16
|
03 | Matthew Bocci | Second last call due to IPR declaration. |
2012-07-16
|
03 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-07-16
|
03 | Stephanie McCammon | New version available: draft-ietf-ancp-pon-03.txt |
2012-05-21
|
02 | Ralph Droms | Last call announcement was generated |
2012-05-14
|
02 | Ralph Droms | 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, … 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. |
2012-04-13
|
02 | Ralph Droms | State changed to AD Evaluation::Revised ID Needed from IESG Evaluation::AD Followup |
2012-04-12
|
02 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2012-04-12
|
02 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-04-11
|
02 | Pete Resnick | [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 … [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. |
2012-04-11
|
02 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-04-11
|
02 | Sean Turner | [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 … [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. |
2012-04-11
|
02 | Sean Turner | [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 … [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. |
2012-04-11
|
02 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2012-04-11
|
02 | Barry Leiba | [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 … [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? |
2012-04-11
|
02 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-04-11
|
02 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-04-11
|
02 | Stephen Farrell | [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 … [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? |
2012-04-11
|
02 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2012-04-09
|
02 | Roni Even | Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. |
2012-04-09
|
02 | Roni Even | Request for Last Call review by GENART Completed. Reviewer: Roni Even. |
2012-04-09
|
02 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-04-09
|
02 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-04-09
|
02 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-04-06
|
02 | Ralph Droms | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-04-06
|
02 | Adrian Farrel | [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 … [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! |
2012-04-06
|
02 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-03-30
|
02 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
2012-03-30
|
02 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-03-27
|
(System) | Posted related IPR disclosure: Deutsche Telekom AG's Statement about IPR related to draft-ietf-ancp-pon-02 | |
2012-03-22
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2012-03-22
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2012-03-21
|
02 | Martin Stiemerling | Request for Early review by TSVDIR is assigned to Allison Mankin |
2012-03-21
|
02 | Martin Stiemerling | Request for Early review by TSVDIR is assigned to Allison Mankin |
2012-03-20
|
02 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Rob Austein |
2012-03-20
|
02 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Rob Austein |
2012-03-16
|
02 | Ralph Droms | Placed on agenda for telechat - 2012-04-12 |
2012-03-16
|
02 | Ralph Droms | Ballot has been issued |
2012-03-16
|
02 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2012-03-16
|
02 | Ralph Droms | Created "Approve" ballot |
2012-03-16
|
02 | Amy Vezza | Last call sent |
2012-03-16
|
02 | Amy Vezza | 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: … 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. |
2012-03-16
|
02 | Ralph Droms | Last call was requested |
2012-03-16
|
02 | Ralph Droms | Ballot approval text was generated |
2012-03-16
|
02 | Ralph Droms | State changed to Last Call Requested from AD Evaluation |
2012-03-16
|
02 | Ralph Droms | Last call announcement was changed |
2012-03-16
|
02 | Ralph Droms | Last call announcement was generated |
2012-03-16
|
02 | Ralph Droms | Ballot writeup was changed |
2012-03-16
|
02 | Ralph Droms | Ballot writeup was changed |
2012-03-16
|
02 | Ralph Droms | Ballot writeup was generated |
2012-03-16
|
02 | Ralph Droms | State changed to AD Evaluation from Publication Requested |
2012-03-15
|
02 | Matthew Bocci | IETF state changed to Submitted to IESG for Publication from WG Document |
2012-03-15
|
02 | Matthew Bocci | Publication requested following WG last call. |
2012-03-15
|
02 | Matthew Bocci | Changed shepherd to Matthew Bocci |
2012-03-14
|
02 | Amy Vezza | 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, … 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. |
2012-03-14
|
02 | Amy Vezza | Note added 'Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.' |
2012-03-14
|
02 | Amy Vezza | Intended Status changed to Informational |
2012-03-14
|
02 | Amy Vezza | IESG process started in state Publication Requested |
2012-01-17
|
02 | (System) | New version available: draft-ietf-ancp-pon-02.txt |
2012-01-12
|
02 | (System) | Document has expired |
2011-07-11
|
01 | (System) | New version available: draft-ietf-ancp-pon-01.txt |
2010-10-18
|
00 | (System) | New version available: draft-ietf-ancp-pon-00.txt |