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@xxxxxxx Mobile: +1 (978) 394-7754 ----------------------------------------------------