> -----Original Message----- > From: regext <regext-boun...@ietf.org> On Behalf Of Gould, James > Sent: Monday, September 11, 2023 11:18 AM > To: shollenbeck=40verisign....@dmarc.ietf.org; > jgould=40verisign....@dmarc.ietf.org; drafts-expert-review- > comm...@iana.org > Cc: a...@hxr.us; regext@ietf.org > Subject: [EXTERNAL] Re: [regext] [IANA #1280008] expert review for draft- > ietf-regext-rdap-redacted (rdap-json-values) > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content > is safe. > > Scott, > > I like the idea of being able to update the registry to include the > additional > Type values, since that would add support for extensibility by the RDAP > extensions. RFC 9083 includes the requirement for the Expert Review > process, which in this case highlights the support for new registry types, > where there are two use cases: > > 1. Define new Type values that can be used for future registrations - > "redacted name" and "redacted reason" Type values > 2. Define new Type value that corresponds with a new registration - > "redacted expression language" Type value with the "jsonpath" registration > > In use case #2, the registration will include the reference to the Type > definition in the draft-ietf-regext-rdap-redacted RFC. In use case #1 there > will be nothing in the registry until there are new registrations using the > Type > values. I would anticipate that the new registrations will reference the > draft- > ietf-regext-rdap-redacted RFC in the registration. The Reference could be > followed for all concrete registrations to find the Type definitions, which > will > be handled for use case #2 initially and in the future for use case #1. > > If the definition of new Type values in both use cases need to be included > in > the Reference section of the Registry itself, how can that be handled?
[SAH] The designated experts are limited to helping IANA review requests to add new values to an existing registry. We look at the request, the registry, and the specification (9083 in this case) that defines the registry, and ensure that the request is valid based on the requirements that are defined in the specification. The experts cannot change the structure of the registry, or approve requests that somehow change the registry. As currently written, the draft defines type values that conflict with 9083. I see two ways to deal with that: change the draft so that it updates 9083, or change the draft so that the IANA instructions in Section 6.2 clearly state that the draft defines three new "type" field values that can be used to populate the RDAP JSON Values Registry. My preference would be the latter approach. That is, change this text in Section 6.2: "Three new RDAP JSON Values Registry Type field values are used to register pre-defined redacted name, reason, and expression language values:" To this: "This specification defines three new RDAP JSON Values Registry Type field values that can be used to register pre-defined redacted name, reason, and expression language values. IANA is instructed to update the RDAP JSON Values Registry to accept these additional type field values as follows:" The net effect of this instruction should be a change to the registry such that the identified reference will change from 9083 alone to 9083 plus this RFC-to-be. Other new type values can be added the same way. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
