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

Hi,

I hate to say it, but I think i agree.  what do other people think?

a.

On 5 jul 2007, at 05.49, Wang,Weiming wrote:

> 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.