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

[Ted Hardie <[e-mail]>]

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:
[e-mail]" 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 <[e-mail]> 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 <[e-mail]>
> *Subject: **[dns-rrtype-applications] New RR Application - DOA*
> *Date: *July 25, 2017 at 11:41:43 AM EDT
> *To: *[e-mail]
>
> 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
>
>
> _______________________________________________
>
>
>
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>
>