RE: [Forces-protocol] Feedback: Section 6.4

Jamal Hadi Salim <hadi@znyx.com> Wed, 27 October 2004 13:35 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03588 for <forces-protocol-web-archive@ietf.org>; Wed, 27 Oct 2004 09:35:15 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMoBF-0005MP-7z for forces-protocol-web-archive@ietf.org; Wed, 27 Oct 2004 09:49:38 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMnsz-0003Am-24; Wed, 27 Oct 2004 09:30:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMnqx-00019B-MP for forces-protocol@megatron.ietf.org; Wed, 27 Oct 2004 09:28:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03257 for <forces-protocol@ietf.org>; Wed, 27 Oct 2004 09:28:37 -0400 (EDT)
Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMo4o-0005GQ-F4 for forces-protocol@ietf.org; Wed, 27 Oct 2004 09:43:00 -0400
Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102706305723:44169 ; Wed, 27 Oct 2004 06:30:57 -0700
Subject: RE: [Forces-protocol] Feedback: Section 6.4
From: Jamal Hadi Salim <hadi@znyx.com>
To: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0257923E@orsmsx408>
References: <468F3FDA28AA87429AD807992E22D07E0257923E@orsmsx408>
Organization: Znyx Networks
Message-Id: <1098883706.1029.11.camel@jzny.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2
Date: 27 Oct 2004 09:28:27 -0400
X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/27/2004 06:30:57 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/27/2004 06:31:06 AM, Serialize complete at 10/27/2004 06:31:06 AM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Content-Transfer-Encoding: 7bit
Cc: ram.gopal@nokia.com, "Wang, Weiming" <wmwang@mail.hzic.edu.cn>, forces-protocol@ietf.org, avri@psg.com, "Joel M. Halpern" <jhalpern@megisto.com>, Ligang Dong <donglg@mail.hzic.edu.cn>, Robert Haas <rha@zurich.ibm.com>
X-BeenThere: forces-protocol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: hadi@znyx.com
List-Id: forces-protocol <forces-protocol.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/forces-protocol>
List-Post: <mailto:forces-protocol@ietf.org>
List-Help: <mailto:forces-protocol-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=subscribe>
Sender: forces-protocol-bounces@ietf.org
Errors-To: forces-protocol-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Content-Transfer-Encoding: 7bit

Folks,

The PATH is needed for _everything_ thats interfacing to any LFB
attributes. 
Think of it as an SNMP OID - you need that _everytime_
To get to where the table etc fits in, please read the two docs i posted
to speed up the discussion; 

Heres a cutnpaste from one of those docs:

path-data
----------
The layout is still under discussion and so is left out from this text.

Each accessible attribute within an LFB is expected to have a 32 bit
identifier.

The path-data will have a map derived from the static class attribute
IDs as well as those derived from variable content such table indices 
(derived at runtime).

Below is an illustration of a complex example and how the different
attributes could be accessed.

Assume LFB Class A.
It contains two Arrays, B, and C (assigned identifiers 1 and 2)
A also contains a structure of type Stoo with a human name F.
F is assigned ID 3.
A also contains two attributes, D and E assigned identifiers 4 and 5.
Array B is an array, indexed as a table, whose contents are int32s.
Array C is an array, indexed as a table, whose contents are a structure 
named Star.
Stoo type structures contain elements X and Y, each characters, 
assigned identifiers 1 and 2.
Star contains An element N (a sting), assigned identifier 1, and an
array 
Arr, assigned identifier 2, indexed as a table, containing int32s.

To reference entities within an LFB instance of Class A, selectors
are as follows:

1, meaning the full array B
3, meaning the full structure named F.
2, 7 meaning the full structure in the seventh entry of the array C.
4 means the attribute D
2, 8, 2, 9 meaning the 9th number in the array in the structure in the 
eigth slot of the array C.
Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct 
type definition.
Since the model team has asserted that class definitions can 
only change (version) in ways that leave existing references intact 
and usable it means backward compatibility is supported.

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


cheers,
jamal

On Wed, 2004-10-27 at 03:20, Khosravi, Hormuzd M wrote:
> Jamal, Weiming,
> 
> I finally got the chance to read some of these emails...sorry for not
> responding earlier. In general, we will need the concept of PATH atleast
> for Query messages (GET), but I don't believe from any of the emails
> that I have read so far that there was any concensus on what this would
> look like. Jamal has a reasonable proposal which needs more discussion
> and refinement.
> 
> Some specific comments on Jamal's proposal so far...
> 
> Where is the Table ID ? Is this part of the path IDs?
> I don't believe we need any Flags in the path, this is similar to the
> comment that Joel had as well.
> Also, for Config msgs, I think the path can be part of the data itself,
> but lets discuss this further...cause I am not sure if you guys agree
> with this,
> 
> Talk to you soon,
> 
> regards
> Hormuzd
> 
> -----Original Message-----
> From: Jamal Hadi Salim [mailto:hadi@znyx.com] 
> Sent: Tuesday, October 26, 2004 3:59 AM
> To: Wang,Weiming
> Cc: Joel M. Halpern; Khosravi, Hormuzd M; ram.gopal@nokia.com;
> forces-protocol@ietf.org; avri@psg.com; Ligang Dong; Robert Haas
> Subject: Re: [Forces-protocol] Feedback: Section 6.4
> 
> On Tue, 2004-10-26 at 00:01, Wang,Weiming wrote:
> 
> 
> > I have no doubt to agree with this. Just need to calrify that a path
> is more
> > than 32 bits long, or there will be not enough bits.
> > 
> 
> Aha! I think i see where the misunderstanding is;->
> Weiming sees either a path like 6 or 1,2,3,4 as represented by _one_
> _fixed_ sized element. In which case you have to find a way to pack both
> representations into that fixed size element.
> 
> The suggested "path" representation is in fact _variable_.
> >From the notes i sent earlier to you, the suggestion is:
> 
> ----
>  A possible path-data layout. 
> ----------------------------
> 
> OPER_TLV : = <PATH-DATA>
> PATH-DATA := flags IDcount <IDs> [BLOCK_OR_KEY_NOTATION] [DATA]
> The operational TLV contains an opcode in the T part. Its V
> contains the PATH-DATA.
> Opcodes discussed so far:
> * SET (create, modify or both depending on PATH-DATA flags}
> * DEL (remove an existing entity specified by PATH-DATA }
> * GET (Access a entity specified in PATH-DATA }
> * EV_S (subscribe to an event defined in PATH-DATA }
> * EV_U (unsubscribe to an event defined in PATH-DATA }
> -> IDs := a series of 32bit IDs (whose size is given by IDcount)
> defining the path.
> -> flags are used to further refine the operation to be applied
> on the ID_TLV.
> -> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension
> defined in section 4.2 and 4.3 of [1]
> -> DATA : = Optional variable sized data dependent on PATH
> and applied operations (eg GET will not have DATA).
> 
> -------
> 
> Well read the rest of the doc; and for completion the notes posted by
> Steve/Zsolt.
> 
> cheers,
> jamal
> 
> 


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol