Subject: Some hints for modifying ForCES Specification

From: Dong Ligang <[email-masked]>
Date: Wed, 13 Apr 2005 03:15:21 -0400

1) [Page 14] Remove the definition of ACID, as ACID is a well known
concept. In this ForCES Specification, we did not provide new information
about the definition of ACID.

 2) The Length field of Common Header[Page 22] is in DWORDS while the
length field of messages is in bytes (e.g., Association Setup Message [Page
36]. They are inconsistent.

 3) [Page 25] "OPER-TLV : = 1*PATH-DATA-TLV" and "DATA := DATARAW-TLV /
RESULT-TLV / 1*PATH-DATA-TLV". Since we can express multiple PATH-DATA-TLV
in OPER-TLV, we do not need multiple PATH-DATA-TLV in DATA. In other words,
I think "flat path data" expression is simpler than "nesting" expression in
example 18 of the appendix.

 4) [Page 25] "PATH := flags IDcount IDs [SELECTOR]". According to the
examples in appendix, I guess that flags is either F_SELKEY, FIND-EMPTY, or
0. An alias should be provided for "flag=0".

 5) [Page 14] We need to express "Transactional all-or-none", "Any-of-N
independent operations", and "go-to-N loose transaction" in the common
header.

 6) We need to define the data in the Association Setup Response Message.
For example,

        Result

         0             the setup msg was successful.

         1            the setup msg is rejected by the CE

         2            the CE cannot read the setup msg because of wrong
message format.

 7)[Page 56] The operations in "6.10  Operation Summary" conflict with the
former introduction from Section 6.4 to Section 6.9.

 8) Remove redundant figures, e.g., Figure 24.

 9) It is difficult to distinguish the attribute& capability between FE
protocol LFB and FE LFB (or called FE object LFB). Why not combine the FE
protocol LFB and FE LFB?

 10) I suggest remove the concept of "FE protocol LFB" and "FE LFB". LFB
is "logical function block", that means a basic and single function.
However in fact, "FE protocol LFB" and "FE LFB" contain many functions.

 11) In Appendix D, we should provide realistic use cases or examples.

 12) We need to define PDU, OID, etc.

 13) CE LFB should be removed.

 14) In "6.5.1  Config Message", "get" operation cannot be used for config
message.

 15) Should Association Setup Response Message should contain some or all
capability&topology info. of FE?

 16) How to use "Throttle flag"?

 17)[Page 57] "When the FE is ready to start forwarding data traffic, it
sends a FE UP Event message to the CE.  The CE responds with a FE ACTIVATE
State Maintenance message to ask the FE to go active and start forwarding
data traffic."

 Individual Up Event message is unnecessary, as Association Setup Message
and Heartbeat Message can implicitly suggest this FE is "Up". Besides,
Individual Down Event message can be replaced by Association Teardown
Message.

 18) [Page 20] "Command (8 bits)" should be changed to "Message Type (8
bits)"

 19) Give more explanation about MIID table [Page 33]

 20) Others, e.g., the lowercase or uppercase, spell of words, should be
fixed.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Apr 2005 07:03:56 -0400

Thank you for taking a careful look at the ForCES protocol specification.

With regard to this specific suggestion, the nested multiplicity is 
deliberate.  It is true that any path-data representable this way can be 
represented with just a top level repetition.  However, if paths get long, 
the ability to share the common subexpression and refer to multiple items 
within that sub-expression was deemed useful by the design teams and the 
working group.

Yours,
Joel M. Halpern