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

Jia Fenggen <[email protected]> Fri, 6 Jul 2007 14:53:28 +0800
Newsgroups gmane.ietf.forces
Message-ID <[email protected]>
hi,avri,
    Thanks for your hard work,I agree with the changes,BTW,I have draw some 
message tree diagram for the protocol,please make it no problem and added 
to the draft,thanks again!
Yours,Fenggen
PS:The tree diagram is in the attachment.
  
>From: Avri Doria <[email protected]>
>Reply-To: Avri Doria <[email protected]>
>To: [email protected]
>Subject: Re: LC: draft-ietf-forces-protocol-10.txt>>comments
>Date: Wed, 4 Jul 2007 16:06:08 -0400
>
>hi,
>
>I am currently working on processing the open issues.
>
>These are the expected answers to this set.
>
>Please let me know if anyone disagrees with the approach.
>
>
>On 12 jun 2007, at 20.47, Jia Fenggen wrote:
>
>
> > > ----- Original Message -----
> > > From: "Jia Fenggen" <[email protected]>
>
>>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.

_________________________________________________________________
芒路 MSN Explorer:   http://explorer.msn.com/lccn/
Forces_message_tree.txt (text/plain, 3.2 KB)
1 tree diagram for Packet Redirect Message
   main hdr (type = PacketRedirect)
        |
        |
        +--- T = Redirect
        .        |
        .        +-- T = METADATA
                 |          |
                 |          +--  Meta Data ILV
                 |          |
                 |          +--  Meta Data ILV
                 |          .
                 |          .
                 |
                 +-- T = REDIRECTDATA
                     |
                     +--  // Redirected Data
2 tree diagram for Association Setup Response Message
               main hdr (type =  Association Setup Response)
               |
               |
               +--- T = ASResult
3 tree diagram for Association Teardown Message
               main hdr (type =  Association Teardown)
               |
               |
               +--- T = ASTreason
4 tree diagram for Config Response Message
          main hdr (type = ConfigResponse)
          |
          |
          +--- T = LFBselect
          .        |
          .        +-- LFBCLASSID = target LFB class
          .        |
                   |
                   +-- LFBInstance = target LFB instance
                   |
                   |
                   +-- T = operation { SET-RESPONSE }
                   |   |
                   |   +--  // one or more path targets
                   |        // associated with FULL or SPARSEDATA TLV(s)
                   |
                   +-- T = operation { DEL-RESPONSE }
                   |   |
                   |   +--  // one or more path targets
                   |
                   +-- T = operation { COMMIT-RESPONSE }
                   |           |
                   |           +--  RESULT
5 tree diagram for Query Response Message
   main hdr (type = QueryResponse)
        |
        |
        +--- T = LFBselect
        .        |
        .        +-- LFBCLASSID = target LFB class
        .        |
                 |
                 +-- LFBInstance = target LFB instance
                 |
                 |
                 +-- T = operation { GET-RESPONSE }
                 |   |
                 |   +--  // one or more path targets
                 |
                 +-- T = operation { GET-PROP-RESPONSE }
                 .   |
                 .   +--  // one or more path targets
                 .
6 some little change to Config Message tree diagram to show the use of 
COMMIT operation.
          main hdr (type = Config)
          |
          |
          +--- T = LFBselect
          .        |
          .        +-- LFBCLASSID = target LFB class
          .        |
                   |
                   +-- LFBInstance = target LFB instance
                   |
                   |
                   +-- T = operation { SET }
                   |   |
                   |   +--  // one or more path targets
                   |        // associated with FULL or SPARSEDATA TLV(s)
                   |
                   +-- T = operation { DEL }
                   |   |
                   |   +--  // one or more path targets
                   |
                   +-- T = operation { COMMIT } //A COMMIT TLV is an empty 
TLV
                   .
                   .