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

From: Daniel Migault <[email-masked]>
Date: Thu, 28 Nov 2019 15:26:41 +0000

I am ccing the authors. 
Yours, 
Daniel

-----Original Message-----
From: Amanda Baber via RT <[email-masked]> 
Sent: Wednesday, November 27, 2019 9:46 PM
Cc: Daniel Migault <[email-masked]>
Subject: [IANA #1156721] Early IANA Review for draft-ietf-calext-jscalendar-21

Hi Daniel,

Michelle may have more to add to this, but we have a review for Sections 8.2 and 8.3 and a few questions about Section 8.4. 

Sections 8.2 and 8.3:

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? 

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), but in the template, the reference field is named "RFC Reference."

If it's possible to make a registration with another type of document, as the choice of Specification Required implies, we recommend changing the name of the field to "Reference." If the intention is to require an expert review while requiring an RFC, we suggest combining two registration procedures, as in the Option Codes registry at https://www.iana.org/assignments/dhcpv6-parameters. If that's what's needed, the registration procedure could be called "Expert Review and RFC Required."

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.

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:

https://tools.ietf.org/html/rfc8126#section-4.6

Also, if a description is to be used in place of a reference, would it be placed in the Reference field, a renamed reference field, or in a separate optional Description field? If IANA had a form based on this registry, would a submitter know where to place the description?

About Section 8.4:

Sections 8.4.1 and 8.4.2 have the same title. If initial values are included in the 8.4.1 template, should there be a reference/description field here to go with them?

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 should add that in the future we may be using a presentation method that allows you to click on a registration name and go directly to its 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?

thanks,
Amanda

On Fri Nov 22 02:22:06 2019, [email-masked] wrote:
> Thanks Michelle!
>  Yours,
> Daniel
> 
> -----Original Message-----
>  From: Michelle Cotton via RT <[email-masked]>
> Sent: Thursday, November 21, 2019 3:01 PM
> Cc: Daniel Migault <[email-masked]>
> Subject: [IANA #1156721] Early IANA Review for draft-ietf-calext-
> jscalendar-21
> 
> Hello Daniel,
> 
> I wanted to let you know that I have created this ticket for the early 
> review of your document.
> We'll get a review back to you as soon as possible.
> 
> Thanks,
> Michelle
>