IETF Logo Mail Archive

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

"Roni Even" <ron.even.tlv@gmail.com> Fri, 27 May 2016 11:36 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 27F4F12D9C9; Fri, 27 May 2016 04:36:11 -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 F3kU59cUy9OA; Fri, 27 May 2016 04:36:09 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 3C43212D5D1; Fri, 27 May 2016 04:36:09 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id n129so268503265wmn.1; Fri, 27 May 2016 04:36:09 -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=D7AuvWtGV5kSmWZW1jFg+p41PcnANN87zD8JygpAzDM=; b=XqA3xIBmY9lS9z0I0WqKx1QCxgX4O2o/Ro4PIB+7hB56Z68kaZDSd9uoA4f93jA0Di y2aY3L0+KrkTkImj1Mwu/u864uZk182F0vqrBkxcGLcDBqdvvDqUvKukKyafYHYTel+L 04zMLAFOw/9LXXPjSPGkrufum+42kUwH9FYbxVHu/ZRM/+mYXTOTpaWiWNGJnDDhxqRm 6+M+mzGece9H1OlXQLD21MUC/oHtOVBC8B0IvfFwttepRPzm1+XUXffdnD03xK/0RcHq L95kTNHduWvfVoAxKIczXu2V7v1YZ/xYrPFmy/yNxi4EojVTRHqSvun8qavFhNnMvVTM p0HQ==
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=D7AuvWtGV5kSmWZW1jFg+p41PcnANN87zD8JygpAzDM=; b=ZESGhxQpnb2WBxDHN5urVobrEWVDDsbRyuAA9gtFh0F8eVpKuvRThKfWCHf/+NQRC6 hGyg2Wcb6MQR5JFClACB8ZI+F0Mv8q+6X3X5LnmWs/KvB+QU5l84+VR5SJsNXzx9bwRP 4TwF4y6ixYLonX7H2sn0BcFwyKKYEsxCcxQTr5fx2yTN4zLzrdiU3LX0PQyjdyGCL3qS bjEPPvncVUfYVHBEog//FWOnhsSP2sA/CzekqLf062Q7KjIJSkfFgNJHYbU4+uDA7MuT dD8nA7mePy7wdfOogcwIo5GcqFzw2r2nPqlTQZGUkp7tpUp/ZCvBAI5WiGoMJc4Xy7G9 DW6Q==
X-Gm-Message-State: ALyK8tJgjZkdXr96KDN7KC8d7aLCmWAMWJ1dAiT3mY1U+0IqB1Q1NdI9hATwp/J1mNq4kQ==
X-Received: by 10.28.45.9 with SMTP id t9mr9074997wmt.89.1464348967734; Fri, 27 May 2016 04:36:07 -0700 (PDT)
Received: from RoniPC (bzq-79-178-104-140.red.bezeqint.net. [79.178.104.140]) by smtp.gmail.com with ESMTPSA id lm1sm19011900wjc.25.2016.05.27.04.36.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 04:36:06 -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>
In-Reply-To: <CALaySJ+5jr3k2R7ovpy8FWqqKp0U-1PnXzYi1n5Esdy2MLZsPA@mail.gmail.com>
Subject: RE: Gen-ART LC review of draft-leiba-cotton-iana-5226bis
Date: Fri, 27 May 2016 14:35:10 +0300
Message-ID: <03ce01d1b80b$d4a06ed0$7de14c70$@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/zIyTZtygFLS6HsniCRGcA=
Content-Language: he
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/pGzdUdNDCqz5jSLEokN5MIUXyaI>
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 11:36:11 -0000

Hi Barry,
Here is a problem I encounter with the registration policy due to IESG not verifying the policy for registration.
The first registry requires standard action

http://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xhtml#sdp-security-descriptions-3

This one has specification required

http://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml

this one has IETF Review or IESG Approval

http://www.iana.org/assignments/mikey-payloads/mikey-payloads.xhtml#mikey-payloads-28

Yet these three are similar and a cipher will register in all three but may need different documents instead of one to register the cypher suite. 
This is a real problem and we ended up with one Informational and one standard track document.

https://tools.ietf.org/html/draft-ietf-avtcore-aria-srtp-09

https://tools.ietf.org/html/draft-ietf-avtcore-aria-sdes-01

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

Roni


> -----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

v2.23.0 | Report a Bug | By Email