Re: [dnsext] Draft for OID

Noel David Torres Taño <envite@rolamasao.org> Fri, 03 May 2013 13:09 UTC

Return-Path: <envite@rolamasao.org>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989DF21F8EC2 for <dnsext@ietfa.amsl.com>; Fri, 3 May 2013 06:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.437
X-Spam-Level: *
X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_STATIC=1.172, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+m2e9Gx747B for <dnsext@ietfa.amsl.com>; Fri, 3 May 2013 06:09:14 -0700 (PDT)
Received: from rolamasao.org (68.167.216.87.static.jazztel.es [87.216.167.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7DE21F87D0 for <dnsext@ietf.org>; Fri, 3 May 2013 06:09:13 -0700 (PDT)
Received: from tochox.localnet (localhost [IPv6:::1]) by rolamasao.org (Postfix_t) with ESMTPSA id ED98111EDA for <dnsext@ietf.org>; Fri, 3 May 2013 14:09:11 +0100 (WEST)
From: Noel David Torres Taño <envite@rolamasao.org>
To: dnsext@ietf.org
Date: Fri, 03 May 2013 14:09:05 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )
References: <201304250029.57132.envite@rolamasao.org> <201305011759.29280.envite@rolamasao.org> <116AB7C6-10BE-43C7-AC76-86498A3FAEDA@rfc1035.com>
In-Reply-To: <116AB7C6-10BE-43C7-AC76-86498A3FAEDA@rfc1035.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1697750.1POzeJua8T"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Content-Transfer-Encoding: 7bit
Message-Id: <201305031409.06978.envite@rolamasao.org>
Subject: Re: [dnsext] Draft for OID
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 May 2013 13:09:18 -0000

> On 1 May 2013, at 17:59, Noel David Torres Taño <envite@rolamasao.org> 
wrote:
> > No comments? I can really not trust I've written such a perfect document
> > that nobody objects to it.
> 
> 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
> and attention to detail.

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

Thanks

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