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

[Leif Johansson <[e-mail]>]

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

On 04/02/2012 05:58 AM, [e-mail] 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:[e-mail]] Sent: Sunday, April 01, 2012 5:59 PM To:
>> Black, David Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail] Subject: Re:
>> Gen-ART review of draft-johansson-loa-registry-04
>> 
> On 04/01/2012 10:57 PM, [e-mail] 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 [phone]             FAX:
>>>> [phone] [e-mail]        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-----