Re: [Gen-art] Gen-ART review of draft-johansson-loa-registry-04

Leif Johansson <leifj@sunet.se> Mon, 02 April 2012 07:07 UTC

Return-Path: <leifj@sunet.se>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70C711E8073; Mon, 2 Apr 2012 00:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULIIFO75T126; Mon, 2 Apr 2012 00:07:12 -0700 (PDT)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 4A10111E80B6; Mon, 2 Apr 2012 00:07:11 -0700 (PDT)
Received: from [192.36.125.227] (dhcp.pilsnet.sunet.se [192.36.125.227]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q3276vjA005610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2012 09:07:02 +0200 (CEST)
Message-ID: <4F795011.2000402@sunet.se>
Date: Mon, 02 Apr 2012 09:06:57 +0200
From: Leif Johansson <leifj@sunet.se>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: david.black@emc.com
References: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80811@MX14A.corp.emc.com> <4F78CFB7.6000209@sunet.se> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E8082E@MX14A.corp.emc.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E8082E@MX14A.corp.emc.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: gen-art@ietf.org, ietf@ietf.org, leifj@nordu.net, tim.polk@nist.gov
Subject: Re: [Gen-art] Gen-ART review of draft-johansson-loa-registry-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 07:07:14 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/02/2012 05:58 AM, david.black@emc.com wrote:
> Leif,
> 
>> The type of consistency you look for is extremely difficult to
>> ascertain and often rely on mapping the underlying policies.
>> However I do see your point. How about this:
>> 
>> "Protocol designers who want to reference this registry should be
>> aware that registered LoAs may depend on assumptions that do not
>> carry over to a new protocol."
> 
> Could you add "and that those assumptions may vary among the
> protocols for which the LoAs were originally registered" ?

yep

> 
> On RFC 2119 terms, I suggest that you talk to your AD (Sean).  The
> IESG recently approved an IANA registry creation draft that I
> co-authored, draft-ietf-storm-rddp-registries, and as part of that
> approval, removal of RFC 2119 terms was requested.  See:
> 
> http://datatracker.ietf.org/doc/draft-ietf-storm-rddp-registries/history/
>
> 
ok I'll do that. Thanks again!

> Thanks, --David
> 
>> -----Original Message----- From: Leif Johansson
>> [mailto:leifj@sunet.se] Sent: Sunday, April 01, 2012 5:59 PM To:
>> Black, David Cc: leifj@nordu.net; gen-art@ietf.org;
>> ietf@ietf.org; turners@ieca.com; tim.polk@nist.gov Subject: Re:
>> Gen-ART review of draft-johansson-loa-registry-04
>> 
> On 04/01/2012 10:57 PM, david.black@emc.com wrote:
>>>> I am the assigned Gen-ART reviewer for this draft. For
>>>> background on Gen-ART, please see the FAQ at 
>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>> 
>>>> Please resolve these comments along with any other Last Call 
>>>> comments you may receive.
>>>> 
>>>> Document: draft-johansson-loa-registry-04 Reviewer: David L.
>>>> Black Review Date: April 1, 2012 IETF LC End Date: April 3,
>>>> 2012 IESG Telechat date: April 12, 2012
>>>> 
>>>> This draft establishes an IETF registry of SAML Level of
>>>> Assurance (LoA) profiles; it's short and clear, although it
>>>> does not contain any initial content for the registry -
>>>> presumably that will be supplied after the registry is
>>>> created via the expert review registration mechanism
>>>> established by this draft.
>>>> 
>>>> Summary: This draft is on the right track but has open
>>>> issues, described in the review.
>>>> 
>>>> Major issues: (1) My major open issue concerns the last
>>>> paragraph in the Introduction:
>>>> 
>>>> Although the registry will contain URIs that reference SAML 
>>>> Authentication Context Profiles other protocols MAY use such
>>>> URIs to represent levels of assurance definitions without
>>>> relying on their SAML XML definitions.  Use of the registry
>>>> by protocols other than SAML or OpenID Connect is
>>>> encouraged.
>>>> 
>>>> While this is good in principle, and one presumes that each 
>>>> registration of sets of profiles from an existing protocol
>>>> will be self-consistent, this text also encourages other
>>>> (e.g., new) protocols to draw upon this registry without
>>>> providing any guidance.  I'm concerned that it's probably
>>>> possible to make a serious mess in a new protocol by using an
>>>> LoA or two from multiple sets of registered LoAs without
>>>> paying attention to whether the resulting collection of LoAs
>>>> is consistent or coherent (or even sensible) for use in a
>>>> single protocol.  This concern is reinforced by the guidance
>>>> to expert reviewers in Section 4.1, which effectively conveys
>>>> a desire to get all of the reasonable LoA profiles registered
>>>> here, regardless of source or consistency with other
>>>> registered LoA profiles.
>>>> 
>>>> I'd like to see some guidance to protocol designers and
>>>> others for how to appropriately select multiple LoA profiles
>>>> from this registry in a fashion that results in a consistent
>>>> and (hopefully) usable collection.  For example, it may be a
>>>> good idea to use (or start with) a set of related profiles
>>>> already in use by an existing protocol in preference to
>>>> mixing/matching individual profiles from multiple existing
>>>> protocols.  At some level, this is common sense advice that
>>>> the presence of profiles in this registry does not obviate
>>>> the need to apply good design judgment, but that does deserve
>>>> to be stated.
> 
> David,
> 
> The type of consistency you look for is extremely difficult to
> ascertain and often rely on mapping the underlying policies.
> However I do see your point. How about this:
> 
> "Protocol designers who want to reference this registry should be
> aware that registered LoAs may depend on assumptions that do not
> carry over to a new protocol."
> 
>>>> 
>>>> Minor issues: (2)
>>>> 
>>>> (1) This draft is intended to be an informational RFC, but it
>>>> uses RFC 2119 keywords.  That's only a good idea in
>>>> exceptional circumstances. I suggest removing section 1.1 and
>>>> replacing upper case MUST/SHOULD/MAY with their lower case
>>>> versions or reworded explanations of rationale.  Most of the
>>>> uses of RFC 2119 keywords are not protocol requirements, but
>>>> requirements on IANA, registrants, and users of the registry
>>>> for which RFC 2119 keywords are not appropriate, e.g., see
>>>> RFC 2119 section 6:
>>>> 
>>>> Imperatives of the type defined in this memo must be used
>>>> with care and sparingly.  In particular, they MUST only be
>>>> used where it is actually required for interoperation or to
>>>> limit behavior which has potential for causing harm (e.g.,
>>>> limiting retransmisssions)
> 
> ok
> 
>>>> 
>>>> (2) Section 4
>>>> 
>>>> OLD The initial pool of expert and the review criteria are
>>>> outlined below. NEW The review criteria are outlined below.
>>>> 
>>>> The initial pool of experts is not designated by this draft.
>>>> 
> 
> good catch
> 
>>>> Nits/editorial comments:
>>>> 
>>>> Section 3
>>>> 
>>>> OLD The following ABNF productions represent reserved values
>>>> and names NEW The reserved element defined by the following
>>>> ABNF productions represents a set of reserved values and
>>>> names
> 
> ok
> 
>>>> 
>>>> Section 4
>>>> 
>>>> The registry is to be operated under the "Designated Expert 
>>>> Review" policy from RFC5226 [RFC5226] employing a pool of
>>>> experts
>>>> 
>>>> Nope, the actual RFC5226 name of that well-known IANA policy
>>>> is Expert Review (or Designated Expert), see section 4.1 of
>>>> RFC5226. If that well-known IANA policy isn't what was
>>>> intended, this is a serious open issue.
> 
> that IANA policy was indeed intended.
> 
>>>> 
>>>> Top of p.7 The presense of an entry in the registy MUST NOT
>>>> be taken to imply ^ r
>>>> ---------------------------------------/
>>>> 
> 
> Here I actually want normative language. It is quite important that
> the registry not be over-interpreted.
> 
>>>> Section 7
>>>> 
>>>> OLD An implementor of MUST NOT treat the registry as a trust 
>>>> framework or NEW A protocol implementor MUST NOT treat the
>>>> registry as a trust framework or
>>>> 
> 
> I actually don't mean protocol implementor here. I mean consumer of
> the registry.
> 
>>>> The minor issue about RFC 2119 keywords also applies to this
>>>> text.
>>>> 
> 
> This is another case where I think I disagree!
> 
>>>> idnits 2.12.13 did not find any nits that need attention.
>>>> 
>>>> Thanks, --David
> 
> thank you!
> 
> Cheers Leif
> 
>>>> ---------------------------------------------------- David
>>>> L. Black, Distinguished Engineer EMC Corporation, 176 South
>>>> St., Hopkinton, MA  01748 +1 (508) 293-7953             FAX:
>>>> +1 (508) 293-7786 david.black@emc.com        Mobile: +1 (978)
>>>> 394-7754 
>>>> ----------------------------------------------------
>>>> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk95UAwACgkQ8Jx8FtbMZnermACfYaNXTG9wfDIfauRXPPV++mal
EVwAoJgNIk/1iXwEBMjURYOpyi3L3SUw
=5XrB
-----END PGP SIGNATURE-----