Note: This ballot was opened for revision 05 and is now closed.
Thanks for this useful document. I plan to support its approval shortly, but I think we need to finish the discussion we had with Paul's Gen-ART review. I think I'm starting to agree with Mike, but this is worthwhile to point out to the IESG during our deliberations tomorrow. (The issue is whether as per RFC 5226 one sends a request to a DE and he or she may send it to mailing list, or if IANA should send the request directly to a mailing list. But I think the language in draft-leiba-cotton-iana-5226bis is looser on this respect, as it probably should be. Or I thought the language is looser... but opinions seem to differ. Maybe we need to send mail to the authors of 5226bis to ask for clarification-)
In 6.1, the text seems to say experts must enforce one of two different standards for handling characters outside the non-printable ascii set. Is that the intent? That seems to invite inconsistent decisions from different experts. Would it make more sense to say that experts must make sure one of the two standards is met, rather than choosing which standard they want to follow?
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.
Could the values in this registry also be used for draft-ietf-kitten-krb-auth-indicator-06?
Thank you for addressing by DISCUSS and comment.