[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian OID / dicom3tools packaging



On Tue, Jan 27, 2009 at 01:05:25PM +0100, Mathieu Malaterre wrote:
> http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration
> 
> ...
> To use SNMP one needs an Enterpise UID assigned by IANA, which is free
> and may also be used for any other purpose that requires a UID root.
> 
>     * http://www.iana.org/cgi-bin/enterprise.pl to register
>     * http://www.iana.org/assignments/enterprise-numbers to see the registry
> 
> 
> You use the assigned enterpise number as xxxx in "1.3.6.1.4.1.xxxx"
> ...

I'm not online at the moment, so I can't read the FAQ reference given, but
this most categorically *not* what an OID is supposed to be used for,
*especially* in the SNMP context.

An OID is supposed to provide a globally-unique but *stable* tree path to
retrieve an SNMP value.  You can't write a MIB if your OIDs are always
changing out from underneath you.

Instead, the SNMP MIB for this device should provide a table mapping the
UUID of the device to entries in a table, or (if there's only one device per
SNMP agent) then you can shortcut the table part of the whole thing.

>   Which would mean for debian that I could simply be using
> 1.3.6.1.4.1.9586 (https://dsawiki.debian.org/dsawiki/iana). Would that
> be ok ? Should I be using some kind of subspace of this UID ? Since
> this would be done for debian-med I would suggest:
> 
> $ echo "med" | od -b
> 0000000 155 145 144 012
> 
>  1.3.6.1.4.1.9586.155.145.144
> 
> This would be the toplevel (root) of all UID generated from the
> dicom3tools package.

Despite the similarity in acronym, an OID is not like a (U)UID.  If you need
a globally-unique value to identify a device or otherwise, we have whole
RFCs dedicated to the task of describing how to generate one.  Trying to
brutalise an OID tree into doing the job is just plain *weird*, not to
mention a bunch of other less-complimentary phrases.

- Matt


Reply to: