Hello,
I was wondering whether there exists - officially or unofficially - a range of private OIDs which can be used internally (privately) in an organization, and is not allowed for schema distribution; something like private network IP address ranges (10.0.0.0/8, etc.)
The existence of such private OIDs would allow organizations to avoid registering their own OID branch, since the "private" OID range would guarrantee that these OIDs can be used internally by the organization safely and would not be included in a new schema distribution; thus, conflicts can be excluded. Any organization which would be using such a "private OID range", should not be allowed to make the associated LDAP attributes publicly available (not even searchable) in its Directory interations.
Secondarily, the above would also serve as an "example" range of OIDs which could be used for communication of schema drafts.
I haven't come across something like this until now.
Thanks, Nick
Nick Milas wrote:
I was wondering whether there exists - officially or unofficially - a range of private OIDs which can be used internally (privately) in an organization, and is not allowed for schema distribution; something like private network IP address ranges (10.0.0.0/8, etc.)
No.
The existence of such private OIDs would allow organizations to avoid registering their own OID branch, since the "private" OID range would guarrantee that these OIDs can be used internally by the organization safely and would not be included in a new schema distribution; thus, conflicts can be excluded.
I don't see how this avoids conflicts.
IANA gives away enterprise-IDs for free. There's no reason why not to register one.
Any organization which would be using such a "private OID range", should not be allowed to make the associated LDAP attributes publicly available (not even searchable) in its Directory interations.
Maybe you should try to provide a good definition on what is "publicly available" and I will tear it to pieces. ;-}
Did you ever participate in a company merger where both companies are using the private network IP address ranges (10.0.0.0/8)?
Secondarily, the above would also serve as an "example" range of OIDs which could be used for communication of schema drafts.
You can safely define your own example OID branch for whatever you need it.
I haven't come across something like this until now.
And that's good!
Ciao, Michael.
Le 2/24/12 1:47 PM, Nick Milas a écrit :
Hello,
I was wondering whether there exists - officially or unofficially - a range of private OIDs which can be used internally (privately) in an organization, and is not allowed for schema distribution; something like private network IP address ranges (10.0.0.0/8, etc.)
Yes. Get one OID for your organization (a PEN number) at http://pen.iana.org/pen/PenApplication.page
On 24/2/2012 5:17 μμ, Emmanuel Lécharny wrote:
Get one OID for your organization (a PEN number) at http://pen.iana.org/pen/PenApplication.page
Thanks to all for the feedback.
In the meantime, I also found this page: http://stackoverflow.com/questions/725837/experimental-private-branch-for-oi... with useful info.
Regards, Nick
Nick Milas wrote:
On 24/2/2012 5:17 μμ, Emmanuel Lécharny wrote:
Get one OID for your organization (a PEN number) at http://pen.iana.org/pen/PenApplication.page
Thanks to all for the feedback.
In the meantime, I also found this page: http://stackoverflow.com/questions/725837/experimental-private-branch-for-oi... with useful info.
Looking at the web page above:
1. I'd not follow Jim's advice to use a different first number (although I much respect Jim's LDAP and eDirectory knowledge).
2. Two other responses also recommend using your own OID arc.
3. AFAICS the UUID-based OIDs do not allow structured OID assignments.
Personally if things are not working fast enough in a project I have defined a non-public customers OID arc under my own enterprise ID where several customers of mine who do not want to register an enterprise-ID themselves get their own OID arc. Yes, that requires some discipline on my side but it's not much work.
Ciao, Michael.
Nick Milas wrote:
On 25/2/2012 1:30 μμ, Michael Ströder wrote:
Two other responses also recommend using your own OID arc.
I have already applied for my own OID arc. :-)
I sent the link just for information completeness (of this thread) purposes.
I sent response also just for information completeness.
Ciao, Michael.
For completness, the reason OIDs are starting with 0, 1 or 2 and nothing else is that the two first numbers are encoded in one byte. Using a higher value is not a good idea. Le 25 févr. 2012 13:16, "Michael Ströder" michael@stroeder.com a écrit :
Nick Milas wrote:
On 25/2/2012 1:30 μμ, Michael Ströder wrote:
Two other responses also recommend using your own OID arc.
I have already applied for my own OID arc. :-)
I sent the link just for information completeness (of this thread) purposes.
I sent response also just for information completeness.
Ciao, Michael.
Emmanuel Lecharny elecharny@apache.org wrote:
For completness, the reason OIDs are starting with 0, 1 or 2 and nothing else is that the two first numbers are encoded in one byte. Using a higher value is not a good idea.
Not quite. Been reading _A Layman's Guide to a Subset of ASN.1, BER, and DER_? It has some errors.
For the two first OID components X.Y, Y must be < 40 if X < 2, and X must be <= 2. If X = 2, Y can be any nonnegative number.
That's because BER stores each OID component is stored as an integer, except the two first components are stored as one integer 40X+Y. It's a space optimization which the inventors later came to regret.
Also it's preferable to keep 40X+Y and each component < 2**31, in case your OIDs meet some implementation which stores each component as a machine integer.
LDAP itself does not use BER format for OIDs, it sends the text format. Except in a few places like certificates.
Le 2/26/12 3:48 PM, Hallvard B Furuseth a écrit :
Emmanuel Lecharny elecharny@apache.org wrote:
For completness, the reason OIDs are starting with 0, 1 or 2 and nothing else is that the two first numbers are encoded in one byte. Using a higher value is not a good idea.
Not quite. Been reading _A Layman's Guide to a Subset of ASN.1, BER, and DER_? It has some errors.
For the two first OID components X.Y, Y must be < 40 if X < 2, and X must be <= 2. If X = 2, Y can be any nonnegative number.
That's because BER stores each OID component is stored as an integer, except the two first components are stored as one integer 40X+Y. It's a space optimization which the inventors later came to regret.
Also it's preferable to keep 40X+Y and each component < 2**31, in case your OIDs meet some implementation which stores each component as a machine integer.
LDAP itself does not use BER format for OIDs, it sends the text format. Except in a few places like certificates.
I should have double checked my (6 years old) facts :)
Thanks Hallvard !
Hallvard B Furuseth wrote:
Emmanuel Lecharny elecharny@apache.org wrote:
For completness, the reason OIDs are starting with 0, 1 or 2 and nothing else is that the two first numbers are encoded in one byte. Using a higher value is not a good idea.
Not quite. Been reading _A Layman's Guide to a Subset of ASN.1, BER, and DER_? It has some errors.
For the two first OID components X.Y, Y must be < 40 if X < 2, and X must be <= 2. If X = 2, Y can be any nonnegative number.
That's because BER stores each OID component is stored as an integer, except the two first components are stored as one integer 40X+Y. It's a space optimization which the inventors later came to regret.
But X > 2 is not possible. That's what Emmanuel basically said in the context of this thread.
Ciao, Michael.
openldap-technical@openldap.org
-
Emmanuel Lecharny -
Emmanuel Lécharny -
Hallvard B Furuseth -
Michael Ströder -
Nick Milas