Scott,

Changing draft-ietf-regext-rdap-redacted from "Three new RDAP JSON Values 
Registry Type field values are used to register 
pre-defined redacted name, reason, and expression language values:" to the 
below is a good and flexible option.  

"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:"

Thanks,

-- 

JG 



James Gould
Fellow Engineer
jgo...@verisign.com 
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 




On 9/11/23, 11:38 AM, "regext on behalf of Hollenbeck, Scott" 
<regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of 
shollenbeck=40verisign....@dmarc.ietf.org 
<mailto:40verisign....@dmarc.ietf.org>> wrote:


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. 


> -----Original Message-----
> From: regext <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org>> On 
> Behalf Of Gould, James
> Sent: Monday, September 11, 2023 11:18 AM
> To: shollenbeck=40verisign....@dmarc.ietf.org 
> <mailto:40verisign....@dmarc.ietf.org>;
> jgould=40verisign....@dmarc.ietf.org <mailto:40verisign....@dmarc.ietf.org>; 
> drafts-expert-review-
> comm...@iana.org <mailto:comm...@iana.org>
> Cc: a...@hxr.us <mailto:a...@hxr.us>; regext@ietf.org <mailto: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 <mailto:regext@ietf.org>
https://secure-web.cisco.com/1oZDLbN8HzqUTGNVObNoGs1Lq-PILZiSDewMe75PqdQoT7EGTBQd_VdaDOuk2HhYFA5PPreLHZxgGobWDIcmfETzpqlD0iiztot9HIMv8NvrD8HBxxjzMDd7G8lgRqFNWbmV9dJEbqFeK1KcjH78z9JRSZOdv6ZRph-gZRZKkPbVsfSCeKq7q8xm5GcDCU7MhOWYDNovY-v3J1Emul8CEny4n3mGykhBg4S041s-2NWr8lNmcGogsAO45gjEt5DXJs6itjcbTZZi4icxrMGqAlGSVxXzPRAiKdCAi4Teszp0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
 
<https://secure-web.cisco.com/1oZDLbN8HzqUTGNVObNoGs1Lq-PILZiSDewMe75PqdQoT7EGTBQd_VdaDOuk2HhYFA5PPreLHZxgGobWDIcmfETzpqlD0iiztot9HIMv8NvrD8HBxxjzMDd7G8lgRqFNWbmV9dJEbqFeK1KcjH78z9JRSZOdv6ZRph-gZRZKkPbVsfSCeKq7q8xm5GcDCU7MhOWYDNovY-v3J1Emul8CEny4n3mGykhBg4S041s-2NWr8lNmcGogsAO45gjEt5DXJs6itjcbTZZi4icxrMGqAlGSVxXzPRAiKdCAi4Teszp0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>





_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Reply via email to