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

<david.black@emc.com> Mon, 02 April 2012 03:58 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 C098D21F87D8; Sun, 1 Apr 2012 20:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.346
X-Spam-Level:
X-Spam-Status: No, score=-109.346 tagged_above=-999 required=5 tests=[AWL=1.253, 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 oIPnAEMZGoSX; Sun, 1 Apr 2012 20:58:26 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id B273221F8748; Sun, 1 Apr 2012 20:58:26 -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 q323wMCG004185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Apr 2012 23:58:23 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sun, 1 Apr 2012 23:58:13 -0400
Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q323wCHP009500; Sun, 1 Apr 2012 23:58:12 -0400
Received: from mx14a.corp.emc.com ([169.254.1.70]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Sun, 1 Apr 2012 23:58:12 -0400
From: <david.black@emc.com>
To: <leifj@sunet.se>
Date: Sun, 1 Apr 2012 23:58:09 -0400
Thread-Topic: Gen-ART review of draft-johansson-loa-registry-04
Thread-Index: Ac0QUsWopmgqpOdLTuWE1NhMZA4iUwAMKDjw
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E8082E@MX14A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80811@MX14A.corp.emc.com> <4F78CFB7.6000209@sunet.se>
In-Reply-To: <4F78CFB7.6000209@sunet.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
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 03:58:27 -0000

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

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/

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
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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/
> 
> iEYEARECAAYFAk94z7cACgkQ8Jx8FtbMZnczSACgtOd/Ltv7PXDMYFkdbDHBeKdB
> n7UAoKNkSnBB/ZQZF96gwvKbTnXQq8Nt
> =lEQ5
> -----END PGP SIGNATURE-----