[OAUTH-WG] Stephen Farrell's No Objection on

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-amr-values-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thanks for clarifying that amr represents classes of auth methods and
not (always) individual methods, that all makes more sense now;-)

I think you might usefully add the phrase "classes of" (or similar) to
the draft in a few places to help folks understand that, in particular,
I spotted two places where I think something like that'd be good:

1. in the definition, I'd suggest:

OLD:

amr
OPTIONAL. Authentication Methods References. JSON array of
strings that are identifiers for authentication methods used in
the authentication.

NEW:

amr
OPTIONAL. Authentication Methods References. JSON array of
strings that are identifiers for classes of authentication methods
used in
the authentication.

2. In the IANA considerations and DE guidance, maybe make the name
of the new registry reflect that these are classes, in case someone
gets
confused only having looked at the IANA pages without reading the RFC,
and perhaps point the DE guidance back to the top bit where you explain
this stuff and add "classes of" in a few places in the template to save
the DEs having to explain that over and over to people who just copy
templates.

Thanks,
S.

[Mike Jones]

Thanks, Stephen. I'll try to apply the suggested changes before the cutoff.

-- Mike

-----Original Message-----
From: Stephen Farrell [mailto:***@cs.tcd.ie]
Sent: Monday, March 13, 2017 8:28 AM
To: The IESG <***@ietf.org>
Cc: draft-ietf-oauth-amr-***@ietf.org; Hannes Tschofenig <***@gmx.net>; oauth-***@ietf.org; ***@gmx.net; ***@ietf.org
Subject: Stephen Farrell's No Objection on draft-ietf-oauth-amr-values-07: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-amr-values-07: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thanks for clarifying that amr represents classes of auth methods and not (always) individual methods, that all makes more sense now;-)

I think you might usefully add the phrase "classes of" (or similar) to the draft in a few places to help folks understand that, in particular, I spotted two places where I think something like that'd be good:

1. in the definition, I'd suggest:

OLD:

amr
OPTIONAL. Authentication Methods References. JSON array of
strings that are identifiers for authentication methods used in
the authentication.

NEW:

amr
OPTIONAL. Authentication Methods References. JSON array of
strings that are identifiers for classes of authentication methods used in
the authentication.

2. In the IANA considerations and DE guidance, maybe make the name of the new registry reflect that these are classes, in case someone gets confused only having looked at the IANA pages without reading the RFC, and perhaps point the DE guidance back to the top bit where you explain this stuff and add "classes of" in a few places in the template to save the DEs having to explain that over and over to people who just copy templates.

Thanks,
S.

[Mike Jones]

Hi Stephen,

Per your suggestion, I added text in the IANA Registration Template saying that names can be for families of closely-related authentication methods. That way, even if people don't read the spec, when they try to register values, they should see the description.

I can't change the definition as you suggested, since that's actually quoted from a different final specification. The good news, however, is that the next sentence after the definition is about values typically being for families of closely-related authentication methods, so I think we're covered there too.

Thanks again for the careful read, as always!

Cheers,
-- Mike

-----Original Message-----
From: Stephen Farrell [mailto:***@cs.tcd.ie]
Sent: Monday, March 13, 2017 8:28 AM
To: The IESG <***@ietf.org>
Cc: draft-ietf-oauth-amr-***@ietf.org; Hannes Tschofenig <***@gmx.net>; oauth-***@ietf.org; ***@gmx.net; ***@ietf.org
Subject: Stephen Farrell's No Objection on draft-ietf-oauth-amr-values-07: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-amr-values-07: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thanks for clarifying that amr represents classes of auth methods and not (always) individual methods, that all makes more sense now;-)

I think you might usefully add the phrase "classes of" (or similar) to the draft in a few places to help folks understand that, in particular, I spotted two places where I think something like that'd be good:

1. in the definition, I'd suggest:

OLD:

amr
OPTIONAL. Authentication Methods References. JSON array of
strings that are identifiers for authentication methods used in
the authentication.

NEW:

amr
OPTIONAL. Authentication Methods References. JSON array of
strings that are identifiers for classes of authentication methods used in
the authentication.

2. In the IANA considerations and DE guidance, maybe make the name of the new registry reflect that these are classes, in case someone gets confused only having looked at the IANA pages without reading the RFC, and perhaps point the DE guidance back to the top bit where you explain this stuff and add "classes of" in a few places in the template to save the DEs having to explain that over and over to people who just copy templates.

Thanks,
S.