Subject: Re: Protocol draft 06

From: Weiming Wang <[email-masked]>
Date: Tue, 7 Feb 2006 00:07:39 +0800

Hi Avri and Evangelos,

Please see the replies inline and Avri may help to put in some updates based on
Evangelos comments and the replies.

Thanks to Evangelos.

BTW, if all agree, I suggest to make  Evangelos, Chawla, Furquan, T. Sridhlar,
Xiaoyi Guo, Fenggen Jia in the acknowledge thanks list.

Thanks to all.

Weiming

----- Original Message -----
From: "Evangelos Haleplidis" <[email-masked]>
>
> 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?
I don't think it is an exception.  A correlator is used regardless of CE or FE
when they expect responses from peers. Any way, we need to modify the definition
for correlator in Page 28.   I suggest the update text as below:

   Correlator (64 bits)
       This field is set by the CE or the FE to correlate its  request messages
       with the corresponding response messages from the message receivers.
       The Correlator is handled  transparently by a request message receiver,
       i.e., for a particular request message,  the receiver must assign
       the same correlator value in the corresponding response message.  In
       the case where the message does  not elicit a response, this field may
       not be useful.

> -----------
> 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?
It is an inconsistency.  We shouldn't have such things if we worked more
carefully.

Avri, please just change all 'SET-REPLACE' and 'SET-CREATE' to 'SET'. I think it
will be fine then, which changes things like 'SET-CREATE-TLV' also.

>
> 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?
We only have SET. In valid usuaally happens when the data structure is not
matched to that defined by FE model or LFB lib.

> -----------
> 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?
Note that an CE can associate with mulitple FEs.
>
> 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?
I agree this is a problem.
>
> 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.
We now have CE and FE manages and we are going to define more at Reference point
Fl for CEM/FEM communications, therefore this feature is really superfuous and
out of scope of the protocol.

Avri, I suggest to remove the two sentences:

Page 48, 'Message header:' paragraph, remove 'The Src ID (FE ID) may be set to O
in the header which means that the FE would like the CE to assign an FE ID for
the FE in the setup  response message.'

Page 50, 'Message header:' paragraph, remove 'The Dst ID in the  header will be
set to some FE ID value assigned by the CE if the  FE had requested that in the
setup message (by SrcID = 0).'

> -----------
> Appendices
>
> No changes in the Appendices. The following are still pending 1)(Page
> 78)Message Types. Missing Response types and Association Teardown type
Yes, that's it.  Avri may fix it.

> 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)
Avri, Evangelos is right. Operation Type is a subset of TLV type. I suggest to
merge the A.2 'Operation Type' into A.4 'TLV Type Name Space' for space
completion.

>3)(Page 80)LFB Class ID 1 is Protocol LFB or Object LFB?
Protocol LFB. We'v fixed the ID in 06 version.

> 4)Appendix-D Use cases: There exist SET-CREATE, SET-REPLACE etc...
The same as the second reply.

>
> ======================
> 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).
That's good. It matches the discussion we'v had. Thanks.

> =================
>
> 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...
> -----------
Avri may fix the editorial nits.