Subject: ForCES Requirements Status Update, 10/09/2002

From: "Putzolu, David" <[email-masked]>
Date: Wed, 9 Oct 2002 17:15:55 -0700

All,

Our area directors have provided feedback on the
requirements draft - see below for a summary.  The
requirements design team is going to respond to the
feedback and post a new revision for the WG to
review.  This new rev will have a brief last call
comment period (one week), and then will be returned
to the IESG for review for publication.

Cheers,
David & Patrick, co-chairs, ForCES WG

--- AD Feedback ---

Section 6.5 Requirement 5) Vendor-Specific Functions

The ADs believe that the IESG will be very hesitant to
approve this part of the draft as worded.  This is due
to a concern that vendors would simply use the
extensibility mechanisms in the protocol to do everything
in a proprietary fashion, including "common" functions.

The ADs suggested rewording the section to talk about
extensibility to support new, currently unknown functions.
Make sure that it is clear that one is *not* compliant
with ForCES if one controls all the standard/common
functions in a proprietary manner.

Section 7 Requirement 6) Reliability

The ADs where confused by the mention of non-IP networks
(hey, they are IETF ADs, IP is all they think of - just
kidding!!!). Recommend breaking up the one long reliability
paragraph into three paragraphs: Para 1: Talks about IP
networks. Essentially the same content. Para 2: Elaborates
what non-IP networks are (FastEth, GigE, cell fabric
between control and forwarding elements). Para 3: Take the
last sentence and expand on it to make clear that the
ability to acknowledge the *content* and execution of
messages, rather than just their delivery. I.e., TCP may
guarantee delivery, but it tells you nothing about whether
the forwarding entry add operation succeeded or not. It is
the latter function that is required for all types of
networks (IP and non-IP).

Section 7 Requirement 9) Packet Redirection

The ADs where concerned that as written this seems more like
a requirement on the FEs/CEs rather than on the protocol.
Suggest rewriting it to say that ForCES must define a way to
deliver packets from FE's that are destined to the CE (i.e.
RIP packets from other routers) and vice versa. This makes
it a protocol requirement instead of a CE or FE requirement.

--- Other Feedback ---

Other feedback based on
http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-02.txt

* Looks like 58 or more lines per page. Reduce this to 55 lines
  per page as per section 3.1 item 3.
* Table of contents should go directly after abstract per section 4.
* References should appear before security considerations per section 4
* Make normative and informative references subsections rather than
  top level sections.

--- end ---

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 24 Oct 2002 16:27:17 -0700

Hi All

I have attached the latest version of the Requirements draft which
I submitted to the IETF after incorporating all the comments below.

Thanks
Hormuzd

-----Original Message-----
From: Putzolu, David [mailto:[email-masked]]
Sent: Wednesday, October 09, 2002 5:16 PM
To: [email-masked]
Subject: [FORCES] ForCES Requirements Status Update, 10/09/2002

All,

Cheers,

--- Other Feedback ---

Other feedback based on

--- end ---