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@xxxxxxxx] > Sent: Sunday, April 01, 2012 5:59 PM > To: Black, David > Cc: leifj@xxxxxxxxx; gen-art@xxxxxxxx; ietf@xxxxxxxx; turners@xxxxxxxx; tim.polk@xxxxxxxx > 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@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-----