Re: Gen-ART LC review of draft-leiba-cotton-iana-5226bis

Barry Leiba <> Fri, 27 May 2016 14:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A91CD12DB0A; Fri, 27 May 2016 07:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JJQoJaFzrM1J; Fri, 27 May 2016 07:34:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5218512D8C7; Fri, 27 May 2016 07:34:17 -0700 (PDT)
Received: by with SMTP id n129so139972328wmn.1; Fri, 27 May 2016 07:34:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=Ako507yDjRZgq/2bHyit1KohPmhCM+q6PXcZvecJmAU=; b=uMD17Fd0ffR6VoodOxstd0O1G3M5vpWBW1qErqN7WqyTBxRImt92JVDaYhzzqsr31a 7oSV1lFYXrVZzEGPfqjWqPbPnqeApt1d3xpBhIqs83TTKP79hw9p+3psmGXZhL6CWV8M jfSPbbCmZuuPf69tE9GRIs7V1saGKx9QWZBFv+kiw5MxeiF+byUUFcDdfFQzdL9gZjSE JSgBp8UDxfpF+NA9X2+6xnBe0dw7JPnmE7/f/4lwPjhl3CVLhFcz89XQY2y3s4rCzqAZ NNKyIdSlnQeBeh3rL4XHWa2eKIEwpJySpz4Weq5XKNdaJL1WkzQxlYdBDBT54/PCJpFY vqpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=Ako507yDjRZgq/2bHyit1KohPmhCM+q6PXcZvecJmAU=; b=V+RVDb73OpGtqT0N7utIe5Jyz2KWrrbsECPtwzgJSs3nzHPNcmOOyJ5woJVp6jSBto sbFTcZflU/1h/keqyK8ICnVuqVFS5nmleS6ZWsoEoQv+SqajSLU0OaGjLYPAkIg6trF1 /n+ci9bg6YpMP0kILzcNa4cDui8fQJ9QOrJgCrwMk0iW/iSUDsuCEeUI0y89jb9a+opl ZUbgUhB/daH66ukFgrc3yzaVrzIiMsCt7pRLThIaTWSXcZO0b5+KGu71hJTegrQGoXJk ySkOHhZieXAYhowljZri3KsS7+ezTWcfxn+CWUd4bXMzqe96HIidKfhvZla4yj8EdKPm KKZA==
X-Gm-Message-State: ALyK8tIvVTFrzdQC5RxPWJ8RLCUxmrPCov6RsjOE7WkYe0xR45ks1Ylstfb35C0+DEnhDjX/mkpf+f/a2/BT2w==
MIME-Version: 1.0
X-Received: by with SMTP id i1mr15263764wjf.142.1464359655739; Fri, 27 May 2016 07:34:15 -0700 (PDT)
Received: by with HTTP; Fri, 27 May 2016 07:34:15 -0700 (PDT)
In-Reply-To: <03ce01d1b80b$d4a06ed0$7de14c70$>
References: <007601d1b58b$79f3afb0$6ddb0f10$> <> <03ce01d1b80b$d4a06ed0$7de14c70$>
Date: Fri, 27 May 2016 10:34:15 -0400
X-Google-Sender-Auth: Nzy_CwvJBuRqjweus2AIQ9uMNfU
Message-ID: <>
Subject: Re: Gen-ART LC review of draft-leiba-cotton-iana-5226bis
From: Barry Leiba <>
To: Roni Even <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: General Area Review Team <>, "" <>, IETF discussion list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 May 2016 14:34:20 -0000

> I think that there should be normative language to the IESG to verify consistency

In principle, I agree with you, but there are practical considerations.

First, I'm pretty sure we don't have IETF consensus to say that
working groups MUST carefully consider the registration policies,
coordinate them among similar/related registries, and write
justifications for their decisions... and I think we'd have a hard
time getting consensus for that.  I think the document does the best
we can here, which is to explain why it's important, and to say that
this (English-word)should be done.

Second, few ADs have the interest in being rigorous about this, when
they consider the time spent looking at it, looking at other
registries, and arguing the point, and considering the other things
they're spending their time on (such as making sure the protocols
themselves are solid, that the security aspects are right, and so on).
When I was on the IESG, I did make a point of challenging working
groups on this point: please show me where the policy was discussed on
the mailing list, and please explain why you settled on Standards
Action, and why IETF Review or even Specification Required doesn't
work as well or better.  Sometimes that resulted in changes, and
sometimes it resulted in reasonable explanations and no change.  But
it took time to do that, and I think we can't expect it to happen in

Third, while there is, as you point out, actual damage done by overly
strict policies (and I do point this out in the new text in the
document), the damage is limited and infrequent for the most part.  A
few times, we've run into major issues with very active registries
(media types and port numbers come to mind), and we've put out
extensive documents that corrected those situations.  But trying to
put MUSTs (whether they be capitalized or not) into a BCP to avoid
those is probably too much, and is not likely to get consensus.


>> -----Original Message-----
>> From: [] On Behalf Of
>> Barry Leiba
>> Sent: Tuesday, May 24, 2016 3:49 PM
>> To: Roni Even
>> Cc: General Area Review Team; draft-leiba-cotton-iana-
>>; IETF discussion list
>> Subject: Re: Gen-ART LC review of draft-leiba-cotton-iana-5226bis
>> Hi, Roni, and thanks for the review.
>> > I am wondering about the lack of normative language for example in
>> > section
>> > 4.11
>> >
>> >    “When reviewing a document that asks IANA to create a new registry
>> > or change a registration policy to any policy more stringent than
>> > Expert Review or Specification Required, the IESG should ask for
>> > justification to ensure that more relaxed policies have been
>> > considered and that the strict policy is the right one.”
>> >
>> > Is the “should” normative here?
>> Perhaps you're confusing "normative language" with "2119 key words":
>> text doesn't need 2119 key words for it to be normative, and this document
>> quite intentionally does not cite RFC 2119.
>> The example you give is a perfect one to show why we're not trying to
>> shoehorn key words that were meant to give instructions for interoperable
>> protocols into a document that's giving advice for writing and interpreting
>> IANA Considerations.  The sentence above means exactly what it says in
>> English: it's advising the IESG, but it is ultimately the IESG's decision.
>> Barry