-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/02/2012 05:58 AM, david(_dot_)black(_at_)emc(_dot_)com 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:leifj(_at_)sunet(_dot_)se] Sent: Sunday, April 01, 2012 5:59 PM To:
Black, David Cc: leifj(_at_)nordu(_dot_)net; gen-art(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; turners(_at_)ieca(_dot_)com;
tim(_dot_)polk(_at_)nist(_dot_)gov Subject: Re:
Gen-ART review of draft-johansson-loa-registry-04
On 04/01/2012 10:57 PM, david(_dot_)black(_at_)emc(_dot_)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(_dot_)black(_at_)emc(_dot_)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/
iEYEARECAAYFAk95UAwACgkQ8Jx8FtbMZnermACfYaNXTG9wfDIfauRXPPV++mal
EVwAoJgNIk/1iXwEBMjURYOpyi3L3SUw
=5XrB
-----END PGP SIGNATURE-----