[secdir] secdir review of draft-saintandre-urn-example-04

Radia Perlman <radiaperlman@gmail.com> Sat, 23 March 2013 03:08 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D1C9F21F8B6D; Fri, 22 Mar 2013 20:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.339
X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id O4eYjCPW-KSM; Fri, 22 Mar 2013 20:08:52 -0700 (PDT)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8FB21F8B3B; Fri, 22 Mar 2013 20:08:44 -0700 (PDT)
Received: by mail-la0-f50.google.com with SMTP id ec20so8477623lab.37 for <multiple recipients>; Fri, 22 Mar 2013 20:08:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=XRzVfL8uxFyB+rXkIgaMY7YmzNrx5sAoTwUMYcVKR6s=; b=mBrjn/nlgjrwzHRqk9zyiBwgO9PXQAESq1O5zzQYPhi88FVbeOzq4dxslTzdYEXhR8 xblBGyfLWpImXorUz6GVSVT9whPCjAYoOKe/zvgl3yvC5kyrq4OBaMTxAwBV1N+ZPhU4 I6IE65RzrOWOye3W3OUKwjB0l8V7XEGK3FEQFmJUsYD/Oz4x7mtVe5Jf9+kH+yqiqiL+ tMZp2KM4/g+W2Ctu/p7bl+pvFih7BPc9dgrJZ4izRHMR+f/8FkMS0yuTc2lTjRCaii+K QAwKcgUA4CpsTMvMONElhj0UuCq/elH7pL3XkzY5Co/cV6KlmwLupMHyPGHgcoJem+LL /BdQ==
MIME-Version: 1.0
X-Received: by with SMTP id lr4mr2126641lab.28.1364008123437; Fri, 22 Mar 2013 20:08:43 -0700 (PDT)
Received: by with HTTP; Fri, 22 Mar 2013 20:08:43 -0700 (PDT)
Date: Fri, 22 Mar 2013 20:08:43 -0700
Message-ID: <CAFOuuo4aOOne3OppwucKZd8p9PYF8JL=q9-GwrMEZR=dWN_nmw@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: secdir@ietf.org, The IESG <iesg@ietf.org>, draft-saintandre-urn-example@tools.ietf.org
Content-Type: multipart/alternative; boundary=f46d042ef661ab188904d88ee38a
Subject: [secdir] secdir review of draft-saintandre-urn-example-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Mar 2013 03:08:53 -0000

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document proposes to standardize the use of "example" as a namespace
identifier in URNs (like "example.com" is for DNS names), and is harmless.

I could (and perhaps should, or is it SHOULD) stop there.  However, I'll
editorialize a bit.  I more or less understand what a URL is.  You type it
into a browser, though mercifully, actual humans seldom have to type

But then I started hearing about URNs and URIs.  I pretty much ignored them
because my life seemed to be complete without needing to understand them.
 But then since I was assigned this draft to review, I decided to
investigate what URNs and URIs are and how they are different.

The definition given in RFC 2141 is "Uniform Resource Names (URNs) are
intended to serve as persistent, location-independent, resource identifiers
and are designed to make it easy to map other namespaces (which share the
properties of URNs) into URN-space."

I could memorize that definition and it still wouldn't help me understand
why my life was incomplete without URNs. Then I read RFC 1630 to find out
about URIs, and that was equally non-illuminating to me, who was simply
groping for "why do I need one of these things, and when would I use it".

Then I read yet another incomprehensible RFC, #3986, which has this
"Future specifications and related documentation should use the general
term "URI" rather than the more restrictive terms "URL" and "URN"
[RFC3305]." So, why are we, today, in 2013, tweaking URNs if we are
supposedly trying to mercifully put the term "URN" to bed?

And why is the NSS (Namespace Specific String, which is part of the URN)
ASCII? Given that I'm never planning on using a URN, I don't really care,
but if people wanted these things for whatever reason, mightn't they want
to use International characters?

So my conclusion is that invention of UR* terminology is a low level denial
of service attack on people, but is otherwise harmless.