[Gen-art] Gen-ART review of draft-johansson-loa-registry-05

<david.black@emc.com> Wed, 11 April 2012 21:49 UTC

Return-Path: <david.black@emc.com>
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 1C5C911E80EC; Wed, 11 Apr 2012 14:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.355
X-Spam-Level:
X-Spam-Status: No, score=-110.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 2lZ5bW4PwfrF; Wed, 11 Apr 2012 14:49:43 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 365A811E80DC; Wed, 11 Apr 2012 14:49:36 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3BLnXDc010891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 17:49:34 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 11 Apr 2012 17:49:25 -0400
Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3BLnOsW015710; Wed, 11 Apr 2012 17:49:24 -0400
Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Wed, 11 Apr 2012 17:49:23 -0400
From: <david.black@emc.com>
To: <leifj@nordu.net>, <gen-art@ietf.org>, <ietf@ietf.org>
Date: Wed, 11 Apr 2012 17:49:23 -0400
Thread-Topic: Gen-ART review of draft-johansson-loa-registry-05
Thread-Index: Ac0QSf/k5rjw1b7/R4GhUN2VW96SjgH4d37Q
Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120535DC@MX15A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80811@MX14A.corp.emc.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80811@MX14A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: tim.polk@nist.gov
Subject: [Gen-art] Gen-ART review of draft-johansson-loa-registry-05
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: Wed, 11 Apr 2012 21:49:44 -0000

The -05 version of this draft resolves all of the issues and comments raised
in the Gen-ART review of the -04 version.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Sunday, April 01, 2012 4:57 PM
> To: leifj@nordu.net; gen-art@ietf.org; ietf@ietf.org
> Cc: Black, David; Sean Turner; tim.polk@nist.gov
> Subject: Gen-ART review of draft-johansson-loa-registry-04
> 
> 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.
> 
> 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)
> 
> (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.
> 
> 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
> 
> 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.
> 
> Top of p.7
>    The presense of an entry in the registy MUST NOT be taken to imply
>                                          ^
> r ---------------------------------------/
> 
> 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
> 
> The minor issue about RFC 2119 keywords also applies to this text.
> 
> idnits 2.12.13 did not find any nits that need attention.
> 
> Thanks,
> --David
> ----------------------------------------------------
> 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
> ----------------------------------------------------