Skip to main content

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