Re: [dnsext] Draft for OID

Phillip Hallam-Baker <hallam@gmail.com> Fri, 03 May 2013 15:50 UTC

Return-Path: <hallam@gmail.com>
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 8FBDC21F97C1 for <dnsext@ietfa.amsl.com>; Fri, 3 May 2013 08:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.191
X-Spam-Level:
X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001]
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 a02fxo36tFFf for <dnsext@ietfa.amsl.com>; Fri, 3 May 2013 08:50:11 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4AE21F8763 for <dnsext@ietf.org>; Fri, 3 May 2013 08:06:07 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id z2so1384921wey.5 for <dnsext@ietf.org>; Fri, 03 May 2013 08:06:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wKV4OUN1DxRJvajtVStXaG4HYoe7u9T/Qljt2PyYQAk=; b=uiZ82gge+5YuoPlDwLVpEdAfR9CM18KoPVibogjAabmvFwDB+YSJufvHugVoJAMra9 NUVbeK2h6tjruezRpa4GlGgIXcewu60yn8DOaC3IhhJGo3unQvhNTInL9nabKK9lKZNy FV9knZfRBFuegftIXARxEN6c50eKOBuhoNgyqWyZfcP0rvy5g+cgk2/al4jfiGT733ni toW/4xGtElHYtiY1CnKG7dLNS9VaguIXkYTHCajs/xhT9Y+uauKymsL/TC0g/UobDS2W yWMFpw5rW3dQl2YI+WdWhge5tKgz4gxKoCupQan6wSIiBlwPyA65SBcgo1hokggvFwtW tGAg==
MIME-Version: 1.0
X-Received: by 10.194.62.174 with SMTP id z14mr14521196wjr.20.1367593560965; Fri, 03 May 2013 08:06:00 -0700 (PDT)
Received: by 10.194.121.161 with HTTP; Fri, 3 May 2013 08:06:00 -0700 (PDT)
In-Reply-To: <6593BCE4-ECF6-450B-9364-62B662EF7BA6@vpnc.org>
References: <201304250029.57132.envite@rolamasao.org> <201305011759.29280.envite@rolamasao.org> <6593BCE4-ECF6-450B-9364-62B662EF7BA6@vpnc.org>
Date: Fri, 03 May 2013 11:06:00 -0400
Message-ID: <CAMm+Lwi5xceRCZR9jEKXEbk3Sws1zbiN9GW69REGXXCOo1=VEw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary="047d7b86d6d8660a9f04dbd1b06a"
Cc: "dnsext@ietf.org" <dnsext@ietf.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 15:50:14 -0000

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 <paul.hoffman@vpnc.org> wrote:

> On May 1, 2013, at 9:59 AM, 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 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
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
>



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