Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

joel jaeggli <joelja@bogus.com> Wed, 01 February 2017 14:59 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BEE129E54; Wed, 1 Feb 2017 06:59:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.098
X-Spam-Level:
X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 szRE8rg1XOP6; Wed, 1 Feb 2017 06:59:06 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA091129E4F; Wed, 1 Feb 2017 06:59:06 -0800 (PST)
Received: from mbp-4.local ([IPv6:2601:647:4201:9e61:c191:d259:1e66:4d2b]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v11Ewscx011131 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 1 Feb 2017 14:58:55 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:c191:d259:1e66:4d2b] claimed to be mbp-4.local
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <c0e62125-14e6-2390-87e3-72a2422f732f@bogus.com>
Date: Wed, 01 Feb 2017 06:58:54 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="irNG4eH1FmULQWpnlSCoA9rh6Omue6dBr"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/OlzT45NewtrhmF2CRsp9T5Hv8c0>
Cc: oauth-chairs@ietf.org, draft-ietf-oauth-amr-values@ietf.org, oauth@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Feb 2017 14:59:08 -0000

On 1/31/17 8:26 AM, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-oauth-amr-values-05: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This specification seems to me to break it's own
> rules. You state that registrations should include
> a reference to a specification to improve interop.
> And yet, for the strings added here (e.g. otp) you
> don't do that (referring to section 2 will not
> improve interop) and there are different ways in
> which many of the methods in section 2 can be done.
> So I think you need to add a bunch more references.

Not clear to me that the document creating the registry needs to adhere
to the rules for further allocations in order to prepoulate the
registry. that is perhaps an appeal to future consistency.
>
>
>