Subject: Re: [Forces-protocol] Presentation of the options for LFB-level multicast]

From: "Weiming Wang" <[email-masked]>
Date: Sat, 6 Nov 2004 21:40:10 +0800

Hi Robert,

Just one tiny point. I still cannot see the vital difference between the Merged mcast and Split mcast. Do you mean the main difference is the Merged mcast is for LFB class mcast while the Split mcast is for LFB Instance ID mcast only?  If possible, I think adding some more to explain (or define) the m1 and i1 may help more or less, especially to indicate if m1 is for LFB class and LFB instance, while il is only for LFB instance IDs. 

Cheers,
Weiming
  ----- Original Message ----- 
  From: Robert Haas 

  Hi All,
  I haven't seen any message on ForCES in the last 2 days, so I smell sth fishy. I post again my presentation here.
  Cheers,
  -Robert

  -------- Original Message -------- Subject:  [Forces-protocol] Presentation of the options for LFB-level multicast 
        Date:  Tue, 02 Nov 2004 22:12:20 +0100 
        From:  Robert Haas <[email-masked]> 
        Organization:  IBM Research Lab 
        To:  <[email-masked]> <[email-masked]> 

All,

Attached is a short presentation for the next IETF that summarizes the 
three options for LFB-level multicast:
- merged (among the current proposal in the draft),
- split (among the current proposals in the draft, called VPN, and 
Zsolt's proposal),
-  xcat (Weiming's proposal).

Also, there is a slide with the issue Jamal raised about unnecessarily 
repeating the class ID for commands destined to LFBs of the same class. 
Personally, I think the overhead is minimal. Maybe your view is different ?

Please review the slides and let me know if you have comments/suggestions.

Depending on the chosen solution(s), we may have to define a TLV for the 
LFB Instance ID, as this can be a normal ID, a virtual ID (MIID), a 
list, or a range.

Regards,
-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

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

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

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

---

From: "Weiming Wang" <[email-masked]>
Date: Sat, 6 Nov 2004 21:59:22 +0800

Hi Jamal,

I hope the discussion on the path can be summarized your the presentation.
Obviously it is an important issue, actually I think the issue spent most of our
time discussing on since last IETF meeting.

Another is I hope you can add a few words on the LFB multicast when you talk
about the protocol grammar where LFB addressign format is included, so as to be
consistent with Robert's presentation.

Cheers,
Weiming

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
> Robert,
> I saw your presentation. Looks fine. Apologies, havent had time to work
> on the protocol one. I am trying not to have too many slides.
> Heres a start that i will refine later.
> I was trying to build upto a point where i could explain the different
> views of "path" - I will still do that if theres
> a) view i should  or b) time allows it
>
> cheers,
> jamal
>
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: 06 Nov 2004 09:41:36 -0500

Weiming,

I will do this.
Can you send me a slide or two on your idea of path - I just wanna make
sure i dont misrepresent it.

cheers,
jamal

---

From: "Weiming Wang" <[email-masked]>
Date: Sun, 7 Nov 2004 09:57:13 +0800

Ok, I'l send you a slide or two for this by today or tomorrow.

Thanks,
Weiming

---

From: Robert Haas <[email-masked]>
Date: Sun, 07 Nov 2004 15:04:16 +0100

Weiming,
Sorry, the slides were made as a support for the presentation, so they 
are not very explicit alone. 

There is no LFB-class mcast.

Do you think it is important to add class mcast, i.e., "send this config 
command to all LFB of class X in FE a", or "send this config command to 
all LFB of class X in the NE" ?

At the moment, this can be done using three alternatives: a PL-ID mcast 
group, a virtual LFB instance ID, or list of LFB instances ID, each of 
which containing all the LFB instances of class X. So the question is, 
do we want to introduce a fourth alternative ?

Regards,
-Robert

Weiming Wang wrote:

> Hi Robert,
>  
> Just one tiny point. I still cannot see the vital difference between 
> the Merged mcast and Split mcast. Do you mean the main difference is 
> the Merged mcast is for LFB class mcast while the Split mcast is for 
> LFB Instance ID mcast only?  If possible, I think adding some more to 
> explain (or define) the m1 and i1 may help more or less, especially to 
> indicate if m1 is for LFB class and LFB instance, while il is only for 
> LFB instance IDs.
>  
> Cheers,
> Weiming
>
>     From: Robert Haas <mailto:[email-masked]>
>      
>     Hi All,
>     I haven't seen any message on ForCES in the last 2 days, so I
>     smell sth fishy. I post again my presentation here.
>     Cheers,
>     -Robert
>
>     -------- Original Message --------
>     Subject: 	[Forces-protocol] Presentation of the options for
>     LFB-level multicast
>     ------------------------------------------------------------------------

---

From: "Weiming Wang" <[email-masked]>
Date: Mon, 8 Nov 2004 01:12:58 +0800

Hi Robert,
  ----- Original Message ----- 
  From: Robert Haas 
  To: Weiming Wang 
  Cc: [email-masked] ; Jamal Hadi Salim ; Khosravi, Hormuzd M ; Avri Doria ; Dong Ligang ; (Ram Gopal ) 
  Sent: Sunday, November 07, 2004 10:04 PM
  Subject: Re: [Forces-protocol] Presentation of the options for LFB-level multicast]

  Weiming,
  Sorry, the slides were made as a support for the presentation, so they are not very explicit alone.  

  Do you think it is important to add class mcast, i.e., "send this config command to all LFB of class X in FE a", or "send this config command to all LFB of class X in the NE" ?
  [Weimign]I think currently we may need the latter more. The requirements fo LFB-class level mcast may still need more experience to find its necessity. Actually What I meant was I just can not see the big difference between the LF-ID mcast and the virtual LFB instance ID mcast. It seems identical to me. maybe I missed something. 

  Thank you.
  Weiming

    At the moment, this can be done using three alternatives: a PL-ID mcast group, a virtual LFB instance ID, or list of LFB instances ID, each of which containing all the LFB instances of class X. So the question is, do we want to introduce a fourth alternative ? 

    Regards,
    -Robert

    Weiming Wang wrote:

    Hi Robert,

    Cheers,
    Weiming
      ----- Original Message ----- 
      From: Robert Haas 

      Hi All,

All,

Regards,

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

---

From: "Weiming Wang" <[email-masked]>
Date: Mon, 8 Nov 2004 01:08:18 +0800

Hi Jamal, David, and Robert,

I just found that the 'path' issue may need more special attention during the
meeting, therefore instead of making a small portion of it as in Jamal's
protocol presentation, I made a specific short presentation for it as in the
attachment. (sorry, I'm out of town and my laptop does not have a pdfmaker,
therefore it's in ppt, I'l send pdf version soon). I'm not sure if it is proper
Jamal helps me to just show it after the protocol presentation, or as another
discussion issue other than mcast, Robert kindly helps to take a little bit
minites to show it?

Thanks a lot.

Weiming

----- Original Message -----
From: "Weiming Wang" <[email-masked]>

> > > Obviously it is an important issue, actually I think the issue spent most
of
> our
> > > about the protocol grammar where LFB addressign format is included, so as
to
> be

---

From: Jamal Hadi Salim <[email-masked]>
Date: 07 Nov 2004 02:30:08 -0500

Weiming,

I have 30 minutes to present. My rough estimate is 1 minute per slide
factoring in questions. I had asked initially for 45 minutes. The new
view of the protocol has never been presented before, and i am already
cutting down on it.

Therefore:
- 2 slides to introduce the concept of IDs and paths
- I will extract max 2 slides from you slides.
- Another 2 slides to introduce the other view
- another one or two slides to discuss the issue of data packing.
- move some of the scenarios to the backend and only present them if i
dont run out of time.

If the chairs would add more time, then we can change this plan
(although it looks fully packed at the moment).

cheers,
jamal

On Sun, 2004-11-07 at 12:08, Weiming Wang wrote:
> begin 666 Discussion on Path.ppt
> MT,\1X*&Q&N$`````````````````````/@`#`/[_"0`&```````````````!
> M````.@``````````$ ``_O___P````#^____`````#D```#_____________
> M____________________________________________________________
> M____________________________________________________________
> M____________________________________________________________
> M____________________________________________________________
> M____________________________________________________________
> M____________________________________________________________
> M____________________________________________________________
> M____________________________________________________________
> M____________________________________________________________
> M______________________\/`.@#?!L```$`Z0,H````@!8``. 0``#@$ ``
> M@!8```4````*```````````````!`````````0\`\@.N`0``+P#(#PP````P
> M`-(/! `````````/`-4'Y ``````MP]$````5 !I`&T`90!S`" `3@!E`'<`
> M( !2`&\`;0!A`&X```!0J1@!?-H2`&3:$@!VQPLP" ````````!\VA(`*-T-
> M, #@!!(0`+</1 ```(M;4T\``&4`<P`@`$X`90!W`" `4@!O`&T`80!N````
> M4*D8`7S:$@!DVA(`=L<+, @`````````?-H2`"C=#3"&X 0"( "W#T0`````
> M`%-/``!E`',`( !.`&4`=P`@`%(`;P!M`&$`;@```%"I& %\VA(`9-H2`';'
> M"S (`````````'S:$@`HW0TP`0``````I \*````@ !@`( ``0``````I0\,
> M````````""X````'``````"I#PH````'`````@`$" D$0 "C#VX````%`/_]
> M/P```"(@``!D`````````&0```````````! `@`````'````___O`( ````!
> M````__\8``````$````%```@`2 !```````%``! `D "```````%``!@`V #
> M```````%``" !( $``````\`"P3 ````#P``\+@```````;P6 ````(H```*
> M````- ````D````!````!P````0````$````!0````0````&````:@````@`
> M```$````"0````0````'````! ````(````$`````P````0```!C``OP) ``
> M`($!! ``"(,!````"+\!$ `0`, !`0``"/\!" `(``$"`@``"# `&O$,````
> M_P```/__``!F`#,`0 `>\1 ````$```(`0``"/__________'P#P#QP`````
> M`/,#% ````(``````````````````( `````#P#0!S<!```?`!0$' ``````
> M%004````$,V9# #*FCLR3LW)`,J:.P$!``$/`/H#9P``````_@,#``````$`
> M``#]`S0```!)````9 ```$D```!D````=L<+, @`````````<-H2````````
> M````!/___[+___\!````< #[`P@`````````< @``' `^P,(`````0```$ +
> M```?``<$/ ``````_0,T````(0```&0````A````9 ```&#S#3 LWA(`````
> M`#RJ& $```````````````````````$2`!\`$P0\``````#]`S0```!D````
> M9 ```&0```!D````8/,-,"S>$@``````/*H8`0``````````````````````
> M`1(`'P#_`Q0````"```$# ```````````````@````\`\ ];%P````#S`Q0`
> M```*``````````(````'`0``````````GP\$````!@``````J \2````1&ES
> M8W5S<VEO;B!O;B!0871H$ "?#P0````%``````"H#U0```!796EM:6YG(%=A
> M;F<-/'=M=V%N9T!M86EL+FAZ:6,N961U+F-N/@U)151&(#8Q=&@@365E=&EN
> M9RP@5V%S:&EN9W1O;BP@3F]V+C<M,3(L(#(P,#0``*$/% ```%4`````````
> M``!5```````"`!@```"J#R0````(`````0````,`&P`````````"`````0``
> M``,`, `````````/`/(/& ``````\P\0````````````````````""$., ``
> MWP\(````" ```"4``````/,#% ````4````$`````@````(!``````````"?
> M#P0```````````"H#R4```!$871A(%-T<G5C='5R92!F;W(@3$9"($%T=')I
> M8G5T97,@*#$I``"A#Q@````F```````@`````````28```````(`( `0`)\/
> M! ````$``````*H/"@````$````!`````````/,#% ````,``````````@``
> M```!``````````"?#P0````&``````"H#R4```!$871A(%-T<G5C='5R92!F
> M;W(@3$9"($%T=')I8G5T97,@*#(I``"A#Q0````F````````````)@``````
> M`@`@`! `GP\$````!0``````H \*! ``( `H`$P`1@!"`" `80!T`'0`<@!I
> M`&(`=0!T`&4`<P`@`&@`90!R`&4`( !I`&X`8P!L`'4`9 !E`" `80!T`'0`
> M<@!I`&(`=0!T`&4`<P`L`" `90!V`&4`;@!T`',`+ `@`&,`80!P`&$`8@!I
> M`&P`:0!T`&D`90!S`"D`#0`@`$$`;@`@`$P`1@!"`" `8P!O`&X`= !A`&D`
> M;@!S`" `80!T`'0`<@!I`&(`=0!T`&4`<P`@`&D`9 !E`&X`= !I`&8`:0!E
> M`&0`( !B`'D`( !!`'0`= !R`&D`8@!U`'0`90`@`$D`1 !S``T`( !,`$8`
> M0@`@`$$`= !T`'(`:0!B`'4`= !E`',`( `]`" `>P`@`$$`= !T`'(`20!$
> M`#$`+ `@`$$`= !T`'(`20!$`#(`+ `@`"8@( !]``T`( !!`'0`= !R`&D`
> M8@!U`'0`90`@`$D`1 !S`" `80!R`&4`( !D`&4`9@!I`&X`90!D`" `8@!Y
> M`" `6 !-`$P`( `H`%,`= !A`'0`:0!C`"D`#0`@`$$`;@`@`$$`= !T`'(`
> M:0!B`'4`= !E`" `;0!A`'D`( !B`&4`( !C`&\`;0!P`&\`<P!E`&0`( !O
> M`&8`( !N`&\`( !O`'(`( !S`&4`=@!E`'(`80!L`" `9@!I`&4`; !D`',`
> M( `H`&,`;P!M`' `;P!U`&X`9 `I`"P`( !E`"X`9P`N`"@`:0!N`" `= !H
> M`&4`( !F`&D`9P!U`'(`90`I`"P`( `-`" `00!T`'0`<@!)`$0`,0`]`'L`
> M?0`L`" `00!T`'0`<@!)`$0`,@`]`'L`9@`Q`"P`( !F`#(`+ `@`"8@( !]
> M`"P`( `-`%<`: !E`'(`90`L`" `00!T`'0`<@!)`$0`,0`@`&@`80!S`" `
> M;@!O`" `9@!I`&4`; !D`" `* !A`&,`= !U`&$`; !L`'D`( !M`&4`80!N
> M`',`( !O`&X`; !Y`" `;P!N`&4`( !F`&D`90!L`&0`( !T`&@`90!R`&4`
> M9@!O`'(`90`@`&0`;P`@`&X`;P!T`" `;@!E`&4`9 `@`'0`;P`@`$D`1 `@
> M`&D`= `L`" `=P!H`&D`; !E`" `00!T`'0`<@!)`$0`,@`@`&@`80!S`" `
> M9@!I`&4`; !D`',`( !F`#$`+ `@`&8`,@`F( T`( !%`'8`90!R`'D`( !F
> M`&D`90!L`&0`( !H`&$`<P`@`&$`( !F`&D`90!L`&0`20!$`"P`( !W`&@`
> M:0!C`&@`( !I`',`( !A`&P`<P!O`" `9 !E`&8`:0!N`&4`9 `@`&(`>0`@
> M`%@`30!,`"@`<P!T`&$`= !I`&,`*0```*$/[@```'@````!`"$(```!````
> M``$``"H````"`"$(```!``````$``"L````#`"$(```!``````$``%@````!
> M`"$(```!``````$``"0````"`"$(```!``````$``'P````"`" (```````!
> M``!!`````@`A" ```0`````!``! ```````"`!@``0```````@`<`#<`````
> M``(`& `J``````0"`( $& `K``````@"`( (% `!``````P"`( ,' !5````
> M``P"`( ,& `"``````P"`( ,' `!`````! "`( 0& #@`````! "`( 0% ``
> M`*H/) ````(````!``````#6`0````````<````!`````P`G````````````
> M\P,4````! `````````"`````0$``````````)\/! ```````````*@/)0``
> M`$1A=&$@4W1R=6-T=7)E(&9O<B!,1D(@071T<FEB=71E<R H,RD``*$/& ``
> M`"8``````" ````````!)@```````@`@`! `GP\$`````0``````H ]J! ``
> M00!N`" `80!T`'0`<@!I`&(`=0!T`&4`( !M`&$`>0`@`&(`90`@`&$`= !O
> M`&T`:0!C`" `;P!R`" `80`@`'0`80!B`&P`90`L`" `90`N`&<`+@`@`"@`
> M:0!N`" `= !H`&4`( !F`&D`9P!U`'(`90`I`"P`( `-`$$`= !O`&T`:0!C
> M`#H`( !!`'0`= !R`$D`1 `Q``T`5 !A`&(`; !E`#H`( !!`'0`= !R`$D`
> M1 `R`%L`:0!=``T`=P!H`&4`<@!E`" `&"!I`!D@( !I`',`( !C`&$`; !L
> M`&4`9 `@`&D`;@!D`&4`> `@`&\`<@`@`',`=0!B`',`8P!R`&D`< !T`" `
> M9@!O`'(`( !A`" `= !A`&(`; !E`" `* !D`'D`;@!A`&T`:0!C`"D`( `-
> M`" `00`@`&8`:0!E`&P`9 `@`&,`80!N`" `8@!E`" `<@!E`&,`=0!R`',`
> M:0!V`&4`( !I`&X`( !T`&@`90`@`&0`80!T`&$`( !S`'0`<@!U`&,`= !U
> M`'(`90`L`" `90`N`&<`+@`H`&D`;@`@`'0`: !E`" `9@!I`&<`=0!R`&4`
> M*0`L`" `#0!F`#(`( !I`&X`( !!`'0`= !R`$D`1 `R`" `80!B`&\`=@!E
> M`" `;0!A`'D`( !B`&4`( !A`&X`;P!T`&@`90!R`" `= !A`&(`; !E`" `
> M=P!I`'0`: `@`&,`;P!M`' `;P!U`&X`9 `@`',`=0!B`&8`:0!E`&P`9 !S
> M`" `80!S`#H`#0`@`" `( `@`" `( `@`" `( !F`#(`6P!J`%T`/0![`&<`
> M,0`L`" `9P`R`"P`( `F('T`#0`@`" `( !W`&@`90!R`&4`+ `@`&H`( !I
> M`',`( !I`&X`9 !E`'@`( !F`&\`<@`@`'0`: !E`" `= !A`&(`; !E`"P`
> M( !G`#$`+ `@`&<`,@`@`"8@( !A`'(`90`@`',`=0!B`&8`:0!E`&P`9 !S
> M`" `* !S`'0`80!T`&D`8P`I`"X`#0!4`&4`<@!M`&D`;@!A`&P`( !F`&D`
> M90!L`&0`<P`@`"@`;@!O`'0`( !R`&4`8P!U`'(`<P!I`'8`90`@`&$`;@!Y
> M`&T`;P!R`&4`*0`@`'0`: !E`&X`( !H`&$`=@!E`" `=@!A`&P`=0!E`',`
> M+ `@`&4`+@!G`"X`( `H`&$`<P`@`&D`;@`@`'0`: !E`" `9@!I`&<`=0!R
> M`&4`*0`L`" `#0!!`'0`= !R`$D`1 `Q`#T`=@`Q``T`00!T`'0`<@!)`$0`
> M,@!;`&D`/0`Q`%T`+@!F`#$`/0!V`&8`,0`-`$$`= !T`'(`20!$`#(`6P!I
> M`#T`,0!=`"X`9@`R`%L`:@`]`#$`70`N`&<`,0`]`'8`9P`Q`"P`( !!`'0`
> M= !R`$D`1 `R`%L`:0`]`#$`70`N`&8`,@!;`&H`/0`Q`%T`+@!G`#(`/0!V
> M`&<`,@```*$/X@```#X````!`" 0```````!6@`B`````@`@$ ```````5H`
> M/@````(`(1 ``````````5H`1P````$`(! ```````%:`$4````"`" 0````
> M```!6@!@`````@`A$ `````````!6@!4`````0`@$ ```````5H`6 ````(`
> M(! ```````%:`#X```````(`& `B``````0"`( $% `^``````@"`( (% !'
> M``````@"`( (& !%``````@"`( (% !@``````P"`( ,% !4``````P"`( ,
> M& !8``````P"`( ,% ```*H/+ ```!P!````````"0````$````#`%$`````
> M````"@````$````#`+8```````````#S`Q0````(``````````(````%`0``
> M````````GP\$````````````J \E````1&%T82!3=')U8W1U<F4@9F]R($Q&
> M0B!!='1R:6)U=&5S("@T*0``H0\8````)@``````( ````````$F```````"
> M`" `$ "?#P0````!``````"H#YP```!3=6UM87)Y#4%T=')I8G5T92!)1"!A
> M;F0@1FEE;&0@240@<&QA>7,@:6UP;W)T86YT(')O;&5S(&9O<B!$871A('-T
> M<G5C='5R92!O9B!,1D(@871T<FEB=71E<PU&:65L9"!)1"!A;F0@:6YD97@H
> M<W5B<V-R:7!T*2!A<F4@='=O('1O=&%L;'D@9&EF9F5R96YT(&YO=&EO;G,`
> M`*$/)@````@```````````"5`````0``````" ````````"5``````0``( $
> M``#S`Q0````&``````````(````#`0``````````GP\$````````````H \D
> M````4 !A`'0`: `@`!,@( !)`&X`9 !E`'@`( !B`&$`<P!E`&0```"A#Q8`
> M```3```````@`````````1,`````````$ "?#P0````!``````"H#ZH!```@
> M57-E(&EN9&5X(&DL(&H@("!E+F<N+ U'970@(&D],3 @:6X@=&%B;&4@;V8@
> M071T<DE$,B -4&%T:" ]($%T='))1#);:3TQ,%T-1V5T("!J/3(P(&EN('1A
> M8FQE(&8R(&]F('1A8FQE($%T='))1#(-4&%T:" ]($%T='))1#);23TQ,%TN
> M(&8R6VH],C!=#4-O;6UE;G1S#5-I;7!L92!I;B!E>'!R97-S:6]N(&%N9"!F
> M87-T(&9O<B!S96%R8VAI;F<-4VAO=6QD('5S92!!='1R:6)U=&4@240@86YD
> M(&9I96QD($E$("AF,BD@87,@=V5L;"!A<R!I;F1E>"!I+&HN#4YO="!V86QI
> M9"!F;W(@:71E;7,@=&AA="!D;R!N;W0@:&%V92!I;F1E>"P@;&EK92!A=&]M
> M:6,@:71E;2P@86YD(&5V96YT<RP@8V%P86)I;&ET:65S('1H870@9&\@;F]T
> M(&]R:6=I;F%L;'D@:&%V92!I;F1E> U.;W0@86QW87ES(&YE8V5S<V%R>2!F
> M;W(@<VUA;&P@<VEZ92!T86)L97,``*$/I@```!@````````0``!:`!\````!
> M```0``!:`!4````"```0``!:`"<````!```0``!:`!\````"```0``!:``D`
> M```````0``!:`! !```!```0``!:`!@```````(`' `?``````0"`( $& `5
> M``````0"`( $% `G``````@"`( (& `?``````P"`( ,% `)`````! "`( 0
> M' `0`0```!0"`( 4& ```/,#% ````<``````````@````0!``````````"?
> M#P0```````````"H#Q0```!0871H+2!F:65L9"!)1"!B87-E9! `GP\$````
> M`0``````J ^G`0``57-E(&9I96QD($E$<R!O;FQY+"!E+F<N+ U'970@=F%L
> M=64@;V8@071T<DE$,0U0871H(#T@071T<DE$,0U'970@:71E;7,@;V8@071T
> M<DE$,B!W:&EC:"!M965T('1H92!C;VYD:71I;VYS(&%S(&8Q/2!V9C$@86YD
> M(&<Q/79G,0U0871H(#T@>T%T='))1#$N9C$](#T@=F8Q?2 F)B![071T<DE$
> M,2YF,2YG,2 ](#T@=F<Q?0U#;VUM96YT<PU$;R!N;W0@;F5E9"!T;R!M86YA
> M9V4@:6YD97@-1FET(&9O<B!A='1R:6)U=&5S('=I=&@@871O;6EC(&]R('-M
> M86QL('-I>F4@=&%B;&4@9&%T82!T>7!E<RP@86YD(&9O<B!C87!A8FEL:71I
> M97,@86YD(&5V96YT<R!T:&%T(&1O(&YO="!O<FEG:6YA;&QY(&AA=F4@:6YD
> M97@N#4ES(&-O;G1E;G0@8F%S960@<V5A<F-H:6YG+"!L;W=E<B!T:&4@969F
> M:6-I96YC>2!F;W(@;&%R9V4@<V-A;&4@=&%B;&5S``"A#Z8````:````````
> M$ ``6@`5`````0``$ ``6@`/`````@``$ ``6@!%`````0``$ ``6@`V````
> M`@``$ ``6@`)````````$ ``6@#F`````0``$ ``6@`:```````"`!P`%0``
> M```$`@" !!@`#P`````$`@" !!0`10`````(`@" "!@`-@`````,`@" #!0`
> M"0`````0`@" $!P`Y@`````4`@" %!@```"J#Q(```"G`0````````$````!
> M`````````/,#% ````D``````````@````8!``````````"?#P0`````````
> M``"H#P0```!0871H$ "?#P0````!``````"H#\(!``!#;VYC;'5S:6]N#4EN
> M9&5X(&)A<V5D(&%N9"!F:65L9"!)1" H8V]N=&5N="D@8F%S960@861D<F5S
> M<VEN9R!A<F4@86QL(&YE8V5S<V%R>0U4:&4@071T<FEB=71E($E$('!A<G0@
> M:7,@86QW87ES(&YE961E9"!F;W(@8F]T:"!W87ES+"!T:&5R969O<F4@8V%N
> M(&)E('!U;&QE9"!O=70L(&%S( U0871H(#H]($%T=')I8G5T94E$(" \26YD
> M97@@;W(@1FEE;&0@261S/BL@#5-U9V=E<W1I;VX-5&AE(&9O;&QO=V5D(#Q)
> M;F1E>"!O<B!F:65L9"!)9',^('!A<G0@8F4@:6YC;'5D960@:6X@=&AE($1A
> M=&$@9FEE;&0@<F%T:&5R('1H86X@:6X@=&AE(%!,(&QA>65R(&9O<B!T:&4@
> M<')O=&]C;VP@=&\@9&5F:6YE('1H92!C;VUP;&5X('-T<G5C='5R92!L:6ME
> M( T@6TD],3!=+B!F,EMJ/3(P72 ->T%T='))1#$N9C$](#T@=F8Q?2 F)B![
> M071T<DE$,2YF,2YG,2 ](#T@=F<Q?2 -#51H92!%;F0``*$/N ````L`````
> M```0``!:`)T````!```0``!:`"P````#```0``!:``L````````0``!:`)@`
> M```!```0``!:`$,````#``$0`````%H``0```````! ``%H`" ```````1@`
> M`````0!:``L```````(`' "=``````0"`( $& `L``````@"`( ($@`+````
> M``P"`( ,' "8`````! "`( 0& !#`````!0"`( 4$@`)`````!@"`( 8' ``
> M`*H/&@```*\`````````#@````$````#``8!``````````#J`P`````/`/@#
> MH @```(`[P,8`````0````$"!PD(````````````````````8 #P!R `````
> M`/\`____``````#__P``_YD```#__P#_````EI:6`& `\ <@````____````
> M``" @( ```````#,F0`S,\P`S,S_`+*RL@!@`/ '( ```/___P``````,S,S
> M``````#=W=T`@(" `$U-30#JZNH`8 #P!R ```#__\P``````&9F,P" @ ``
> M,YDS`( `````,\P`_\QF`& `\ <@````____``````" @( ``````/_,9@``
> M`/\`S #,`,# P !@`/ '( ```/___P``````@(" ``````# P, ``&;_`/\`
> M````F0``8 #P!R ```#___\``````(" @ ``````,YG_`)G_S #,`,P`LK*R
> M````HP\^`````0#__3\````B( ``9 ```````0!D````````````0 (`````
> M!P```/__[P" `````0```/__+ `````#```0`*,/? ````4`__T_``$`(B `
> M`&0`````````9 `4````V ```$ "``````<```#__^\`@ ````$```#__R `
> M`````0``@ 4``!,@U $@`0```@`<`( %```B(- "0 (```(`& " !0``$R#P
> M`V #```"`!0`@ 4``+L`$ 6 ! `````@`*,/;@````4`__T_````(B ``&0`
> M````````9 `>`````````$ "``````<```#__^\`@ ````$```#__PP`````
> M`0````4``" !( $```````4``$ "0 (```````4``& #8 ,```````4``( $
> M@ 0`````4 "C#U(````%`````0D``````0`````````!``$)``````$`( $`
> M`````@`!"0`````!`$ "``````,``0D``````0!@`P`````$``$)``````$`
> M@ 0`````8 "C#PP````!``````````````!P`*,//@````4````````````"
> M`!P``0`````````"`!@``@`````````"`!0``P`````````"`!(`! ``````
> M```"`!(`@ "C#SX````%`````````````@`8``$``````````@`4``(`````
> M`````@`2``,``````````@`0``0``````````@`0``\`# 3J! ``#P`"\.($
> M```0``CP" ````8````&! ``#P`#\'H$```/``3P* ````$`"? 0````````
> M``````````````````(`"O (``````0```4````/``3PR@```!(`"O (````
> M`@0````*``"3``OP-@```'\``0`%`( `S-X8`8<``0```($!! ``"(,!````
> M"+\!`0`1`, !`0``"/\!`0`)``$"`@``" ``$/ (````@ &P`= 44 0/`!'P
> M$ ``````PPL(``````````$`& $/``WP3 ``````GP\$````````````H \8
> M````55/[461K!%D6?Y&/S6M(<@=HF)@W: ]?``"B#P8````-`````````*H/
> M"@````T````!```````/``3P_ ```!(`"O (`````P0````*``"#``OP, ``
> M`'\``0`%`( `E. 8`8$!! ``"(,!````"+\!`0`1`, !`0``"/\!`0`)``$"
> M`@``" ``$/ (````X 2P`= 4``\/`!'P$ ``````PPL(`````0````(`& $/
> M``WPA ``````GP\$`````0``````H \X````55/[461K!%D6?Y&/S6M(<H=E
> M+&<W: ]?#0`L>XQ.IWX-`"Q["4ZG?@T`+'O;5J=^#0`L>Y1.IWX``*(/'@``
> M``T```````0````!``0````"``0````#``0````$````J@\*````'0````$`
> M``````\`!/#(````$@`*\ @````$! ````H``(,`"_ P````?P`!``4`@ "X
> MYA@!@0$$```(@P$````(OP$!`!$`P $!```(_P$!``D``0("```(```0\ @`
> M``!@#[ !8 : $ \`$? 0``````##"P@````"````!P$8`0\`#?!0``````"?
> M#P0````$``````"@#P(````J````H0\4`````@````````````(```````(`
> M#@```/@/! ```````````*H/"@````(````!```````/``3PR@```!(`"O (
> M````!00````*``"#``OP, ```'\``0`%`( `L.H8`8$!! ``"(,!````"+\!
> M`0`1`, !`0``"/\!`0`)``$"`@``" ``$/ (````8 ^P!] .@! /`!'P$ ``
> M````PPL(`````P````D"& $/``WP4@``````GP\$````! ``````H \"````
> M*@```*$/%@````(````````(```!``(```````(`#@```/H/! ``````````
> M`*H/"@````(````!```````/``3PR@```!(`"O (````!@0````*``"#``OP
> M, ```'\``0`%`( `J.X8`8$!! ``"(,!````"+\!`0`1`, !`0``"/\!`0`)
> M``$"`@``" ``$/ (````8 \@$- 4@! /`!'P$ ``````PPL(````! ````@"
> M& $/``WP4@``````GP\$````! ``````H \"````*@```*$/%@````(`````
> M```(```"``(```````(`#@```-@/! ```````````*H/"@````(````!````
> M```/``3P2 ```!(`"O (`````00````,``"#``OP, ```($!````"(,!!0``
> M"),!CI^+`)0!WKUH`+\!$@`2`/\!```(``0#"0```#\#`0`!`! `\ <@````
> M____``````" @( ```````#,F0`S,\P`S,S_`+*RL@`@`+H/# ```-B>I(N^
> MBZ&+(6I_9P\`[@/D`0```@#O`Q@`````````#Q ```````````" ``````<`
> M```/``P$E $```\``O",`0``, `(\ @````#`````R0```\``_ D`0``#P`$
> M\"@````!``GP$ `````````````````````````"``KP" `````D```%````
> M#P`$\'(````2``KP" ````(D```@`@``4P`+\!X```!_````! " `&RG\P._
> M`0```0#_`0```0`!`P($`````!#P" ```& #4 %P%# &#P`1\! ``````,,+
> M" `````````/`/,##P`-\ P``````)X/! `````````/``3P<@```!(`"O (
> M`````R0``" "``!3``OP'@```'\````$`( `**CS`[\!```!`/\!```!``$#
> M`P0`````$/ (````D E0`0`5X T/`!'P$ ``````PPL(`````0```! `\P,/
> M``WP# ``````G@\$`````0````\`!/!(````$@`*\ @````!) ````P``(,`
> M"_ P````@0$````(@P$%```(DP&.GXL`E '>O6@`OP$2`!(`_P$```@`! ,)
> M````/P,!``$`$ #P!R ```#___\``````(" @ ```````,R9`#,SS #,S/\`
> MLK*R``\`[@.)#@```@#O`Q@````!````#0X```````````" ``````<````/
> M``P$.0X```\``O Q#@``8 `(\ @````9````:1 ```\``_#)#0``#P`$\"@`
> M```!``GP$ `````````````````````````"``KP" `````0```%````#P`$
> M\%(````2``KP" ```&(0````"@``<P`+\"H```"%``(```"'``$```"!`08`
> M``B_`1 `$ # `0$```C_`0@`" `!`@(```@``!#P" `````#D `P%6 /#P`$
> M\'(````2``KP" ````(0```@`@``4P`+\!X```!_````! " `&R*!@2_`0``
> M`0#_`0```0`!`P($`````!#P" ```" !L '0%* "#P`1\! ``````,,+" ``
> M```````-``8$#P`-\ P``````)X/! `````````/``3P4@```$(!"O (````
> M!1 ``( *``!S``OP*@```$0!! ```'\!```!`+\!```0`, !_P```-$!`0``
> M`/\!& `8``$"`@``" ``$/ (````4 >@#F /$ @/``3PPP```*(,"O (````
> M!Q ````*``#S``OP6@```( `0(P&!+\``@`"`($!! ``"+\!$ `0`, !`0``
> M"/\!```(```"`0````$"`P``" ("\P-F$ 4"4%,"``8"Z _^_P<"H*8$``@"
> MT!_\_S\"```"`+\"```(````$/ (````( 3 "5 -0 4/``WP.0``````GP\$
> M````! ``````J \'````071T<DE$,@``H0\6````" ```````"@```$`,@`(
> M``````````\`!/##````H@P*\ @````($ ````H``/,`"_!:````@ #X=@8$
> MOP`"``(`@0$$```(OP$0`! `P $!```(_P$```@```(!`````0($```(`@+S
> M`V80!0)04P(`!@+H#_[_!P*@I@0`" +0'_S_/P(```(`OP(```@````0\ @`
> M``!0!' "``9P!0\`#? Y``````"?#P0````$``````"H#P<```!!='1R240Q
> M``"A#Q8````(````````* ```0`R``@`````````#P`$\-T```"B# KP" ``
> M``D0````"@``\P`+\%H```" `$AY!@2_``(``@"!`00```B_`1 `$ # `0$`
> M``C_`0``" ```@$````!`@0```@"`O,#9A %`E!3`@`&`N@/_O\'`J"F! `(
> M`M ?_/\_`@```@"_`@``" ```!#P" ```" $@! 0%$ %#P`-\%,``````)\/
> M! ````0``````*@/!P```$%T='))1'@``*$/%@````@````````H```!`#(`
> M" ```````````*H/$@````<````!`````P`!``````````\`!/"7````H@P*
> M\ @````I$ ````H``(,`"_ P````@ !,? 8$OP`"``(`@0$$```(@P$````(
> MOP$``! `P $!```(_P$```@``0("```(```0\ @```"0!F /4!"P!P\`#? W
> M``````"?#P0````$``````"H#P$```!I``"A#QH````"````````( ``,@`"
> M```````D``(`_P``_@\`!/ 0`0``H@P*\ @```!4$ ````H``/,`"_!:````
> M@ #<FP8$OP`"``(`@0'_S ``OP$0`! `P $!```(_P$```@```(!`````0("
> M```(`@+S`V80!0+X? ,`!@+<%_W_!P+P^08`" *X+_K_/P("``(`OP(```@`
> M```0\ @````@!Q (L U " \`#?"&``````"?#P0````$``````"@#RP````@
> M`" `9@`Q`" `( `@`'P`( `@`" `( !F`#(`( `@`" `? `@`" `)B N````
> MH0\4````%P```````" ``#(`%P```````````*H/(@````(`````````" ``
> M```````!`````0``````# `````````/``3PV ```*(,"O (````51 ````*
> M``#S``OP6@```( `.'X&!+\``@`"`($!_YG,`+\!$ `0`, !`0``"/\!```(
> M```"`0````$"`@``" ("\P-F$ 4"^'P#``8"W!?]_P<"\/D&``@"N"_Z_S\"
> M`@`"`+\"```(````$/ (````$ O "7 ., P/``WP3@``````GP\$````! ``
> M````H \>````9P`Q`" `( !\`" `( !G`#(`( !\`" `( `F("X```"A#Q0`
> M```0````````( ``,@`0``````````\`!/!2````0@$*\ @```!6$ ``@ H`
> M`',`"_ J````1 $$````?P$```$`OP$``! `P '_````T0$!````_P$8`!@`
> M`0("```(```0\ @```!P"S /\ \P# \`!/"7````H@P*\ @```!7$ ````H`
> M`(,`"_ P````@ # JP8$OP`"``(`@0$$```(@P$````(OP$``! `P $!```(
> M_P$```@``0("```(```0\ @```"P"O /X!#0"P\`#? W``````"?#P0````$
> M``````"H#P$```!J``"A#QH````"````````( ``,@`"```````D``(`_P``
> M_@\`!/!8````0@$*\ @```!8$ ````H``(,`"_ P````1 $$````?P$```$`
> MOP$``! `P $!```(RP$X8P``T0$!````_P$8`!@``0("```(```0\ @```! 
> M!7 +< O !@\`!/!8````0@$*\ @```!9$ ````H``(,`"_ P````1 $$````
> M?P$```$`OP$``! `P $!```(RP$X8P``T0$!````_P$8`!@``0("```(```0
> M\ @```! "- (T CP"0\`!/!8````0@$*\ @```!:$ ````H``(,`"_ P````
> M1 $$````?P$```$`OP$``! `P $!```(RP$X8P``T0$!````_P$8`!@``0("
> M```(```0\ @```! "$ +0 NP"@\`!/"9````H@P*\ @```!<$ ````H``(,`
> M"_ P````@ `D608$OP`"``(`@0$$```(@P$````(OP$``! `P $!```(_P$`
> M``@``0("```(```0\ @```"0"< &@ JP"@\`#? Y``````"?#P0````$````
> M``"H#PD```!686QU93UV9C$``*$/% ````H````````@```R``H`````````
> M#P`$\)D```"B# KP" ```%T0````"@``@P`+\# ```" `(Q$\P._``(``@"!
> M`00```B#`0````B_`0``$ # `0$```C_`0``" `!`@(```@``!#P" ```/ ,
> MX <`#! .#P`-\#D``````)\/! ````0``````*@/"0```%9A;'5E/79G,0``
> MH0\4````"@```````" ``#(`"@`````````/``3P6 ```$(!"O (````7Q `
> M```*``"#``OP, ```$0!! ```'\!```!`+\!```0`, !`0``",L!.&,``-$!
> M`0```/\!& `8``$"`@``" ``$/ (````, R "H *( T/``3PF0```*(,"O (
> M````8! ````*``"#``OP, ```( `W$3S`[\``@`"`($!! ``"(,!````"+\!
> M```0`, !`0``"/\!```(``$"`@``" ``$/ (````X W "> -``\/``WP.0``
> M````GP\$````! ``````J \)````5F%L=64]=F<R``"A#Q0````*````````
> M( ``,@`*``````````\`!/!8````0@$*\ @```!A$ ````H``(,`"_ P````
> M1 $$````?P$```$`OP$``! `P $!```(RP$X8P``T0$!````_P$8`!@``0("
> M```(```0\ @````P# `,``RP#0\`!/"9````H@P*\ @```!C$ ````H``(,`
> M"_ P````@ " 2/,#OP`"``(`@0$$```(@P$````(OP$``! `P $!```(_P$`
> M``@``0("```(```0\ @```"P#1 1`!70#@\`#? Y``````"?#P0````$````
> M``"H#P,```!,1D(``*$/&@````0````````H```!`#(`! ``````! !F`#/^
> M#P`$\)@```"B# KP" ```&40````"@``@P`+\# ```" `-0[\P._``(``@"!
> M`00```B#`0````B_`0``$ # `0$```C_`0``" `!`@(```@``!#P" ```) &
> M0 (`!K '#P`-\#@``````)\/! ````0``````*@/" ```%9A;'5E/78Q``"A
> M#Q0````)````````( ``,@`)``````````\`!/!8````0@$*\ @```!F$ ``
> M``H``(,`"_ P````1 $$````?P$```$`OP$``! `P $!```(RP$X8P``T0$!
> M````_P$8`!@``0("```(```0\ @```!P!? #\ .0!@\`!/!8````0@$*\ @`
> M``!H$ ````H``(,`"_ P````1 $$````?P$```$`OP$``! `P $!```(RP$X
> M8P``T0$!````_P$8`!@``0("```(```0\ @```! !6 28!)@!@\`!/"4````
> MH@P*\ @```!I$ ````H``(,`"_ P````@ #,W_,#OP`"``(`@0$$```(@P$`
> M```(OP$``! `P $!```(_P$```@``0("```(```0\ @```!@!H 00!2 !P\`
> M#? T``````"?#P0````$``````"@#P(````F( ``H0\6`````@```````"@`
> M``$`,@`"``````````\`!/!(````$@`*\ @````!$ ````P``(,`"_ P````
> M@0$````(@P$%```(DP&.GXL`E '>O6@`OP$2`!(`_P$```@`! ,)````/P,!
> M``$`$ #P!R ```#___\``````(" @ ```````,R9`#,SS #,S/\`LK*R``\`
> M[@/D`0```@#O`Q@`````````#Q ```````````" ``````<````/``P$E $`
> M``\``O",`0``0 `(\ @````#`````P@```\``_ D`0``#P`$\"@````!``GP
> M$ `````````````````````````"``KP" `````(```%````#P`$\'(````2
> M``KP" ````((```@`@``4P`+\!X```!_````! " `*Q)!@2_`0```0#_`0``
> M`0`!`P($`````!#P" ```) `@ &@%& ##P`1\! ``````,,+" `````````/
> M``8$#P`-\ P``````)X/! `````````/``3P<@```!(`"O (`````P@``" "
> M``!3``OP'@```'\````$`( `5$H&!+\!```!`/\!```!``$#`P0`````$/ (
> M````, .P`0`5X T/`!'P$ ``````PPL(`````0```! `!@0/``WP# ``````
> MG@\$`````0````\`!/!(````$@`*\ @````!" ````P``(,`"_ P````@0$`
> M```(@P$%```(DP&.GXL`E '>O6@`OP$2`!(`_P$```@`! ,)````/P,!``$`
> M$ #P!R ```#___\``````(" @ ```````,R9`#,SS #,S/\`LK*R``\`[@/D
> M`0```@#O`Q@````!````#0X```````````" ``````<````/``P$E $```\`
> M`O",`0``4 `(\ @````#`````PP```\``_ D`0``#P`$\"@````!``GP$ ``
> M```````````````````````"``KP" `````,```%````#P`$\'(````2``KP
> M" ````(,```@`@``4P`+\!X```!_````! " ``B4!@2_`0```0#_`0```0`!
> M`P($`````!#P" ```) `L '0%- "#P`1\! ``````,,+" `````````-``8$
> M#P`-\ P``````)X/! `````````/``3P<@```!(`"O (`````PP``" "``!3
> M``OP'@```'\````$`( `R)4&!+\!```!`/\!```!``$#`P0`````$/ (````
> MT *P`= 4``\/`!'P$ ``````PPL(`````0````X`!@0/``WP# ``````G@\$
> M`````0````\`!/!(````$@`*\ @````!# ````P``(,`"_ P````@0$````(
> M@P$%```(DP&.GXL`E '>O6@`OP$2`!(`_P$```@`! ,)````/P,!``$`$ #P
> M!R ```#___\``````(" @ ```````,R9`#,SS #,S/\`LK*R``\`[@/D`0``
> M`@#O`Q@````!````#0X```````````" ``````<````/``P$E $```\``O",
> M`0``< `(\ @````#`````QP```\``_ D`0``#P`$\"@````!``GP$ ``````
> M```````````````````"``KP" `````<```%````#P`$\'(````2``KP" ``
> M``(<```@`@``4P`+\!X```!_````! " `*A)\P._`0```0#_`0```0`!`P($
> M`````!#P" ```/ `4 %P%, ##P`1\! ``````,,+" `````````-`/,##P`-
> M\ P``````)X/! `````````/``3P<@```!(`"O (`````QP``" "``!3``OP
> M'@```'\````$`( `8(/S`[\!```!`/\!```!``$#`P0`````$/ (````\ .P
> M`= 4``\/`!'P$ ``````PPL(`````0````X`\P,/``WP# ``````G@\$````
> M`0````\`!/!(````$@`*\ @````!' ````P``(,`"_ P````@0$````(@P$%
> M```(DP&.GXL`E '>O6@`OP$2`!(`_P$```@`! ,)````/P,!``$`$ #P!R `
> M``#___\``````(" @ ```````,R9`#,SS #,S/\`LK*R``\`[@/D`0```@#O
> M`Q@````!````#0X```````````" ``````<````/``P$E $```\``O",`0``
> M@ `(\ @````#`````Q0```\``_ D`0``#P`$\"@````!``GP$ ``````````
> M```````````````"``KP" `````4```%````#P`$\'(````2``KP" ````(4
> M```@`@``4P`+\!X```!_````! " `.!E\P._`0```0#_`0```0`!`P($````
> M`!#P" ```) `L '0%* "#P`1\! ``````,,+" `````````-`/,##P`-\ P`
> M`````)X/! `````````/``3P<@```!(`"O (`````Q0``" "``!3``OP'@``
> M`'\````$`( `G&;S`[\!```!`/\!```!``$#`P0`````$/ (````H *P`= 4
> M``\/`!'P$ ``````PPL(`````0````X`\P,/``WP# ``````G@\$`````0``
> M``\`!/!(````$@`*\ @````!% ````P``(,`"_ P````@0$````(@P$%```(
> MDP&.GXL`E '>O6@`OP$2`!(`_P$```@`! ,)````/P,!``$`$ #P!R ```#_
> M__\``````(" @ ```````,R9`#,SS #,S/\`LK*R``\`[@/D`0```@#O`Q@`
> M```!````#0X```````````" ``````<````/``P$E $```\``O",`0``D `(
> M\ @````#`````Q@```\``_ D`0``#P`$\"@````!``GP$ ``````````````
> M```````````"``KP" `````8```%````#P`$\'(````2``KP" ````(8```@
> M`@``4P`+\!X```!_````! " `!"I!@2_`0```0#_`0```0`!`P($`````!#P
> M" ```) `L '0%- "#P`1\! ``````,,+" `````````-``8$#P`-\ P`````
> M`)X/! `````````/``3P<@```!(`"O (`````Q@``" "``!3``OP'@```'\`
> M```$`( `&)<&!+\!```!`/\!```!``$#`P0`````$/ (````H *P`1 4``\/
> M`!'P$ ``````PPL(`````0````X`!@0/``WP# ``````G@\$`````0````\`
> M!/!(````$@`*\ @````!& ````P``(,`"_ P````@0$````(@P$%```(DP&.
> MGXL`E '>O6@`OP$2`!(`_P$```@`! ,)````/P,!``$`$ #P!R ```#___\`
> M`````(" @ ```````,R9`#,SS #,S/\`LK*R``\`[@/D`0```@#O`Q@````!
> M````#0X```````````" ``````<````/``P$E $```\``O",`0``( `(\ @`
> M```#`````R ```\``_ D`0``#P`$\"@````!``GP$ ``````````````````
> M```````"``KP" `````@```%````#P`$\'(````2``KP" ````(@```@`@``
> M4P`+\!X```!_````! " `+B&\P._`0```0#_`0```0`!`P($`````!#P" ``
> M`) `L '0%' "#P`1\! ``````,,+" `````````-`/,##P`-\ P``````)X/
> M! `````````/``3P<@```!(`"O (`````R ``" "``!3``OP'@```'\````$
> M`( `2(?S`[\!```!`/\!```!``$#`P0`````$/ (````< *P`= 4``\/`!'P
> M$ ``````PPL(`````0````X`\P,/``WP# ``````G@\$`````0````\`!/!(
> M````$@`*\ @````!( ````P``(,`"_ P````@0$````(@P$%```(DP&.GXL`
> ME '>O6@`OP$2`!(`_P$```@`! ,)````/P,!``$`$ #P!R ```#___\`````
> M`(" @ ```````,R9`#,SS #,S/\`LK*R````<A<L`````0"@``````"$&P``
> MJ30``)4V```8)@``;3H``%D\``"!. ``13X``"PD`````/4/' ````(!``"<
> M"@`#`````#% ```!````"@````$`)0$`````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M``````````````````````````````````````````````````#^_P``!0`"
> M```````````````````````!````X(6?\OE/:!"KD0@`*R>SV3 ```#8" ``
> M"P````$```!@`````@```&@````$````A ````@```"4````"0```*0````2
> M````L ````H```#0````# ```-P````-````Z ````\```#T````$0```/P`
> M```"````J ,``!X````3````1&ES8W5S<VEO;B!O;B!0871H```>````!P``
> M`'=M=V%N9P!I'@````<```!W;7=A;F<`:1X````#````.34`81X````5````
> M36EC<F]S;V9T(%!O=V5R4&]I;G0``% `0 ```(#>FP4>````0 ```! >O!YQ
> MQ,0!0 `````&4ASLQ,0!`P````4"``!'````U <``/____\#````" ")$&<,
> M```!``D```/B`P``!@`]```````1````)@8/`!@`_____P``$ ``````````
> M`, #``#0`@``"0```"8&#P`(`/____\"````%P```"8&#P`C`/____\$`!L`
> M5$Y04!0`_ `8`3(```#__T\`% ```$T`:0````H````F!@\`"@!43E!0```"
> M`/0#"0```"8&#P`(`/____\#````#P```"8&#P`4`%1.4% $``P``0````$`
> M````````!0````L"``````4````,`M "P ,%````! $-````!P```/P"``#_
> M__\````$````+0$```@```#Z`@4``0`````````$````+0$!``0````M`0``
> M"0```!T&(0#P`- "P ,`````! ```"T!```'````_ (``/___P````0````M
> M`0(`! ```/ !```(````^@(`````````````! ```"T!```0````)@8/`!8`
> M_____P``1P```(\"```1`0``P0(```@````F!@\`!@#_____`0`<````^P(`
> M````````````````````````S1(`:'_U=T ```#=!PKTOF+U=\=B]7<!````
> M```P``0````M`0,`!0````D"`````@4````4`@`````%`````@$"````$ ``
> M`"8&#P`6`/____\``$<!``"/`@``>0(``,$"```(````)@8/``8`_____P$`
> M!0````D"`````@4````4`@`````%`````@$"````!P```/P"`0`````````$
> M````+0$$``0````M`0$`!P```!L$"0%I`Y `. `$````+0$"``0````M`0``
> M!0````D"`````@4````4`@`````<````^P+%_P```````) !``````! ``!4
> M:6UE<R!.97<@4F]M86X`OF+U=\=B]7<!```````P``0````M`04`! ```/ !
> M`P`%````"0(````"!0```!0"``````4````N`1@````%`````@$!````(@``
> M`#(*X0#O`!(```!$:7-C=7-S:6]N(&]N(%!A=&@K`! `%P`:`!X`%@`7`! `
> M'0`>``\`'0`=``\`(0`:`! `'@`%````+@$!````!0````(!`@````4````"
> M`0(````$````+0$$``0````M`0$`!P```!L$40*!`Y@!. `$````+0$"``0`
> M```M`0``!0````D"`````@4````4`@`````<````^P+@_P```````) !````
> M``! ``!4:6UE<R!.97<@4F]M86X`OF+U=\=B]7<!```````P``0````M`0,`
> M! ```/ !!0`%````"0(````"!0```!0"``````4````N`1@````%`````@$!
> M````$P```#(*NP%W`0@```!796EM:6YG(!T`#@`*`!@`"@`0``\`"0`%````
> M+@$!````!0````(!`@````4````)`@````(%````% (`````!0```"X!& ``
> M``4````"`0$````-````,@J[`?8!! ```%=A;F<=``\`$ `/``4````N`0$`
> M```%`````@$"````!0````D"`````@4````4`@`````%````+@$8````!0``
> M``(!`0```"@````R"ND!& $6````/'=M=V%N9T!M86EL+FAZ:6,N961U+A(`
> M& `7`!<`#P`0`! `'@`8``X`"0`)``@`$ `.``D`#@`(``X`$0`/``@`!0``
> M`"X!`0````4````"`0(````%````"0(````"!0```!0"``````4````N`1@`
> M```%`````@$!````"@```#(*Z0%P`@(```!C;@\`#P`%````+@$!````!0``
> M``(!`@````4````)`@````(%````% (`````!0```"X!& ````4````"`0$`
> M```)````,@KI`8X"`0```#YN$@`%````+@$!````!0````(!`@````4````)
> M`@````(%````% (`````!0```"X!& ````4````"`0$````]````,@H7`I\`
> M) ```$E%5$8@-C%T:"!-965T:6YG+"!787-H:6YG=&]N+"!.;W8N-PL`% `3
> M`!(`" `0`! `"0`/``@`' `.``X`"0`*`! `#P`(``D`'0`/``P`#P`*`! `
> M#P`)`!$`#P`(``@`%P`1``\`" `1``4````N`0$````%`````@$"````!0``
> M``D"`````@4````4`@`````%````+@$8````!0````(!`0````D````R"A<"
> MGP(!````+6X*``4````N`0$````%`````@$"````!0````D"`````@4````4
> M`@`````%````+@$8````!0````(!`0```!,````R"A<"J0((````,3(L(#(P
> M,#00`! `" `(`! `$ `0`! `!0```"X!`0````4````"`0(````%`````@$"
> M````! ```"T!`0`$````+0$$`!P```#[`A `!P``````O (```"&`0("(E-Y
> M<W1E;0`````*````! ``````!0````$``````# `! ```"T!!0`$````\ $#
> M``\````F!@\`% !43E!0! `,``````````````````D````F!@\`" #_____
> M`0````,`````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````_O\```4`
> M`@```````````````````````0````+5S=6<+AL0DY<(`"LL^:XP````I (`
> M`! ````!````B ````,```"0````#P```*0````$````N ````8```# ````
> M!P```,@````(````T ````D```#8````"@```. ````7````Z ````L```#P
> M````$ ```/@````3``````$``!8````(`0``#0```! !```,````1 (```(`
> M``"H`P``'@````D```#&P<2[S]3*O@``; `>````"0```%=734=23U50``!L
> M``,```")0 ```P```$P````#````" ````,``````````P`````````#````
> M``````,```#\"@D`"P`````````+``````````L`````````"P`````````>
> M$ ``# ```! ```!4:6UE<R!.97<@4F]M86X`!0```,O.S.4``0`````-````
> MQ*S(S\GHO,;$H[#E`!,```!$:7-C=7-S:6]N(&]N(%!A=&@`)@```$1A=&$@
> M4W1R=6-T=7)E(&9O<B!,1D(@071T<FEB=71E<R H,2D`)@```$1A=&$@4W1R
> M=6-T=7)E(&9O<B!,1D(@071T<FEB=71E<R H,BD`)@```$1A=&$@4W1R=6-T
> M=7)E(&9O<B!,1D(@071T<FEB=71E<R H,RD`)@```$1A=&$@4W1R=6-T=7)E
> M(&9O<B!,1D(@071T<FEB=71E<R H-"D`% ```%!A=&@@J$,@26YD97@@8F%S
> M960`%0```%!A=&@M(&9I96QD($E$(&)A<V5D``4```!0871H``P0```&````
> M'@````L```#2T=/#M<37ULSE``,````#````'@```!$```#1W<J^SL2XY<GH
> MO,;$H[#E``,````!````'@````L```"[P[7&QJRQZLSB``,````(````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````]@\>
> M````% ```%_ D>-E0 ``!@#T`P,`& %W;7=A;F<(````=P!M`'<`80!N`&<`
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M```````````````````````````````````````````````````````!````
> M`@````,````$````!0````8````'````" ````D````*````"P````P````-
> M````#@````\````0````$0```!(````3````% ```!4````6````%P```!@`
> M```9````&@```!L````<````'0```!X````?````( ```/[___\B````(P``
> M`"0````E````)@```"<````H````_O___RH````K````+ ```"T````N````
> M+P```# ```#^____,@```#,````T````-0```#8````W````. ```/[____]
> M____.P```/[_________________________________________________
> M____________________________________________________________
> M____________________________________________________________
> M____________________________________________________________
> M____________________________________________________________
> M____________________________________________________________
> M_________________U(`;P!O`'0`( !%`&X`= !R`'D`````````````````
> M```````````````````````````````````````````6``4!__________\#
> M````$(V!9)M/SQ&&Z@"J`+DIZ ``````````````````````````_O___P``
> M````````0P!U`'(`<@!E`&X`= `@`%4`<P!E`'(`````````````````````
> M`````````````````````````````````!H``@'_______________\`````
> M```````````````````````````````````````````Q`````! ````````%
> M`%,`=0!M`&T`80!R`'D`20!N`&8`;P!R`&T`80!T`&D`;P!N````````````
> M````````````````````````* `"`0$```#__________P``````````````
> M`````````````````````````````````"$`````$ ```````% `;P!W`&4`
> M<@!0`&\`:0!N`'0`( !$`&\`8P!U`&T`90!N`'0`````````````````````
> M```````````````H``(!`@````0```#_____````````````````````````
> M`````````````````````````````(E ````````!0!$`&\`8P!U`&T`90!N
> M`'0`4P!U`&T`;0!A`'(`>0!)`&X`9@!O`'(`;0!A`'0`:0!O`&X`````````
> M`````#@``@'_______________\`````````````````````````````````
> M```````````````I`````! `````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M`/_______________P``````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M````````````````````````````````````````````````````________
> M________````````````````````````````````````````````````````
> M````````````````````````````````````````````````````````````
> M``````````````````````````````````````````#_______________\`
> M````````````````````````````````````````````````````````````
> "````
> `
> end
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: 07 Nov 2004 07:04:19 -0500

Weiming,

As i am reading your slides I cant to seem to see what the difference is
with your scheme (vs what i would call "other"). Maybe we are just
saying the same thing.

Lets use your example to refer to set g1 to value of vg1:

You say:
AttrID2[i=1].f2[j=1].g1=vg1

Other scheme:
Assuming table refered by AttrID2 has ID=2 and f2 has ID=2 and g1 has
ID=1, then configuring g1 as you described is:
[2,1,2,1,1]=vg1

Is your difference in how this is presented? i.e you seem to say:
[2,[1]],[2,[1]],1 ? Did i get this right?

It seems to me that we are both saying that a vector, such as a table
entry will have two or more "coordinates" (table,index) but a scalar
such as what you refer to as AttrID1 will have a single entry.

Please respond as soon as you can because i am not sure what to say
and i have asked around here and havent anyone who could point the
difference.

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Mon, 08 Nov 2004 00:29:02 +0100

Weiming,
Sure I could present your slides. They seem fairly self-explanatory. 
That would take max 10 min. Let's see how the chairs want to schedule this.
-Robert

Weiming Wang wrote:

>>>>Another is I hope you can add a few words on the LFB multicast when you
>>>>        
>>>>
>talk
>  
>

---

From: "Weiming Wang" <[email-masked]>
Date: Mon, 8 Nov 2004 09:47:06 +0800

Robert,

Thank you very much for your help. Just because it's out of the date for agenda, I'm not sure Chairs will be able to schedule it or not. If not, could you just help me to show (with out much explanation) it using less than 3 minites? 

Thank you.
Weiming
  ----- Original Message ----- 
  From: Robert Haas 

  Weiming,
  Sure I could present your slides. They seem fairly self-explanatory. That would take max 10 min. Let's see how the chairs want to schedule this.
  -Robert

  Weiming Wang wrote:

Thanks a lot.

Weiming

---

From: "Weiming Wang" <[email-masked]>
Date: Mon, 8 Nov 2004 10:02:17 +0800

Jamal,

----- Original Message -----
> with your scheme (vs what i would call "other"). Maybe we are just
Firstly, I should say the index based path is fairly the same as you mentioned.
Only thing I just want to specifically mention is even in the index based path
scheme, the field ID also plays important role, and the field ID is different
from index (subscript).
> [2,[1]],[2,[1]],1 ? Did i get this right?
[Weiming]This expression is actually not important. The important is it should
contain f2 ID as well as indexes.
> such as what you refer to as AttrID1 will have a single entry.
[Weiming]Yes, this is another point I just want to say. By this, I just want to
say that index-based searching is not enough. We have to use field ID (content)
based searching.

> and i have asked around here and havent anyone who could point the
Because it seems quite discussion topic and not very proper to be put in our
protocol presentation, therefore I just want to ask Robert to help to show it.

Thank you.
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: 07 Nov 2004 22:51:32 -0500

Weiming,

> scheme, the field ID also plays important role, and the field ID is different

Is this the same as content based description in slide 23?
Note that content based is under discussion

> contain f2 ID as well as indexes.

Weiming, Isnt this f2 the same as #2 that i assumed above when i said
"Assuming table refered by AttrID2 has ID=2 and f2 has ID=2 "?
Maybe you are refering to a mixture of content and Ids? 

> say that index-based searching is not enough. We have to use field ID (content)

Content based access is tabled under discussion in slide 23.

> protocol presentation, therefore I just want to ask Robert to help to show it.

I still dont see what where we have differences. If Robert can see that
difference i think it would be worth presenting it. 

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 8 Nov 2004 12:48:15 +0800

Hi Jamal,

----- Original Message -----
> Content based access is tabled under discussion in slide 23.
[Weiming]I'v seen the difference. What you refered here as content based
searching actually in my slides still belongs to the index-based path. In your
example of NOP attributes, you only have one level of table, when you put the
second level of table (that is, the Datatable in the NOP LFB you mentioned,
which sub field is another table), you will see that anything is based on what
you mean content based searching (which actually isn't content based).  Pls read
other part of my slides where I think content based searching is quite different
thing, something like:

Path = {AttrID1.f1= = vf1} && {AttrID1.f1.g1 = = vg1}

where you can see the difference is, in this path, there is no index, instead
there are values for terminal nodes. Do you think a path can include values? I
think no, therefore, my opinion is that the path except the attribute ID part
should be inside the 'Data' field.

Anyway, I think what you mean content based searching is different from what I
mean, and you actually still have not mentioned content based searching in your
example.

Actually I have had a private discusion with Joel on content searching. The
slides are actually some topic we discussed, therefore I think it maybe worth to
present it to all others.

Cheers,
Weiming

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 8 Nov 2004 13:12:20 +0800

Jamal,
----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
To: "Weiming Wang" <[email-masked]>

> 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 :)

Cheers,
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: 08 Nov 2004 05:53:21 -0500

> Sorry, but I don't think it's very proper for you to try to stop an individual

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 8 Nov 2004 19:21:45 +0800

Jamal,

----- Original Message -----

> 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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 08 Nov 2004 06:29:15 -0500

> mean, and you actually still have not mentioned content based searching in your

I did not elaborate on content addressing, just listed it as a bullet of
"under discussion" mostly because we as a protocol team have not
disccussed it since we are stuck on this that i thought is a difference
all along - just like we have not discussed block operations for the
same reasons. 

As a reminder from the doc posted by Steve (Sep 20 if you want to review
thread of discussion which i think you participated in) which described
the different table operation requirements:

---
4.3  Associative (Key-Based) Operators

In the following operators the following additional notations are used:
<key>:   Refers to the identification of the key. Note that the same
         table may be addressable by more than one key.  Indirectly,
         the key refers to the field in the table entry that will
         be compared to the <key-val>.
<mode>   Search modes as described in section 2 (e.g., exact match,
         all that match prefix, longest prefix match, range, etc.)
<key-val>  Data to be compared to the entry fields that are used as
           key. What is provided in <key-val> depends on the <key>
           and also on <mode>.
--------

Note the key-val is the value to be compared. We have no difference in
nested tables, so the expression you supplied applies here quiet well to
access content.

I have attached this document.

I also posted another document to try and map this document to
protocol-speak that i worked on. That document (was posted 2-3 weeks ago
to the protocol team) is attached. We have not reached that discussion
point is the reason this document or suggested BNF is not seen on my
slides.

Weiming, to be honest i still dont see the difference. I am giving you
the benefit of doubt given past experience with you - I think the may be
a difference. All i am saying is i dont see it.

What i would like to ask the chairs at this point is to make some time
for your presentation if possible. I will try to rush through mine and
allocate maybe 5 minutes at the end for yours if they dont have time.
Let other people judge. It is too bad we dont have you physically here.

[What you are forcing me to do now is talk more about content based
access as well as have a nested table example - which i wasnt planning
to do. The reason i have to talk more about it now is in order for
people who have no clue what this is to make a comparison against your
slides]

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 08 Nov 2004 07:58:10 -0500

Ok, heres an update. I really dont wanna add more slides - I think this
takes me to the boundary of the allocated time.
Please comment. Theres opportunity for one more update which i will do
if needed about 4 hours from now.

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Tue, 09 Nov 2004 21:33:35 +0100

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.

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.

Content-search remains to be defined more precisely, as well as block 
access. So it is too early to disagree ;-)

Regards,
-Robert

Wang,Weiming wrote:

>>>Sorry, but I don't think it's very proper for you to try to stop an
>>>      
>>>
>individual
>  
>
>>>presentation :)
>>>      
>>>

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 10 Nov 2004 11:33:41 +0800

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

Jamal,
----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
To: "Weiming Wang" <[email-masked]>

      
individual
  
presentation :)

Cheers,
Weiming

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 10 Nov 2004 10:34:54 -0500

Hi Weiming,

I am not sure if this is what you are saying all along, but i think it
may be valuable to have "relative" path encoding.

i.e you say parent-path=1,2,3,4 then everything else is relative to
that.
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.

cheers,
jamal

On Tue, 2004-11-09 at 22:33, Wang,Weiming wrote:
>         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,
>         > 
> ______________________________________________________________________
>

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 11 Nov 2004 11:35:14 +0800

Hi Jamal,

----- Original Message -----

> may be valuable to have "relative" path encoding.
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.
2. It's quite unnecessary we may set different Attributes in one single
operation, therefore the AttrID part is always the same.

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
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.e you say parent-path=1,2,3,4 then everything else is relative to
The only possible common parent path is the Attribute ID.

> 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

---

From: Robert Haas <[email-masked]>
Date: Thu, 11 Nov 2004 14:15:58 +0100

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

>operation, therefore the AttrID part is always the same.
I am not sure about this.

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

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

Regards,
-Robert

>>>        > > > > I still dont see what where we have differences. If Robert
>>>      
>>>
>can see that
>  
>
>>>        > > > Sorry, but I don't think it's very proper for you to try to
>>>      
>>>
>stop an
>  
>
>>>        > > >
>>>        >
>>>        > individual
>>>        >
>>>        > > > presentation :)
>>>        > > >
>>>        > >
>>>        > > 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
>  
>
>>>        > > 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
>  
>
>>>        phone +41-1-724-8698  fax +41-1-724-8578
>>>      
>>>
>http://www.zurich.ibm.com/~rha
>  
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Nov 2004 09:14:50 -0500

Within an LFB, there are two common classes of multiple references (GETs 
and SETs).
1) All of the elements being referenced are within the exact same 
structure, but you do not want to get / set the entire structure.  In this 
case, all of the path descriptors except the last are identical.
2) One is referencing different things in the LFB.  In that case, one is 
just as likely to change the first path identifier (what I think you mean 
by attribute ID) as any other part of the path.

Hence, I can see no argument for treating the first path element any 
differently from the others.  If we really want to optimize for cases with 
shared path, we could do so by allowing more complex nested TLVs.

Note that because we allow references to full tables and structures which 
make full SNMP OID references so expensive are less of an issue in our work.

As a minor point, note that getting / setting multiple elements can be done 
by sending multiple target selection TLVs.

Yours,
Joel M. Halpern

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 12 Nov 2004 21:15:46 +0800

Robert,

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

  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.

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

  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

    

Cheers,
Weiming

cheers,
jamal

Hi Robert,

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

        All,

        Regards,
        -Robert

        Thank you again.
        Weiming

can see that

stop an

difference".

cannot catch

understand

now.

did not

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 12 Nov 2004 21:50:51 +0800

Joel,

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>

[Weiming] I think things like addressing simultenously 1.1 and 1.2.1 may also be
quite often.

2) One is referencing different things in the LFB.  In that case, one is
just as likely to change the first path identifier (what I think you mean
by attribute ID) as any other part of the path.
[Weiming]This is a different issue from one attribute.

Hence, I can see no argument for treating the first path element any
differently from the others.
[Weiming] My view is,  from your 1) I can instead only see the benifits to pull
the attribute ID part out, for 2), it is the necessity for multiple path-data
TLVs in one OpTLV, which is another issue worthy discuss.

If we really want to optimize for cases with
shared path, we could do so by allowing more complex nested TLVs.
[Weiming]Do you mean multiple path-data TLVs in one OpTLV? If is, I agree well.
It helps well for multiple Attributes, but helps little to save Attribute IDs.

Note that because we allow references to full tables and structures which
make full SNMP OID references so expensive are less of an issue in our work.
[Weiming] Sorry, I can not catch it well. Could you explain a little more?
thanks.

As a minor point, note that getting / setting multiple elements can be done
by sending multiple target selection TLVs.
[Weiming] This is even more expensive, which means we are repeating LFB class
and LFB instance ID as well as Attribute ID.

Thank you.
Weiming

Yours,
Joel M. Halpern

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 12 Nov 2004 22:03:20 +0800

Joel,

One more thing is, for index based searching, after some operation such as add,
delete and modify, the table actually will also become a random table rather
than a linear one regarding the index. In this case, I see that the index
actually plays no more efficient role other than a general content searching,
i.e., it has actually become content(the content is the index) based searching.
Therefore, in this case, I cannot see any advantage to explicitly define Index
in the protocol over to just define the 'index' as a field in the table
structure. For latter, the path will not include any explicit index anymore, to
do index based operation is to assign an  'index'  field value.

Cheers,
Weiming

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>
To: "Wang,Weiming" <[email-masked]>; <[email-masked]>
Cc: "Robert Haas" <[email-masked]>; "Khosravi, Hormuzd M"
<[email-masked]>; "(Ram Gopal )" <[email-masked]>; "Avri
Doria" <[email-masked]>; <[email-masked]>; "Patrick Droz"
<[email-masked]>; <[email-masked]>; "Dong Ligang"
<[email-masked]>
Sent: Thursday, November 11, 2004 10:14 PM
Subject: Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level
multicast]

Yours,
Joel M. Halpern

---

From: Jamal Hadi Salim <[email-masked]>
Date: 12 Nov 2004 09:27:45 -0500

On Fri, 2004-11-12 at 09:03, Wang,Weiming wrote:
> than a linear one regarding the index.

This is not the case as has been discussed so far (in the document
posted by Steve/Zsolt as well as followup by me).
Index can be specified by the operation.
In the case index is not specified, the next available one is used.
How this is achieved or rules is discussed in those two documents.

I am sorry cant participate in the rest of the discussion because i
still dont see the differences. I would suggest we put a time limit to
this discussion so we can move to the big one which is data encoding.
Shall we say two weeks from now as the deadline?

Or maybe i should start the discussion on encoding in parallel?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 12 Nov 2004 09:35:23 -0500

> Or maybe i should start the discussion on encoding in parallel?

Actually the immediate one is probably content based and block table
operations.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 12 Nov 2004 22:37:22 +0800

Jamal,

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
Subject: Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level
multicast]

> How this is achieved or rules is discussed in those two documents.
I just see random index is unavoidable regardless of rules used.
> Or maybe i should start the discussion on encoding in parallel?
That's fine.

Cheers,
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: 12 Nov 2004 09:51:11 -0500

Weiming,

> I just see random index is unavoidable regardless of rules used.

I agree there will be holes in the indixes. So this somehow needs to be
managed.

> > Or maybe i should start the discussion on encoding in parallel?

I am travelling today, but (at the cost of probably being frowned on)
heres the document i gathered from reading Steve/Zsolt doc. It talks
about content and block operations.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Nov 2004 10:54:16 -0500

Yes, I am happy to repeat the path and data TLVs inside an OP TLV.
I just want all of the path information in the path TLV and the data in the 
data TLV.

My reference to SNMP is because one of the ugly things for SNMP is that if 
you want to fetch an entire table you have to fetch each individual element 
with a full OID for each one.  (And their OIDs are much longer than our 
path identifiers, for various historical reasons.)

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Nov 2004 10:55:53 -0500

This is an important question.
I agree that tables will develop holes.  However, because the index has no 
operational significance, it will be very easy and natural to reuse those 
holes.  Hence, the tables will not become progressively more sparse.  The 
mechanisms must cope with hole.  But we do not have to expect tables where 
only 1 in every three indices are used or some such.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: 12 Nov 2004 20:04:46 -0500

Hrm, I think i may have figured what Weiming has been saying all
along - but i could still be wrong ;->
While on the plane i started jotting down how we do data encoding in our
code. And it struck me to be probably related to what Weiming was
saying. To make sense of this please look at the slides i presented at
the last example.

In our implementation so far we havent had the opportunity to use a
nested table, but i think that example is useful.

When we do a get we pass the path as in the scheme presented so far i.e
path=1 to access goo1 and path=2 to access goo2 as well as path={4,0} to
access datatable2 first row.
So lets start with a simple example of the response getting goo1.

We get back a TLV; the T=ID=1  and the content being a padded
32 bit (since goo1 is 16 bits).

Example2:
Lets say the request path was 4 (for datatable2) in that case we get the
whole table 4.

This is encoded similarly with T being the ID in this case
T = 4, length = size of all entries in bytes + 4*numberofrows
It is assumed that all rows in the tables are 32 bit aligned.
Each table row is preceeded by a 32 bit index followed by the structure
for the row. This extra 32 bit index is not needed if the table already
has an index as part of its row contents.

I wont go into the nested table example because i want people to digest
this.

Now you could logically argue (as probably Weiming was) that to set a
value you would use the same technique.

A query and delete stay the same as before (since they only need to
identify the path). 
Dont wanna go into block or content operations yet. But it should be
noted that if you used the above mentioned encoding you could send
blocks of data to update a table as well as have holes in that table;
example you could have index0 followed by 3 and miss out 1 and 2.

I will write up more on our encoding scheme later, just wanted to share
my brain storm at 30K feet.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Nov 2004 22:16:09 -0500

I may be missing something, but when I consider likely encodings of data, 
there are two aspects.  There are element identifiers (top level attribute, 
element of struct, etc) and there are subscripts.

Now, for nested structs, or structs within tables, or any other cases, 
there is no need to encode the identifiers for the fields in the 
data.  Knowing the starting point of the data, and the type of that 
starting point, and the encoding rules, should allow one to decode the 
elements without needing either internal type identifiers or internal 
element identifiers.  Variable length elements (strings, arrays) do need 
lengths.

When an entire array is being shipped, if the elements have subscripts 
(which I want) then it is indeed necessary to include the subscripts of 
each element with that element.  There are multiple ways to adress this, 
but none of them involve putting the field identifiers into the data.

Yours,
Joel

PS: If one is going to use a verbose TLV-like encoding of the data, one may 
end up encoding the types in the data or the field identifiers.  But this 
is fundamentally redundant information.

---

From: "Weiming Wang" <[email-masked]>
Date: Sat, 13 Nov 2004 11:43:23 +0800

Joel, as well as Jamal,

----- Original Message -----

> path identifiers, for various historical reasons.)
I think we are the same at this point. Actually I'm afraid this is even a little
more to my view on puting some subpaths in the data field. I think Jamal's
latest post has also noticed this, that is, a pure data format may become quite
difficult to describe a whole table here, instead, to allow to associate the
data with some subpath will make it easier. Jamal mentioned to put index of the
table in the data in this whole table response case, I think that the response
data structure may be better structured something like (say the table has field
as (f1, f2, f3)):
        index =1, f1=2, f2=3, f3=4
        index =2, f1=5, f2=6, f3=7
this means the field id and the index is also included in the data field, rather
than only the data value is included. In this way, data encoding becomes much
simpler, it actually makes us not necessary to define individual data encoding
for all individual LFB attributes, because the format can apply to all
regardless of their different field definitions.

Of course, this is only simple show for the use of combining subpath with data.
I can see other cases where such approach may be vital. Say we need to express a
need to "get a routing table (table ID =4, field is (f1, f2, f3) as above) with
all f1=2 or  f2=3 entries". In this case, we need to express a logical
relationship 'OR' for the two paths 4.f1 and 4.f2. I can see that to express the
'OR' is more ugly between the 'path-data' than in the data field only. The
original 'path-data' approach may have to be something like:
        path= 4.f1
        data=2
        .....  (need to add something to express the logical relation 'OR' for
the two 'path-data's)
       path=4.f2
        data=3

My proposed approach will be something like:
        Attribute ID= 4
        data = < f1=2 'OR' f2=3>

I just think it is more flexible for later one.

Cheers,
Weiming

---

From: "Weiming Wang" <[email-masked]>
Date: Sat, 13 Nov 2004 11:55:14 +0800

Joel,

We'v seen more clearly our difference now after we begin to consider the data
encoding, therefore it's very good to associate our previous discussion with
followed data encoding.

----- Original Message -----

> element identifiers.  Variable length elements (strings, arrays) do need
One thing I just want to strenthen that is in my previous post is,  if the field
IDs and others are not allowed in the data field, we will have to strictly
define all individual data format (including its data PDU and appearing
sequence) for all attributes of all LFBs, which is really a horrible thing to
do. By allowing field IDs in data, we only need to define the individual field
ID actual values, which I think is much simpler and FE model can do well.

Cheers,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Nov 2004 23:21:58 -0500

Sorry, I missed something.
I believe that the protocol will have to define the encoding for all data, 
in such a fashion that any data types (including structures) describable in 
the model can be represented in well defined ways.
Given such a definition, and given that the CE and FE both know the 
definition of the data, then it can be processed.

There are actually cases where the CE may not understand part of the data 
that he is being handed.  If the structure being returned is actually a 
subclass, with additional fields, of that understood by the CE.  However, 
this actually works:
1) The CE will be able to parse all the fields he understands
2) The CE will have to ignore any fields he can not understand.  Note that 
he has to ignore them if they have no type / field ID tagging or if it has 
type and field ID tagging, since he has no idea what those fields mean anyway.

The one implication of this is that the encoding for structures and arrays 
must ALWAYS have a length.

As far as I can tell, tables, or tables within tables, do not change this 
with regard to field identification.  With regard to subscripts, there is 
room to discuss.

Given a field foo in the LFB which has ID 2, and is a structure with fields 
bar (id 1), bas (id 2), and bat (id 3), where bas is a structure with field 
cab (id 1), cac (id 2) and cad (id 3), then:
if I want to reference cac I need the path 2.2.2 somewhere.
if I want to reference bas, I need the path 2.2 somewhere, and I do not 
need the id 2 of cac inside the representation of bas.
if I want the whole field foo, I need the path 2, and I do not need the ids 
for any of the contained fields.

With regard to subscripts and content based addressing, things are more 
complicated.  In the path, we need the indication at each table of whether 
indexing is occuring, and if so which subscript or content field is being 
used.  That is type based information which can go in the path.
The question is where the subscripts or content values go.
They are going to have to have their won TLVs somewhere.  They can go 
inside the path TLV, although that will complicate the structure of the 
path TLV.
They can be siblings of the path and data TLV.
Or they can somehow be in the data TLV.
Given the structuring requirements I believe it will be simpler to make 
them (the element value selection TLVs) siblings of the path and data TLVs 
within the overall path-data structure.  I can believe that there exists a 
clean structure for putting them in the data itself.  And the placement of 
this is much less important to me than the placement of the information 
which tells me what syntax of subscripts and what syntax and semantics of 
final data I am using, namely the path information.

Yours,
Joel M. Halpern

---

From: Jamal Hadi Salim <[email-masked]>
Date: 13 Nov 2004 16:33:39 -0500

> the model can be represented in well defined ways.

Would you say that an ID is a coherent description of a data type at
a given hierachy level? I.e as someone who knows the schema/template for
a LFB I should be able to tell with 100% certainty how to decode data if
you gave me the hierachy level and the ID (assuming the ID exists in the
template), No?

> type and field ID tagging, since he has no idea what those fields mean anyway.

nod.

> with regard to field identification.  With regard to subscripts, there is 

I think every time you start encoding you need a lenght and some path ID
which says "btw, here starts foo1 which is of  length X"..
And within foo1 anytime you have anything thats of variable size such as
a string or array or cells that may reference variable sized entities
then you need again those two things { ID, length} 
If you assume these rules then you can pack data effeciently.
Sorry for jumping into encoding - it just seems that effective encoding
requires some deviation from the clean series-of-IDs approach.

> for any of the contained fields.

nod

I am gonna delete the rest of the discussion on content stuff. Can we
get some agreement on this basic stuff first?

Note - I still see the queries and deleted using the series of 32 bit
IDs to create a path.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 13 Nov 2004 17:08:18 -0500

Given that the instance ID of the LFB is actually a class-instance pair, I 
believe that the combination of an LFB ID and an LFB element PATH is enoguh 
to fully decode the data that goes with that path.  There is a need for 
some length information in the encoding, but no need for type 
information.  The CE already knows the schema and the class.  The 
mechanisms for extension are deliberately defined so taht information can 
be interpretted properly even when it is actually from an unknown subclass.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: 14 Nov 2004 13:51:21 -0500

Weiming, Joel,

Ok, If i am on the right track putting together the core of what we have
said so far, then the attached doc is a good start capturing the
discussions.
I will maintain the doc until we reach a resolution. I will accept 
diff -du against it when we agree on something. Just let me know you are
doing changes to avoid redundancy.

Main assumption i should probably state is if you are configuring things
you better know the type etc for decoding/encoding

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 14 Nov 2004 23:21:03 -0500

This appears to be on the right track.
I will try to find time to reread it in more detail.
Yours,
Joel

---

From: "Weiming Wang" <[email-masked]>
Date: Mon, 15 Nov 2004 23:06:35 +0800

Jamal,  Joel as well,

Good, I'l try to follow the example in the doc. I'm just trying to raise some
question in the line actually trying to show my view further.

To summarize, I strongly believe the Data field should allow IDs other than pure
values. I think in the examples Jamal also has shown some cases where Data are
not pure values (including index, field ids).

Regarding using Data encoding without IDs,  I really have a feeling that it is
more dangerous than with IDs. Note one bit error produced by programmer (e.g.,
mistaken one u32 to u64 and another u64 to 32) will result in the total failure
for the whole Data and the error is hard to be debugged (no IDs to verify it).
One more question is the appearing sequence also become important with this
approach, which makes the FE model schema sequence sensetive. This is really
inconvenient.

I'm trying to add Steve and Zsolt in the list (but seems Steve's server always
takes my post as spam:( .  ).

Cheers,
Weiming
---------------------
OPER_TLV : = <PATH-DATA>
PATH-DATA := flags IDcount <IDs> [BLOCK_OR_KEY_NOTATION] [DATA]
[Weiming]Why don't we just set the PATH as a TLV?

-> IDs := a series of 32bit IDs (whose size is given by IDcount) defining the
path.
[Weiming] Obviously, we need a flag to indicate the ID being index(subscript) or
field ID as
    ID:= flag(1bit)  Index(31bit) | fieldID(31bit)
    flag:=0(fieldID) | 1(index)
[/Weiming]

Assume LFB with following attributes

foo1, type u32, ID = 1

foo2, type u32, ID = 2

table2: type array, ID = 4
 elements are:
 j1, type u32, ID = 1
 j2, type u32, ID = 2
[Weiming] Let me add one more field as
 j3, type u32, ID=3

Then, very often, we may have operations as:

1) delete(or get ) all entries with j1=100, and j2=200 (note j3 is not cared)
2) modify entry with index=10 to j1=100, and j2=200 (note j3 is not to be
changed)

If we allow field ID in Data, this can be expressed easily. I just see some
difficulty using the encoding you and Joel proposed. For 2) you may say it can
be done by using two separate Path-data, but I just think this way is very
tedious, saying if we have 10 fields more. If we allow field ID in data, it can
be tidily expressed.
[/Weiming]

table1: type array, ID = 3
 elements are:
 t1, type u32, ID = 1
 t2, type u32, ID = 2  // index into table 2

[Weiming] I think a compund structural type is very common, which should be
instanced  in the example.  Let me show one as:

foo3, type structure, ID=5
{
    s1, type u32, ID=1
    s2, type structure, ID=2
    {
        g1, type u32, ID=1
        g2, type u32, ID=2
    }
 }

For this type, we then may also have very common operations as:
        Modify s1 to 100 and g1 to 200.
I also see some tidious problem if we don't allow field ID in the DataTLV.
[/Weiming]

1) To get foo1
Path IDs = 1

Result:
Path = 1, DATA_TLV with value of foo1

2) to set foo2 to 10
Path IDs = 2
DATA_TLV: L = 4+4, V=10

3) To dump table2 (get)
Path = 4

Result:
Path = 4
DATA_TLV, Length = 4 + (#of entries in table2)(8+4)
This is followed by data of the form:
subscript,j1value,j2value (subscript is 4 bytes, j1 + j2 is 8 bytes)

Note the above allows for holes in subscripts, i.e if subscript is
not in use it doesnt take space
[Weiming] Note that some tables may or may not have subscript, above format will
then result in ambiguity in semantics. If we uniformly ask IDs in Data, no such
problem then.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 16 Nov 2004 08:04:40 -0500

Weiming,

You introduce two things below:
1) content based access aka associative 
2) operations of such contents (AND, OR are the two i see you using)

We havent discussed those. But this is a good point as any to start.

Lets talk about one issue at a time

There is a TLV "KEY_INFO" Which has in its value a KEY that could be a
the ID and KEY_DATA to be the value. If we allow to have multiple of
these in a path-data then we can have complex operations.
With that in mind, let me move to the rest of your email and use this to
address your examples.

> not pure values (including index, field ids).

I think this should be available but optionaly i.e you could have
simple, BLOCK or KEY based accesses. It may also be ok to have a mixture
of all 3.

> approach, which makes the FE model schema sequence sensetive. This is really

I dont see how. The path is still composed of IDs and subscripts/indices

> takes my post as spam:( .  ).

Lets defer your idea of decomposing the ID above for now. I think we can
still achieve the goals without it.

> 1) delete(or get ) all entries with j1=100, and j2=200 (note j3 is not cared)

Can be done as follows:

Path = 4
TLV, T = KEY_INFO, Length = 4+8
KEY = 1 // j1
KEY_DATA = 100 
TLV, T = KEY_INFO, Length = 4+8
KEY = 2 // j2
KEY_DATA = 200  

The above is an && operation of the two keys. Not sure how to do ||
cleverly

Other 
Of course we could make KEY_DATA a TLV so we can have variable sized
DATA for a KEY, eg to repeat above:

Path=4
T=KEY_INFO, length = 4 + xx
   T=1,  Length= 4 + 4 // 1 is ID for j1
   V = 100
   T=2, L = 4 + 4
   V = 200

The above wastes 4 bytes per value because of TLV and is clearly more
complex to parse, but we could say thats the cost of doing this.

> 2) modify entry with index=10 to j1=100, and j2=200 (note j3 is not to be

Can use one of those two schemes above.

> tedious, saying if we have 10 fields more. If we allow field ID in data, it can

I think what you have described is content based schemes - which is not
exclusive. Both schemes need to be supported.

> I also see some tidious problem if we don't allow field ID in the DataTLV.

We could add that as another example; Lets come back to it when we have
solved some of the basic stuff

> then result in ambiguity in semantics. If we uniformly ask IDs in Data, no such

Forget about IDs for a second - I dont think we need them for this
specific case - and make a recommendation about how to word this.

Again, to reiterate both content and the other schemes need to be
supported. 

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Nov 2004 15:07:54 -0500

The more I think about it, the more I like three sets of information,
first the base path (length, sequence of identifiers)
then one or more TLVs for the subscripts, where the TLV wil contain an 
index identifier and the data to be used as a subscript.  This may be the 
base subscript, or some other field.  (The identifier is a field identifier 
rather than a type identifier since there might be two key fields for the 
same table with the same type, but differing values.)
Then for modify operations (and GET responses?) a TLV for the actual data.
If we want to allow block references, then the structure of the subscript 
TLV can be expanded to indicate ranges somehow.
This keeps the notions of "what structural thing", "which instance", and 
"what value" cleanly separated.

Yours,
Joel

---

From: "Weiming Wang" <[email-masked]>
Date: Wed, 17 Nov 2004 22:21:05 +0800

----- Original Message -----

> "what value" cleanly separated.
[Weiming] I understand your state as first coming the field IDs, then the
indexes, and last the values. A little worry is that in some cases, the field
IDs and the indexes have to be interfered to reference an entry, that is, the
path may be something liek fieldID.index.fieldID, When the index appear in the
path is important for correct addressing, that is, fieldID.index.fieldID is
different from fieldID.fieldID.index, therefore, to separately express fieldID
and indexes may make things more complex.

Cheers,
Weiming

---

From: "Weiming Wang" <[email-masked]>
Date: Wed, 17 Nov 2004 22:48:16 +0800

Jamal,

----- Original Message -----

> Lets talk about one issue at a time
[Weiming] I just think they(content based and index based) are so tightly tied
that we may have to consider it simulteneously.
> With that in mind, let me move to the rest of your email and use this to
[Weiming]My thought on this is, we do not have to recognize if it is a KEY or
not. It's just a kind of element in a path.
> still achieve the goals without it.
[Weiming]By separate the fieldIDs from Indexes, as Joel just proposed? I just
have a worry on this expression. Pls see my reply to Joel.
> TLV, T = KEY_INFO, Length = 4+8
[Weiming]I have to say above format only applies to where KEY is only with one
ID. In reality, the KEY refered here is actually a subpath, which may also have
multiple levels, like j2.g3 .
> complex to parse, but we could say thats the cost of doing this.
[Weiming]This still applies to where KEY is with one ID, not with multiple level
IDs as 1.2.

Cheers,
Weiming

> specific case - and make a recommendation about how to word this.
[Weiming]It's true to express above with IDs are more bits consuming. Actually
I'm not vitally against not using IDs in values, just a little worry that it may
also be complex to do with pure heap values, just considering above j1 is
another compond structure rather than an atomic one. We need to verify more to
see the practicability.

Cheers,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 17 Nov 2004 10:11:15 -0500

Yes, the instance selection process will essentially involve inserting the 
indices into the path.  But the semantics for what is being targetted can 
be determined without such interleaving.

Separating the indices from the path is a compromise.  From an analytic 
point of view, I would like to include the indices in the path.  With the 
push for content addressing, and some folks asking for block selection, The 
path would get too messy if the indices where in it.  SO I just end up 
concluding that the best compromise is to separate the indices from the 
path and from the data.

Just my personal conclusion,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: 17 Nov 2004 09:42:43 -0500

Weiming/Joel,

> not. It's just a kind of element in a path.

Ok, then we need a path TLV. And as Joel has been pushing for eons now,
separate the path from data; but allow recursive relationship.

> have a worry on this expression. Pls see my reply to Joel.

I am not quiet sure i have parsed what you and Joel are talking about.
My approach may even be a third one.

> [Weiming]This still applies to where KEY is with one ID, not with multiple level

To solve that we need something that allows variable path (in addition
to variable data) like:

T=PATH, Length = ZZ
  flags(16bit)=0 IDcount(16bit)=1, ID=4
  T=KEY_INFO, Length = xx
    T=PATH, Length = 4+4
      flags(16bit)=0 IDcount(16bit)=1, ID=1 //j1
    T=DATA, Length = 4+4
      V=100
    T=PATH, Length = 4+4
      flags(16bit)=0 IDcount(16bit)=1, ID=2 //j2
    T=DATA, Length = 4+4
      V=100

Essentially, KEY_INFO contains some content/data as well and reuses
PATH and DATA TLVs. So there could be a nested PATH/DATA pair.
Like i said this maybe the third view (with other two being what you and
Joel are saying)

Essentially grammar becomes:

OPER_TLV : = <PATH-DATA>
PATH-DATA := <PATH_TLV> [PATH_EXTENSIONS] [DATA]
PATH_TLV := flags IDcount <IDs>
PATH_EXTENSIONS := BLOCK_NOTATION | KEY_INFO
KEY_INFO := PATH-DATA
BLOCK_NOTATION :=   BLOCK_RANGE_INDEX_TLV | 
                    BLOCK_COUNT_INDEX_TLV |                
                    BLOCK_LIST_INDEX TLV

We dont distinguish between indices and IDs

I havent thought clearly about this but the recursive nature may
introduce loops. 

Thoughts?

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 18 Nov 2004 20:10:53 +0800

Jamal and Joel,

In reply to Joel, I should say the compromise may not be necessary, for it seems
we all tend to think indices and IDs will be interleaved under the condition
that we should use indices. Pls allow me to try to propose a path scheme(I hope
not too messy) as below:

        PathTLV:= Index|FieldID <Index|RangeMark|FieldID>+

Then,
1) path = FieldID1 Index1 Field2 --- for single index case
2) path = FieldID1 Index1 Index2 Index3 Field2 --- for listed indices case
3) path = FieldID1 Index1 RangeMark Index2 Field2 --- for block index1 to index2
case
4) path = FieldId1 Index1 Index2 RangeMark Index3 Field2 --- for list and
combined block indices cases

Where the length is controlled by the TLV length.

Based on this path TLV, and with Jamal's scheme in mind, I see the OpTLV format
as below:

        OpTLV:= MainPathTLV [SubPathTLV VALUE]+ [DataTLV]

MainPathTLV and SubPathTLV all have uniform formats as a PathTLV.

Points a little different from Jamal's are:
1. IDcount removed, instead using PathTLV's length to control
2. Key is replaced by Subpath, which allows more general multiple level IDs.
3. block operation is included in the PathTLV, where indices appear.
4. Data part should be a TLV, or else there will be a parse problem.

Cheers,
Weiming

----- Original Message -----
> BLOCK_NOTATION :=   BLOCK_RANGE_INDEX_TLV |
[Weiming]The BlockTLV will acompany indices where it appear.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 18 Nov 2004 16:50:38 -0500

Weiming,

> 1) path = FieldID1 Index1 Field2 --- for single index case

I dont follow: Why do you need all that to say get a simple top level
attribute?

> 1. IDcount removed, instead using PathTLV's length to control

I have to think about it - it should probably be able to remove it. What
happened to the flags?

> 2. Key is replaced by Subpath, which allows more general multiple level IDs.

I am not sure i followed this.
Can you reproduce the use cases i showed?

> 3. block operation is included in the PathTLV, where indices appear.

Same comment as above

> 4. Data part should be a TLV, or else there will be a parse problem.

It is a TLV as proposed earlier.

Start with the use cases i used and show how you achieve the connection
if possible.

you can ignore the key based example or include it if it will help to
see the value easier.

cheers,
jamal