Forwarding and Control Element Separation (ForCES) Forwarding Element Model

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    forces mailing list <>, 
    forces chair <>
Subject: Protocol Action: 'ForCES Forwarding Element Model' to 
         Proposed Standard 

The IESG has approved the following document:

- 'ForCES Forwarding Element Model '
   <draft-ietf-forces-model-16.txt> as a Proposed Standard

This document is the product of the Forwarding and Control Element 
Separation Working Group. 

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:

Technical Summary

   This document defines the forwarding element (FE) model used in the
   Forwarding and Control Element Separation (ForCES) protocol (see 
   draft-ietf-forces-protocol).  The model represents the capabilities,  
   state and configuration of forwarding elements within the context of
   the ForCES protocol, so that control elements (CEs) can control the
   FEs accordingly.  More specifically, the model describes the logical
   functions that are present in an FE, what capabilities these
   functions support, and how these functions are or can be 
   interconnected.  This FE model is intended to satisfy the model
   requirements specified in the ForCES requirements document, RFC3654.

Working Group Summary

   Good working group consensus. 

Document Quality

   This document is very closely related to the Forces protocol
   (draft-ietf-forces-protocol), which will be submitted for IESG
   review very soon. There are multiple implementations of the 
   Forces protocol underway, and has been some interoperability
   testing. Alia Atlas did a very thorough review of both documents
   (on the request of the routing AD), and Elwyn Davies did a very 
   thorough Gen-Art review. The model has been updated in response
   to both reviews. 


   Jamal Hadi Salim is the Document Shepherd. Ross Callon is the 
   responsible area director. 

RFC Editor Note

    Section 12 (Security Considerations), second sentence, please 
    change reference [2] to instead be reference [7].