Subject: [issue84] RESULT TLV modification

From: Weiming Wang <[email-masked]>
Date: Wed, 25 Jan 2006 06:38:12 +0000

New submission from Weiming Wang <[email-masked]>:

Some comments on the protocol draft mentioned the care about the modification 
of the Result TLV section. David mentioned the context on the 'permission 
denided', Avri mentioned the bits consume about the error code. Based on the 
suggestions, I give the following update on the Result TLV section. Pls 
comments on it, and Avri pls help to put it in the new 07 after no more 
comments. 

<original>

7.1.1.1.7.  Result TLV

   A RESULT TLV contains a 4 octet integer value.

   The defined values are

   0 = success

   1 = no such object

   2 = permission denied

   3 = invalid value (the encoded data could not validly be stored in
   the field)

   4 = invalid array creation (when the subscript in an array create is
   not allowed)

   255 = unspecified error (for when the FE can not decide what went
   wrong)
</original>

<changed to>
7.1.1.1.7.  Result TLV

   The RESULT TLV is an instance of TLV defined in Section 6.2.  The
   definition is as below: 
 
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Type = RESULT          |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Result Value  |                  Reserved                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   The defined Result Values are

   0 = success

   1 = no such object

   2 = permission denied (e.g., trying to configure an attribute that is read-
only)

   3 = invalid value (the encoded data could not validly be stored in
   the field)

   4 = invalid array creation (when the subscript in an array create is
   not allowed)

   255 = unspecified error (for when the FE can not decide what went
   wrong)

   others = Reserved

</changed to>

Thanks,
Weiming

----------
category: Editorial
draft: draft-ietf-forces-protocol
messages: 437
nosy: weiming
priority: May fix
status: No discussion
title: RESULT TLV modification

___________________________________________________
Forces issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/forces/issue84>
___________________________________________________

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 25 Jan 2006 14:43:52 +0800

I think 'extensive use of TLVs' has quite accurately described the use of
TLV as well as ILV. No more text is needed as in the Introduction section.

I suppose this issue can be closed in one week if theres no further
comments.

Thanks,
Weiming

David Says:
In the Introduction section it says "Information exchanged between FEs and
CEs
makes extensive use of TLVs."

Doesn't *all* control information use TLVs in ForCES?

Jamal replied:
We need to be more explicit:

We have two types of TLVs: 16 bit T, 16bit L and then
We have ILVs which use elementID for T ...

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 25 Jan 2006 15:03:50 +0800

After some work, I think some model terminology related to protocol like the
LFB, LFB instance, LFB metadata have all been included in the protocol
definition section, therefore I don't think we need the sentence in
definition section on refering to model anymore, i.e., to change the text:

3.  Definitions
   This document follows the terminology defined by the ForCES
   Requirements in [RFC3654] and by the ForCES framework in [RFC3746].
   This document also uses the terminology defined by ForCES the FE
   model in [FE-MODEL].  The definitons below are repeated below for
   clarity.

to:

3.  Definitions
   This document follows the terminology defined by the ForCES
   Requirements in [RFC3654] and by the ForCES framework in [RFC3746].
   Some definitons below are repeated for clarity.

In Page 10, remove the following sentence:

   The following terms are defined by this document:

Please comments on the above change,and this issue is to be closed in one
week.

Thanks,
Weiming

> David Says:

In the definitions section of the ForCES protocol, there is a reference to
the
model draft. The reference to the model seems normative to me.  Is this the
case?

Jamal replied:
"I dont think so - Joel? The dependency on the model at the moment rests
with the FEO; which we may end removing."

Solutions can be:
* Clarify that this is informative
* Bring the definitions into this doc
* Make it normative, then both docs required to become RFCs

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Jan 2006 06:07:50 -0500

The reason for referencing the model document for the definitions is that 
any time things occur in two places (like these definitions) it is a good 
idea to be clear as to which one is the actual definition.  (After all, the 
text can be different.)
Here, our intent is that the model document defines what an LFB is, and 
what an LFB Class is, etc.
So it is a good idea to say that.

Yours,
Joel

---

From: Avri Doria <[email-masked]>
Date: Wed, 25 Jan 2006 08:38:16 -0500

I agree.  the linkage should remain.

a.

On 25 jan 2006, at 06.07, Joel M. Halpern wrote:

> The reason for referencing the model document for the definitions  
> is that any time things occur in two places (like these  
> definitions) it is a good idea to be clear as to which one is the  
> actual definition.  (After all, the text can be different.)
> Here, our intent is that the model document defines what an LFB is,  
> and what an LFB Class is, etc.

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 26 Jan 2006 11:14:24 +0800

A standardized interface between PL and TML is essential for the separation
of PL from TML, or it makes no sense for the separation.  I suggest to
change it to MUST and close the issue then if no objection.

thanks,
Weiming

> David wrote:
> 3.1.2 The TML Layer
> * s/layer is essentially responsible for transport of/layer transports/
> ** There is a "should" in here ("All ForCES Protocol Layer
> implementations
>   should be portable across all TMLs").  From the context, it feels like
>   Is should be a MUST. Which is it?  If it is only a SHOULD, explain
> why.

[Jamal responded]
Well, if we are going to define the service primitives then its a MUST;
else it is a SHOULD.

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 26 Jan 2006 11:13:45 +0800

Then, I suggest just to change the reference of FE- model to informative and
noted with work in progress, and keep the original reference text. Note that
because the protocol and the model are inter-referenced, theoretically,
there must be an informative one in between.

I suppose we can close the issue after some change.

thanks,
weiming

 ----- Original Message -----
From: "Avri Doria" <[email-masked]>

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 26 Jan 2006 12:46:39 +0800

Double checked by sampling the updated, quite sure that this editorial issue
can be closed.So, closed as accepted.Thank EllenWeiming> Ellen wrote:General
comment - running a spell checker would be helpful, it would probably
catch most of the misspelled words found throughout the document. Also,
there
are a lot of places where articles (the, a, an) are missing, particularly
before FE and CE (too many to list) that would make the text flow better -
but
this is really a nit.

2. Definitions
Post-Association Phase -  /FE does know/ --> /FE knows/

3.1.1 /LFB'ss/ --> /LFB's/
3.2 /looses/ --> /loses/
3.3.1.1.1.  /maybe/ --> /may be/
3.3.1.1.2.  /maybe/ --> /may be/ and /dissallowed/ -->/disallowed/
3.3.1.1.5. /In which several/ --> /Several/
3.3.1.1.6. /In which all/ --> /All/
3.3.1.1.7. /the first one are/ --> /the first one is/
3.3.2. /Heartbeating/ --> /Heartbeat/
4. (item 8) /the TML only support/ --> /the TML only supports/
5.1. (item c, 2nd bullet) /donot/ --> /do not/
5.1. (Correlator) /ForCES Requests/ --> /Forces Request messages/
      /Fe/ --> /FE/
5.1. (Flags) /inidcate/ --> /indicate/
6.2.1 /gramar/ --> /grammar/
6.1.1.1. /a substantial amount of/ --> /a substantial number of/
6.1.1.1.1. (4th bullet) /refered/ --> /referred/ (should probably spell out
OTOH)
6.1.1.1.6. Is Idefined correct? /can not/ --> /cannot/
6.1.1.1.8. /alignement/ --> /alignment/
   /layout/ --> /lay out/
   /element ordered in the order/ --> /element in the order/
   /In the case of a SPARSEDATA we dont need to order/ --> /SPARSEDATA does
not need to be ordered/
   /For a GET responses/ --> /For a GET response/
   /deleteing/ --> /deleting/
6.1.1.1.9. /definitions as that was/ --> /definitions as/
   /possible that one would/ --> /possible to/
   /the GET-RESPONSE, merely editing the T to be set will endup
overwritting/
   --> /the GET-RESPONSE that merely edits the T to be set will end up
overwriting/

6.2.1 /used for the operation/ --> /used for correct operation/
   (FE heartbeat policy) /define the operating/ --> /defines the operating/
                         /liveliness/ --> /liveness/
   (FE restart policy) /pre-association phase definitely/ remove
"definitely"
            /FE itself decides/ --> /FE decides/
            /FE still keeps enough infomation of/ -->
                /FE is able to keep enough information from the/
            /post-associatin/ --> /post-association/
   (CE failover policy) /This basically makes the FE/ -->
            /This basically requires the FE/
   (CE timeout interval) /message body optionally consist/ -->
            /message body optionally consists/
     The statement that starts: "There is only one FE object LFB..." is
inconsistent with previous text and redundant. This text could be removed
without losing any information. Other sections led me to believe the
instance
ID must be set to 0x1 for the FE object and FE protocol LFBs.
            /notificationis/ --> /notification is/
6.4.2 (Message Header) /more response/ --> /more responses/
            /header MUST keep/ --> /header MUST be/
            /association setup message to be responded/ -->
              /corresponding association setup message/
      (Message body) /follows: is:/ --> /follows:/
6.4.3 (Message Header)
      "correlator field in the header is also ignored owing to no further
response requested" (even though the correlator field is ignored by the
message recipient, in most protocol specs, it is usually a requirement that
the sender set such fields to zero and the field MUST be ignored by the
receiver)
e.g. "the ACK flag and Correlator MUST be ignored by the message recipient".

6.5.1 (Message Header) /inidcate/ --> /indicate/
   /or to indicate in which case/ --> /or to indicate under which
conditions/
6.5.2 (Message body) /TThe/ --> /The/
6.6.1    /As usual, a query/ --> /A query/
6.6.2 (Message Header) /MUST keep/ --> /MUST be/
        /query message to be responded/ --> /associated query message/
6.7. /All events happen in FE are subscribable by CE/ -->
     /All events that can happen in an FE are subscribable by the CE/
   (Message Header) /MUST be ignored/ --> /MUST be ignored by the CE/
(Same comment as in the previous section, the CE MUST also ignore the
correlator field in this case)

6.8 /usually happen/ --> /usually happens/
    /CE and are decided by CE/ --> /CE that the CE decides/
    /making the redirect path been congested/ -->
      /resulting in the redirect path becoming congested/
 (Message Body) /describes the packet/ --> /describes packet redirection/

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 26 Jan 2006 13:04:20 +0800

The issue is closed because it is included in issue68.Thanks,WeimingHi
Ellen,

Thanks for pointing out this.  It seems also a prominent question, for David
mentioned this either (issue68).  My view is it may provide more freedom if
we
define it as the sender can ignore it.  For instance for Query message, the
sender will always want a response, therefore, the coder may be more incline
to
set the ACK flag to 'AlwaysACK'.  If we define Sender MUST set the ignored
field
to zero, the just mentioned case will then have to be treated as an message
error by the receiver.

I hope other protocol authors can give some comments on this, and we decide
it
quickly, then I can update the text accordingly.

Thanks,
WeimingEllen wrote:In cases where fields are ignored, it should be more
explicit which side
(sender or recipient) ignores the field. Also, most protocols that I've seen
require the recipient to ignore the field (receiver MUST ignore), and the
Sender MUST set the field to zero. (HW engineers want to have a fixed value,
even if the other side ignores the field.)

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 26 Jan 2006 16:02:59 +0800

Avri,

In Section 7.9, the message header paragraph, after the sentense "When not
soliciting for response(default behavior), the ACK flag is set to 'NoACK'",
a full stop mark is missed.

Eeditorial nits have been well repaired by sampling check. This issue can be
closed after above small nit is fixed.

Thank Ellen.

Weiming

Allen wrote:

6.9 (Message Header)
Does the ACK flag have to be set to either 'NoACK' or 'AlwaysACK'? If so,
the
sentence should read: "The ACK flag in the header MUST be set to
either 'NoACK' or 'AlwaysACK' when the HB is sent."
"Correlator field can be ignored" is too vague.

7.1 /association have/ --> /associations have/
  /it by enabling the FE/ --> /it enables the FE/

7.2 /Figure below helps/ --> /The figure below helps/

8. (1st paragraph)
 /there can only be one Primary CE controlling the FEs and there/ -->
 /only one Primary CE can control the FEs, but there/

 (2nd paragraph)
  /There are 2 modes of HA defined/ --> /Two HA modes are defined/

8.1.
 (PL Level:)
  /All the other/ --> /For all the other/

9.
  (1st bullet)
    /Security mechanism/ --> /Security mechanisms/
    /controlled that is/ --> /controlled. That is,/
  (2nd bullet)
    /uniform operations/ --> /uniform operation/
  (3rd bullet)
    /pre-established/ --> /pre-establish/
    /reduce the security/ --> /reduce the number of security messages
exchanged/

9.1
  (1st para)
    /When No security/ --> /When "No security"/
    /needs be performed/ --> /needs to be performed/
    /within an single/ --> /within a single/

9.1.1.
    /PL layer maintain set of association list/ -->
    /PL layer maintains a set of association lists/

    /FE MSUT connect/ --> /An FE MUST connect/
    /similarly CE should/ --> /similarly, a CE should/

10. /Allan DeKok/ --> /Alan DeKok/

B.4.
  /TheLFB/ --> /The LFB/
  /iws/ --> /is/

B.5
  Every instance of Response is misspelled as "Repsonse" (also Responses
as "Repsonses")

C. I didn't look at the XML carefully, but noticed that the RFC references
need to be resolved, currently they are "XXXX".

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 26 Jan 2006 16:15:39 +0800

The draft 06 has fixed the problem along with the model team work.

This issue is closed as accepted.

Thank Evangelos.

Weiming

[email-masked] wrote:

This is an editorial comment for the protocol draft.

In Appendix B of the Protocol draft in page 80 an FE LFB is mentioned.
It should be changed to FE Object LFB

Also, in the Protocol Draft the FE Protocol LFB is assigned to value 0x01,
and
the FE Object LFB is assigned to value 0x02.
In the Model Draft the FE Object LFB is assigned to value 0x01.

In two tracker issues, i will insert reference of the LFBClassID values of
the
two LFBs.

-------------

References to LFBClassID values for FE Protocol LFB and FE Object LFB:

Page 43: The FE Protocol LFB is a logical entity in each FE that is used to
control the ForCES protocol.  The FE Protocol LFB Class ID is assigned the
value 0x1.

Page 80:
                 0x00000000       Reserved
                 0x00000001       FE Protocol LFB
                 0x00000002       FE LFB

Page 84: (Must be changed by now to)
 <LFBClassDef LFBClassID="1">
   <name>FEPO</name>".