Subject: Protocol draft 06

From: Evangelos Haleplidis <[email-masked]>
Date: Wed, 25 Jan 2006 14:54:03 +0200

Greetings to the list,

I was reading the protocol draft-06, and i have some
comments/questions/editorials.

Regards,

Evangelos Haleplidis

======================

Comments
-----------
Page 48, Correlator in the Assoc. Setup message

If I have understood correctly, the Correlator field is opaque to the FE.
Meaning that it does not mean anything to the FE.
In the association setup in page 48 in the draft-06 it is written:
"The Correlator field in the header is set, so that FE can correlate the
response coming back from CE correctly."
Since the association setup message originates from the FE it should leave
value 0 to the correlator and not insert a value.
Is it an exception to the rule, or something I have not understood correctly?
-----------
Page 38-39/42-44 Picture/Appendix-D. SET Operation Type

In the document the SET operation type is defined simply as SET and is
assigned the value of 0x0001 in Appendix-1.

However later in the document (Pages 42-44) and in Appendix-D there is an
operation called SET-REPLACE and SET-CREATE which is not specifically
defined in the document. Do these two operations still exist? There is the
DEL command, why not have also a CREATE command?

If I understand correctly from the text in page 39:
"Note that if a SET request with a structure in a FULLDATA is issued, and
some field in the structure is invalid..." that SET does not create. Is it
correct? What does invalid mean exactly?
-----------
Page 50. About the FE requesting ID from the CE.

What happens if two FEs request ID from the CE the same time. How can the
CE make the distinction. Which FE should it associate with? How to send
the association message correctly? How can the TML make the distinction
based on the ForCES message? Which FE is associated and which not?

Also the FE-ID is read-only. Even with the association setup-response,
isn't it a write-attempt? Or is it considered a setup? Is the read-only
attribute valid on the UP state?

Proposal-1: Remove the feature. The manager(s) should have already set-up
the IDs
Proposal-2: Make the FE-ID read-write. As it is now, read-only the
setting-up of the ID is contradictory.
-----------
Appendices

No changes in the Appendices. The following are still pending 1)(Page
78)Message Types. Missing Response types and Association Teardown type
2)(Pages 79-80) What is the difference between Operation Type and the
OPER-TLV type. Does OPER-TLV exists? In page 80 it should be erased.
Proposal-1: Make the Operation Types 0x0101, 0x0102 etc (if you want to
put 0x010# (where # the different numbers of operation types) 3)(Page
80)LFB Class ID 1 is Protocol LFB or Object LFB?
4)Appendix-D Use cases: There exist SET-CREATE, SET-REPLACE etc...

======================
Proposal for TLV texts in page 31

The TLV length field is two octets and indicates the length of this TLV
including the TLV Type, TLV Length, and the  TLV data in octect.

Proposed change to

The TLV length field is two octets and indicates the length of this TLV
including the TLV Type, TLV Length, and the  TLV data in octect (prior to
padding).
=================

Editorial
-----------
Page 6
"Section 9 describes mechanism ..."

Correction to:

"Section 9 describes a mechanism ..."
-----------
Page 29
"No ACK... receiver MUST not to send...back to this message sender"

Correction to

"No Ack... receiver MUST not send...back to the message sender"
-----------
Page 39
...each FULLDATA or or SPARSEDATA...

Correction to

...each FULLDATA or SPARSEDATA...
-----------