From owner-rap@ops.ietf.org Thu Sep 4 05:28:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06044 for ; Thu, 4 Sep 2003 05:28:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uqN1-000DzD-G8 for rap-data@psg.com; Thu, 04 Sep 2003 09:25:39 +0000 Received: from [212.198.2.70] (helo=smtp.noos.fr) by psg.com with esmtp (Exim 4.22) id 19uqMn-000DxX-T0 for rap@ops.ietf.org; Thu, 04 Sep 2003 09:25:26 +0000 Received: (qmail 10079546 invoked by uid 0); 4 Sep 2003 09:25:24 -0000 Received: from unknown (HELO noos.fr) ([212.198.2.179]) (envelope-sender ) by 212.198.2.70 (qmail-ldap-1.03) with SMTP for ; 4 Sep 2003 09:25:24 -0000 MIME-Version: 1.0 X-Mailer: NOOSwebmail v2 Date: Thu, 04 Sep 03 11:25:24 To: rap@ops.ietf.org Reply-to: chum@noos.fr From: "chum chum" Subject: BER encoding of Unsigned32 and BITS Content-Type: text/plain; charset="iso-8859-1" Message-Id: X-Spam-Status: No, hits=1.5 required=5.0 tests=INVALID_DATE,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk Hello, I read the RFC 3084 (COPS-PR) and find in the example of BER encoding for EDP that: 02 01 08 :ipv4FilterIndex/Unsigned32/Value = 8 However, in the book "Understanding SNMP MIBs", page 396, Unsigned32 has a tag encoding of 0x42, not 0x02. Could someone tell me which one is correct? How about BER encoding for BITS? For example, in RFC 3317 (COPS-PR for DiffServ) DsIfAlgDropCapsEntry ::= SEQUENCE { dsIfAlgDropCapsType BITS, dsIfAlgDropCapsMQCount Unsigned32 } I want to encode the following: dsIfAlgDropCapsType/BITS/value = 0011100 (binary) Tag value = ?? length = ?? value = ?? Thank you very much, C. From owner-rap@ops.ietf.org Thu Sep 4 05:47:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07078 for ; Thu, 4 Sep 2003 05:47:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uqh7-000HVD-Jr for rap-data@psg.com; Thu, 04 Sep 2003 09:46:25 +0000 Received: from [192.11.222.163] (helo=ihemail2.firewall.lucent.com) by psg.com with esmtp (Exim 4.22) id 19uqgc-000HOW-KY for rap@ops.ietf.org; Thu, 04 Sep 2003 09:45:54 +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.0/Switch-2.2.0) with ESMTP id h849jpJ28245 for ; Thu, 4 Sep 2003 04:45:51 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 4 Sep 2003 11:45:50 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155023314BD@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'chum@noos.fr'" , rap@ops.ietf.org Subject: RE: BER encoding of Unsigned32 and BITS Date: Thu, 4 Sep 2003 11:45:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.4 required=5.0 tests=QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk Inline > -----Original Message----- > From: chum chum [mailto:chum@noos.fr] > Sent: donderdag 4 september 2003 13:25 > To: rap@ops.ietf.org > Subject: BER encoding of Unsigned32 and BITS > > > Hello, > > I read the RFC 3084 (COPS-PR) and find in the example of BER > encoding for EDP that: > > 02 01 08 :ipv4FilterIndex/Unsigned32/Value = 8 > > However, in the book "Understanding SNMP MIBs", page 396, > Unsigned32 has a tag encoding of 0x42, not 0x02. Could > someone tell me which one is correct? > Sounds to me that the above is indeed incorrect and should be 420108 RAP/COPS-PR folk, pls check, and if you also agree, then we should register an ERRATUM with RFc-Editor. > How about BER encoding for BITS? > For example, in RFC 3317 (COPS-PR for DiffServ) > > DsIfAlgDropCapsEntry ::= SEQUENCE { > dsIfAlgDropCapsType BITS, > dsIfAlgDropCapsMQCount Unsigned32 > } > > I want to encode the following: > > dsIfAlgDropCapsType/BITS/value = 0011100 (binary) > Tag value = ?? > length = ?? > value = ?? > tag octet string length 1 octet (BITS need to be send as complete octets) value 38 (for 00111000, last zero to make it an octet) So I think it would be 040138 RAP/COPS-PR people, pls check and comment Bert > Thank you very much, > C. > > > > From owner-rap@ops.ietf.org Thu Sep 4 05:57:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07598 for ; Thu, 4 Sep 2003 05:57:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uqr3-000JHx-2f for rap-data@psg.com; Thu, 04 Sep 2003 09:56:41 +0000 Received: from [134.169.34.18] (helo=agitator.ibr.cs.tu-bs.de) by psg.com with esmtp (Exim 4.22) id 19uqqX-000JEN-Nr for rap@ops.ietf.org; Thu, 04 Sep 2003 09:56:09 +0000 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h849txo4022639 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 4 Sep 2003 11:55:59 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h849txHV016194; Thu, 4 Sep 2003 11:55:59 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h849txke016191; Thu, 4 Sep 2003 11:55:59 +0200 Date: Thu, 4 Sep 2003 11:55:59 +0200 Message-Id: <200309040955.h849txke016191@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: chum@noos.fr CC: rap@ops.ietf.org In-reply-to: (chum@noos.fr) Subject: Re: BER encoding of Unsigned32 and BITS References: X-IBRFilter-SpamReport: -9.9 () IN_REP_TO,REFERENCES X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> chum chum writes: chum> I read the RFC 3084 (COPS-PR) and find in the example of BER chum> encoding for EDP that: chum> 02 01 08 :ipv4FilterIndex/Unsigned32/Value = 8 chum> However, in the book "Understanding SNMP MIBs", page 396, chum> Unsigned32 has a tag encoding of 0x42, not 0x02. Could someone chum> tell me which one is correct? RFC 3159 (which defines the SPPI) follows the SMIv2 and defines Unsigned32 as follows: Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) The tag [APPLICATION 2] indeed becomes 0x42 in BER so I guess RFC 3084 is buggy. If others agree to this, you should submit a defect report to the RFC editor. chum> How about BER encoding for BITS? For example, in RFC 3317 chum> (COPS-PR for DiffServ) [...] chum> I want to encode the following: chum> dsIfAlgDropCapsType/BITS/value = 0011100 (binary) Tag value = ?? chum> length = ?? value = ?? I guess this is not really defined but I think you can assume that the usual SNMP serialization rules defined in the transport mappings apply which say that BITS are encoded as OCTET STRINGs (RFC 3417, section 8): (3) When encoding an object whose syntax is described using the BITS construct, the value is encoded as an OCTET STRING, in which all the named bits in (the definition of) the bitstring, commencing with the first bit and proceeding to the last bit, are placed in bits 8 (high order bit) to 1 (low order bit) of the first octet, followed by bits 8 to 1 of each subsequent octet in turn, followed by as many bits as are needed of the final subsequent octet, commencing with bit 8. Remaining bits, if any, of the final octet are set to zero on generation and ignored on receipt. Of course, the COPS-PR/SPPI documents should say that somewhere. (Perhaps they do and I just did not see that - otherwise this is again something for the RFC editor's errata page.) /js From owner-rap@ops.ietf.org Fri Sep 5 17:06:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19223 for ; Fri, 5 Sep 2003 17:06:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19vNjs-000Jo8-WC for rap-data@psg.com; Fri, 05 Sep 2003 21:03:29 +0000 Received: from [47.103.122.112] (helo=zrc2s0jx.nortelnetworks.com) by psg.com with esmtp (Exim 4.22) id 19vNj6-000Jkz-Jd for rap@ops.ietf.org; Fri, 05 Sep 2003 21:02:40 +0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h85L2YI13407; Fri, 5 Sep 2003 16:02:34 -0500 (CDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SC6Z0QHV; Fri, 5 Sep 2003 14:02:34 -0700 Received: from tweedy.NortelNetworks.com (artpt5pc.us.nortel.com [47.140.52.97]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QZX3K9SS; Fri, 5 Sep 2003 17:02:31 -0400 Message-Id: <5.2.0.9.0.20030905112405.028009f0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 05 Sep 2003 16:46:33 -0400 To: Juergen Schoenwaelder From: Kwok Ho Chan Subject: Re: BER encoding of Unsigned32 and BITS Cc: chum@noos.fr, rap@ops.ietf.org, Kwok Ho Chan In-Reply-To: <200309040955.h849txke016191@hansa.ibr.cs.tu-bs.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk Please see inline below with denoting my comments. Thanks! -- Kwok -- At 11:55 AM 9/4/03 +0200, Juergen Schoenwaelder wrote: > >>>>> chum chum writes: > >chum> I read the RFC 3084 (COPS-PR) and find in the example of BER >chum> encoding for EDP that: > >chum> 02 01 08 :ipv4FilterIndex/Unsigned32/Value = 8 > >chum> However, in the book "Understanding SNMP MIBs", page 396, >chum> Unsigned32 has a tag encoding of 0x42, not 0x02. Could someone >chum> tell me which one is correct? > >RFC 3159 (which defines the SPPI) follows the SMIv2 and defines >Unsigned32 as follows: > >Unsigned32 ::= > [APPLICATION 2] > IMPLICIT INTEGER (0..4294967295) > >The tag [APPLICATION 2] indeed becomes 0x42 in BER so I guess RFC 3084 >is buggy. If others agree to this, you should submit a defect report >to the RFC editor. The above indicated example section does contain a typo "02". It should be "42". The typo is only in the example section, it does not affect the definition sections of the RFC. Please submit the correction. >chum> How about BER encoding for BITS? For example, in RFC 3317 >chum> (COPS-PR for DiffServ) > >[...] > >chum> I want to encode the following: > >chum> dsIfAlgDropCapsType/BITS/value = 0011100 (binary) Tag value = ?? >chum> length = ?? value = ?? > >I guess this is not really defined but I think you can assume that the >usual SNMP serialization rules defined in the transport mappings apply >which say that BITS are encoded as OCTET STRINGs (RFC 3417, section 8): > > (3) When encoding an object whose syntax is described using the > BITS construct, the value is encoded as an OCTET STRING, in > which all the named bits in (the definition of) the bitstring, > commencing with the first bit and proceeding to the last bit, > are placed in bits 8 (high order bit) to 1 (low order bit) of > the first octet, followed by bits 8 to 1 of each subsequent > octet in turn, followed by as many bits as are needed of the > final subsequent octet, commencing with bit 8. Remaining bits, > if any, of the final octet are set to zero on generation and > ignored on receipt. > >Of course, the COPS-PR/SPPI documents should say that somewhere. >(Perhaps they do and I just did not see that - otherwise this is >again something for the RFC editor's errata page.) The SPPI (RFC 3159) does not list all types used in PIBs, it only indicate the ones different from SMI. The ones that are not defined in SPPI are assumed to be same as in SMI. This is stated in SPPI, section 2 on page 4 as: "This document specifies the SPPI also via a ASN.1 definition, which is a modified version of the SMI's definition, together with descriptive text for only those elements in the SPPI's ASN.1 definition which have differences from the SMI's. For elements in the ASN.1 definition which have no descriptive text in this specification, the reader is referred to the SMI's descriptive text for that element." Hence IMHO, no RFC editor's errata page needed for this. >/js From owner-rap@ops.ietf.org Mon Sep 8 06:40:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09163 for ; Mon, 8 Sep 2003 06:40:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wJPK-0009FZ-B2 for rap-data@psg.com; Mon, 08 Sep 2003 10:38:06 +0000 Received: from [134.169.34.18] (helo=agitator.ibr.cs.tu-bs.de) by psg.com with esmtp (Exim 4.22) id 19wJOn-0009Dd-UE for rap@ops.ietf.org; Mon, 08 Sep 2003 10:37:34 +0000 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h88Aano4008030 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 8 Sep 2003 12:36:50 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h88AanHV018289; Mon, 8 Sep 2003 12:36:49 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h88AalnO018286; Mon, 8 Sep 2003 12:36:47 +0200 Date: Mon, 8 Sep 2003 12:36:47 +0200 Message-Id: <200309081036.h88AalnO018286@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: khchan@NortelNetworks.com CC: chum@noos.fr, rap@ops.ietf.org, khchan@NortelNetworks.com In-reply-to: <5.2.0.9.0.20030905112405.028009f0@zbl6c002.corpeast.baynetworks.com> (message from Kwok Ho Chan on Fri, 05 Sep 2003 16:46:33 -0400) Subject: Re: BER encoding of Unsigned32 and BITS References: <5.2.0.9.0.20030905112405.028009f0@zbl6c002.corpeast.baynetworks.com> X-IBRFilter-SpamReport: -9.9 () IN_REP_TO,REFERENCES X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Kwok Ho Chan writes: [...] Kwok> The SPPI (RFC 3159) does not list all types used in PIBs, Kwok> it only indicate the ones different from SMI. The ones that are Kwok> not defined in SPPI are assumed to be same as in SMI. This is Kwok> stated in SPPI, section 2 on page 4 as: "This document specifies Kwok> the SPPI also via a ASN.1 definition, which is a modified Kwok> version of the SMI's definition, together with descriptive text Kwok> for only those elements in the SPPI's ASN.1 definition which Kwok> have differences from the SMI's. For elements in the ASN.1 Kwok> definition which have no descriptive text in this specification, Kwok> the reader is referred to the SMI's descriptive text for that Kwok> element." Kwok, please note that the serialization of BITS into OCTET STRING values is not defined in the SMI and hence your comment does not really help. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From owner-rap@ops.ietf.org Mon Sep 8 15:04:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14589 for ; Mon, 8 Sep 2003 15:04:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wRIp-000LrL-9U for rap-data@psg.com; Mon, 08 Sep 2003 19:03:55 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.22) id 19wRIJ-000LqM-OP for rap@ops.ietf.org; Mon, 08 Sep 2003 19:03:23 +0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h88J3HS19154; Mon, 8 Sep 2003 15:03:17 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q0DASMTK; Mon, 8 Sep 2003 15:03:16 -0400 Received: from tweedy.NortelNetworks.com (tweedy.engeast.baynetworks.com [192.32.135.156]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SQRYK2CT; Mon, 8 Sep 2003 15:03:16 -0400 Message-Id: <5.2.0.9.0.20030908145246.0352c3e0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 08 Sep 2003 15:00:50 -0400 To: Juergen Schoenwaelder From: Kwok Ho Chan Subject: Re: BER encoding of Unsigned32 and BITS Cc: "Kwok-Ho Chan" , chum@noos.fr, rap@ops.ietf.org, "Kwok-Ho Chan" In-Reply-To: <200309081036.h88AalnO018286@hansa.ibr.cs.tu-bs.de> References: < <5.2.0.9.0.20030905112405.028009f0@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030905112405.028009f0@zbl6c002.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk Juergen: The intent for the SPPI is to reuse as much of SMIv2 as possible. I believe BITS is a construct created in SMIv2 (I think in the modified version). And it is described in RFC 2578 (SMIv2) section 7.1.4 on page 22. If you feel the SPPI (RFC 3159) needs to be corrected, please advise. Thank! -- Kwok -- At 12:36 PM 9/8/03 +0200, Juergen Schoenwaelder wrote: > >>>>> Kwok Ho Chan writes: > >[...] > >Kwok> The SPPI (RFC 3159) does not list all types used in PIBs, >Kwok> it only indicate the ones different from SMI. The ones that are >Kwok> not defined in SPPI are assumed to be same as in SMI. This is >Kwok> stated in SPPI, section 2 on page 4 as: "This document specifies >Kwok> the SPPI also via a ASN.1 definition, which is a modified >Kwok> version of the SMI's definition, together with descriptive text >Kwok> for only those elements in the SPPI's ASN.1 definition which >Kwok> have differences from the SMI's. For elements in the ASN.1 >Kwok> definition which have no descriptive text in this specification, >Kwok> the reader is referred to the SMI's descriptive text for that >Kwok> element." > >Kwok, please note that the serialization of BITS into OCTET STRING >values is not defined in the SMI and hence your comment does not >really help. > >/js > >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany From owner-rap@ops.ietf.org Tue Sep 9 03:03:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23214 for ; Tue, 9 Sep 2003 03:03:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wcVy-000GdS-BT for rap-data@psg.com; Tue, 09 Sep 2003 07:02:14 +0000 Received: from [134.169.34.18] (helo=agitator.ibr.cs.tu-bs.de) by psg.com with esmtp (Exim 4.22) id 19wcVS-000GY1-8q for rap@ops.ietf.org; Tue, 09 Sep 2003 07:01:42 +0000 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h8971TmA007497 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 9 Sep 2003 09:01:29 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h8971THV031597; Tue, 9 Sep 2003 09:01:29 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h8971Skf031594; Tue, 9 Sep 2003 09:01:28 +0200 Date: Tue, 9 Sep 2003 09:01:28 +0200 Message-Id: <200309090701.h8971Skf031594@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: khchan@NortelNetworks.com CC: khchan@NortelNetworks.com, chum@noos.fr, rap@ops.ietf.org, khchan@NortelNetworks.com In-reply-to: <5.2.0.9.0.20030908145246.0352c3e0@zbl6c002.corpeast.baynetworks.com> (message from Kwok Ho Chan on Mon, 08 Sep 2003 15:00:50 -0400) Subject: Re: BER encoding of Unsigned32 and BITS References: < <5.2.0.9.0.20030905112405.028009f0@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030905112405.028009f0@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030908145246.0352c3e0@zbl6c002.corpeast.baynetworks.com> X-IBRFilter-SpamReport: -3.3 () IN_REP_TO X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_01,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Kwok Ho Chan writes: Kwok> The intent for the SPPI is to reuse as much of SMIv2 as Kwok> possible. I believe BITS is a construct created in SMIv2 (I Kwok> think in the modified version). And it is described in RFC 2578 Kwok> (SMIv2) section 7.1.4 on page 22. Kwok, we are discussing the _encoding_ of BITS and not the BITS construct per se. As I wrote before, the _encoding_ of BITS when using SNMP is defined in RFC 3417 section 8 and is not really defined for COPS-PR as far as I can tell. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From owner-rap@ops.ietf.org Fri Sep 12 11:45:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28840 for ; Fri, 12 Sep 2003 11:45:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xq56-0001zH-Sd for rap-data@psg.com; Fri, 12 Sep 2003 15:43:32 +0000 Received: from [194.117.21.40] (helo=mail.di.fc.ul.pt) by psg.com with esmtp (Exim 4.22) id 19xq4L-0001v6-3C for rap@ops.ietf.org; Fri, 12 Sep 2003 15:42:45 +0000 Received: from di.fc.ul.pt (globdata01.di.fc.ul.pt [194.117.20.216]) by mail.di.fc.ul.pt (8.11.6/8.11.6) with ESMTP id h8CFgUg25415 for ; Fri, 12 Sep 2003 16:42:30 +0100 Message-ID: <3F61E966.1070706@di.fc.ul.pt> Date: Fri, 12 Sep 2003 16:42:30 +0100 From: Nuno Carvalho User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: RSVP (or other recent reservation protocol) implementation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-mail: Found to be clean X-SpamCheck-mail: not spam (whitelisted), SpamAssassin (score=2.6, required 8, RCVD_IN_OSIRUSOFT_COM, SPAM_PHRASE_02_03, USER_AGENT, USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG, X_OSIRU_OPEN_RELAY) X-Spam-Status: No, hits=0.0 required=5.0 tests=USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'm a researcher that is starting to work with protocols that make QoS reservations. I need to find some implementation of RSVP or another more recent protocol. Can someone help me finding some pointers to protocols that are being used now, or some recent implementation of RSVP? I found some in the WWW but they seem to be old. Thanks for your attention! Best regards, Nuno Carvalho From owner-rap@ops.ietf.org Mon Sep 15 16:33:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25330 for ; Mon, 15 Sep 2003 16:33:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yzzD-0006Um-UI for rap-data@psg.com; Mon, 15 Sep 2003 20:30:15 +0000 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by psg.com with esmtp (Exim 4.22) id 19yzyS-0006Ku-Ff for rap@ops.ietf.org; Mon, 15 Sep 2003 20:29:28 +0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8FKTNi28779; Mon, 15 Sep 2003 13:29:24 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S5BC4Z4J; Mon, 15 Sep 2003 13:29:24 -0700 Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.156]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZWAH7CK; Mon, 15 Sep 2003 16:29:22 -0400 Message-Id: <5.2.0.9.0.20030915160834.028c6390@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 15 Sep 2003 16:24:29 -0400 To: chum@noos.fr From: Kwok Ho Chan Subject: Re: BER encoding of Unsigned32 and BITS Cc: rap@ops.ietf.org, schoenw@ibr.cs.tu-bs.de, Kwok Ho Chan In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk Chum: SPPI treats BITS the same way SNMPv2/SMIv2 does, as a pseudotype. Hence the encoding will be the same. For: >DsIfAlgDropCapsEntry ::= SEQUENCE { > dsIfAlgDropCapsType BITS, > dsIfAlgDropCapsMQCount Unsigned32 >} > >I want to encode the following: > >dsIfAlgDropCapsType/BITS/value = 0011100 (binary) tag value = 0x04 (same as for OCTET STRING) length = 0x01 value = 0x38 (for binary 0011 100 0, with zero padded at LSBit) Hope this helped. We may also need to see if the SPPI needs to be updated on explaining this. -- Kwok -- At 11:25 AM 9/4/03 +0000, chum chum wrote: >Hello, > >I read the RFC 3084 (COPS-PR) and find in the example of BER encoding for >EDP that: > >02 01 08 :ipv4FilterIndex/Unsigned32/Value = 8 > >However, in the book "Understanding SNMP MIBs", page 396, Unsigned32 has a >tag encoding of 0x42, not 0x02. Could someone tell me which one is correct? > >How about BER encoding for BITS? >For example, in RFC 3317 (COPS-PR for DiffServ) > >DsIfAlgDropCapsEntry ::= SEQUENCE { > dsIfAlgDropCapsType BITS, > dsIfAlgDropCapsMQCount Unsigned32 >} > >I want to encode the following: > >dsIfAlgDropCapsType/BITS/value = 0011100 (binary) >Tag value = ?? >length = ?? >value = ?? > >Thank you very much, >C. From owner-rap@ops.ietf.org Fri Sep 26 10:15:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07776 for ; Fri, 26 Sep 2003 10:15:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2tLA-000GYY-U4 for rap-data@psg.com; Fri, 26 Sep 2003 14:13:00 +0000 Received: from [192.11.222.163] (helo=ihemail2.firewall.lucent.com) by psg.com with esmtp (Exim 4.22) id 1A2tL2-000GYC-Ju for rap@ops.ietf.org; Fri, 26 Sep 2003 14:12:52 +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.0) with ESMTP id h8QECnu11620 for ; Fri, 26 Sep 2003 09:12:49 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Fri, 26 Sep 2003 16:12:48 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC30B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Rap-wg (E-mail)" Subject: FW: RAP WG open items Date: Fri, 26 Sep 2003 16:12:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=0.0 required=5.0 tests=ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk Since I am threatening to shutdwon the WG, I concluded it is best to post this to the WG list as well. Thanks, Bert (AD hat on) -----Original Message----- From: Wijnen, Bert (Bert) Sent: vrijdag 26 september 2003 16:12 To: 'Hahn, Scott'; 'mlstevens@rcn.com'; Wijnen, Bert (Bert) Cc: 'Walter Weiss'; 'jrv@umich.edu'; 'dspence@interlinknetworks.com'; 'fdijkstr@science.uva.nl'; 'delaat@science.uva.nl'; 'lgommans@science.uva.nl'; 'Kulkarni, Amol'; 'Sahita, Ravi'; 'khchan@nortelnetworks.com'; Randy Bush (E-mail) Subject: RE: RAP WG open items WG chairs (Scott specifically). I have not seen any follow up on the below. We are now another month further. If I di not see real action in the next few weeks, I think that I can only conclude that it is time to just shutdown the WG. Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: donderdag 28 augustus 2003 0:35 > To: Hahn, Scott; bwijnen@lucent.com > Cc: Walter Weiss; jrv@umich.edu; dspence@interlinknetworks.com; > fdijkstr@science.uva.nl; delaat@science.uva.nl; > lgommans@science.uva.nl; > Kulkarni, Amol; Sahita, Ravi; khchan@nortelnetworks.com; > mlstevens@rcn.com; Randy Bush (E-mail) > Subject: RE: RAP WG open items > > > Thanks for the Update Scott. > > See comments inline. > > > -----Original Message----- > > From: Hahn, Scott [mailto:scott.hahn@intel.com] > > Sent: woensdag 27 augustus 2003 19:49 > > To: bwijnen@lucent.com > > Cc: Walter Weiss; jrv@umich.edu; dspence@interlinknetworks.com; > > fdijkstr@science.uva.nl; delaat@science.uva.nl; > > lgommans@science.uva.nl; > > Kulkarni, Amol; Sahita, Ravi; khchan@nortelnetworks.com; > > mlstevens@rcn.com > > Subject: RAP WG open items > > > > > > Bert, > > A few weeks ago we had an email exchange over the future of > some of the > > open RAP WG items. I have followed up with the authors of > the BIND PIB > > and there is consensus among the authors that the work involved to > > complete draft is large enough that they do not believe it would be > > accomplished in the near term. As a result, I believe we will > > remove the BIND PIB from the WG items that need to be completed. > > > OK, pls send a request to ietf-action@ietf.org to remove the doc from > the WG charter page. Copy me so that I can approve it. > > > As an update to the other open work item, COPS over TLS, I > believe the > > security issues raised by Uri Blumenthal have been addressed in the > > latest draft and I have sent a note to him asking if he is satisfied > > with the response. At this point I have not heard back. My > > assumption is that the "COPS over TLS" draft is close enough to > > completion that it will complete the RFC process before the WG > > closes down. > > > Pls resend the email to Uri with copy to me and ask him when he > expects to respond. Pls copy me on such emails. He is involved at > my request as he serves as security-expert for the OPS NM area and > so I need to make sure he reacts promptly. > > Hopefully we can get this completed soon. > > Bert > > -Scott > > >