Re: [dnsext] Fwd: [dns-rrtype-applications] New RR Application - DOA

Ted Hardie <> Thu, 27 July 2017 20:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C13612EB8C for <>; Thu, 27 Jul 2017 13:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MHIGLPJy5SEG for <>; Thu, 27 Jul 2017 13:53:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D4A712EC32 for <>; Thu, 27 Jul 2017 13:53:51 -0700 (PDT)
Received: by with SMTP id v29so49252032qtv.3 for <>; Thu, 27 Jul 2017 13:53:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6u2Wag0fojjMDsdbJsD5aqI/DEsEcX6DAV1KDFSLphU=; b=D/RASf1zkn5veeEZM1DEMpKPgux80M5zdnoOOwR+6egU3ugV3D0MeyIPccd5awHZT5 cGQIB1EX25HjbD1KCbTfTcYvxNpjioidPpUCO6yB2gAUqzTBJeMF/rY4ODpRA0/xgYpL fi/XRbekCZGUwATmkCU/DEzeINIfy0+zuQQydZvtHqEuXXnhswKkz3GpYQzm748FCTzc tQEfw6matqSh1g0XPmGRbb+swYl6LDGRLgtAuNMhJ/j7aFjV7ipB/d0NecR6Fu1OLu+D r5oFyVcauVJPZivqf/gZ8riyK5g3lfd4j7uKXbyqYtrUVod4ibqMUmiL6aLk4bZjOkDA k4Uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6u2Wag0fojjMDsdbJsD5aqI/DEsEcX6DAV1KDFSLphU=; b=sVfZy/jYdkXSnjG2TU+OAT4nz979sUcg0mDSRenA6AkMbSTWGHIVvH6S33wfxTnQQx QwA9zaCdiT1gNGTqCONI3xKaOo7u2/MPJOlr3+/72R8HHx9O5fxmu/2wulgY02+y/sFh OB21jworWI/uUIrZ3NmL3iTTEJy7vqZ9LYrasJatRVMFwU1RShGmKIOtLHtu4UJGFJYw yRxHKRCHQVYxpwVA+ebn9NKYzBQXaHnvPuztBPzKXLgHgjpMbrxrWJ266MyR+hP2Evjs 3sbmEqVfzy/JiWFgz7Fk0wFpL0jozF1emE6PdmZDTNXcYRoK2bIs9OlvVK4ziWe2YMRF YzbQ==
X-Gm-Message-State: AIVw113LJ534AyMnOCBvucrW4yXKUlD4dA0U4XpAoEWF+rfgo/yYAPgl iCJikgBbax6f8s1ihjGfv09JdQ68gA==
X-Received: by with SMTP id q8mr7923097qte.199.1501188830302; Thu, 27 Jul 2017 13:53:50 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 27 Jul 2017 13:53:19 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Ted Hardie <>
Date: Thu, 27 Jul 2017 13:53:19 -0700
Message-ID: <>
To: Olafur Gudmundsson <>
Cc: DNSEXT Working Group <>, Alain Durand <>,
Content-Type: multipart/alternative; boundary="94eb2c1914aef89937055552c216"
Archived-At: <>
Subject: Re: [dnsext] Fwd: [dns-rrtype-applications] New RR Application - DOA
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Jul 2017 20:53:54 -0000

HI Olafur,

I do not think think specification retains some ambiguities at the moment.
A couple of issues:

In section  3.1.2, the document says: 'For the value 2 ("URI") the DOA-DATA
contains a UTF-8 encoded string representing the URI from which the DOA
object can be obtained.'   This is appears to assume a limited set of URI
types related to client/server retrieval (what happens if this has "mailto:" as a value? or bitcoin:mumble?).  In general, actually
listing the acceptable URI schemes is more useful and can easily be made
part of an extensible registry.

In section 3.1.3, the document says "For the value 3 ("HDL") the DOA-DATA
contains a UTF-8 encoded string representing the handle from the Handle
System [RFC3650] from which the DOA object can be obtained."  RFC 3650
limited the set of characters appropriate for Handles to Version 3 of the
UCS (see section 3).  I don't follow the current work, but it seems that
this document either needs to preserve that restriction or to point to
later documents that removed it.  Note also that section 6.1 of RFC 3650
argued explicitly against using the DNS for the Handle system.  Since DOAs
are currently distributed with the Handle system, it would likely be useful
to indicate why an RR for this purpose works now when it did not on
publication of the core Handle documents.

This statement:

"DNS software implementing the DOA RR type MUST NOT drop or otherwise
refuse to handle the DOA RRs containing an unknown or unsupported
DOA-location and MUST treat the DOA-DATA portion of the RR as an abstract
opaque field."

seems to amount to "DNS software must not fail when serving syntactically
correct data in an RR." That's rather an odd thing to say, and I kind of
wonder why it belongs in a document registering this RR type.  Perhaps some
more data on this point is required or perhaps the statement can be removed.

In general, I think the authors would do well to look back at the history
of the URN-related DNS systems (possibly with a large adult beverage in
hand).  What they propose in this draft is somewhere between a generic URI
pointer to a handle, a re-implementation of the data URI scheme in the DNS,
the DDDS without all that pesky NAPTR business, and a way of storing opaque
strings of no known utility.  There are already ways to do most of this, in
other words, and its not clear what lumping them together here is really
that good at doing.

While engaged in that review, I really hope that  they go back through Chip
Sharp's description of the DOA system ( https://www.internetsociety.
org/doc/overview-digital-object-architecture-doa).  I think it does a good
job of reviewing why many of the most valued elements of the DOA (e.g.
persistenc) are properties created by assurances from the issuers and not
by the protocol itself.  Thinking on that more may inspire them to adjust
this proposal.



On Thu, Jul 27, 2017 at 7:41 AM, Olafur Gudmundsson <> wrote:

> Dear Colleagues
> The RRType experts received the application below,
> I have been selected as the expert, after reviewing the application it
> meets all criteria for acceptance.
> This message is to solicit any reasons that the applications should not be
> accepted.
> The last day for comment on the application is August 8’th.
> Any reports of implementations experience would be helpful.
> Olafur
> Begin forwarded message:
> *From: *Ray Bellis <>
> *Subject: **[dns-rrtype-applications] New RR Application - DOA*
> *Date: *July 25, 2017 at 11:41:43 AM EDT
> *To: *
> Please find attached an RR application template for the "DOA" RR type.
> The link to the I-D describing the RR is:
> <>
> I am obviously recusing myself from evaluation of this application :)
> Please address any questions to both authors of the I-D.
> Ray
> _______________________________________________
> _______________________________________________
> dnsext mailing list