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

"Roni Even" <ron.even.tlv@gmail.com> Fri, 27 May 2016 15:23 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6438B12D67C; Fri, 27 May 2016 08:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQakuCFpxosm; Fri, 27 May 2016 08:23:56 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14B812D777; Fri, 27 May 2016 08:23:52 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id n129so277980607wmn.1; Fri, 27 May 2016 08:23:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=f2wR0vPUali3YaZz5PP11hksXrFYKymHjqJVXGm+QME=; b=y3Zau9h244j1H4iae7lF52PxU5yjHSIpLEW+6OM9otcNnsEjNug1ivSVkT5lelEelQ fdOfRfpXWuJNQykneGwPxCQcml5BpViqSgbTndTGhfbAeeIueHmncWFXj9DY5acCqUz3 Unp4oshcufiuESn9X/qmby9/nv84+LyNoCis8CvAA4WYlwYUIqo94i+LuvZn2kedq1i+ 6A/jpzBbyLprJJHfQQB1Ok7wlPKyTy58yqARPmZ0oeae0d6fuzqo45u4kImKno7aDKs/ rUdGskifdj/JfqD6Ytxg4KSSM4dAkWk67YihU8p6ZOTbLFja5J7HioNTCGR0sPEDVVhR Gbeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=f2wR0vPUali3YaZz5PP11hksXrFYKymHjqJVXGm+QME=; b=b5a84gKsDXfHxdKdv2/UOvGqeNyptktxmhAOov0krJVDC4uiKxOlKpm00yZmuHjPRX b/mDov4DZwhicofIhAqV2gj7mflOZ+ICbK6FCDqQtIK/Alr/JjIeRZ9MlAefLLXol3mD z8dqyVcPFzmHRdb3DlGgkNPp89Url0GZ3xpM0WKn8kFsNMEvlYUOHxIioBxS5cjYqj9D i2feebuRILFk8+rhs2M63pAa2r2TTTiCZfG+E0rRUmfF9hzMI23oa6Ov2U7pnU7Z69sv ZzKVRQlwI0RWu/ORRKdNv3i/pAOflcDnmnir/97l8qx4Bw2p1+RpfmtOhvOWazhFgaSD Lcdg==
X-Gm-Message-State: ALyK8tKbuoBjoi0gbHviYiJbiG/fNEnJsFVCdqrKbsForIlAWbY6tIQ5GwWbNO2tnhrjQw==
X-Received: by 10.28.54.204 with SMTP id y73mr9271580wmh.59.1464362631455; Fri, 27 May 2016 08:23:51 -0700 (PDT)
Received: from RoniPC (bzq-79-178-104-140.red.bezeqint.net. [79.178.104.140]) by smtp.gmail.com with ESMTPSA id f8sm19959653wjm.13.2016.05.27.08.23.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 08:23:50 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Barry Leiba'" <barryleiba@computer.org>
References: <007601d1b58b$79f3afb0$6ddb0f10$@gmail.com> <CALaySJ+5jr3k2R7ovpy8FWqqKp0U-1PnXzYi1n5Esdy2MLZsPA@mail.gmail.com> <03ce01d1b80b$d4a06ed0$7de14c70$@gmail.com> <CALaySJLx6EH3NchmWp3eDe5HGi1PAsJXnLNOcROJ+2YNEB=5LA@mail.gmail.com>
In-Reply-To: <CALaySJLx6EH3NchmWp3eDe5HGi1PAsJXnLNOcROJ+2YNEB=5LA@mail.gmail.com>
Subject: RE: Gen-ART LC review of draft-leiba-cotton-iana-5226bis
Date: Fri, 27 May 2016 18:22:53 +0300
Message-ID: <03e501d1b82b$a507c770$ef175650$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKilLRPiWd1xYSYhcMpg/zIyTZtygFLS6HsASj9X44B+wzUqJ4HsdYg
Content-Language: he
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/TnEk9dB62cvwI0bFytSRpzcfOm4>
Cc: 'General Area Review Team' <gen-art@ietf.org>, draft-leiba-cotton-iana-5226bis.all@tools.ietf.org, 'IETF discussion list' <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 May 2016 15:23:58 -0000

Hi Barry,
Thanks for the explanation. It make sense to me. 
I hope that the document will help with getting better defined registries in the future. 
Maybe we can present this document,  once it is done, at one of the WG chairs lunches at the IETF meeting
Roni

> -----Original Message-----
> From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of
> Barry Leiba
> Sent: Friday, May 27, 2016 5:34 PM
> To: Roni Even
> Cc: General Area Review Team; draft-leiba-cotton-iana-
> 5226bis.all@tools.ietf.org; IETF discussion list
> Subject: Re: Gen-ART LC review of draft-leiba-cotton-iana-5226bis
> 
> > 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 general.
> 
> 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.
> 
> Barry
> 
> >> -----Original Message-----
> >> From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] 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-
> >> 5226bis.all@tools.ietf.org; 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
> >