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: Sun, 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
- RE: [Forces-protocol] Header Section Khosravi, Hormuzd M
- RE: [Forces-protocol] Header Section Jamal Hadi Salim
- Re: [Forces-protocol] Header Section avri
- RE: [Forces-protocol] Header Section Khosravi, Hormuzd M
- Re: [Forces-protocol] Header Section avri
- Re: [Forces-protocol] Header Section Wang,Weiming
- [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB… Robert Haas
- Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE… Weiming Wang
- Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE… avri
- Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE… Robert Haas
- Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE… Robert Haas
- Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE… Jamal Hadi Salim
- [Forces-protocol] querry message (path vs attribu… Jamal Hadi Salim
- Re: [Forces-protocol] Header Section Jamal Hadi Salim
- Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE… Robert Haas
- Re: [Forces-protocol] FE Protocol LFB, FE LFB,CE … Jamal Hadi Salim
- [Forces-protocol] 01-5 avri
- [Forces-protocol] Feedback section 6.1. Jamal Hadi Salim
- [Forces-protocol] Feedback: Section 6.2 Jamal Hadi Salim
- [Forces-protocol] Feedback on section 6.3 Jamal Hadi Salim
- [Forces-protocol] Feedback: Section 6.4 Jamal Hadi Salim
- [Forces-protocol] Feedback on section 6.5 Jamal Hadi Salim
- [Forces-protocol] Feedback on rest of section 6 Jamal Hadi Salim
- [Forces-protocol] Re: querry message (path vs att… Wang,Weiming
- Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE… Wang,Weiming
- [Forces-protocol] Re: 01-5 Wang,Weiming
- Re: [Forces-protocol] Feedback: Section 6.4 Wang,Weiming
- Re: [Forces-protocol] Feedback on section 6.5 Wang,Weiming
- Re: [Forces-protocol] Re: querry message (path vs… Jamal Hadi Salim
- Re: [Forces-protocol] Feedback: Section 6.4 Jamal Hadi Salim
- Re: [Forces-protocol] Feedback on section 6.5 Jamal Hadi Salim
- [Forces-protocol] Re: 01-5 avri
- [Forces-protocol] Re: 01-5 Jamal Hadi Salim
- [Forces-protocol] Re: 01-5 avri
- [Forces-protocol] Re: 01-5 Jamal Hadi Salim
- Re: [Forces-protocol] Re: querry message (path vs… Wang,Weiming
- Re: [Forces-protocol] Feedback: Section 6.4 Wang,Weiming
- Re: [Forces-protocol] Re: querry message (path vs… Jamal Hadi Salim
- Re: [Forces-protocol] Feedback: Section 6.4 Jamal Hadi Salim
- [Forces-protocol] 01-7 avri
- Re: [Forces-protocol] Feedback: Section 6.4 Wang,Weiming
- Re: [Forces-protocol] Feedback: Section 6.4 Joel M. Halpern
- Re: [Forces-protocol] Feedback: Section 6.4 avri
- Re: [Forces-protocol] Feedback: Section 6.4 Wang,Weiming
- Re: [Forces-protocol] Feedback: Section 6.4 Jamal Hadi Salim
- Re: [Forces-protocol] Feedback: Section 6.4 Joel M. Halpern
- [Forces-protocol] Resend: Feedback: Section 6.2 Jamal Hadi Salim