[apps-discuss] RFC 3405 needs revising

Mykyta Yevstifeyev <evnikita2@gmail.com> Sun, 10 July 2011 10:20 UTC

Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 683F721F86FC for <apps-discuss@ietfa.amsl.com>; Sun, 10 Jul 2011 03:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.209
X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0ftbMn1sXP51 for <apps-discuss@ietfa.amsl.com>; Sun, 10 Jul 2011 03:20:21 -0700 (PDT)
Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4C15021F86E0 for <apps-discuss@ietf.org>; Sun, 10 Jul 2011 03:20:21 -0700 (PDT)
Received: by fxe4 with SMTP id 4so4036927fxe.27 for <apps-discuss@ietf.org>; Sun, 10 Jul 2011 03:20:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=GOe7XFFJHEe5WKOYots0KE6SmxAvWV8hjhTFXL1kLsY=; b=b7pqCuPANspjayEmSN4Y3XMXiQimAjVgnJI0xmiXhfG3xRck005JtANzDQfvQBk32j XASth3uaOhXEOyGrurVCp27MEgn7/8elvSJKAP86PACJVM79CsTOiFxfitghyIo6GRpX DRvsB9OFWJZCPCajQmjnEZQDYjF725QSRXlQM=
Received: by with SMTP id l6mr5785705fae.14.1310293220351; Sun, 10 Jul 2011 03:20:20 -0700 (PDT)
Received: from [] ([]) by mx.google.com with ESMTPS id q14sm1999143faa.27.2011. (version=SSLv3 cipher=OTHER); Sun, 10 Jul 2011 03:20:19 -0700 (PDT)
Message-ID: <4E197D10.1070202@gmail.com>
Date: Sun, 10 Jul 2011 13:21:04 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Apps-discuss list <apps-discuss@ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: michael@refactored-networks.com
Subject: [apps-discuss] RFC 3405 needs revising
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Jul 2011 10:20:22 -0000


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 register@uri.arpa/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