Re: LC: draft-ietf-forces-protocol-10.txt>>comments

Hi, 

I'm afraid only the changes on table 1 may not be enough to address the issue. In current Version 10, the sections on the messages definitions have all been changed more or less according to table 1. The most prominant changes are the paragraphs in the sections on "message body" are totally removed depending on the assumption that all message bodies were composed of "LFBselect TLV". Now, this assuption is not ture, therefore the message body paragraph still needs to be there. 

 Let me just quote one section of them from Version 10, and compared it with that in Version 9 to see the difference. 

(I'm afraid section 7.5.2, 7.6.1, 7.6.2, 7.7.1, 7.7.2, 7.8 all have this problem. The simpliest correct way is to recover back to version 9 mode by recovering the "message body" paragraph.)

In Version 10: 

7.5.3.  Association Teardown Message

   This message can be sent by the FE or CE to any ForCES element to end
   its ForCES association with that element.


   Message transfer direction:
       CE to FE, or FE to CE (or CE to CE)

   Message Header:
       The Message Type in the header is set MessageType=
       "AssociationTeardown".  The ACK flag MUST be ignored.  The
       correlator field in the header MUST be set to zero and MUST be
       ignored by the receiver.

     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 = ASTreason       |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Teardown Reason                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 25: ASTreason TLV

   Type (16 bits):
       The type of the TLV is "ASTreason".
    ...... 

In Version 9: 

7.4.3.  Association Teardown Message

   This message can be sent by the FE or CE to any ForCES element to end
   its ForCES association with that element.


   Message transfer direction:
       CE to FE, or FE to CE (or CE to CE)

   Message Header:
       The Message Type in the header is set MessageType=
       "AssociationTeardown".  The ACK flag MUST be ignored.  The
       correlator field in the header MUST be set to zero and MUST be
       ignored by the receiver.

   Message Body:
       The association teardown message body only consists of one TLV,
       the Association Teardown Reason TLV, the format of which is as
       follows:

     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 = ASTreason       |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Teardown Reason                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 25: ASTreason TLV

   Type (16 bits):
       The type of the TLV is "ASTreason".
   ......

thanks,
Weiming

> 
>> Here are some comments on the draft-ietf-forces-protocol-10.txt.
>> 1 Page43,table1,on association teardown message: Does Association  
>> Teardown message need LFB selectTLV, I can't find any clue in  
>> Section 7.5.3?
> 
> Table 1 corrected - needs ASTreason TLV

> 
> 
>> 2 Page43,table1,on Heartbeat message:Section 7.10 says clearly that  
>> heartbeat message doesn't need LFB SelectTLV,so the top level TLV  
>> for this should be none?
> 
> Table 1 corrected to say none
> 
>> 3 Page43,table1,on packet redirect message:Section 7.9 says it
>> doesn't need LFBSelectTLV,it only needs REDIRECT TLV,what is the  
>> right one?
> 
> Table 1 corrected to say REDIRECT TLV
> 
>> 4 Page43,table1,on Config message:what is the meaning of ()+,does
>> anywhere explain this?
> 
> i think it was meant as a multiplicity indicator.  i will remove the  
> notation.
> 
>> 5 Page46,table2,on GET-RESPONSE TLV:   (RESULT-TLV)* (what is the
>> meaning of ()* ?)
> 
> i think it was meant as a multiplicity indicator.  i will remove the  
> notation.
> 
>> 6 Page46,table2 and page50 table 3:here is conflict on Redirect
>> TLV, table 2 treats Redirect TLV as a kind of Oper TLV while table  
>> 3 not,which
>> is right?
> 
> It is not defined as an Oper TLV as far as i can tell.  i will remove  
> if from table 2.
> 
> 
>> 7 suggestion:we should add a tree structure for Packet redirect  
>> message,also for association setup response message,Association  
>> Teardown Message, config response message and query response  
>> message to clarify the format
>> of the specified messages.
>>
> 
> As it is just a suggestion and not a bug, I decline to do that at  
> this point.
> 
> If someone else wishes to draw it up, i will cut it into the document.
> 
> If I am required to do it, it will not get done before the draft  
> deadline.
> 
> 
> a.