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?
- Re: [dnsext] Draft for OID Noel David Torres Taño
- [dnsext] Draft for OID Noel David Torres Taño
- Re: [dnsext] Draft for OID Noel David Torres Taño
- Re: [dnsext] Draft for OID Patrik Fältström
- Re: [dnsext] Draft for OID Jim Reid
- Re: [dnsext] Draft for OID Noel David Torres Taño
- Re: [dnsext] Draft for OID Paul Hoffman
- Re: [dnsext] Draft for OID Warren Kumari
- Re: [dnsext] Draft for OID Noel David Torres Taño
- Re: [dnsext] Draft for OID Phillip Hallam-Baker
- Re: [dnsext] Draft for OID Paul Hoffman
- Re: [dnsext] Draft for OID Noel David Torres Taño