Re: assumption about number of octets encoding PENs

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:[email protected]]
> Sent: Thursday, May 24, 2012 10:31 AM
> To: Juergen Schoenwaelder; Randy Presuhn
> Cc: Romascanu, Dan (Dan); Mark Ellison; [email protected]; ops-
> [email protected]; Alan DeKok
> Subject: Re: [OPS-AREA] assumption about number of octets encoding
PENs
> 
> 
> 
> 
> 
> On 5/24/12 2:25 AM, "Juergen Schoenwaelder"
> <[email protected]> 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)
> [email protected]
> +1-603-828-1401
> 
> 
> 
> 
> 
> >
>