1) WG status & Agenda Bash, Robert Haas
slides: http://www3.ietf.org/proceedings/06nov/slides/forces-0.ppt

- Protocol and MIB drafts under AD review. Ross Callon to complete
reviews by year end. Avri to incorporate changes.
- Model draft will have another LC once changes are incorporated.
- TCP-based TML ready for LC.
- TML Service Primitives draft ready LC once changes are incorporated.


2) A Framework Adapting Traditional Router to ForCES-based Architecture.
Huaiyuan, Ma (Michael)
http://www.ietf.org/internet-drafts/draft-ma-forces-proxy-framework-00.txt
slides: http://www3.ietf.org/proceedings/06nov/slides/forces-3.ppt

The draft addresses two main issues to allow the evolution from
traditional routers towards ForCES-compatible routers:
a) Ensuring interoperability between FEs with different forwarding
models by introducing an FE Adapter. Comment from Joel: the fact that
different forwarding models are used by the FEs is irrelevant: it is the
Fi interface that is out of scope of the standardization effort and for
which an FE Adapter could be needed. This would allows FEs from
different vendors to interoperate by interpreting the metadata that is
passed along with the packet.
b) Control of legacy FEs that do not support ForCES by using an FE
Proxy. Comment from Joel: The FE Proxy is not distinguishable from an FE
from the ForCES-protocol perspective.
Comment by Robert: the draft shows how FE Proxies can be used in a
traditional router to make it ForCES compatible, while remaining
transparent to the ForCES protocol. Moreover, as the Fi interface is not
 subject to standardization, the FE Adapter is out of the scope of the
standardization.


3) ForCES Model, Joel Halpern
http://www.ietf.org/internet-drafts/draft-ietf-forces-model-07.txt
(no slides available)
Credits also to Ellen for editing. The last call uncovered
inconsistencies in the terminology: clash between XML attributes and LFB
attributes, clash between XML elements and LFB elements (encompasses
capabilities, capacities, attributes). More comments are welcome.


4) TML Service Primitives (Weiming Wang) presented by Robert Haas.
http://www.ietf.org/internet-drafts/draft-ietf-forces-tcptml-04.txt
slides: http://www3.ietf.org/proceedings/06nov/slides/forces-1.ppt

Discussion of the open issues:
a) TML errors and congestion alerts, and possibly stats.
Comment by Joel: Should first determine if such information should be
reflected in an LFB or if it is only useful locally (between the TML and
PL). For instance, taking the example of congestion notification, this
can be done as follows:
- the TML locally notifies the PL about congestion it observes on the
communication channel, and that's all, or:
- in addition, the TML changes an attribute in an LFB that in turn
generates a ForCES event notification from FE to CE. But is it wise to
generate more traffic when congestion has been detected ? The TML should
preferably deal with congestion itself directly.
Comment by Robert: Authors of the draft should examine each of these
information and determine if they are of local interest (hence no need
to be reflected in an LFB) or have FE-CE interest (hence update the LFBs).
b) Statement from protocol draft that "PL must be portable across TMLs".
Comment by Joel: this statement is a mistake. This comes from a
confusion between definition vs implementation. Standardization of
TML-to-PL-interface is out of scope. Avri seconds Joel's comment.