Re: Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

[Edward Lewis <[e-mail]>]

On 7/15/15, 10:32, "Stephane Bortzmeyer" <[e-mail]> wrote:

>First, RFC 6761 is silent about the characteristics of the
>documentation to include in such a draft. RFC 6761 is very specific
>about "in each of the seven categories below, what special treatment,
>if any, is to be applied" but never mandated a specific type of
>external references.

Never said that the draft did not fulfill the requirements of RFC 6761.  I
opined that it contained little information enabling an informed opinion.

An aside to all this (not meant to derail the application of "onion"),
when a process is as loosely defined as what is in RFC 6761, decisions
made according to it will build up a set of precedents that following
applications will be judged by.  One could argue that RFC 6761 is too
loose in specification or one can accept that it lays an open process
which will be defined by cases later on.  For the latter, merely meeting
the requirements of the process-setting document is not enough.

>Second, I much prefer an URL (a few seconds after, I have the document
>and I can read it) to... (incoming troll) a DOI or other kind of
>reference that I may or may not be able to dereference.

To give a data point, the ATMA resource record type was originally defined
by a document resting on the ATM Forum site.  That was absorbed by
SomeOther Forum and then again by YetAnother Forum.  I had been tracking
the documentation of RR types since the days of DNSSEC's development and
thus was aware of the document's movement.  Eventually I made a request to
have the document "escrowed" (if that's the right term) with IANA so we
didn't lose it altogether - even if for historical purposes.

If we are going to rely on prior cases to build RFC 6761's process, we
need to be able to find the historical record.  URL's don't ensure that.