Establishing a CAA parameter registry in another document

[ounsworth]

Corey Bonnell suggested that we structure the Discovery and Priority definitions and IANA registry requests on how they did it in rfc8657.

[vanbroup]

RFC8657 includes the following IANA Considerations:

This document has no IANA actions. As per [RFC8659], the parameter namespace for the CAA "issue" and "issuewild" Properties has CA-defined semantics, and the identifiers within that namespace may be freely and arbitrarily assigned by a CA. This document merely specifies recommended semantics for parameters of the names "accounturi" and "validationmethods", which CAs may choose to adopt.

We can include the same statement but I'm not sure how helpful this is.

[vanbroup]

@CBonnell can you clarify your suggestion?

[CBonnell]

@vanbroup My recollection might be a bit hazy, but @ounsworth and I discussed the verbiage that you quoted in #14 (comment). A statement similar to the quoted RFC 8657 text would be useful, as it explains to the reader why these parameters are not in any registry.

Another proposal that we discussed was this document (or perhaps another document?) establishing a CAA parameter registry. Although there is no requirement for a RFC 8659-compliant CA to process parameters, having a list of parameters whose recommended semantics have been defined would likely be useful.

If I had to choose between the two options, I'd lean towards the latter one, as it adds discoverability to the IETF-defined parameters.

[vanbroup]

Thanks for clarifying, I agree that we might want to establish a registry in a seperate document.

[vanbroup]

@ounsworth wrote:

At 117, I spoke with Phillip Hallam-Baker (the IANA Designated Expert for the CAA registry) and he’s ok with creating whatever registries for whatever parameters we need to make this work.

https://mailarchive.ietf.org/arch/msg/acme/UV5ET0T7cOnVjh-SfkdbRIgrtfw/