[apps-discuss] RFC 3405 needs revising

[Mykyta Yevstifeyev <[e-mail]>]

Hello,

RFC 3405 is a fifth of the document series defined Dynamic Delegation 
Discovery System (DDDS), produced by IETF URN WG in 2002.  The entire 
series is specified in RFC 3401; RFC 3405 specified the rules for 
assignments in IANA-maintained uri.arpa. and urn.arpa. zones, used with 
DDDS Application for resolving URIs (including URNs).  However, I've 
identified a number of issues with current procedures which make any 
registration almost impossible.  The two main of them follow.

First, Section 3.1.1 of RFC 3405 sets that only URI schemes registered 
in IETF Tree may be approved in uri.arpa.  Registration trees for URI 
schemes, introduced by RFC 2717, were eliminated by RFC 4395.

The second problem is probably with Section 5, which is the procedures 
description itself.  The most notable is the [e-mail]/urn.arpa 
lists, which, as Frank already mentioned are quite obscure.  Here are 
some observations with respect to these lists.

RFC 3405 implied these lists' archives will serve as persistent records 
for registrations; there are actually only 7 messages in the uri.arpa 
archive and 9 - in urn.arpa.  I tried to ask IANA where are all 
assignments for uri.arpa/urn.arpa domains listed; the response was 
received that RFC 3405 didn't request to have a place where they are 
listed.  The only information I managed to get is 3 registrations for 
'ftp', 'http' and 'mailto' schemes (see 
http://www.iana.org/protocols/archives/register-uri/) and even more 
obscure assignment to 'urn.arpa' 
(http://www.iana.org/protocols/archives/register-urn - messages here are 
actually absent).  With respect to the last, it is the "pin" URN NID 
(RFC 3043) entered in urn.arpa; I didn't get an access to the messages 
registering it.  After trying to manually query pin.urn.arpa for NAPTR 
RRs I was pointed to pin.verisignlabs.com, which doesn't seem to have 
any NAPTR records.  No other messages were found in these archives, 
which are indeed the only place where I might have found any information 
about uri.arpa and urn.arpa assignments; so this attempt returned FAIL :-).

Such approach actually doesn't fit in anything described in RFC 5226; I 
suppose it was intended to be 'expert review'.  This may be deduced from 
Section 3 of RFC 3405.  Actually it implies "(1) posting to list->(2) 
(a) no objections: success/(b) objections: resolve issues and return to 
(1)".  Correspondingly, new assignments are not formally approved by 
some party (whereas it's interesting that changes of assignments require 
approval of 'Authority' (Section 6.2)).

There also are a number of minor and editorial omissions in the RFC, a 
part of which were reported as errata 
(http://www.rfc-editor.org/errata_search.php?rfc=3405).  One is my 
erratum, which was rejected per corresponding IESG statement, as 
"community consensus required for substantial changes".  This, at all, 
caused me to write this message.  Taking everything into account, I 
propose to undertake an effort to revise the RFC 3405 in order to align 
it with the reality and current situation.

I'm glad to hear what others think.

Mykyta Yevstifeyev