-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/01/2012 10:57 PM, david.black@xxxxxxx 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@xxxxxxx 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-----