Forwarding and Control Element Separation (ForCES) Protocol Specification
draft-ietf-forces-protocol-22
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
22 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
22 | (System) | post-migration administrative database adjustment to the No Objection position for Magnus Westerlund |
2009-03-24
|
22 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-03-24
|
22 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-03-24
|
22 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-03-12
|
22 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-03-03
|
22 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2009-03-03
|
22 | (System) | IANA Action state changed to In Progress |
2009-03-03
|
22 | Amy Vezza | IESG state changed to Approved-announcement sent |
2009-03-03
|
22 | Amy Vezza | IESG has approved the document |
2009-03-03
|
22 | Amy Vezza | Closed "Approve" ballot |
2009-03-03
|
22 | Ross Callon | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ross Callon |
2009-03-03
|
22 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
2009-03-02
|
22 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-03-02
|
22 | (System) | New version available: draft-ietf-forces-protocol-22.txt |
2009-02-19
|
22 | Ross Callon | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Ross Callon |
2009-02-13
|
22 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2009-02-13
|
22 | (System) | Removed from agenda for telechat - 2009-02-12 |
2009-02-12
|
22 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2009-02-12
|
22 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2009-02-12
|
22 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2009-02-12
|
22 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2009-02-12
|
22 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2009-02-12
|
22 | Dan Romascanu | [Ballot comment] I do not opose the approval of this document. I just wonder how this work would have looked like, or even if it … [Ballot comment] I do not opose the approval of this document. I just wonder how this work would have looked like, or even if it would have been chartered as a completely new protocol if NETCONF was available a few years earlier. |
2009-02-12
|
22 | Dan Romascanu | [Ballot comment] I do not opose the approval of this document. I just wonder how this worked would have looked like, or even if it … [Ballot comment] I do not opose the approval of this document. I just wonder how this worked would have looked like, or even if it would have been chartered as a completely new protocol if NETCONF was available a few years earlier. |
2009-02-11
|
22 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Undefined by Cullen Jennings |
2009-02-11
|
22 | Cullen Jennings | [Ballot discuss] |
2009-02-11
|
22 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from Discuss by Cullen Jennings |
2009-02-11
|
22 | Cullen Jennings | [Ballot comment] This now requires the SCTP TML with deals with my discuss - but the SCTP TML is a MUST implement TLS, DTLS, and … [Ballot comment] This now requires the SCTP TML with deals with my discuss - but the SCTP TML is a MUST implement TLS, DTLS, and IPsec. Are you sure the WG really wants all that? I note that this will also end up normatively depending on draft-ietf-tsvwg-dtls-for-sctp which is still a ways from done. The solution here does resolve my discuss, but I suspect it means this document is going to sit in the RFC Ed. Q for a very long time. |
2009-02-11
|
22 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2009-02-10
|
22 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2009-02-04
|
22 | Ross Callon | I am returning this to an upcoming IESG telechat agenda since it has been updated to deal with all existing DISCUSS votes, but still needs … I am returning this to an upcoming IESG telechat agenda since it has been updated to deal with all existing DISCUSS votes, but still needs more votes to pass as a proposed standard. |
2009-02-04
|
22 | Ross Callon | State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Ross Callon |
2009-02-04
|
22 | Ross Callon | Placed on agenda for telechat - 2009-02-12 by Ross Callon |
2009-02-03
|
21 | (System) | New version available: draft-ietf-forces-protocol-21.txt |
2009-02-02
|
22 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-02-02
|
20 | (System) | New version available: draft-ietf-forces-protocol-20.txt |
2008-12-18
|
22 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2008-12-18
|
22 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2008-12-18
|
22 | David Ward | [Ballot Position Update] New position, Abstain, has been recorded by David Ward |
2008-12-18
|
22 | Tim Polk | [Ballot discuss] My concerns are related to Cullen's and Magnus's issues, but with a security area spin: This document does not clearly specify the security … [Ballot discuss] My concerns are related to Cullen's and Magnus's issues, but with a security area spin: This document does not clearly specify the security requirements that need to be supported by every TML. In the absence of those requirements, the document needs to specify a single TML with strong security properties as mandatory to implement. Otherwise, two fully compliant implementations might be interoperable but have no ability to provision security. Alternatively, this document could clearly specify that all TMLs MUST include mandatory to implement mechanism that provide the necessary security services. Note that the SCTP TML specification implies that such mechanisms need to be specified for each TML: > 2. Security > TML provides security services to the ForCES PL. The TML > definition needs to define how the following are achieved: > > * Endpoint authentication of FE and CE > > * Message authentication > > * Confidentiality service Strengthening this text and moving it into the Forces protocol spec or some normative reference seems to be in order. I personally prefer the second solution (establishing requirements for all TMLs) but that does not resolve Cullen's issue. Specifying a mandatory to implement TML with appropriate security properties would resolve both our discusses. (Add in the reliability requirements and you could take care of Magnus' first issue as well.) |
2008-12-18
|
22 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2008-12-18
|
22 | Magnus Westerlund | [Ballot discuss] 1. Section 1: As the reliability requirement is for varying degrees of reliability it seems that some discussion should be had if this … [Ballot discuss] 1. Section 1: As the reliability requirement is for varying degrees of reliability it seems that some discussion should be had if this can be realized by using different TMLs or if a single TML needs to provide all the different degrees of reliability? 2. Section 5: 3. Congestion control The congestion control scheme used needs to be defined. The congestion control mechanism defined by the TML should prevent the FE from being overloaded by the CE or the CE from being overwhelmed by traffic from the FE. Additionally, the circumstances under which notification is sent to the PL to notify it of congestion must be defined. Isn't this split putting to much functionality regarding overload control into the TML rather than having it in the PL? It seems correct to have the TML be responsible for transport congestion avoidance. However, if it is the FORCES nodes themselves that are overloaded rather than the network connecting them duplicating the overload protection mechanism in each TML seems wrong. Are there good reasons for doing overload protection in the TMLS rather than the PL? Looking at http://www.ietf.org/internet-drafts/draft-ietf-forces-sctptml-01.txt it seems that the difference between transport congestion control and overload protection is not correctly considered. To me it seems that one needs to dig much more into the details of how overload prevention and handling affects the priorities and is affected by head of line blocking within the underlying transport. Also with a two layer approach the pushback in overload situations to the PL becomes more complex and needs to be considered. |
2008-12-18
|
22 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
2008-12-17
|
22 | Cullen Jennings | [Ballot discuss] I don't see how one can get interoperability without specifying at least one mandatory to implement TML. Or say something like the CE … [Ballot discuss] I don't see how one can get interoperability without specifying at least one mandatory to implement TML. Or say something like the CE needs to implement A and B and the FE can choose A or B. |
2008-12-17
|
22 | Cullen Jennings | [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings |
2008-12-17
|
22 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2008-12-15
|
22 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2008-11-25
|
22 | Ross Callon | [Ballot Position Update] New position, Yes, has been recorded for Ross Callon |
2008-11-25
|
22 | Ross Callon | Ballot has been issued by Ross Callon |
2008-11-25
|
22 | Ross Callon | Created "Approve" ballot |
2008-11-20
|
22 | Ross Callon | Placed on agenda for telechat - 2008-12-18 by Ross Callon |
2008-11-20
|
22 | Ross Callon | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Ross Callon |
2008-11-18
|
22 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-11-18
|
19 | (System) | New version available: draft-ietf-forces-protocol-19.txt |
2008-11-11
|
22 | Ross Callon | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead::AD Followup by Ross Callon |
2008-10-30
|
18 | (System) | New version available: draft-ietf-forces-protocol-18.txt |
2008-09-26
|
22 | Sam Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Uri Blumenthal. |
2008-09-25
|
17 | (System) | New version available: draft-ietf-forces-protocol-17.txt |
2008-09-16
|
22 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-09-16
|
16 | (System) | New version available: draft-ietf-forces-protocol-16.txt |
2008-09-08
|
22 | Ross Callon | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for Writeup by Ross Callon |
2008-09-08
|
22 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2008-09-08
|
22 | Amanda Baber | IANA Last Call questions and comments: IESG Note: - Expert Assignment required for Action 5. IANA has questions: - In the Message Types registry, are … IANA Last Call questions and comments: IESG Note: - Expert Assignment required for Action 5. IANA has questions: - In the Message Types registry, are the Reserved values (0x00 and 0x07-0x0E) available for registration? - Throughout section 7 the document has lots of result codes for various messages. Should the document create registries for each of these sets of responses in order to add new ones later? E.g.: * 7.3.1.1.2.4. CEHBPolicy * 7.3.1.1.2.6. FEHBPolicy * 7.3.1.1.2.11. CEFailoverPolicy * 7.3.1.1.2.13. FERestartPolicy * 7.5.2. Association Setup Response Message * 7.5.3. Association Teardown Message Action 1 (Section A.1): Upon approval of this document, the IANA will create the registry "Message Types" at http://www.iana.org/assignments/TBD Message Types 0x00 - 0x0F Registration Procedures: IETF Consensus Message Types 0x20 - 0x7F Registration Procedures: Specification Required Message Types 0x80 - 0xFF Reserved for Private Use Initial contents of this registry will be: Value Description Reference ------ -------------------- ----------------- 0x00 Reserved [RFC-forces-protocol-15] 0x01 AssociationSetup [RFC-forces-protocol-15] 0x02 AssociationTeardown [RFC-forces-protocol-15] 0x03 Config [RFC-forces-protocol-15] 0x04 Query [RFC-forces-protocol-15] 0x05 EventNotification [RFC-forces-protocol-15] 0x06 PacketRedirect [RFC-forces-protocol-15] 0x07 - 0x0E Reserved [RFC-forces-protocol-15] 0x0F Hearbeat [RFC-forces-protocol-15] 0x11 AssociationSetupRepsonse [RFC-forces-protocol-15] 0x12 Reserved [RFC-forces-protocol-15] 0x13 ConfigRepsonse [RFC-forces-protocol-15] 0x14 QueryResponse [RFC-forces-protocol-15] 0x15-0xFF Available for assignment [RFC-forces-protocol-15] Action 2 (Section A.2): Upon approval of this document, the IANA will create the registry "Operation Select TLV (OPER-TLV)" at http://www.iana.org/assignments/TBD OPER-TLV Type 0x0000-0x00FF IETF Consensus OPER-TLV Type 0x0100-0x7FFF Specification Required OPER-TLV Type 0x8000-0xFFFF Reserved for Private Use Initial contents of this registry will be: Type Description Reference ------ -------------------- ----------------- 0x0000 Reserved [RFC-forces-protocol-15] 0x0001 SET [RFC-forces-protocol-15] 0x0002 SET-PROP [RFC-forces-protocol-15] 0x0003 SET-RESPONSE [RFC-forces-protocol-15] 0x0004 SET-PROP-RESPONSE [RFC-forces-protocol-15] 0x0005 DEL [RFC-forces-protocol-15] 0x0006 DEL-RESPONSE [RFC-forces-protocol-15] 0x0007 GET [RFC-forces-protocol-15] 0x0008 GET-PROP [RFC-forces-protocol-15] 0x0009 GET-RESPONSE [RFC-forces-protocol-15] 0x000A GET-PROP-RESPONSE [RFC-forces-protocol-15] 0x000B REPORT [RFC-forces-protocol-15] 0x000C COMMIT [RFC-forces-protocol-15] 0x000D COMMIT-RESPONSE [RFC-forces-protocol-15] 0x000E TRCOMP [RFC-forces-protocol-15] 0x000F- 0xFFFF Available for assignment [RFC-forces-protocol-15] Action 3 (Section A.3, Section 6.1): Upon approval of this document, the IANA will create the registry "Header Flags" at http://www.iana.org/assignments/TBD Registration Procedures: IETF Consensus [RFC5226] Initial contents of this registry will be: Flag Description Reference ------ ------------ ---------- 0 ACK-0 [RFC-forces-protocol-15] 1 ACK-1 [RFC-forces-protocol-15] 2 Priority (Pri-0) [RFC-forces-protocol-15] 3 Pri-1 [RFC-forces-protocol-15] 4 Pri-2 [RFC-forces-protocol-15] 5-7 Available for assignment [RFC-forces-protocol-15] 8 Execution Mode (EM-0) [RFC-forces-protocol-15] 9 EM-1 [RFC-forces-protocol-15] 10 Atomic Transaction (AT) [RFC-forces-protocol-15] 11 Transaction Phase (TP-0) [RFC-forces-protocol-15] 12 TP-1 [RFC-forces-protocol-15] 13-31 Available for assignment [RFC-forces-protocol-15] Action 4 (Section A.4): Upon approval of this document, the IANA will create the registry "TLV Type Name Space" at http://www.iana.org/assignments/TBD TLV Type 0x0000-0x00FF IETF Consensus TLV Type 0x0200-0x7FFF Specification Required TLV Type 0x8000-0xFFFF Reserved for Private Use Initial contents of this registry will be: Type Description Reference ------ -------------------- ----------------- 0x0000 Reserved [RFC-forces-protocol-15] 0x0001 REDIRECT-TLV [RFC-forces-protocol-15] 0x0002- 0x000F Available for assignment [RFC-forces-protocol-15] 0x0010 ASResult-TLV [RFC-forces-protocol-15] 0x0011 ASTreason-TLV [RFC-forces-protocol-15] 0x0012 - 0x010F Available for assignment [RFC-forces-protocol-15] 0x0110 PATH-DATA-TLV [RFC-forces-protocol-15] 0x0111 KEYINFO-TLV [RFC-forces-protocol-15] 0x0112 FULLDATA-TLV [RFC-forces-protocol-15] 0x0113 SPARSEDATA-TLV [RFC-forces-protocol-15] 0x0114 RESULT-TLV [RFC-forces-protocol-15] 0x0115 METADATA-TLV [RFC-forces-protocol-15] 0x0116 REDIRECTDATA-TLV [RFC-forces-protocol-15] 0x0117 - 0x0FFF Available for assignment [RFC-forces-protocol-15] 0x1000 LFBselect-TLV [RFC-forces-protocol-15] 0x1001 - 0xFFFF Available for assignment [RFC-forces-protocol-15] Action 5 (Section A.5): [ IESG Note: Expert Assignment Required ] Upon approval of this document, the IANA will create the registry "Result-TLV Result Values" at http://www.iana.org/assignments/TBD Registration Procedure: Expert review Initial contents of this registry will be: Result Description Reference ------ -------------------- ----------------- 0x00 E_SUCCESS [RFC-forces-protocol-15] 0x01 E_INVALID_HEADER [RFC-forces-protocol-15] 0x02 E_LENGTH_MISMATCH [RFC-forces-protocol-15] 0x03 E_VERSION_MISMATCH [RFC-forces-protocol-15] 0x04 E_INVALID_DESTINATION_PID [RFC-forces-protocol-15] 0x05 E_LFB_UNKNOWN [RFC-forces-protocol-15] 0x06 E_LFB_NOT_FOUND [RFC-forces-protocol-15] 0x07 E_LFB_INSTANCE_ID_NOT_FOUND [RFC-forces-protocol-15] 0x08 E_INVALID_PATH [RFC-forces-protocol-15] 0x09 E_COMPONENT_DOES_NOT_EXIST [RFC-forces-protocol-15] 0x0A E_EXISTS [RFC-forces-protocol-15] 0x0B E_NOT_FOUND [RFC-forces-protocol-15] 0x0C E_READ_ONLY [RFC-forces-protocol-15] 0x0D E_INVALID_ARRAY_CREATION [RFC-forces-protocol-15] 0x0E E_VALUE_OUT_OF_RANGE [RFC-forces-protocol-15] 0x0F E_CONTENTS_TOO_LONG [RFC-forces-protocol-15] 0x10 E_INVALID_PARAMETERS [RFC-forces-protocol-15] 0x11 E_INVALID_MESSAGE_TYPE [RFC-forces-protocol-15] 0x12 E_E_INVALID_FLAGS [RFC-forces-protocol-15] 0x13 E_INVALID_TLV [RFC-forces-protocol-15] 0x14 E_EVENT_ERROR [RFC-forces-protocol-15] 0x15 E_NOT_SUPPORTED [RFC-forces-protocol-15] 0x16 E_MEMORY_ERROR [RFC-forces-protocol-15] 0x17 E_INTERNAL_ERROR [RFC-forces-protocol-15] 0x18-0xFE Available for assignment [RFC-forces-protocol-15] 0xFF E_UNSPECIFIED_ERROR [RFC-forces-protocol-15] Action 6 (Section A.6): Upon approval of this document, the IANA will create the registry "Association Setup Response" at http://www.iana.org/assignments/TBD Association Setup Response 0x0000-0x00FF IETF Consensus Association Setup Response 0x0100-0x0FFF Specification Required Association Setup Response 0x1000-0xFFFFFFFFF Reserved for Private Use Initial contents of this registry will be: Code Description Reference ----- --------------- ------------- 0x0000 Success [RFC-forces-protocol-15] 0x0001 FE ID Invalid [RFC-forces-protocol-15] 0x0002 Permission Denied [RFC-forces-protocol-15] 0x0003 - 0x0FFF Available for Assignment [RFC-forces-protocol-15] Action 7 (Section A.7): Upon approval of this document, the IANA will create the registry "Association Teardown Message" at http://www.iana.org/assignments/TBD Association Teardown Message 0x00000000-0x0000FFFF IETF Consensus Association Teardown Message 0x00010000-0x7FFFFFFF Specification Required Association Teardown Message 0x80000000-0xFFFFFFFFF Reserved for Private Use Initial contents of this registry will be: Message Code Description Reference ----------- ------------------- -------------- 0x00000000 Normal - Teardown by Administrator [RFC-forces-protocol-15] 0x00000001 Error - loss of heartbeats [RFC-forces-protocol-15] 0x00000002 Error - loss of bandwidth [RFC-forces-protocol-15] 0x00000003 Error - Out of Memory [RFC-forces-protocol-15] 0x00000004 Error - Application Crash [RFC-forces-protocol-15] 0x00000005 - 0x000000FE Available for Assignment [RFC-forces-protocol-15] 0x000000FF Error - Unspecified [RFC-forces-protocol-15] 0x00000100 - 0x7FFFFFFF Available for Assignment [RFC-forces-protocol-15] We understand the above to be the only IANA Actions for this document. |
2008-09-05
|
22 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Uri Blumenthal |
2008-09-05
|
22 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Uri Blumenthal |
2008-08-25
|
22 | Amy Vezza | Last call sent |
2008-08-25
|
22 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-08-25
|
22 | Ross Callon | Removed from agenda for telechat - 2008-09-25 by Ross Callon |
2008-08-25
|
22 | Ross Callon | Last Call was requested by Ross Callon |
2008-08-25
|
22 | Ross Callon | State Changes to Last Call Requested from IESG Evaluation by Ross Callon |
2008-08-25
|
22 | (System) | Ballot writeup text was added |
2008-08-25
|
22 | (System) | Last call text was added |
2008-08-25
|
22 | (System) | Ballot approval text was added |
2008-08-25
|
22 | Ross Callon | Placed on agenda for telechat - 2008-09-25 by Ross Callon |
2008-08-25
|
22 | Ross Callon | State Changes to IESG Evaluation from AD Evaluation::External Party by Ross Callon |
2008-08-25
|
15 | (System) | New version available: draft-ietf-forces-protocol-15.txt |
2008-04-10
|
22 | Ross Callon | State Changes to AD Evaluation::External Party from Waiting for AD Go-Ahead::External Party by Ross Callon |
2008-03-12
|
14 | (System) | New version available: draft-ietf-forces-protocol-14.txt |
2007-12-04
|
13 | (System) | New version available: draft-ietf-forces-protocol-13.txt |
2007-11-18
|
12 | (System) | New version available: draft-ietf-forces-protocol-12.txt |
2007-09-13
|
22 | Ross Callon | State Changes to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead by Ross Callon |
2007-07-10
|
11 | (System) | New version available: draft-ietf-forces-protocol-11.txt |
2007-06-04
|
22 | Ross Callon | State Changes to Waiting for AD Go-Ahead from Waiting for AD Go-Ahead::AD Followup by Ross Callon |
2007-06-04
|
22 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-06-04
|
10 | (System) | New version available: draft-ietf-forces-protocol-10.txt |
2007-05-15
|
22 | Ross Callon | I put this into "waiting for AD go ahead" since this is waiting for the ForCES Forwarding Element Model draft (to which it quite appropriately … I put this into "waiting for AD go ahead" since this is waiting for the ForCES Forwarding Element Model draft (to which it quite appropriately has a normative reference). My understanding is that the Forces FE Model is currently in progress and should be available relatively soon. |
2007-05-15
|
22 | Ross Callon | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for Writeup by Ross Callon |
2007-05-15
|
22 | Ross Callon | State Changes to Waiting for Writeup from AD Evaluation::Revised ID Needed by Ross Callon |
2007-04-30
|
22 | Ross Callon | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Ross Callon |
2007-03-05
|
22 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-03-05
|
09 | (System) | New version available: draft-ietf-forces-protocol-09.txt |
2007-02-01
|
22 | Ross Callon | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::External Party by Ross Callon |
2006-07-26
|
22 | Ross Callon | State Changes to AD Evaluation::External Party from Publication Requested by Ross Callon |
2006-05-05
|
22 | Dinara Suleymanova | PROTO Write-up 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready … PROTO Write-up 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Which chair is the WG Chair Shepherd for this document? Yes, the chairs have reviewed this draft and believe it is ready to forward to the IESG for publication. Both chairs will shepherd the document. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? This document has been fully reviewed by all key WG members and was reviewed for the routing directorate by Sue Hares. No concerns. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, internationalization, XML, etc.)? The membership of the ForCES WG includes a sufficiently broad range of expertise that many of these areas have been reasonably looked at. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. There are no specific areas of serious concern with this document. There is a normative dependency which will keep this draft in the RFC editor's queue pending publication on the ForCES Model draft, which we expect to submit to the IESG shortly. 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? This document is the result of a merger of several proposals from competing design teams and represents a good WG consensus. Many individuals with varying interests provided feedback into this draft. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email to the Responsible Area Director. (It should be separate email because this questionnaire will be entered into the tracker). There are no known threats of appeal or extreme discontent at this time. Technical discussions did become rather passionate while this draft was still in process. 1.g) Have the chairs verified that the document checks out against all the ID nits? (see http://www.ietf.org/ID-Checklist.html). Boilerplate checks are not enough; this check needs to be thorough. This document has been checked against the ID-nits. 1.h) Has the document split its references into normative and informative? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? The RFC Editor will not publish an RFC with normative references to IDs (will delay the publication until all such IDs are also ready for RFC publication). If the normative references are behind, what is the strategy for their completion? On a related matter, are there normative references that are downward references, as described in BCP 97, RFC 3967 RFC 3967 [RFC3967]? Listing these supports the Area Director in the Last Call downref procedure specified in RFC 3967. The references are split up. There is one normative reference to an ID (FE-MODEL), which is a companion document that specifies a model that the protocol used in this document "carries" over the wire. It is expected that the FE-MODEL document will be entering IETF last call soon and until it completes it, this document will remain at the last stage of the RFC editor queue. 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary This document specifies the Forwarding and Control Element Separation (ForCES) protocol. ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC3654. Besides the ForCES protocol messages, the specification also defines the framework, the mechanisms, and the Transport Mapping Layer (TML) requirements for ForCES protocol. * Working Group Summary This document derives from three different protocol proposals from different design teams that participated in the ForCES working group. Representatives from each of the design teams agreed to a merged proposal that became this draft. There is good consensus about most of the draft. There was significant contention within the merged design team that drove the draft through several iterations, but at this time there are no significant open objections. * Protocol Quality + Are there existing implementations of the protocol? There are at least four different implementations of this protocol (Znyx, Intel CP-PDK, ZJGSU, and by the University of Patras in Greece). + Have a significant number of vendors indicated they plan to implement the specification? Several vendors have indicated interest but there are no products announced using this protocol at this time. + Are there any reviewers that merit special mention as having done a thorough review (i.e., that resulted in important changes or a conclusion that the document had no substantive issues)? Sue Hares reviewed this document for the routing directorate and provided feedback that was incorporated into the draft. |
2006-04-07
|
22 | Ross Callon | Waiting for working group chair's PROTO writeup |
2006-04-07
|
22 | Ross Callon | Draft Added by Ross Callon in state Publication Requested |
2006-03-24
|
08 | (System) | New version available: draft-ietf-forces-protocol-08.txt |
2006-03-06
|
07 | (System) | New version available: draft-ietf-forces-protocol-07.txt |
2005-12-13
|
06 | (System) | New version available: draft-ietf-forces-protocol-06.txt |
2005-10-26
|
05 | (System) | New version available: draft-ietf-forces-protocol-05.txt |
2005-07-19
|
04 | (System) | New version available: draft-ietf-forces-protocol-04.txt |
2005-06-07
|
03 | (System) | New version available: draft-ietf-forces-protocol-03.txt |
2005-02-22
|
02 | (System) | New version available: draft-ietf-forces-protocol-02.txt |
2004-10-26
|
01 | (System) | New version available: draft-ietf-forces-protocol-01.txt |
2004-09-30
|
00 | (System) | New version available: draft-ietf-forces-protocol-00.txt |