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

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 27 Jul 2017 10:41:41 -0400

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 <[email-masked]>
> Subject: [dns-rrtype-applications] New RR Application - DOA
> Date: July 25, 2017 at 11:41:43 AM EDT
> To: [email-masked]
> 
> Please find attached an RR application template for the "DOA" RR type.
> 
> The link to the I-D describing the RR is:
> 
> <https://www.ietf.org/internet-drafts/draft-durand-doa-over-dns-02.txt>
> 
> I am obviously recusing myself from evaluation of this application :)
> 
> Please address any questions to both authors of the I-D.
> 
> Ray
> _______________________________________________

---

From: Ray Bellis <[email-masked]>
Date: Thu, 27 Jul 2017 16:13:34 +0100

> Any reports of implementations experience would be helpful. 

ISC has implemented the DOA RR in our development version of BIND9 per
the format described in draft-durand-doa-over-dns-02 (albeit using a
private RR code until such time as this application is approved and a
code allocated)

Ray

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 27 Jul 2017 12:04:50 -0400

When ever I see DOA, I think "Dead On Arrival" but I don't have any
good short alternative to suggest...

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Thu, Jul 27, 2017 at 10:41 AM, Olafur Gudmundsson <[email-masked]> wrote:
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 27 Jul 2017 13:53:19 -0700

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:
[email-masked]" 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.

regards,

Ted

On Thu, Jul 27, 2017 at 7:41 AM, Olafur Gudmundsson <[email-masked]> wrote:

> *From: *Ray Bellis <[email-masked]>
> *Subject: **[dns-rrtype-applications] New RR Application - DOA*
> *Date: *July 25, 2017 at 11:41:43 AM EDT
> *To: [email-masked]
>

---

From: Evan Hunt <[email-masked]>
Date: Thu, 27 Jul 2017 22:51:28 +0000

> good short alternative to suggest...

I have the exact same reaction, and would have suggested changing it
to DOARC if I'd noticed this draft earlier in the process, but given that
there are already experimental implementations, I guess this suggestion has
been rendered moot and nonoperative even before I made it.  If only I could
think of a pithy way to express that concept...

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 28 Jul 2017 10:05:01 -0400

(I co-chair DNSOP, but no hat here.)

> On Jul 27, 2017, at 6:51 PM, Evan Hunt <[email-masked]> wrote:
> 

Without more information about a deployed base, it’s hard to understand possible ramifications of change in the mnemonic, but I respectfully suggest the requester could change the requested mnemonic if they want. 

I suspect the expert can also suggest or support such a change in the interest of avoiding confusion in other contexts, even though RFC 6895 doesn’t explicitly say so.

Suzanne