Re: [apps-discuss] Reivew of draft-johansson-loa-registry

[Leif Johansson <[e-mail]>]

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

On 04/06/2012 08:59 PM, Ted Hardie wrote:
> I have been selected as the Applications Area Directorate reviewer
> for this draft (for background on appsdir, please see 
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
>
>  Please resolve these comments along with any other Last Call
> comments you may receive. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.

Excellent review Ted, thank you very much!

> 
> Document:  draft-johansson-loa-registry Reviewer:Ted Hardie Review
> Date: April 6, 2012
> 
> Summary:
> 
> There are some clarifications needed to ensure that the resulting
> registry is as useful as possible.
> 
> Major Issues:
> 
> The document currently describes a registry primarily focused on 
> SAML Authentication Context Profiles, but with the understanding
> that other protocols may re-use the registry contents  in their own
> contexts:
> 
> 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.
> 
> Each registration contains a URI, a schema definition, a short
> name, and an informational URL.  It is not clear, however, whether
> these URIs must be unique across registrations.  Would it be
> possible, for example, to have a non-SAML usage documented in this
> registry by having it re-register with an existing URI, but a
> different informational URL? I believe this point should be made
> explicit as guidance to the expert reviewers.

No that would not be consistent with the intent of the registry. Did you
suggest that such a practice would be useful?

> 
> The document uses ABNF to describe the required format of the short
> name, but there is no reference for ABNF given; presumably RFC5234
> should be included as a reference.   The ABNF  in the document
> excludes specific prefixes (LOA, AL) in order to avoid
> non-descriptive short names, but it is not clear why it also 
> excludes all-digit references.  In general, the use of the ABNF for
> this seems fairly clumsy, and I would suggest that the document
> shift this from ABNF determinism to advice  (to both registrants
> and expert reviewers), to help ensure that the resulting names are
> useful. There are a host of equally problematic possibilities 
> (saml-loa-10, for example) that good guidance would better avoid
> than ABNF rules.
> 

I see your point. However I believe there is value in having very
clear guidance which the ABNF does give... Perhaps if I include
text in the reviewers guide along the lines of "The reviewers should
exclude registrations where the short name does not unambiguously
identify the LoA definition or where the short name is a simple
variation on one of the reserved (cf above) LoA names."

> For the "informational URL" definition, a list of permitted URI 
> schemes might be useful, as it is not clear whether a contact-only
> URI would be acceptable. The document says:
> 
> Informational URL:  A URL containing auxilliary information.  This 
> URL MUST minimally reference contact information for the 
> administrative authority of the level of assurance definition.
> 
> Would an informational URL of mailto:[e-mail]  be
> acceptable?
> 

Ah yes. Good catch!

> 
> Minor Issues:
> 
> The example given in 3.1 does not give an information URL, but the 
> registration template implies that this field is mandatory.
> 

Good catch. Quite embarrassing :-)

> In 4.1, the document twice uses the term "bona fide" to describe
> entries:
> 
> The expectation of the IANA LoA Registry is that it contain bona
> fide Level of Assurance Profiles while not presenting a very high
> bar for entry.  Expert reviewers SHOULD NOT place undue value in
> any percieved or actual quality of the associated trust framework
> or federation and SHOULD only exclude such registrations that in
> the view of the experts do not represent bona fide attempts at
> defining an LoA.
> 
> I suggest that "good faith" be used to replace at least one of
> these, to clarify the meaning.
> 

I like it.

> 
> 
> 
> Nits: [list editorial issues such as typographical errors,
> preferably by section number]
> 
> I personally found the Introduction somewhat hard to parse, and I
> believe it would be improved by bringing paragraphs two and three
> forward, then following them with the gist of paragraphs one and
> four.
> 
> 
> In the Acknowledgements Section:
> 
> The various versions of the draft was socialized
> 
> should be "were socialized".

Yep

	Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+BgtEACgkQ8Jx8FtbMZnfR4ACbBK2JHXFpM9nEehqAp6IinGW9
2HwAn3qHKIXXpVHEHEEJ7+6qpmIZTc+a
=mHA3
-----END PGP SIGNATURE-----