Subject: Re: [dnsext] Draft for OID

From: Noel David Torres Taño <[email-masked]>
Date: Wed, 1 May 2013 17:59:28 +0100

Hi all

Draft for DNS-like OID system has been submitted:

https://datatracker.ietf.org/doc/draft-torres-dnsext-oid/

No comments? I can really not trust I've written such a perfect document that 
nobody objects to it.

Noel Torres
er Envite
-------------------------
A: Because it breaks the logical flow of discussion.
Q: Why is top posting bad?

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 1 May 2013 19:17:06 +0200

> No comments? I can really not trust I've written such a perfect document that 

Well, I pointed at the existing registry http://www.alvestrand.no/objectid/top.html earlier, but did not see any comments from for example you :-)

Have you been in contact with Harald?

   Patrik

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Jim Reid <[email-masked]>
Date: Wed, 1 May 2013 19:32:29 +0100

> No comments? I can really not trust I've written such a perfect document that 

I don't object to the document. I just don't see what problem it solves or why/how it's needed. I think it needs a great deal of work, perhaps far, far more than you appreciate. Sorry.

The principle of putting OIDs into the DNS is sound. Any hierarchical naming or numbering scheme is an obvious fit with the DNS.

But beyond that your draft lacks vast amounts of important detail. For example, what's the justification for using a new class? Who is going to provide and operate the DNS infrastructure for that: name servers, registry, etc? Which entities are responsible for managing this new name space? What roles do they have and how do they interact with each other? Have you asked them -- ISO, ITU-T, National Standards Institutes, vendors, current users of OIDs, etc -- and what did they say? [cf The handshakes between all the actors in the management of e164.arpa.] Who manages the registries which map names to numbers for (parts of) the OID labels? How does an ISO-flavour OID -- which is delimited by spaces IIUC -- get mapped into a domain name? The purpose and meaning of the proposed RRtypes are unclear too. Who defines these types and manages the registry for them? Why does your draft propose/need a new root? Why not put all OIDs under oid.arpa (say) and just stick with the IN class, like pretty much everything else on the Internet? What does this EQUIV RRtype do that CNAME or DNAME can't? What are resolvers expected to do and not do when they encounter this EQUIV record? Are IN class RRtypes valid or not in this new name space? How is delegation done and how do resolvers traverse your new name space? Your draft has a couple of sentences on an NS RRtype but nothing on how these name servers are located or how their IP addresses (presumably) are presented in this OID class.

These are all rhetorical questions BTW. There's no need to answer them here and now but they really have to be addressed somehow in a future version of your document or set of documents.

There's the seed of a nice idea here but it needs an awful lot of hard work and attention to detail.

---

From: Noel David Torres Taño <[email-masked]>
Date: Wed, 1 May 2013 20:24:21 +0100

On Miércoles, 1 de mayo de 2013 18:17:06 Patrik Fältström wrote:
> > No comments? I can really not trust I've written such a perfect document
> > that nobody objects to it.
> 
> Well, I pointed at the existing registry
> http://www.alvestrand.no/objectid/top.html earlier, but did not see any
> comments from for example you :-)
> 

No, I knew of that page and also of http://oid-info.com but they are web-
based, thus not easily parseable, and not complete. I'm seeking for a machine-
parseable, as-complete-as-each-owner-wants-to-publicite solution.

Thanks for the comment

Noel
er Envite

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 May 2013 12:32:34 -0700

> No comments? I can really not trust I've written such a perfect document that 

I can only speak for myself about why I didn't comment. You never answered the earlier question about why this is needed. A much, much lighter-weight solution is to simply set up something in the current IN class under a name like "all-oids.org". Why expect the world to make a heavy-weight change to the DNS protocol for some use case that you don't even state?

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Thu, 2 May 2013 12:15:39 -0400

On May 1, 2013, at 3:32 PM, Paul Hoffman <[email-masked]> wrote:

> I can only speak for myself about why I didn't comment. You never answered the earlier question about why this is needed. A much, much lighter-weight solution is to simply set up something in the current IN class under a name like "all-oids.org".

Or, as another option, set up something in the current IN class under a name like "all-oids.org", using that to demonstrate how / what problem it solves and then going through all the effort of getting consensus, polishing the edges, etc. Or, just charge folk to register their OIDs in all-oids.org :-P

I don't think folk are against the idea, but there needs to be more justification than: because it's cool and easier to parse...

> Why expect the world to make a heavy-weight change to the DNS protocol for some use case that you don't even state?

+1. Demonstrate the utility (or, more clearly state the problem) and folk will probably follow along.

W

--
"Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life." -- Terry Pratchett

---

From: Noel David Torres Taño <[email-masked]>
Date: Fri, 3 May 2013 14:09:05 +0100

> I don't object to the document. I just don't see what problem it solves or
> why/how it's needed. I think it needs a great deal of work, perhaps far,
> far more than you appreciate. Sorry.

I know it is very far beyond being a candidate to RFC, but I thought that the 
best way to get interesting comments on its deficiences whould be this WG. I 
thought I may be plain wrong, but I'll never know unless trying.
> 
> The principle of putting OIDs into the DNS is sound. Any hierarchical
> naming or numbering scheme is an obvious fit with the DNS.

Thanks
> 
> But beyond that your draft lacks vast amounts of important detail. For
> example, what's the justification for using a new class? Who is going to

My intention i creating a new Class is in that the current IN Class maps a 
tree into a linear space, and do an ugly hack in the back mapping (PTR records 
and the in-addr.arpa pseudo-TLD), while this OID mapping would be for mapping 
a real tree-like structure in a unique way into another tree-like structure, 
back and forth. No ugly hack :D

> provide and operate the DNS infrastructure for that: name servers,
> registry, etc? Which entities are responsible for managing this new name

Each RA for a OID would be responsible for its own nameserver, pretty much 
like in the IN class. There is no central registry for OID as there are only 
three TLDs, each one acting as a RA and delegating under its own arc. A start 
point may be IANA running its own nameserver for 1.3.6.1 .

> space? What roles do they have and how do they interact with each other?

Responsibility for managing is actually assigned as responsibility for 
managing OID themselves. This is not a new namespace, only a new machine-ready 
way of accessing it.

> Have you asked them -- ISO, ITU-T, National Standards Institutes, vendors,
> current users of OIDs, etc -- and what did they say? [cf The handshakes
> between all the actors in the management of e164.arpa.] Who manages the

No, I have not asked them. I would not like going to them woithout a working 
implementation and a semi-usable specification at least.

> registries which map names to numbers for (parts of) the OID labels? How

Each RA manages under its own arc.

> does an ISO-flavour OID -- which is delimited by spaces IIUC -- get mapped
> into a domain name? The purpose and meaning of the proposed RRtypes are

This is only a presentation way. Dot notation is another one. This means, 
{joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) 
nistAlgorithm(4) hashAlgs(2)}, which is the OID for SHA2, can be directly 
mapped without any register to joint-iso-itu-
t.country.us.organization.gov.csor.nistAlgorithm.hashAlgs or to 
2.16.840.1.101.3.4.2 but if you have the latter, you'll have a hard time 
finding out what is it referring to.

> unclear too. Who defines these types and manages the registry for them?

IETF (that is, we) should define them, and IANA manage the register, like for 
IN class.

> Why does your draft propose/need a new root? Why not put all OIDs under
> oid.arpa (say) and just stick with the IN class, like pretty much
> everything else on the Internet? What does this EQUIV RRtype do that CNAME

I thougt it is better to have a new root matching that of the OID tree than 
faking one under the already cluttered IN tree.

> or DNAME can't? What are resolvers expected to do and not do when they

In my view, EQUIV is mainly the same as CNAME is for IN, but CNAME means "The 
canonical name of the resource your are looking for is X, go search there" and 
is not easy to view it in the reverse mapping, while EQUIV for OID means "The 
resource you are looking for is equivalent, both in alphanumerical and in 
numerical form, to X, go search there". For the machine it is the same (go 
search X), but the meaning is not.

> encounter this EQUIV record? Are IN class RRtypes valid or not in this new

Resolvers are expected to cache if they are caching resolvers, and go search 
X.

> name space? How is delegation done and how do resolvers traverse your new

They are not.

> name space? Your draft has a couple of sentences on an NS RRtype but

Resolvers should be seeded with the root nameservers like in IN class. There 
are 13 for IN class which every resolver is well aware of, and there should be 
a similar setup for OID class (maybe same servers, maybe not, maybe some of 
them volunteer and others do not). Beyond that, like in IN class the root 
servers only manage TLDs which are then delegated and managed individually by 
each country central Registrar, in OID the three (and there are only three) 
TLDs would be managed (if they want) by ISO and ITU-T. But, even if they do 
not want to, this setup can be used inside an organization like a library or 
an emergencies body which has its own OID assigned and manages it 
independently. For example, World Meteorological Organization may use 2.49.0 
even if ISO and ITU-T does not provide any DNS resource for 2.49, just 
providing that WMO computers use a nameserver that is aware on its own about 
2.49.0 (BTW, 2.49.0 is the OID used for weather alerts and weather alerting 
agencies).

> nothing on how these name servers are located or how their IP addresses
> (presumably) are presented in this OID class.

The idea is that nameservers are managed like for the IN class but they may be 
separated machines. The NS register indicates which nameservers are available 
for an OID arc. Like in current practice, inside the organizations these 
nameservers do not need to be appointed by any higher level, but just be aware 
of local names/oids.
> 
> These are all rhetorical questions BTW. There's no need to answer them here
> and now but they really have to be addressed somehow in a future version
> of your document or set of documents.

Not rethorical, they help me think twice as well!
> There's the seed of a nice idea here but it needs an awful lot of hard work

I volunteer for the hard work (didn't I?) but I need your expertise for the 
attention to detail.

Thanks

Noel
er Envite

---

From: Noel David Torres Taño <[email-masked]>
Date: Fri, 3 May 2013 14:24:06 +0100

On Miércoles, 1 de mayo de 2013 20:32:34 Paul Hoffman wrote:
> I can only speak for myself about why I didn't comment. You never answered
> the earlier question about why this is needed. A much, much lighter-weight
> solution is to simply set up something in the current IN class under a
> name like "all-oids.org". Why expect the world to make a heavy-weight
> change to the DNS protocol for some use case that you don't even state?
> 
> --Paul Hoffman

In fact, the world at large does not need to change nothing. Only machines 
which (in some way) need to deal with OIDs in this way would need a resolver 
or nameserver OID-aware.

For the question about why is needed, well, why Internet itself is needed? 
This is just a convenience that may help. About why a new class, I have just 
answered that in my answer to Jim Reid.

Regards

Noel
er Envite

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 3 May 2013 11:06:00 -0400

If it was going to be done at all. oids.arpa ??

Yes, I can see the reasons why not. And they are unfortunately the reasons
that the idea is probably unsound.

I think this proposal suffers from the authoritative registry bug. It is
not possible to establish an authoritative registry for an existing
namespace after the fact. Not unless there is a reason to believe that the
community that uses the identifier will move to the new one. Experience
with SRV shows that even that is difficult. IETF has even less claim to
OIDs.

Or at least the IETF should have less claim to OIDS. What the IETF could do
is to tell IANA to set up and manage a registry that would map to a part of
the DNS space which would in turn contain links to some source of authority
(via DNS space) describing the purpose.

So for example, I have an OID space for Default Deny Security Inc off the
IETF arc. There might be some sort of DNS record like

1.2.3.4.5.oid.arpa OIDPTR defaultdenysecurity.com

It would probably be more useful to have a URI that could point to a text
document with some description.

But what would be the use of such a scheme? OIDs are a useful idea but I
can't think of any case where having a machine readable description of an
OID would have a lot of value.

there are some cases where having a link to a human readable description
could be of use. It would be useful if the OID for a crypto algorithm
linked to the specification, maybe. Probably the bast use would be to
describe PKIX certificate policy OIDs.

Normally this would be a pointless task since Harald's database is
adequate. But what might change matters is the politics surrounding IETF
and ITU-T. I didn't think we were there yet when we talked about this in
Orlando, but I think that relationship is on the brink of collapse.

I am reading ITU-T proposals relating to X.509 coming from the people's
republic of Iran. Whatever the content of the proposal, the ITU-T model of
nation state participation is simply not sustainable. I think they are
going to push and push until the only answer the IETF can give is to sever
all links and all dependencies on ITU-T standards.

On Wed, May 1, 2013 at 3:32 PM, Paul Hoffman <[email-masked]> wrote:

> solution is to simply set up something in the current IN class under a name
> like "all-oids.org". Why expect the world to make a heavy-weight change
> to the DNS protocol for some use case that you don't even state?
>
> --Paul Hoffman

-- 
Website: http://hallambaker.com/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 3 May 2013 08:09:49 -0700

On May 3, 2013, at 8:06 AM, Phillip Hallam-Baker <[email-masked]> wrote:

> I think this proposal suffers from the authoritative registry bug.

+1

--Paul Hoffman

---

From: Noel David Torres Taño <[email-masked]>
Date: Fri, 3 May 2013 18:48:26 +0100

> with SRV shows that even that is difficult. IETF has even less claim to
Maybe the proposal has been misunderstood. It DOES NOT (note capitals) try to 
establish a new authoritative registry. It only creates a parseable method of 
storage. Nothing in the draft implies that you need to have your DNS appointed 
by the upper OID arc if you're using OID-DNS privately, you only need that if 
you are publishing, but in that case the authority delegation has already 
taken place.
> (via DNS space) describing the purpose.

IANA already has a registry of OIDs on the PEN, but that does not allow 
anybody to have an easy way of knowing what's under 1.3.6.1.4.1.41434.3.1 if I 
use that (even if you know by reading the list that 1.3.6.1.4.1.41434 is 
assigned to Rolamasao.org)
> document with some description.
Yes, the Draft can be amended adding an URI RR instead of the current DNS RR. 
What a good idea. I'll use it in next version.
> OID would have a lot of value.

If you are presenting a LDAP structure (lots of OIDs assigned by different 
people), if you are identifiying people's medical records (2.16.840.1.113883), 
if you are looking at people's identity cards (2.16.724.1.2.2.4.2.1) and more 
others.
> describe PKIX certificate policy OIDs.
Yes
> Orlando, but I think that relationship is on the brink of collapse.

Why is it adequate? If I maintain an OID arc under a PEN number, why must I 
register into Harald's instead of publishing on my own and let people check on 
my authoritative server?
> all links and all dependencies on ITU-T standards.

I will not mess in politics (yet). But this depends 0% on ITU-T, this is a new 
method of representing, transmitting and storing OIDs, not a new authority on 
them

Thanks for the comments! I always learn by reading

Noel
er Envite