From owner-rap@ops.ietf.org Mon Mar 8 13:01:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17150 for ; Mon, 8 Mar 2004 13:01:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0P3k-000M54-S9 for rap-data@psg.com; Mon, 08 Mar 2004 18:01:00 +0000 Received: from [216.155.196.93] (helo=web61004.mail.yahoo.com) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B0P3Z-000LvA-4R for rap@ops.ietf.org; Mon, 08 Mar 2004 18:00:49 +0000 Message-ID: <20040308180045.52520.qmail@web61004.mail.yahoo.com> Received: from [193.49.124.107] by web61004.mail.yahoo.com via HTTP; Mon, 08 Mar 2004 10:00:45 PST Date: Mon, 8 Mar 2004 10:00:45 -0800 (PST) From: "Jerry :-\)" Subject: Question on PRI codding To: rap@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=0.1 required=5.0 tests=BAYES_30,FROM_ENDS_IN_NUMS autolearn=no version=2.63 Sender: owner-rap@ops.ietf.org Precedence: bulk Hello, I would like to clarify the encapsulation of an PRI into PRID and EDP objects. For example, I have a PRC as follows: myExampleEntry OBJECT-TYPE SYNTAX MyExampleEntry .... ::= {1.3.6.1.2.3.4} MyExampleEntry ::= SEQUENCE { myExamplePrid InstanceId, myExampleParam1 Unsigned32, myExampleParam2 Prid } and I have an PRI of this PRC as follows: { myExamplePrid 1, myExampleParam1 5, myExampleParam2 1.3.6.1.2.3.2.1 } Then, this PRI can be codded into an PRID and EDP objects defined in COPS-PR as follows: - PRID object data (contains the ODI of the PRC followed by the Instance ID): OID : 06 length : 07 PRID : 2B 06 01 02 03 04 01 - EDP obejct data (does not include the first attribute which is myExamplePrid): Unsigned32 : 42 length : 01 value : 05 OID : 06 length : 07 PRID : 2B 06 01 02 03 02 01 Please tell me if this codding is correct. Otherwise, how to convey an PRI information using PRID and EDP objects. Thank you. __________________________________ Do you Yahoo!? Yahoo! Search - Find what you’re looking for faster http://search.yahoo.com From owner-rap@ops.ietf.org Tue Mar 16 16:45:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27524 for ; Tue, 16 Mar 2004 16:45:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3MLW-0004j4-VU for rap-data@psg.com; Tue, 16 Mar 2004 21:43:34 +0000 Received: from [192.11.223.161] (helo=auemail1.firewall.lucent.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3MLM-0004fg-1z for rap@ops.ietf.org; Tue, 16 Mar 2004 21:43:24 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2GLhKi28962 for ; Tue, 16 Mar 2004 15:43:20 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <169947SW>; Tue, 16 Mar 2004 22:43:19 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503DB0667@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Jerry :-)" , rap@ops.ietf.org Subject: RE: Question on PRI codding Date: Tue, 16 Mar 2004 22:43:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-rap@ops.ietf.org Precedence: bulk > Hello, > > I would like to clarify the encapsulation of an PRI > into PRID and EDP objects. For example, I have a PRC > as follows: > > myExampleEntry OBJECT-TYPE > SYNTAX MyExampleEntry > .... > ::= {1.3.6.1.2.3.4} > > MyExampleEntry ::= SEQUENCE { > myExamplePrid InstanceId, > myExampleParam1 Unsigned32, > myExampleParam2 Prid > } > > and I have an PRI of this PRC as follows: > > { myExamplePrid 1, > myExampleParam1 5, > myExampleParam2 1.3.6.1.2.3.2.1 > } > > Then, this PRI can be codded into an PRID and EDP > objects defined in COPS-PR as follows: > > - PRID object data (contains the ODI of the PRC > followed by the Instance ID): > OID : 06 > length : 07 > PRID : 2B 06 01 02 03 04 01 The above seems correct... at least as far as you only talk about the PRID... you need the Length, S-num and S-type as well as padding to make it 32bit boundary. Look at sect 4 and 4.1 of RFC3084. I think the complete PRID object would be encoded as: 00 0d 01 01 06 07 2B 06 01 02 03 04 01 00 00 00 > - EDP obejct data (does not include the first > attribute which is myExamplePrid): > Unsigned32 : 42 > length : 01 > value : 05 > OID : 06 > length : 07 > PRID : 2B 06 01 02 03 02 01 > > Please tell me if this codding is correct. Otherwise, > how to convey an PRI information using PRID and EDP > objects. > Again, this needs to be prefixed with the Length, S-num and S-type as per section 4.3 of RFC3084. This is already 32-bit alligned, so no padding needed. SO the resulting EPD encoding I thik would be: 00 10 03 01 42 01 05 06 07 2B 06 01 02 03 02 01 Hope this helps. Pls do realize that I am not a real COPS-PR expert. Bert > Thank you. > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Search - Find what you're looking for faster > http://search.yahoo.com > From owner-rap@ops.ietf.org Thu Mar 25 16:15:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25032 for ; Thu, 25 Mar 2004 16:15:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6cBE-0009DG-NH for rap-data@psg.com; Thu, 25 Mar 2004 21:14:24 +0000 Received: from [192.11.222.163] (helo=ihemail2.firewall.lucent.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6cBD-0009CU-Ds for rap@ops.ietf.org; Thu, 25 Mar 2004 21:14:23 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2PLEIZ17813 for ; Thu, 25 Mar 2004 15:14:19 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <16997BPW>; Thu, 25 Mar 2004 22:14:17 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503ED0605@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jesse.walker@intel.com Cc: "Rap-wg (E-mail)" Subject: AD review of: draft-ietf-rap-cops-tls-07.txt Date: Thu, 25 Mar 2004 22:14:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-rap@ops.ietf.org Precedence: bulk Took a while.. but I did find some time to do AD evaluation of this document. 1. In sect 3.2.1 you talk about Protocol and Flags. How does this fit into the ClientSI object defined in RFC2748. Is this something needs to be addressed/described in IANA Considerations? Where should IANA register this? How are future assignments to be made? For protocols? for flags? 2. In sect 3.2.2 you define new sub-error codes. How does that fit into the definition of RFC2748? Are the sub-error codes zero by default? ANyway, this needs more explanation in IANA considerations as to how/where IANA needs to put these new assignments and how future values can be allocated, no? 3. Section 7 states that the non-well-know port needs to be communicated by the server to the client. But it does not explain how. Am I missing something here? 4. You may want to add IPR and copyright notices as per RFCs3667/8/9 Thanks, Bert From owner-rap@ops.ietf.org Tue Mar 30 20:13:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14374 for ; Tue, 30 Mar 2004 20:13:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B8UGF-0003bg-Gl for rap-data@psg.com; Wed, 31 Mar 2004 01:11:19 +0000 Received: from [134.134.136.6] (helo=hermes.jf.intel.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8UGC-0003bH-Mw for rap@ops.ietf.org; Wed, 31 Mar 2004 02:11:16 +0100 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2V1DbYb030912; Wed, 31 Mar 2004 01:14:16 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2V0ben0028478; Wed, 31 Mar 2004 00:38:40 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004033016454405152 ; Tue, 30 Mar 2004 16:45:44 -0800 Received: from orsmsx403.amr.corp.intel.com ([192.168.65.209]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Mar 2004 16:45:44 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: AD review of: draft-ietf-rap-cops-tls-07.txt Date: Tue, 30 Mar 2004 16:45:44 -0800 Message-ID: <37F890616C995246BE76B3E6B2DBE055171E9C@orsmsx403.jf.intel.com> Thread-Topic: AD review of: draft-ietf-rap-cops-tls-07.txt Thread-Index: AcQSrlognq1whDwoTxG/WsB/HHclywEBxPMw From: "Kulkarni, Amol" To: "Wijnen, Bert (Bert)" , "Walker, Jesse" Cc: "Rap-wg (E-mail)" X-OriginalArrivalTime: 31 Mar 2004 00:45:44.0561 (UTC) FILETIME=[80024610:01C416B9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Bert, Thanks for evaluating the draft. Please see my reply below. Thanks, Amol -----Original Message----- From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Thursday, March 25, 2004 1:14 PM To: Walker, Jesse Cc: Rap-wg (E-mail) Subject: AD review of: draft-ietf-rap-cops-tls-07.txt Took a while.. but I did find some time to do AD evaluation of this document. 1. In sect 3.2.1 you talk about Protocol and Flags. How does this fit into the ClientSI object defined in RFC2748. Is this something needs to be addressed/described in IANA Considerations? Where should IANA register this? How are future assignments to be made? For protocols? for flags?=20 2. In sect 3.2.2 you define new sub-error codes. How does that fit into the definition of RFC2748? Are the sub-error codes zero by default? ANyway, this needs more explanation in IANA considerations as to how/where IANA needs to put these new assignments and how future values can be allocated, no? --------------- Amol> I'll update the IANA consideration section for points 1 & 2. 3. Section 7 states that the non-well-know port needs to be communicated by the server to the client. But it does not explain how. Am I missing something here? --------------- Amol> The server redirects the client to the non-well-known port as explained in section 4. Maybe there was some confusion over communicating the non-well-known port to the client versus communicating it to the COPS/TCP server running on the well-known port. The draft doesn't specify the latter as it is considered out of scope. 4. You may want to add IPR and copyright notices as per RFCs3667/8/9 --------- Amol> OK.