Re: [Forces-protocol] Feedback: Section 6.4

Jamal Hadi Salim <hadi@znyx.com> Sun, 24 October 2004 13:18 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 JAA26741 for <forces-protocol-web-archive@ietf.org>; Sun, 24 Oct 2004 09:18:37 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLiTs-0005wl-BC for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 09:32:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLiFg-0002lZ-6K; Sun, 24 Oct 2004 09:17:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLiEk-0002eo-Ha for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 09:16: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 JAA26546 for <forces-protocol@ietf.org>; Sun, 24 Oct 2004 09:16:40 -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 1CLiRw-0005v8-PB for forces-protocol@ietf.org; Sun, 24 Oct 2004 09:30:24 -0400
Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102406190698:39640 ; Sun, 24 Oct 2004 06:19:06 -0700
Subject: Re: [Forces-protocol] Feedback: Section 6.4
From: Jamal Hadi Salim <hadi@znyx.com>
To: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>
In-Reply-To: <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn>
References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <C4CB0B3C-251F-11D9-9DB1-000393CC2112@psg.com> <1098562959.1096.80.camel@jzny.localdomain> <1098564534.1098.106.camel@jzny.localdomain> <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn>
Organization: ZNYX Networks
Message-Id: <1098623794.1255.145.camel@jzny.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2
Date: 24 Oct 2004 09:16:34 -0400
X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 06:19:07 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 06:19:09 AM, Serialize complete at 10/24/2004 06:19:09 AM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: 7bit
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.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: 10ba05e7e8a9aa6adb025f426bef3a30
Content-Transfer-Encoding: 7bit

On Sun, 2004-10-24 at 08:19, Wang,Weiming wrote:

> > Isnt everything an LFB? Why not say that its for querying LFBs?
> [Weimig]it's just a top level description I think we need. i don't think it
> conflict with the ideas of LFBs. Maybe we can add one more sentense as "The
> information of a ForCES element all reside in LFBs in the element, therefore,
> query message will actually query the LFBs for kinds of information." Does it
> work?

So while you are defining that at the top; i think its also important to
have a subsection somewhere which says something along the lines of:

---
Every attribute within an LFB will have a unique 32 bit ID defined
during the LFB definition. This allows mapping any attribute within an
LFB to a path not unlike the SNMP OID. 

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


> >
> > - 6.4.1  Query Message
> >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |    Type = GET                 |               Length          |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                        Path(or Attribute ID?)                 |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                            Query Data                         |
> >                                                               .
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> > Should really be:
> >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |    Type = GET                 |               Length          |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                        Path to queried data                   |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> [Weiming] This may be better described in the followed description. So, Avri,
> could you please add the 'Path to queried data' after the Path description, just
> before the [[Under discussion and TBD]
> 
> Again, I think it may be better to leave the discussion topic on attribute
> ID/table ID here.


Read my text above on examples. If you still think that this is still
under discussion, lets tag it as so for now just so we can release the
draft. My opinion is that we have agreement on the path concept.

cheers,
jamal



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