Subject: draft-ietf-forces-protocol-03.txt

From: [email-masked]
Date: Tue, 7 Jun 2005 11:43:11 +0200

Hi,

on june 02 i tried to submit the latest draft to the id editor.  but it 
was rejected because i mentioned rfc 3668 instead of bcp79.  
unfortunately i was away from email and did not see this rejection 
until this morning.

i have resubmitted it.  and hopefully this time have correctly dealt 
with the bureaucratic minutia.  but in case i haven't, or in the 
meantime, a copy can be found in:
http://psg.com/~avri/forces/draft-ietf-forces-protocol-03.txt

a.

---

From: Robert Haas <[email-masked]>
Date: Thu, 9 Jun 2005 14:56:14 +0200

Hi Avri, All,
I took a fresh look at the draft and noted the following errors and/or 
inconsistencies.
Regards,
-Robert

Sec 3.3.2 FE, CE, and FE protocol LFBs
 syntax problem:
All PL messages follow the LFB structure as this provides more 
flexibility for future enhancements. This means maintanance and 
configurability of FEs, NE, as well as the protocol require a fit in the 
LFB architecture. For this reason special LFBs are created to accomodate 
this need.
 I would rephrase the paragraph as follows (hopefully more clear :)
All PL messages operate on LFB structures as this provides more 
flexibility for future enhancements. This means that maintenance and 
configurability of FEs, NE, as well as the ForCES protocol itself must 
be expressed in terms of this LFB architecture. For this reason special 
LFBs are created to accomodate this need.

 typo:
The FE Protocol LFB also contains the various ForCES ID to be used: 
unicast IDs a table of the PL multicast IDs the FE must be listening to.
                                                                        
                                                     ^ add "and" after 
"unicast IDs".

Sec 4 TML Requirements
As an example they could be defined to be delivered via hardware or 
inter- TML protocol level schemes.
                                                                         
                                    ^ where did we define what 
"inter-TML" means ?

It is expected that the TML will be able to handle up to 8 priority 
levels needed by the PL layer and will provide preferential treatment.
                                                                         
     ^ writing "up to" means that the TML may support no priorities at 
all too. Is this what we intended to say ?

Sec 5.1 Common Header
Sequence [number is] Unique to a PDU.
 So a response message will have a different sequence number than the 
original request message. This is OK as long as nobody tries to use the 
Sequence number as a correlator for request/responses ...

Sec 6.1.1.1.1 Data Packing Rules
 Sorry, but the paragraph below is far from clear ... maybe correct 
"PATH flags" instead of "SELECTOR flags" as there are no flags defined 
in the SELECTOR. But this remains still obscure.
When a table is refered in the PATH (ids), then the RAWDATA's V will 
contain that tables row content prefixed by its 32 bit index/ subscript 
OTOH, when SELECTOR flags are 00, the PATH may contain an index pointing 
to a row in table; in such a case, the RAWDATA's V will only contain the 
content with the index in order to avoid ambiguity.

Sec 6.1.1.1.6 SET and GET Relationship
 I had a syntax error reading the sentence below ...
2. When dumping a whole table in a GET, the GET-RESPONSE, merely editing 
the T to be SET will endup overwritting the table.

Fig. 11: Sample operation layout
 Why is the path-data segmented 3 times for the SET-CREATE operation ? I 
thought that this was necessary only each time a different KEY was used ?

Sec 6.3 Semantics of message Direction
 Note that the semantics of the message direction are different for 
event notifications originated at the CE LFB: in that case the LFB 
selector points to the event of the CE.

Sec 6.4.2 Association Setup Response Message
 There is no reason to have SHOW operations about the FE object and/or 
FE protocol object here. I don't understand this and would rather use a 
separate CONFIG message to set the HBI ,for instance.

6.4.3 Association Teardown Message
 What is this new operation type FEReason ?

6.10 Operation Summary
 In the table, change "Event" in the "Operation" column by "Report" in 
order to be consistent with the prior descriptions.

[email-masked] wrote:

> Hi,
>
> on june 02 i tried to submit the latest draft to the id editor.  but 
> it was rejected because i mentioned rfc 3668 instead of bcp79.  

-- 
Dr. Robert R. Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-44-724-8698  fax +41-44-724-8578  http://www.zurich.ibm.com/~rha