Re: [OPS-AREA] assumption about number of octets encoding PENs
"Romascanu, Dan (Dan)" <dromasca@avaya.com> Thu, 24 May 2012 09:40 UTC
Return-Path: <dromasca@avaya.com>
X-Original-To: ops-area@ietfa.amsl.com
Delivered-To: ops-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA5021F85E5 for <ops-area@ietfa.amsl.com>; Thu, 24 May 2012 02:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.978
X-Spam-Level:
X-Spam-Status: No, score=-102.978 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+bDWlKLFcLa for <ops-area@ietfa.amsl.com>; Thu, 24 May 2012 02:40:24 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2542E21F85E1 for <ops-area@ietf.org>; Thu, 24 May 2012 02:40:24 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAJMBvk+HCzI1/2dsb2JhbAA5BwO0RIEHghUBAQEBAgESHgo/BQcEAgEIDQECAQQBAQEKBgwLAQYBRQkIAQEEARIIGoddAwYFnjeTJwiJU4p/EIF1gjtgA5sJiX+CbA
X-IronPort-AV: E=Sophos;i="4.75,650,1330923600"; d="scan'208";a="10783797"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 May 2012 05:38:40 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 May 2012 05:22:35 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 24 May 2012 11:39:54 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A0407A4F8B2@307622ANEX5.global.avaya.com>
In-Reply-To: <CBE358A7.22480%ietfdbh@comcast.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OPS-AREA] assumption about number of octets encoding PENs
Thread-Index: Ac05fyrwB05+c1xWSL6G0oGEC31XqwAET9ng
References: <20120524062516.GA5397@elstar.local> <CBE358A7.22480%ietfdbh@comcast.net>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: David Harrington <ietfdbh@comcast.net>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Randy Presuhn <randy_presuhn@mindspring.com>
Cc: pearl.liang@icann.org, Alan DeKok <aland@deployingradius.com>, ops-area@ietf.org
Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs
X-BeenThere: ops-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPS Area e-mail list <ops-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ops-area>, <mailto:ops-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ops-area>
List-Post: <mailto:ops-area@ietf.org>
List-Help: <mailto:ops-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ops-area>, <mailto:ops-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2012 09:40:25 -0000
Yes. And worse. This discussion started from the fact that RADIUS (RFC 2865) assumes 24 bits, and draft-radext-radius-extensions prepared to do the same. Actually Vendor-ID field in the Vendor-Specific attribute in RFC 2865 is defined like this: > The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order. So I there may be a way in the protocol to extend from 24 to 32 bits, but implementations need to change. Beyond 32 bits the problem is the same as with the other protocols listed below, but that moment in time seems very remote. Regards, Dan > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, May 24, 2012 10:31 AM > To: Juergen Schoenwaelder; Randy Presuhn > Cc: Romascanu, Dan (Dan); Mark Ellison; pearl.liang@icann.org; ops- > area@ietf.org; Alan DeKok > Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs > > > > > > On 5/24/12 2:25 AM, "Juergen Schoenwaelder" > <j.schoenwaelder@jacobs-university.de> wrote: > > > > >And because of this, sub-identifiers were restricted to 32 bits in > >SMIv2. In other words, assuming PENs can be larger than 32 bits will > >surely not work with SNMP. > >/js > > Notes: > 1) sysObjectID includes SMI PENs, and many SNMP network monitoring > systems > use sysObjectID to identify devices, as suggested by RFC1065. > Auto-discovery is especially reliant on these values. > 2) syslog (RFC5424) uses the SMI PEN registry. > 3) ipfix (RFC5101) uses the SMI PEN registry. > 4) sipclf IDs use the SMI PEN registry. > 5) middisc ID does not use the SMI PEN registry because it is too large > for its intended use, and requests a smaller (8-bit) vendor code > registry. > > I am not sure how these uses would be impacted by a PEN larger than 32 > bits. > > > -- > David Harrington > Internet Engineering Task Force (IETF) > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > > >
- [OPS-AREA] assumption about number of octets enco… Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Mark Ellison
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Benoit Claise
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Alexey Melnikov
- Re: [OPS-AREA] assumption about number of octets … Randy Presuhn
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Randy Presuhn
- Re: [OPS-AREA] assumption about number of octets … Benoit Claise
- Re: [OPS-AREA] assumption about number of octets … David Harrington
- Re: [OPS-AREA] assumption about number of octets … Randy Presuhn
- Re: [OPS-AREA] assumption about number of octets … Juergen Schoenwaelder
- Re: [OPS-AREA] assumption about number of octets … David Harrington
- Re: [OPS-AREA] assumption about number of octets … David Harrington
- Re: [OPS-AREA] assumption about number of octets … David Harrington
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Juergen Schoenwaelder
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Alan DeKok