Re: [calsify] [IANA #1156721] Early IANA Review for draft-ietf-calext-jscalendar-21

["Neil Jenkins" <[e-mail]>]

Sorry for the delay responding.

> About the statement that "The IANA will list common-use registrations prominently and separately from those with other intended use values": would listing common-use values first be sufficient, or would you want the registry divided into three separate registries? 

Listing common-use values first is fine, no need for separate registries.

> The registration procedure for common use registrations is described as Specification Required (it might be helpful to capitalize the registration procedures and cite RFC 8126), 

I will capitalise Specification Required. RFC 8126 is referenced in Section 8.2.3 describing the expert review, but I will add another reference here too.

> but in the template, the reference field is named "RFC Reference." On the other hand, if the statement in Section 8.2.3 that "for simple definitions a description in the registry may be sufficient" refers to the Specification Required range, I wonder if it could be more appropriate to describe the registration procedure for that range as Expert Review and have us add a note that says something like "RFC preferred." The registration procedures for all three ranges (common, reserved, obsolete) could be presented in a table like the ones at https://www.iana.org/assignments/cose, with the addition of a "Notes" field to expand on the requirements/expectations for common-use submissions.

I have changed this to "Reference or Description", defined as “A brief description or RFC number and section reference where the property is specified”.

While we could make it Expert Review, I think Specification Required is still correct, because we want to ensure there is sufficient documentation for interoperability. It's just sometimes a single sentence is sufficient, and to make it easy to update we'd like to just be able to put that straight in the registry rather than require a separate document.

Does that sound reasonable, or would you still prefer something different?

> The problem is that a description in the registry may not fit the description of Specification Required defined in Section 4.6 of RFC 8126:

Reading this again, I can't see anything in it that prohibits the specification being included in the registry entry itself.

> Sections 8.4.1 and 8.4.2 have the same title. 

This was a mistake; the second one should just be “JMAP Enum Subregistry Template”.

> Section 8.4 is unusual, as we haven't run into the idea of a template for a new subregistry.
> 
> We may have some presentation issues. We can't leave the subregistry name field blank, and it may not be possible to create additional fields at the top of the registry for Property Name, Property Context, and Change Controller, except within the context of a "Note:" field that appears after the registry reference. Even if the presentation in the document doesn't change, would it be possible to use a registry naming scheme that captures the property name and context, after which we could add the change controller information in a note? For example, would something like this work? 
> 
> Registry Name: Enum Values for freeBusyStatus Property (Contexts: JSEvent, JSTask)
> Reference: [this document]
> Registration Procedure: Expert Review
> Expert(s): [expert names]
> Note:
> Change Controller: IETF

I think this would be OK. I guess my main questions is can a new subregistry be added without an RFC (i.e. just by submitting to IANA the new subregistry template)? The scenario I'm thinking of is someone adds a new simple enumerable property and so needs a new subregistry.

> One more question: Section 8.4.1 says that the IETF is the change controller for Standards Track / BCP RFCs, but would the IETF not be the change controller for any IETF-stream RFC?

Yes, they probably should be. I've changed that.

I have published a new draft <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-22> with the above changes for review.

Many thanks,
Neil.