Randy: > On 2022-11-06 5:41 AM, Russ Housley wrote: >> I have no objection to this document being published, but I do request a small editorial change. >> Section 2.3 says: >> Although such requests are rare, registrations can be deleted. When >> a registration is deleted, all identifying information is removed >> from the registry, and the value is marked as "returned." Returned >> values will not be made available for re-assignment until all other >> unassigned values have been exhausted. >> It would be helpful to say that the upper bound is described in the next section. >> By the way, many common tools deal with OID elements much larger than 2**32-1. >> The dumpasn1 tool will properly display this OID: >> 014: OBJECT IDENTIFIER '1 3 6 1 4 1 4611686018427387903' >> But, dumpasn1 has trouble with bigger element values. The pyasn1 library does fine with much bigger values. > > But FWIW it's a longstanding limitation of SNMP. > For example RFC 2578 says: > > An OBJECT IDENTIFIER value is an ordered list of non-negative > numbers. For the SMIv2, each number in the list is referred to as a > sub-identifier, there are at most 128 sub-identifiers in a value, and > each sub-identifier has a maximum value of 2^32-1 (4294967295 > decimal). > > I know that's *not* what the ASN.1 specs said, but it's a general > limitation of SNMP implementations due to the constraints on the > ASN.1 BER laid down in the SMI. I am not an author of the draft. However, it sounds like the justification for the limitation on the PEN registry assignments needs to be expanded. Russ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
