Re: [urn] normative language -- a new convention

Barry Leiba <> Fri, 18 May 2012 20:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 001EF21F8584 for <>; Fri, 18 May 2012 13:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.783
X-Spam-Status: No, score=-100.783 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OYZIe6QP30Dj for <>; Fri, 18 May 2012 13:01:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6927421F8582 for <>; Fri, 18 May 2012 13:01:28 -0700 (PDT)
Received: by yenq13 with SMTP id q13so3762601yen.31 for <>; Fri, 18 May 2012 13:01:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pGroBikwrLU6wHIq5L9rrU9GasGMafhtuXSEFl/4XSg=; b=WNeq6riVcdEiCSbJOCUFbCM2h5W/Mq6p+3IlPB1sOJxe0cYC8kl2VJUoMeFRKtYuBT HKJix16AsmGw1Y4wx7Yrlc1FFwvZGGWQImIRu62KQ2bEb/s+pckSZYe4iMu+kVQvuiZi DMwFoskJlYefJVNbtAowbqp4Wfgo0TwODmG5WGViXh1Uzdi4LquGnjr+Oh1KkMS3mRCS T2jlFgRhtkD7mUvhfgoi1Q6YU/kC9KMbuGyzd+hCB1mJ/f/RP/NtqfOIK+GRWhA5EJKR a+0YNIkvXxOjt+wBi29hslGDb0E0geG5tDTNmn+UnzV0fmg//1woE9QlMgQaUUQW2glv Fpfg==
MIME-Version: 1.0
Received: by with SMTP id 2mr11305305oez.27.1337371287851; Fri, 18 May 2012 13:01:27 -0700 (PDT)
Received: by with HTTP; Fri, 18 May 2012 13:01:27 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Fri, 18 May 2012 16:01:27 -0400
X-Google-Sender-Auth: an4VRgOH0TTGWrOBFuloFA9ZSE8
Message-ID: <>
From: Barry Leiba <>
To: =?ISO-8859-1?Q?Alfred_H=F6nes?= <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [urn] normative language -- a new convention
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 May 2012 20:01:32 -0000

>>> <speaking both as an individual and as a co-chair>
>> As the responsible AD, I am at a loss to understand how it's at all
>> appropriate for you to make this suggestion as chair.  Please
>> explain specifically where the authority to do that comes from.
> So observing a Standards Track RFC published less than 4 weeks ago
> with an apparently Solomonian method to deal with the topic, which
> obviously has been accepted by the (previous) IESG, I think that was
> reason and justification enough to *suggest* this method to the WG
> as well, assuming consistent, continued support for it in the IESG.
> You also might have observed that in my original posting,
> I deliberately obstained from stating a personal preference;
> I even mentioned diverging opinions.

OK.  The reason that caught my attention is that many IETF
participants aren't sure of the role of the chair, and the limitations
of chairs' (and ADs') control.  When one explicitly says that one is
speaking as a chair, one should have a good reason to (declaring
consensus, moderating discussion, doing process management, and so
on).  There's no reason to speak ex-cathedra when one's just informing
the working group of something that might interest them, and I think
chairs should be careful to avoid confusing things by saying they're
acting as chair when they don't need to.

> Please note that this was not a *decision*, but a *suggestion* for
> a way forward (and awaiting feedback from the list):

Exactly the reason that "as a participant" is enough.

>>> With the approval of the IESG, RFC 6329 (published in April 2012)
>>> has introduced a new convention (see Section 3 of that RFC), and
>>> I suggest that we liberally adopt this method for our WG documents:
>> As a participant, I suggest that this is a very bad idea.
> Obviously, opinions vary; at least, the text of RFC 6329 once has
> found IETF (and IESG) consensus.

As I said, I won't be discussing that part further on this list.  The
discussion continues on the IETF discussion list.