Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]

["Wang,Weiming" <[e-mail]>]

Robert,



  ----- Original Message ----- 
  From: Robert Haas 
   
  Wang,Weiming wrote:

In some way, you may call it a thought of relative path. My view is actually
from following thought:
1. A single path is not enough for an operation. In some cases, we may need to
assign several paths for an single operation, e.g.,   we may at the same time
need to set value to 1.2.3 and 1.2.4 where 3 and 4 are field IDs for the same
table. We may also possibly need to set 1.1 in the same operation.
  
  So why don't we support multiple times "path+data" under the same LFBSelect ?
  [Weiming]I think we have. Only mutimle 'path, data' in one OpTLV is not sured.

2. It's quite unnecessary we may set different Attributes in one single
operation, therefore the AttrID part is always the same.
  
  I am not sure about this.
   
  [Weiming]Actually my imagine of a PDU format looks like:

          OpTLV = AttributeID <DataTLV>
          DataTLV = <subpath-value pare>+

  Of course, I also don't oppose the format as:
          OpTLV = AttributeID <DataTLV> AttributeID <Data TLV>
          DataTLV = <subpath-value pare>+

  What I really mean is, for a group of subpaths, the AttributeID is the same. Pls see my reply later soon to Joel on this necessity.
Based on above, I think that:
1. It may be very complex to have one specific 'path'  in one 'path' format to
express the actual paths like 1.2.3 and 1.2.4 and 1.1 simulteneously , but it
would be much simpler to have Data field to express it, like the data format as:
    subpath(1.2.3) value, subpath(1.2.4) value, subpath(1.1) value
  
  Instead, take these subpaths out of the data part, and make normal paths out of them. That's doable if we decide to support multiple "path+data" under the same LFBSelect.
  [Weiming]I'm afraid you mean LFB Select here OpTLV, is't it?
2. for all subpaths, the head AttrID part is the same, and this is also the only
part that are the same.

Therefore, my thought is the AttrID part is defined in the protocol, leaving the
subpath go along with the data.

  
  I would prefer to have the whole path in the "path", not mixing the subpath and the data. That sounds to me like a cleaner design. Note that this was the consensus in the room after the presentation. But if you have other arguments that would favor the "subpath going into the data", please share them with us.
  [Weiming]Obviously to have AttributeID out meets the tree data structure, just the same as we pull out LFB class and LFB instance ID out of the while path. It also makes the protocol very clear in structure, i.e., to set some 'attribute' in some ' LFB insatnce' with  some 'LFB class'. While to let a whole path meets the linear data structure, its lower in efficiency and also not very clear in semantics. And also, very offten you will find some part of the path (especially the attribute ID part) is repeating.
  Best regards,
  Weiming

  Regards,
  -Robert


i.e you say parent-path=1,2,3,4 then everything else is relative to
that.
    
The only possible common parent path is the Attribute ID.

  
Example if you say 5 afterwards for relative path, then the full path
is: 1,2,3,4,5.

I still dont think that "5" should be in the data portion though.
    
When we have more than one subpath that should be expressed, you may see the
necessity for this.


Cheers,
Weiming

  
cheers,
jamal

On Tue, 2004-11-09 at 22:33, Wang,Weiming wrote:
    
Hi Robert,

Thank you very much to bring the slides to the meeting.

 ----- Original Message -----
        From: Robert Haas
        Subject: Re: [Fwd: [Forces-protocol] Presentation of the
        options for LFB-level multicast]

        All,
        I presented Weiming's slides just after Jamal's presentation
        yesterday. No divergence of views on the principle of how to
        describe paths was found.

        Whereas, according to his slides, Weiming considers that the
        distinction of Attribute, field, and index, must be reflected
        in the path notation, the consensus in the room was that this
        is not necessary: a path could be x.y.z, where it is clear
        that x must be an attribute, and y and z can be field or
        index. No need to mention it explicitely in the path notation.
        [Weiming] Actually this is not the key point. While I'm just a
        little afraid it may lead to ambiguity if , e.g., z can be a
        field ID or a subscript without tag to indicate it.
        The path can be constructed with index-search or
        content-search. The consensus in the room was that the path
        should include the whole thing, not only the first attribute,
        as opposed to Weiming's suggestion on the last slide.
        [Weiming]This is really the key point. We need to verify if it
        is possible for a single 'path'  format to describe all need
        for path. I just think that, apart from the attribute ID part,
        others are tightly combined with Data. We may feel difficulty
        to try to separate path explicitly.
        Content-search remains to be defined more precisely, as well
        as block access. So it is too early to disagree ;-)

        Regards,
        -Robert

        Thank you again.
        Weiming
        Wang,Weiming wrote:

        > Jamal,
        >
        > ----- Original Message -----
        > From: "Jamal Hadi Salim" <[e-mail]>
        >
        >
        > > On Mon, 2004-11-08 at 00:12, Wang,Weiming wrote:
        > >
        > > > Jamal,
        > > > ----- Original Message -----
        > > > From: "Jamal Hadi Salim" <[e-mail]>
        > > > To: "Weiming Wang" <[e-mail]>
        > > >
        > > >
        > > > > I still dont see what where we have differences. If Robert
      
can see that
  
        > > > > difference i think it would be worth presenting it.
        > > > >
        > > >
        > > > Sorry, but I don't think it's very proper for you to try to
      
stop an
  
        > > >
        >
        > individual
        >
        > > > presentation :)
        > > >
        > >
        > > The first step is to understand what you are trying to show.
        > > Look at how many emails it took for you to say "i see the
      
difference".
  
        > >
        >
        > Sorry, I know the difference very well, just can not see why you
      
cannot catch
  
        > it. That's just the 'i see the difference' mean.
        >
        > Cheers,
        > Weiming
        >
        >
        > > So i am not trying to stop your presentation rather trying to
      
understand
  
        > > what you are saying. Let me go back and read your other email
      
now.
  
        > >
        > > cheers,
        > > jamal
        > >
        > > PS:- Everyone i have talked to here upto before i went to bed
      
did not
  
        > > see any difference. This includes Robert.
        > >
        > >
        >
        >
        >
        >
        >


        --
        Robert Haas
        IBM Zurich Research Laboratory
        Säumerstrasse 4
        CH-8803 Rüschlikon/Switzerland
        phone [phone]  fax [phone]
      
http://www.zurich.ibm.com/~rha
  
______________________________________________________________________

_______________________________________________
Forces-protocol mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol
      
    




  


-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone [phone]  fax [phone]  http://www.zurich.ibm.com/~rha

_______________________________________________
Forces-protocol mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol