Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[James Galvin]

In fact, OpenID is next on the list as soon as we get “redacted” out the door.

Jim


On 23 May 2023, at 15:12, Hollenbeck, Scott wrote:

>> -Original Message-
>> From: regext  On Behalf Of James Galvin
>> Sent: Tuesday, May 23, 2023 3:00 PM
>> To: Gould, James 
>> Cc: t...@apnic.net; ietf=40antoin...@dmarc.ietf.org; regext@ietf.org
>> Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11
>>
>> 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.
>>
>> Thank you Jim Gould, and everyone for bringing this to closure.
>>
>> This WGLC is now closed.
>
> [SAH] Can we start the last call for the federated authentication draft next?
>
> Scott

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

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Hollenbeck, Scott]

> -Original Message-
> From: regext  On Behalf Of James Galvin
> Sent: Tuesday, May 23, 2023 3:00 PM
> To: Gould, James 
> Cc: t...@apnic.net; ietf=40antoin...@dmarc.ietf.org; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11
>
> 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.
>
> Thank you Jim Gould, and everyone for bringing this to closure.
>
> This WGLC is now closed.

[SAH] Can we start the last call for the federated authentication draft next?

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

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[James Galvin]

Thank you Jim Gould, and everyone for bringing this to closure.

This WGLC is now closed.

In order to move this document forward the Chairs will need the document 
shepherd (Gustavo Ibarra) to indicate on the list if all issues have been 
addressed when v12 is published.

The Chairs will also need Tom Harrison and Andy Newton to indicate on the list 
if their questions have been satisfactorily addressed.

And, of course, the document shepherd will need to prepare the usual writeup.

Thanks again to all!

Antoin and Jim


On 23 May 2023, at 7:47, Gould, James wrote:

> Tom,
>
> Thanks for all your feedback.  I'll be making the edits based on the feedback 
> received and posting draft-ietf-regext-rdap-redacted-12 tomorrow or Thursday.
>
> Thanks,
>
> -- 
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com 
> 
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
>
>
>
>
> On 5/22/23, 7:07 PM, "Tom Harrison" mailto:t...@apnic.net>> 
> wrote:
>
>
>
> Hi James,
>
>
> On Mon, May 22, 2023 at 09:08:53PM +, Gould, James wrote:
>> On 5/22/23, 8:12 AM, "Tom Harrison" mailto:t...@apnic.net> 
>> >> wrote:
>>> On Fri, May 19, 2023 at 12:48:11PM +, Gould, James wrote:
 For background, the considerations associated with multiple roles
 were added to section 5.2, based on the multiple role discussion
 that happened on the mailing list. How about providing a note in
 Section 2 "Conventions Used in This Document" associated with the
 approach taken with the examples (e.g., based on unredacted RDAP
 lookup response in Figure 11 and using snippets from the redacted
 RDAP lookup response in Figure 12) and the use of single-role
 entities? The note could read:

 The examples are based on the unredacted RDAP lookup response in
 Figure 11 and use snippets from the redacted RDAP lookup response in
 Figure 12, which use single-role entities.
>>>
>>> The problem with this (which I could have made clearer in my last
>>> mail, sorry) is that the examples don't show how a client can
>>> distinguish (in-band) a server that limits each entity to a single
>>> role and a server that permits each entity to have multiple roles. If
>>> it isn't communicated in-band, then clients are stuck with the
>>> incorrect inference from the path. Some potential options:
>>>
>>> - Embed this aspect of server policy in the "name"."description" text
>>> for the relevant "redacted" entries.
>>> - Declare in the document than any prePath with the form
>>> "$.entities[?(@.roles[0]==...)]" means that the server will always
>>> include at most one entry in the associated "roles" list. (Servers
>>> using multiple-role entities have no reason to include a path like
>>> this, as best as I can tell.)
>>> - Add some sort of flag (e.g. to the "/help" response) indicating
>>> that entities returned by this server will only ever contain one
>>> role.
>>> - The suggestion from the previous mail (i.e. remove the prePaths
>>> that have this form).
>>
>> Based on a separate private thread with Mario, who provided the
>> example expressions, it looks like the
>> "$.entities[?(@.roles[0]==...)]" will match all entities with the
>> role defined at position 0 of the roles array, so it doesn't need to
>> be done one-by-one. A more flexible approach is to use the function
>> extension, such as the non-standard indexOf function extension
>> supported by jsonpath.com. The expression
>> $.entities[?(@.roles.indexOf('technical')!=-1)] does match all
>> entities with the "technical" role defined anywhere within the roles
>> array. Jsonpath-base defines a different syntax for function
>> extensions, so it could be supported by a server using something
>> like $.entities[?indexOf(@.roles,'technical')!=-1]. The exact JSON
>> expression to use will be up to server policy and out-of-scope for
>> draft-ietf-regext-rdap-redacted. I can add clarity Section 2
>> "Conventions Used in This Document" that the examples are based on
>> the unredacted RDAP lookup response in Figure 11 and using snippets
>> from the redacted RDAP lookup response in Figure 12. Figure 11 and
>> Figure 12 can include a multi-role entity example if that helps or
>> specify that the examples only cover a single-role entities. The
>> prePaths are optional and are used in the examples to demonstrate
>> the use of the expressions.
>
>
> Specifying that the exact paths to use are out of scope and that the
> examples are limited to single-role entities sounds fine to me,
> thanks.
>
>
> Signalling via "name" exclusively is sensible, but if that's the
> approach that has to be used for multiple-role entities, and it
> works for single-role entities as well, and it would avoid the
> problem with the ambiguous prePath, why not update the examples
> to use this approach? Assuming that the document registers the
> associated types, this would al

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Gould, James]

Tom,

Thanks for all your feedback.  I'll be making the edits based on the feedback 
received and posting draft-ietf-regext-rdap-redacted-12 tomorrow or Thursday.  

Thanks,

-- 

JG 



James Gould
Fellow Engineer
jgo...@verisign.com 


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

Verisign.com  




On 5/22/23, 7:07 PM, "Tom Harrison" mailto:t...@apnic.net>> 
wrote:



Hi James,


On Mon, May 22, 2023 at 09:08:53PM +, Gould, James wrote:
> On 5/22/23, 8:12 AM, "Tom Harrison" mailto:t...@apnic.net> 
> >> wrote:
>> On Fri, May 19, 2023 at 12:48:11PM +, Gould, James wrote:
>>> For background, the considerations associated with multiple roles
>>> were added to section 5.2, based on the multiple role discussion
>>> that happened on the mailing list. How about providing a note in
>>> Section 2 "Conventions Used in This Document" associated with the
>>> approach taken with the examples (e.g., based on unredacted RDAP
>>> lookup response in Figure 11 and using snippets from the redacted
>>> RDAP lookup response in Figure 12) and the use of single-role
>>> entities? The note could read:
>>> 
>>> The examples are based on the unredacted RDAP lookup response in
>>> Figure 11 and use snippets from the redacted RDAP lookup response in
>>> Figure 12, which use single-role entities.
>> 
>> The problem with this (which I could have made clearer in my last
>> mail, sorry) is that the examples don't show how a client can
>> distinguish (in-band) a server that limits each entity to a single
>> role and a server that permits each entity to have multiple roles. If
>> it isn't communicated in-band, then clients are stuck with the
>> incorrect inference from the path. Some potential options:
>> 
>> - Embed this aspect of server policy in the "name"."description" text
>> for the relevant "redacted" entries.
>> - Declare in the document than any prePath with the form
>> "$.entities[?(@.roles[0]==...)]" means that the server will always
>> include at most one entry in the associated "roles" list. (Servers
>> using multiple-role entities have no reason to include a path like
>> this, as best as I can tell.)
>> - Add some sort of flag (e.g. to the "/help" response) indicating
>> that entities returned by this server will only ever contain one
>> role.
>> - The suggestion from the previous mail (i.e. remove the prePaths
>> that have this form).
> 
> Based on a separate private thread with Mario, who provided the
> example expressions, it looks like the
> "$.entities[?(@.roles[0]==...)]" will match all entities with the
> role defined at position 0 of the roles array, so it doesn't need to
> be done one-by-one. A more flexible approach is to use the function
> extension, such as the non-standard indexOf function extension
> supported by jsonpath.com. The expression
> $.entities[?(@.roles.indexOf('technical')!=-1)] does match all
> entities with the "technical" role defined anywhere within the roles
> array. Jsonpath-base defines a different syntax for function
> extensions, so it could be supported by a server using something
> like $.entities[?indexOf(@.roles,'technical')!=-1]. The exact JSON
> expression to use will be up to server policy and out-of-scope for
> draft-ietf-regext-rdap-redacted. I can add clarity Section 2
> "Conventions Used in This Document" that the examples are based on
> the unredacted RDAP lookup response in Figure 11 and using snippets
> from the redacted RDAP lookup response in Figure 12. Figure 11 and
> Figure 12 can include a multi-role entity example if that helps or
> specify that the examples only cover a single-role entities. The
> prePaths are optional and are used in the examples to demonstrate
> the use of the expressions.


Specifying that the exact paths to use are out of scope and that the
examples are limited to single-role entities sounds fine to me,
thanks.


 Signalling via "name" exclusively is sensible, but if that's the
 approach that has to be used for multiple-role entities, and it
 works for single-role entities as well, and it would avoid the
 problem with the ambiguous prePath, why not update the examples
 to use this approach? Assuming that the document registers the
 associated types, this would also increase implementation
 consistency, which will make things easier on clients. (Even if
 the signalling is unregistered, and relies on "description", it
 at least puts the client on notice that if they want to
 understand what's happening more precisely, they'll need to get
 that information out of band.)
>>> 
>>> The examples do include the required "name" member, where the
>>> "prePath" member is included to provide a concrete example of use
>>> of the expression. The "name" member is required, and a note can
>>> be added that it can serve as the redaction signal. Would that
>>> help?
>> 
>> I'm not sure what "it can serve as the redaction signal" means
>> he

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Tom Harrison]

Hi James,

On Mon, May 22, 2023 at 09:08:53PM +, Gould, James wrote:
> On 5/22/23, 8:12 AM, "Tom Harrison" mailto:t...@apnic.net>> 
> wrote:
>> On Fri, May 19, 2023 at 12:48:11PM +, Gould, James wrote:
>>> For background, the considerations associated with multiple roles
>>> were added to section 5.2, based on the multiple role discussion
>>> that happened on the mailing list. How about providing a note in
>>> Section 2 "Conventions Used in This Document" associated with the
>>> approach taken with the examples (e.g., based on unredacted RDAP
>>> lookup response in Figure 11 and using snippets from the redacted
>>> RDAP lookup response in Figure 12) and the use of single-role
>>> entities? The note could read:
>>> 
>>> The examples are based on the unredacted RDAP lookup response in
>>> Figure 11 and use snippets from the redacted RDAP lookup response in
>>> Figure 12, which use single-role entities.
>> 
>> The problem with this (which I could have made clearer in my last
>> mail, sorry) is that the examples don't show how a client can
>> distinguish (in-band) a server that limits each entity to a single
>> role and a server that permits each entity to have multiple roles. If
>> it isn't communicated in-band, then clients are stuck with the
>> incorrect inference from the path. Some potential options:
>> 
>>  - Embed this aspect of server policy in the "name"."description" text
>>for the relevant "redacted" entries.
>>  - Declare in the document than any prePath with the form
>>"$.entities[?(@.roles[0]==...)]" means that the server will always
>>include at most one entry in the associated "roles" list.  (Servers
>>using multiple-role entities have no reason to include a path like
>>this, as best as I can tell.)
>>  - Add some sort of flag (e.g. to the "/help" response) indicating
>>that entities returned by this server will only ever contain one
>>role.
>>  - The suggestion from the previous mail (i.e. remove the prePaths
>>that have this form).
> 
> Based on a separate private thread with Mario, who provided the
> example expressions, it looks like the
> "$.entities[?(@.roles[0]==...)]" will match all entities with the
> role defined at position 0 of the roles array, so it doesn't need to
> be done one-by-one.  A more flexible approach is to use the function
> extension, such as the non-standard indexOf function extension
> supported by jsonpath.com.  The expression
> $.entities[?(@.roles.indexOf('technical')!=-1)] does match all
> entities with the "technical" role defined anywhere within the roles
> array.  Jsonpath-base defines a different syntax for function
> extensions, so it could be supported by a server using something
> like $.entities[?indexOf(@.roles,'technical')!=-1].  The exact JSON
> expression to use will be up to server policy and out-of-scope for
> draft-ietf-regext-rdap-redacted.  I can add clarity Section 2
> "Conventions Used in This Document" that the examples are based on
> the unredacted RDAP lookup response in Figure 11 and using snippets
> from the redacted RDAP lookup response in Figure 12.  Figure 11 and
> Figure 12 can include a multi-role entity example if that helps or
> specify that the examples only cover a single-role entities.  The
> prePaths are optional and are used in the examples to demonstrate
> the use of the expressions.

Specifying that the exact paths to use are out of scope and that the
examples are limited to single-role entities sounds fine to me,
thanks.

 Signalling via "name" exclusively is sensible, but if that's the
 approach that has to be used for multiple-role entities, and it
 works for single-role entities as well, and it would avoid the
 problem with the ambiguous prePath, why not update the examples
 to use this approach? Assuming that the document registers the
 associated types, this would also increase implementation
 consistency, which will make things easier on clients. (Even if
 the signalling is unregistered, and relies on "description", it
 at least puts the client on notice that if they want to
 understand what's happening more precisely, they'll need to get
 that information out of band.)
>>> 
>>> The examples do include the required "name" member, where the
>>> "prePath" member is included to provide a concrete example of use
>>> of the expression. The "name" member is required, and a note can
>>> be added that it can serve as the redaction signal. Would that
>>> help?
>> 
>> I'm not sure what "it can serve as the redaction signal" means
>> here.  Assuming that this is about adding text that makes it
>> clearer that the "name" member alone is sufficient to indicate the
>> field that's being redacted, then I don't think that will help,
>> because the problem with ambiguous prePaths will still be present.
>> (Putting aside the possibility of embedding this aspect of server
>> policy into the "name"."description" text, per the earlier
>> suggestion.)
> 
> T

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Gould, James]

Tom,

I include responses to your feedback embedded below.

-- 

JG 



James Gould
Fellow Engineer
jgo...@verisign.com 


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

Verisign.com  




On 5/22/23, 8:12 AM, "Tom Harrison" mailto:t...@apnic.net>> 
wrote:



Hi James,


On Fri, May 19, 2023 at 12:48:11PM +, Gould, James wrote:
> On Fri, May 05, 2023 at 10:36:18AM +1000, Tom Harrison wrote:
>> On Wed, May 03, 2023 at 07:50:07PM +, Gould, James wrote:
>>> In relation to the example JSONPath in the draft, they are based
>>> on the unredacted RDAP lookup response in Figure 11 and are
>>> snippets from the redacted RDAP lookup response in Figure 12. They
>>> are not intended to provide an example for a broader set of
>>> unredacted RDAP responses, such as having multiple entities with
>>> the same role.
>> 
>> Right, but section 3.1 has:
>> 
>> An example of redacting an RDAP object is removing the
>> administrative contact from the RDAP response and including the
>> following "redacted" member:
>> 
>> "redacted": [
>> {
>> "name": {
>> "type": "Administrative Contact"
>> },
>> "prePath": "$.entities[?(@.roles[0]=='administrative')]",
>> "method": "removal"
>> }
>> ]
>> 
>> i.e., it's presented as being of general application, and it's not
>> until much later in the document that the caveats around multiple
>> roles are noted (in section 5.2). The obvious fix is to note in the
>> text that the examples assume single-role entities, but even with that
>> approach there's no way for a client to know that a server will
>> include only single-role entities, and if the client doesn't know
>> that, then they are left with the (incorrect) inference from my
>> previous mail (that entities where the first role in the array is
>> administrative have been removed). Removing the prePath in this sort
>> of case addresses the problem.
> 
> For background, the considerations associated with multiple roles
> were added to section 5.2, based on the multiple role discussion
> that happened on the mailing list. How about providing a note in
> Section 2 "Conventions Used in This Document" associated with the
> approach taken with the examples (e.g., based on unredacted RDAP
> lookup response in Figure 11 and using snippets from the redacted
> RDAP lookup response in Figure 12) and the use of single-role
> entities? The note could read:
> 
> The examples are based on the unredacted RDAP lookup response in
> Figure 11 and use snippets from the redacted RDAP lookup response in
> Figure 12, which use single-role entities.


The problem with this (which I could have made clearer in my last
mail, sorry) is that the examples don't show how a client can
distinguish (in-band) a server that limits each entity to a single
role and a server that permits each entity to have multiple roles. If
it isn't communicated in-band, then clients are stuck with the
incorrect inference from the path. Some potential options:


- Embed this aspect of server policy in the "name"."description" text
for the relevant "redacted" entries.
- Declare in the document than any prePath with the form
"$.entities[?(@.roles[0]==...)]" means that the server will always
include at most one entry in the associated "roles" list. (Servers
using multiple-role entities have no reason to include a path like
this, as best as I can tell.)
- Add some sort of flag (e.g. to the "/help" response) indicating
that entities returned by this server will only ever contain one
role.
- The suggestion from the previous mail (i.e. remove the prePaths
that have this form).

JG - Based on a separate private thread with Mario, who provided the example 
expressions, it looks like the "$.entities[?(@.roles[0]==...)]" will match all 
entities with the role defined at position 0 of the roles array, so it doesn't 
need to be done one-by-one.  A more flexible approach is to use the function 
extension, such as the non-standard indexOf function extension supported by 
jsonpath.com.  The expression $.entities[?(@.roles.indexOf('technical')!=-1)] 
does match all entities with the "technical" role defined anywhere within the 
roles array.  Jsonpath-base defines a different syntax for function extensions, 
so it could be supported by a server using something like 
$.entities[?indexOf(@.roles,'technical')!=-1].  The exact JSON expression to 
use will be up to server policy and out-of-scope for 
draft-ietf-regext-rdap-redacted.  I can add clarity Section 2 "Conventions Used 
in This Document" that the examples are based on the unredacted RDAP lookup 
response in Figure 11 and using snippets from the redacted RDAP lookup response 
in Figure 12.  Figure 11 and Figure 12 can include a multi-role entity example 
if that helps or specify that the examples only cover a single-role entities.  
The prePaths are optional and are used in the examples to demonstrate the use 
of the expressions.  

>>> This JSONPath would not comply with draft-ietf-jsonpath-base. You
>>> can use the g

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Tom Harrison]

Hi James,

On Fri, May 19, 2023 at 12:48:11PM +, Gould, James wrote:
> On Fri, May 05, 2023 at 10:36:18AM +1000, Tom Harrison wrote:
>> On Wed, May 03, 2023 at 07:50:07PM +, Gould, James wrote:
>>> In relation to the example JSONPath in the draft, they are based
>>> on the unredacted RDAP lookup response in Figure 11 and are
>>> snippets from the redacted RDAP lookup response in Figure 12. They
>>> are not intended to provide an example for a broader set of
>>> unredacted RDAP responses, such as having multiple entities with
>>> the same role.
>> 
>> Right, but section 3.1 has:
>> 
>>An example of redacting an RDAP object is removing the
>>administrative contact from the RDAP response and including the
>>following "redacted" member:
>> 
>>"redacted": [
>>  {
>>"name": {
>>  "type": "Administrative Contact"
>>},
>>"prePath": "$.entities[?(@.roles[0]=='administrative')]",
>>"method": "removal"
>>  }
>>]
>> 
>> i.e., it's presented as being of general application, and it's not
>> until much later in the document that the caveats around multiple
>> roles are noted (in section 5.2).  The obvious fix is to note in the
>> text that the examples assume single-role entities, but even with that
>> approach there's no way for a client to know that a server will
>> include only single-role entities, and if the client doesn't know
>> that, then they are left with the (incorrect) inference from my
>> previous mail (that entities where the first role in the array is
>> administrative have been removed).  Removing the prePath in this sort
>> of case addresses the problem.
> 
> For background, the considerations associated with multiple roles
> were added to section 5.2, based on the multiple role discussion
> that happened on the mailing list.  How about providing a note in
> Section 2 "Conventions Used in This Document" associated with the
> approach taken with the examples (e.g., based on unredacted RDAP
> lookup response in Figure 11 and using snippets from the redacted
> RDAP lookup response in Figure 12) and the use of single-role
> entities?  The note could read:
> 
> The examples are based on the unredacted RDAP lookup response in
> Figure 11 and use snippets from the redacted RDAP lookup response in
> Figure 12, which use single-role entities.

The problem with this (which I could have made clearer in my last
mail, sorry) is that the examples don't show how a client can
distinguish (in-band) a server that limits each entity to a single
role and a server that permits each entity to have multiple roles.  If
it isn't communicated in-band, then clients are stuck with the
incorrect inference from the path.  Some potential options:

 - Embed this aspect of server policy in the "name"."description" text
   for the relevant "redacted" entries.
 - Declare in the document than any prePath with the form
   "$.entities[?(@.roles[0]==...)]" means that the server will always
   include at most one entry in the associated "roles" list.  (Servers
   using multiple-role entities have no reason to include a path like
   this, as best as I can tell.)
 - Add some sort of flag (e.g. to the "/help" response) indicating
   that entities returned by this server will only ever contain one
   role.
 - The suggestion from the previous mail (i.e. remove the prePaths
   that have this form).

>>> This JSONPath would not comply with draft-ietf-jsonpath-base.  You
>>> can use the guidance provided by including multiple “redacted”
>>> member fields with JSONPath entries (“prePath” or “postPath” ) or
>>> decide not to use the JSONPath (“prePath” or “postPath” ) and signal
>>> it with a registered “name” child member, such as:
>>> 
>>> "redacted": [
>>>   {
>>> "name": {
>>>   "type": "Administrative Contact"
>>> },
>>> "method": "removal"
>>>   }
>>> ]
>> 
>> Signalling via "name" exclusively is sensible, but if that's the
>> approach that has to be used for multiple-role entities, and it works
>> for single-role entities as well, and it would avoid the problem with
>> the ambiguous prePath, why not update the examples to use this
>> approach?  Assuming that the document registers the associated types,
>> this would also increase implementation consistency, which will make
>> things easier on clients.  (Even if the signalling is unregistered,
>> and relies on "description", it at least puts the client on notice
>> that if they want to understand what's happening more precisely,
>> they'll need to get that information out of band.)
> 
> The examples do include the required "name" member, where the
> "prePath" member is included to provide a concrete example of use of
> the expression.  The "name" member is required, and a note can be
> added that it can serve as the redaction signal.  Would that help?

I'm not sure what "it can serve as the redaction signal" means here.
Assuming that this is about adding text that makes it clearer that the
"name" member alo

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Gould, James]

Tom,

Thanks again for the feedback.  Below are responses to your feedback.

-- 

JG 



James Gould
Fellow Engineer
jgo...@verisign.com 


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

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

> -Original Message-
> From: regext mailto:regext-boun...@ietf.org>> On 
> Behalf Of Tom Harrison
> Sent: Thursday, May 4, 2023 8:36 PM
> To: Gould, James mailto:jgo...@verisign.com>>
> Cc: ietf=40antoin...@dmarc.ietf.org <mailto:40antoin...@dmarc.ietf.org>; 
> regext@ietf.org <mailto:regext@ietf.org>
> Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11
>
> 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.
>
> Hi James,
>
> On Wed, May 03, 2023 at 07:50:07PM +, Gould, James wrote:
> > In relation to the example JSONPath in the draft, they are based on
> > the unredacted RDAP lookup response in Figure 11 and are snippets from
> > the redacted RDAP lookup response in Figure 12. They are not intended
> > to provide an example for a broader set of unredacted RDAP responses,
> > such as having multiple entities with the same role.
>
> Right, but section 3.1 has:
>
> An example of redacting an RDAP object is removing the
> administrative contact from the RDAP response and including the
> following "redacted" member:
>
> "redacted": [
> {
> "name": {
> "type": "Administrative Contact"
> },
> "prePath": "$.entities[?(@.roles[0]=='administrative')]",
> "method": "removal"
> }
> ]
>
> i.e., it's presented as being of general application, and it's not until 
> much later
> in the document that the caveats around multiple roles are noted (in section
> 5.2). The obvious fix is to note in the text that the examples assume 
> single-role
> entities, but even with that approach there's no way for a client to know 
> that a
> server will include only single-role entities, and if the client doesn't 
> know that,
> then they are left with the (incorrect) inference from my previous mail 
> (that
> entities where the first role in the array is administrative have been 
> removed).
> Removing the prePath in this sort of case addresses the problem.
>

JG - For background, the considerations associated with multiple roles were 
added to section 5.2, based on the multiple role discussion that happened on 
the mailing list.  How about providing a note in Section 2 "Conventions Used in 
This Document" associated with the approach taken with the examples (e.g., 
based on unredacted RDAP lookup response in Figure 11 and using snippets from 
the redacted RDAP lookup response in Figure 12) and the use of single-role 
entities?  The note could read:

The examples are based on the unredacted RDAP lookup response in Figure 11 and 
use snippets from the redacted RDAP lookup response in Figure 12, which use 
single-role entities.  


> > Validating the JSONPath has been discussed previously on the mailing
> > list, but the approach for the draft was to use
> > https://secure-web.cisco.com/13326- <https://secure-web.cisco.com/13326->
> iHe0PhHEO3WJrsaAoB88qgOrE463kcupPIX
> > aG-
> zVAyTHJq5I4qNhDDj2_8jaGbQwKmDIgapXA7Ff_5ThoO0vlHQKTmeeqOKLLw8wK
> h9FP
> >
> RvbqWmnuuDRV_5SL1NnipqaCQmNJEV3OcBbMrevFXJ_rNT4CC3g9DZV_WKh1
> bb2oyp0Wdl
> >
> Du3EQskw36Ryr2bOQNVl4GcHxOrk8bavbbhnfXHEfwTyeW9Xg8EMlGsOZ2PFZg
> hYi6S9Az
> > Pg8wcCKTTxs3mlD9HN34p-3fX2uk4iKAVmNk1-
> gy1MT3HNqZg/https%3A%2F%2Fjsonpa
> > th.com with the RDAP lookup response in Figure 11 and validate that
> > the
> > example JSONPath resulted in the desired JSON members. The use of
> > the wildcard (*) states in draft-ietf-jsonpath-base-12:
> >
> > A wildcard * (Section 2.3.2) in the expression [*] selects all
> > children of a node and in the expression ..[*] selects all
> > descendants of a node.
> >
> > The use of $.entities[?(@.roles[*]=='administrative')] does not look
> > to match the definition and fails with
> > https://secure-web.cisco.com/13326- <https://secure-web.cisco.com/13326->
> iHe0PhHEO3WJrsaAoB88qgOrE463kcupPIX
> > aG-
> zVAyTHJq5I4qNhDDj2_8jaGbQwKmDIgapXA7Ff_5ThoO0vlHQKTmeeqOKLLw8wK
> h9FP
> >
> RvbqWmnuuDRV_5SL1NnipqaCQmNJEV3OcBbMrevFXJ_rNT4CC3g9DZV_WKh1
> bb2oyp0Wdl
> >
> Du3EQskw36Ryr2bOQNVl4GcHxOrk8bavbbhnfXHEfwTyeW9Xg8EMlGsOZ2PFZg
> hYi6S9Az
> > Pg8wcCKTTxs3mlD9HN34p-3fX2uk4iKAVmNk1-
> gy1MT3HNqZg/https%3A%2F%2Fjsonpa
> > th.com
> >
> &g

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Tom Harrison]

Hi James,

On Wed, May 03, 2023 at 07:50:07PM +, Gould, James wrote:
> In relation to the example JSONPath in the draft, they are based on
> the unredacted RDAP lookup response in Figure 11 and are snippets
> from the redacted RDAP lookup response in Figure 12.  They are not
> intended to provide an example for a broader set of unredacted RDAP
> responses, such as having multiple entities with the same role.

Right, but section 3.1 has:

   An example of redacting an RDAP object is removing the
   administrative contact from the RDAP response and including the
   following "redacted" member:

   "redacted": [
 {
   "name": {
 "type": "Administrative Contact"
   },
   "prePath": "$.entities[?(@.roles[0]=='administrative')]",
   "method": "removal"
 }
   ]

i.e., it's presented as being of general application, and it's not
until much later in the document that the caveats around multiple
roles are noted (in section 5.2).  The obvious fix is to note in the
text that the examples assume single-role entities, but even with that
approach there's no way for a client to know that a server will
include only single-role entities, and if the client doesn't know
that, then they are left with the (incorrect) inference from my
previous mail (that entities where the first role in the array is
administrative have been removed).  Removing the prePath in this sort
of case addresses the problem.

> Validating the JSONPath has been discussed previously on the mailing
> list, but the approach for the draft was to use https://jsonpath.com
> with the RDAP lookup response in Figure 11 and validate that the
> example JSONPath resulted in the desired JSON members.The use of
> the wildcard (*) states in draft-ietf-jsonpath-base-12:
> 
>   A wildcard * (Section 2.3.2) in the expression [*] selects all
>   children of a node and in the expression ..[*] selects all
>   descendants of a node.
> 
> The use of $.entities[?(@.roles[*]=='administrative')] does not look
> to match the definition and fails with https://jsonpath.com.
> 
> I provide more detailed responses to your feedback embedded below.
>
> On 4/25/23, 8:16 PM, "regext on behalf of Tom Harrison" 
> mailto:regext-boun...@ietf.org> on behalf of 
> t...@apnic.net  wrote:
>> On Mon, Apr 17, 2023 at 03:27:23PM +0200, Antoin Verschuren wrote:
>>> The document editors have indicated that the following document is
>>> ready for submission to the IESG to be considered for publication as
>>> a Proposed Standard:
>>>
>>> ...
>> 
>> Looks good overall, some minor comments/suggestions.
>>
>> Per previous mail from Pawel and Mario, some of the JSON path
>> expressions are not quite right for entities that have multiple
>> roles.  There are some issues with the guidance added to the
>> document to account for this, though, and some further updates in
>> this space that would be useful. (We rely on entities having
>> multiple roles in our server implementation at the moment, for
>> reference, and returning a copy of each entity per role as a
>> workaround is not ideal, particularly when addressing the comments
>> here shouldn't be difficult.) To summarise these issues (mostly
>> along the lines of the comments from Pawel and Mario):
>> 
>>  - The first example use of prePath has a value of:
>>
>> $.entities[?(@.roles[0]=='administrative')]
>>
>>But all that a client can infer from this path is that all
>>entities with "administrative" as their first role have been
>>removed. Since there are no guarantees around ordering of roles
>>within an entity, this doesn't necessarily mean that all
>>entities with "administrative" as one of their roles have been
>>removed from the resulting object. It would be better to use a
>>more general expression in this example (and the others like it)
>>that captured the intent more clearly. Per earlier mail from
>>Pawel, something like:
>> 
>> $.entities[?(@.roles[*]=='administrative')]
>> 
>>should do the job, though I wasn't able to determine the syntax
>>that would be acceptable for draft-ietf-jsonpath-base.
> 
> This JSONPath would not comply with draft-ietf-jsonpath-base.  You
> can use the guidance provided by including multiple “redacted”
> member fields with JSONPath entries (“prePath” or “postPath” ) or
> decide not to use the JSONPath (“prePath” or “postPath” ) and signal
> it with a registered “name” child member, such as:
> 
> "redacted": [
>   {
> "name": {
>   "type": "Administrative Contact"
> },
> "method": "removal"
>   }
> ]

Signalling via "name" exclusively is sensible, but if that's the
approach that has to be used for multiple-role entities, and it works
for single-role entities as well, and it would avoid the problem with
the ambiguous prePath, why not update the examples to use this
approach?  Assuming that the document registers the associated types,
this would also increase implementation consistency

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Gould, James]

Tom,



Thank you for your review and feedback.



In relation to the example JSONPath in the draft, they are based on the 
unredacted RDAP lookup response in Figure 11 and are snippets from the redacted 
RDAP lookup response in Figure 12.  They are not intended to provide an example 
for a broader set of unredacted RDAP responses, such as having multiple 
entities with the same role.  Validating the JSONPath has been discussed 
previously on the mailing list, but the approach for the draft was to use 
https://jsonpath.com with the RDAP lookup response in Figure 11 and validate 
that the example JSONPath resulted in the desired JSON members.The use of 
the wildcard (*) states in draft-ietf-jsonpath-base-12:


A wildcard * (Section 2.3.2) in the expression [*] selects all children of a 
node and in the expression ..[*] selects all descendants of a node.



The use of $.entities[?(@.roles[*]=='administrative')] does not look to match 
the definition and fails with https://jsonpath.com.



I provide more detailed responses to your feedback embedded below.



--



JG







James Gould

Fellow Engineer

jgo...@verisign.com 




703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 









On 4/25/23, 8:16 PM, "regext on behalf of Tom Harrison" 
mailto:regext-boun...@ietf.org> on behalf of 
t...@apnic.net > wrote:







On Mon, Apr 17, 2023 at 03:27:23PM +0200, Antoin Verschuren wrote:

> The document editors have indicated that the following document is

> ready for submission to the IESG to be considered for publication as

> a Proposed Standard:

>

> Redacted Fields in the Registration Data Access Protocol (RDAP) Response

> https://secure-web.cisco.com/1m8Jc5V3IUZ6YkB_A55wM2dnfKYv81MCPcYcihzzsCw4YWAahrFiCU_oJmmFU5wal-NelwIRMTEwEFogLtj48jxaodjIyaprjFasr_0TYCyk1Kz2syMWccw_d8676qs0jr3k55hNP0xbR0rje7hU756wcvUlp6Y0Gm1N1DwT90CSvz6KdUFwpziIC5GlXyw1ky9mTDqLBJXEnZcYF1SK4_9Q3P1Kp4jrSbYlfKyEAmTsGylkSlzmQSRfQJ7KyYeJZPTJ-F8JpLWpiUQ_cMBNYNanKxXV5qqGe4YOWwnLrpMA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-redacted%2F11%2F
>  
> 

>

> Please indicate your support or no objection for the publication of

> this document by replying to this message on list (a simple “+1” is

> sufficient).

>

> If any working group member has questions regarding the publication

> of this document please respond on the list with your concerns by

> close of business everywhere, Monday, 1 May 2023.

>

> If there are no objections the document will be submitted to the

> IESG.

>

> The Document Shepherd for this document is Gustavo Lozano Ibarra.





Looks good overall, some minor comments/suggestions.





Per previous mail from Pawel and Mario, some of the JSON path

expressions are not quite right for entities that have multiple roles.

There are some issues with the guidance added to the document to

account for this, though, and some further updates in this space that

would be useful. (We rely on entities having multiple roles in our

server implementation at the moment, for reference, and returning a

copy of each entity per role as a workaround is not ideal,

particularly when addressing the comments here shouldn't be

difficult.) To summarise these issues (mostly along the lines of the

comments from Pawel and Mario):





- The first example use of prePath has a value of:





$.entities[?(@.roles[0]=='administrative')]





But all that a client can infer from this path is that all entities

with "administrative" as their first role have been removed. Since

there are no guarantees around ordering of roles within an entity,

this doesn't necessarily mean that all entities with

"administrative" as one of their roles have been removed from the

resulting object. It would be better to use a more general

expression in this example (and the others like it) that captured

the intent more clearly. Per earlier mail from Pawel, something

like:





$.entities[?(@.roles[*]=='administrative')]





should do the job, though I wasn't able to determine the syntax

that would be acceptable for draft-ietf-jsonpath-base.



This JSONPath would not comply with draft-ietf-jsonpath-base.  You can use the 
guidance provided by including multiple “redacted” member fields with JSONPath 
entries (“prePath” or “postPath” ) or decide not to use the JSONPath (“prePath” 
or “postPath” ) and signal it with a registered “name” child member, such as:


"redacted": [
  {
"name": {
  "type": "Administrative Contact"
},
"method": "removal"
  }
]

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Mario Loffredo]

The draft-ietf-jsonpath-base GitHub project includes some Ruby code to 
test JSONPath expressions against the defined syntax.


But I don't know Ruby.

Maybe a Ruby programmer in this WG  could hopefully find out and test a 
JSONPath expression compliant with the jsonpath-base syntax and able to 
select an entity with a given role without assuming that the role is in 
the first position of the roles array.


Best,

Mario

Il 26/04/2023 21:05, Gould, James ha scritto:

I don't believe we're using advanced features of JSONPath in 
draft-ietf-regext-rdap-redacted and jsonpath.com has been used to validate the 
included examples.  If there is a better tool to use, please let me know and 
I'll validate the examples with it.  Otherwise, I believe we can continue to 
leverage jsonpath.com.

Thanks,


--
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

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

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Gould, James]

I don't believe we're using advanced features of JSONPath in 
draft-ietf-regext-rdap-redacted and jsonpath.com has been used to validate the 
included examples.  If there is a better tool to use, please let me know and 
I'll validate the examples with it.  Otherwise, I believe we can continue to 
leverage jsonpath.com.

Thanks,  

-- 

JG 



James Gould
Fellow Engineer
jgo...@verisign.com 


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

Verisign.com  




On 4/26/23, 1:07 PM, "regext on behalf of Mario Loffredo" 
mailto:regext-boun...@ietf.org> on behalf of 
mario.loffr...@iit.cnr.it > wrote:



Hi Andy,


Il 26/04/2023 17:55, Andrew Newton ha scritto:
> I see in the implementation section of the draft there is a test
> server that lists the redactions.
> However, has anybody taken any real output from a DNR and INR server
> and run some JSONPath expressions on them?
> Doing so would help to prove out this spec.


Think the main problem is that AFAIK there aren't JSONPath online 
testers fully compliant with jsonpath-base :-(


I have used some of them thus far (e.g. jsonpath.com, 
jsonpath.curiousconcept.com/) but they refer to proprietary 
implementations sharing only the basic features with jsonpath-base.


Just to be sure, have also tested on those sites some advanced JSONPath 
expressions included in jsonpath-base but they returned no results.




Mario


>
> -andy
>
> On Wed, Apr 26, 2023 at 7:39 AM Mario Loffredo
> mailto:mario.loffr...@iit.cnr.it>> wrote:
>>
>> Il 26/04/2023 02:16, Tom Harrison ha scritto:
>>> On Mon, Apr 17, 2023 at 03:27:23PM +0200, Antoin Verschuren wrote:
 The document editors have indicated that the following document is
 ready for submission to the IESG to be considered for publication as
 a Proposed Standard:

 Redacted Fields in the Registration Data Access Protocol (RDAP) Response
 https://secure-web.cisco.com/1KCYlZwumc1dMsWu4lHKi2uzBOOZvyGHP9hcYqgZZYMGctG6zT4WbgzJ4D7h00jgOtrNq-nsfqTPXQBiM-5NJUav2WwZAU6S44oavA2cTJbO2RNP-fXyJ3dWNpJ0kFN2Zkh4RLQm8xqqIofV2Vv5YEUrAyQcoVWKK7ZmjvnawHVQHFwdXd6FGwi15qKRETU82bAeP9GZePR3sCRJcmYowAT5gOf5M6zRDa65D-xeYOxmcOsyWHz5pwvW2WAwJTk-59INdwGqqglOwT_zhx90HhP7BkEDlAtcZ_VA2NL1kRNs/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-redacted%2F11%2F
  
 

 Please indicate your support or no objection for the publication of
 this document by replying to this message on list (a simple “+1” is
 sufficient).

 If any working group member has questions regarding the publication
 of this document please respond on the list with your concerns by
 close of business everywhere, Monday, 1 May 2023.

 If there are no objections the document will be submitted to the
 IESG.

 The Document Shepherd for this document is Gustavo Lozano Ibarra.
>>> Looks good overall, some minor comments/suggestions.
>>>
>>> Per previous mail from Pawel and Mario, some of the JSON path
>>> expressions are not quite right for entities that have multiple roles.
>>> There are some issues with the guidance added to the document to
>>> account for this, though, and some further updates in this space that
>>> would be useful. (We rely on entities having multiple roles in our
>>> server implementation at the moment, for reference, and returning a
>>> copy of each entity per role as a workaround is not ideal,
>>> particularly when addressing the comments here shouldn't be
>>> difficult.) To summarise these issues (mostly along the lines of the
>>> comments from Pawel and Mario):
>>>
>>> - The first example use of prePath has a value of:
>>>
>>> $.entities[?(@.roles[0]=='administrative')]
>>>
>>> But all that a client can infer from this path is that all entities
>>> with "administrative" as their first role have been removed. Since
>>> there are no guarantees around ordering of roles within an entity,
>>> this doesn't necessarily mean that all entities with
>>> "administrative" as one of their roles have been removed from the
>>> resulting object. It would be better to use a more general
>>> expression in this example (and the others like it) that captured
>>> the intent more clearly. Per earlier mail from Pawel, something
>>> like:
>>>
>>> $.entities[?(@.roles[*]=='administrative')]
>>>
>>> should do the job, though I wasn't able to determine the syntax
>>> that would be acceptable for draft-ietf-jsonpath-base.
>> [ML] Per what is reported in Sections 2.3.5.1 (filter selector syntax)
>> and 2.3.3.1 (index selector synta

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Mario Loffredo]

Hi Andy,

Il 26/04/2023 17:55, Andrew Newton ha scritto:

I see in the implementation section of the draft there is a test
server that lists the redactions.
However, has anybody taken any real output from a DNR and INR server
and run some JSONPath expressions on them?
Doing so would help to prove out this spec.


Think the main problem is that AFAIK there aren't JSONPath online 
testers fully compliant with jsonpath-base :-(


I have used some of them thus far (e.g. jsonpath.com, 
jsonpath.curiousconcept.com/) but they refer to proprietary 
implementations sharing only the basic features with jsonpath-base.


Just to be sure, have also tested on those sites some advanced JSONPath 
expressions included in jsonpath-base but they returned no results.



Mario



-andy

On Wed, Apr 26, 2023 at 7:39 AM Mario Loffredo
 wrote:


Il 26/04/2023 02:16, Tom Harrison ha scritto:

On Mon, Apr 17, 2023 at 03:27:23PM +0200, Antoin Verschuren wrote:

The document editors have indicated that the following document is
ready for submission to the IESG to be considered for publication as
a Proposed Standard:

Redacted Fields in the Registration Data Access Protocol (RDAP) Response
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/

Please indicate your support or no objection for the publication of
this document by replying to this message on list (a simple “+1” is
sufficient).

If any working group member has questions regarding the publication
of this document please respond on the list with your concerns by
close of business everywhere, Monday, 1 May 2023.

If there are no objections the document will be submitted to the
IESG.

The Document Shepherd for this document is Gustavo Lozano Ibarra.

Looks good overall, some minor comments/suggestions.

Per previous mail from Pawel and Mario, some of the JSON path
expressions are not quite right for entities that have multiple roles.
There are some issues with the guidance added to the document to
account for this, though, and some further updates in this space that
would be useful.  (We rely on entities having multiple roles in our
server implementation at the moment, for reference, and returning a
copy of each entity per role as a workaround is not ideal,
particularly when addressing the comments here shouldn't be
difficult.)  To summarise these issues (mostly along the lines of the
comments from Pawel and Mario):

   - The first example use of prePath has a value of:

  $.entities[?(@.roles[0]=='administrative')]

 But all that a client can infer from this path is that all entities
 with "administrative" as their first role have been removed.  Since
 there are no guarantees around ordering of roles within an entity,
 this doesn't necessarily mean that all entities with
 "administrative" as one of their roles have been removed from the
 resulting object.  It would be better to use a more general
 expression in this example (and the others like it) that captured
 the intent more clearly.  Per earlier mail from Pawel, something
 like:

  $.entities[?(@.roles[*]=='administrative')]

 should do the job, though I wasn't able to determine the syntax
 that would be acceptable for draft-ietf-jsonpath-base.

[ML] Per what is reported in Sections  2.3.5.1 (filter selector syntax)
and 2.3.3.1 (index selector syntax), it seems to me that wildcard is not
accepted.

The only acceptable values are integers (e.g. 0, 1, -1)

Neither any of the pre-defined functions seems helpful.

Looking at the examples in section 2.3.5.3, $.entities[?@.roles[?@ ==
'administrative]] could work maybe.


Another solution might be using the indexOf function that is defined by
some JSONPath implementations such as JSONPath.com and should be
registered as Function Extension (see Section 3.2) :

$.entities[?(@.roles.indexOf('administrative')!=-1)]  //tested on
jsonpath.com

Anyway, the indexOf syntax should be redefined to be compliant with the
jsonpath-base syntax:

$.entities[?indexOf(@.roles,'administrative')!=-1]


Best,

Mario


   - Section 5.2 at point 4 has:

  When an entity has multiple roles, include "redacted" members
  for each role using the role index.  This will result in
  duplicate "redacted" members, but will enable the client to
  treat redaction consistently when there is a single role per
  entity or multiple roles per entity.

 It's not clear why this advice is present, when compared with e.g.
 having the redacted members be a mapping from the server's
 policies.  For example, if the policy is that administrative
 contacts not be returned, then a single "redacted" entry with a
 prePath like "$.entities[?(@.roles[*]=='administrative')]" clearly
 conveys that message to the client, and the client will understand
 that those entities will be removed regardless of any additional
 roles that they might have.  How do multiple redacted members
 ena

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Gould, James]

Sorry, that didn't come out in a usable form.  I used jsonpath.com to validate 
the expressions against the pre-redacted response in the draft.

-- 

JG 



James Gould
Fellow Engineer
jgo...@verisign.com 


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

Verisign.com  




On 4/26/23, 12:46 PM, "regext on behalf of Gould, James" 
mailto:regext-boun...@ietf.org> on behalf of 
jgould=40verisign@dmarc.ietf.org > 
wrote:



Andy,


I used 
https://secure-web.cisco.com/1-bWL59tA3_up4WWjpW2qUjacDSlHoa9r9c4MxSmItvffYh6CTxSJ_rs00jhh8RRJeveLDWUhPyLWZlDl0eN-RCIJJuMo_JyF16tjWVNVJqlmTfFTlQN7VErnEXS4zCEKfKwGNnXyf7j3uuLJwfmBwyJL_JYmHw0sPLFb7mdLwrtGBYF7HGXbZDlZVg6ZP28-UWjH2FqVUJ-upXP3HAwyNgaxTmM59n4Nx_3QlAjzEJTilXdwx-gF0A2-qe4f4fB1xyaJTLP8Gfmr7I8zAQ1o2JgzZxtv4sv4uRjWrC5PRcQ/https%3A%2F%2Fjsonpath.com
 

 to validate the expressions against the pre-redacted response in the draft. 


-- 


JG 






James Gould
Fellow Engineer
jgo...@verisign.com  
mailto:jgo...@verisign.com>>


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


Verisign.com 

 
;>
 








On 4/26/23, 11:56 AM, "regext on behalf of Andrew Newton" 
mailto:regext-boun...@ietf.org> 
> on behalf of 
a...@hxr.us  >> 
wrote:






I see in the implementation section of the draft there is a test
server that lists the redactions.
However, has anybody taken any real output from a DNR and INR server
and run some JSONPath expressions on them?
Doing so would help to prove out this spec.




-andy




On Wed, Apr 26, 2023 at 7:39 AM Mario Loffredo
mailto:mario.loffr...@iit.cnr.it> 
>> wrote:
>
>
> Il 26/04/2023 02:16, Tom Harrison ha scritto:
> > On Mon, Apr 17, 2023 at 03:27:23PM +0200, Antoin Verschuren wrote:
> >> The document editors have indicated that the following document is
> >> ready for submission to the IESG to be considered for publication as
> >> a Proposed Standard:
> >>
> >> Redacted Fields in the Registration Data Access Protocol (RDAP) Response
> >> https://secure-web.cisco.com/1iAbLGLPLxLJO8hzh27ViRK4bd-bt0GbQhUPIR2fX6D5EeH2odcVEK_ffmTZkTj0-p2u2un10AG_qkU-2VEGTay2CrfhByh9LG9OyjOd4yNunvYI1mO081jP9odoXhstPWpgFkcNIBlN90l0TZGP8MMDPy8LarElavE224AKk8GoGO-X8IofymkVYZIokMprztLdnTYQZFRZxlmo3drbusAaAR9OJa81pIgusdOR7LAiEyQgfJriJGlrLt7jzh4thYH475NtZctFTSQ8-pufORdjZijb2qK1zVeOtu-qidbs/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-redacted%2F11%2F
> >>  
> >> 
> >>  
> >> 
> >>  
> >> 

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Gould, James]

Andy,

I used https://jsonpath.com to validate the expressions against the 
pre-redacted response in the draft.  

-- 

JG 



James Gould
Fellow Engineer
jgo...@verisign.com 


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

Verisign.com  




On 4/26/23, 11:56 AM, "regext on behalf of Andrew Newton" 
mailto:regext-boun...@ietf.org> on behalf of 
a...@hxr.us > wrote:



I see in the implementation section of the draft there is a test
server that lists the redactions.
However, has anybody taken any real output from a DNR and INR server
and run some JSONPath expressions on them?
Doing so would help to prove out this spec.


-andy


On Wed, Apr 26, 2023 at 7:39 AM Mario Loffredo
mailto:mario.loffr...@iit.cnr.it>> wrote:
>
>
> Il 26/04/2023 02:16, Tom Harrison ha scritto:
> > On Mon, Apr 17, 2023 at 03:27:23PM +0200, Antoin Verschuren wrote:
> >> The document editors have indicated that the following document is
> >> ready for submission to the IESG to be considered for publication as
> >> a Proposed Standard:
> >>
> >> Redacted Fields in the Registration Data Access Protocol (RDAP) Response
> >> https://secure-web.cisco.com/1iAbLGLPLxLJO8hzh27ViRK4bd-bt0GbQhUPIR2fX6D5EeH2odcVEK_ffmTZkTj0-p2u2un10AG_qkU-2VEGTay2CrfhByh9LG9OyjOd4yNunvYI1mO081jP9odoXhstPWpgFkcNIBlN90l0TZGP8MMDPy8LarElavE224AKk8GoGO-X8IofymkVYZIokMprztLdnTYQZFRZxlmo3drbusAaAR9OJa81pIgusdOR7LAiEyQgfJriJGlrLt7jzh4thYH475NtZctFTSQ8-pufORdjZijb2qK1zVeOtu-qidbs/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-redacted%2F11%2F
> >>  
> >> 
> >>
> >> Please indicate your support or no objection for the publication of
> >> this document by replying to this message on list (a simple “+1” is
> >> sufficient).
> >>
> >> If any working group member has questions regarding the publication
> >> of this document please respond on the list with your concerns by
> >> close of business everywhere, Monday, 1 May 2023.
> >>
> >> If there are no objections the document will be submitted to the
> >> IESG.
> >>
> >> The Document Shepherd for this document is Gustavo Lozano Ibarra.
> > Looks good overall, some minor comments/suggestions.
> >
> > Per previous mail from Pawel and Mario, some of the JSON path
> > expressions are not quite right for entities that have multiple roles.
> > There are some issues with the guidance added to the document to
> > account for this, though, and some further updates in this space that
> > would be useful. (We rely on entities having multiple roles in our
> > server implementation at the moment, for reference, and returning a
> > copy of each entity per role as a workaround is not ideal,
> > particularly when addressing the comments here shouldn't be
> > difficult.) To summarise these issues (mostly along the lines of the
> > comments from Pawel and Mario):
> >
> > - The first example use of prePath has a value of:
> >
> > $.entities[?(@.roles[0]=='administrative')]
> >
> > But all that a client can infer from this path is that all entities
> > with "administrative" as their first role have been removed. Since
> > there are no guarantees around ordering of roles within an entity,
> > this doesn't necessarily mean that all entities with
> > "administrative" as one of their roles have been removed from the
> > resulting object. It would be better to use a more general
> > expression in this example (and the others like it) that captured
> > the intent more clearly. Per earlier mail from Pawel, something
> > like:
> >
> > $.entities[?(@.roles[*]=='administrative')]
> >
> > should do the job, though I wasn't able to determine the syntax
> > that would be acceptable for draft-ietf-jsonpath-base.
>
> [ML] Per what is reported in Sections 2.3.5.1 (filter selector syntax)
> and 2.3.3.1 (index selector syntax), it seems to me that wildcard is not
> accepted.
>
> The only acceptable values are integers (e.g. 0, 1, -1)
>
> Neither any of the pre-defined functions seems helpful.
>
> Looking at the examples in section 2.3.5.3, $.entities[?@.roles[?@ ==
> 'administrative]] could work maybe.
>
>
> Another solution might be using the indexOf function that is defined by
> some JSONPath implementations such as JSONPath.com and should be
> registered as Function Extension (see Section 3.2) :
>
> $.entities[?(@.roles.indexOf('administrative')!=-1)] //tested on
> jsonpath.com
>
> Anyway, the indexOf syntax should be redefined to be compliant with the
> jsonpath-base syntax:
>
> $.entities[?indexOf(@.roles,'administrative')!=-1]
>
>
> Best,
>
> Mario
>
> >
> > - Section 5.2 at point 4 h

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Andrew Newton]

I see in the implementation section of the draft there is a test
server that lists the redactions.
However, has anybody taken any real output from a DNR and INR server
and run some JSONPath expressions on them?
Doing so would help to prove out this spec.

-andy

On Wed, Apr 26, 2023 at 7:39 AM Mario Loffredo
 wrote:
>
>
> Il 26/04/2023 02:16, Tom Harrison ha scritto:
> > On Mon, Apr 17, 2023 at 03:27:23PM +0200, Antoin Verschuren wrote:
> >> The document editors have indicated that the following document is
> >> ready for submission to the IESG to be considered for publication as
> >> a Proposed Standard:
> >>
> >> Redacted Fields in the Registration Data Access Protocol (RDAP) Response
> >> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/
> >>
> >> Please indicate your support or no objection for the publication of
> >> this document by replying to this message on list (a simple “+1” is
> >> sufficient).
> >>
> >> If any working group member has questions regarding the publication
> >> of this document please respond on the list with your concerns by
> >> close of business everywhere, Monday, 1 May 2023.
> >>
> >> If there are no objections the document will be submitted to the
> >> IESG.
> >>
> >> The Document Shepherd for this document is Gustavo Lozano Ibarra.
> > Looks good overall, some minor comments/suggestions.
> >
> > Per previous mail from Pawel and Mario, some of the JSON path
> > expressions are not quite right for entities that have multiple roles.
> > There are some issues with the guidance added to the document to
> > account for this, though, and some further updates in this space that
> > would be useful.  (We rely on entities having multiple roles in our
> > server implementation at the moment, for reference, and returning a
> > copy of each entity per role as a workaround is not ideal,
> > particularly when addressing the comments here shouldn't be
> > difficult.)  To summarise these issues (mostly along the lines of the
> > comments from Pawel and Mario):
> >
> >   - The first example use of prePath has a value of:
> >
> >  $.entities[?(@.roles[0]=='administrative')]
> >
> > But all that a client can infer from this path is that all entities
> > with "administrative" as their first role have been removed.  Since
> > there are no guarantees around ordering of roles within an entity,
> > this doesn't necessarily mean that all entities with
> > "administrative" as one of their roles have been removed from the
> > resulting object.  It would be better to use a more general
> > expression in this example (and the others like it) that captured
> > the intent more clearly.  Per earlier mail from Pawel, something
> > like:
> >
> >  $.entities[?(@.roles[*]=='administrative')]
> >
> > should do the job, though I wasn't able to determine the syntax
> > that would be acceptable for draft-ietf-jsonpath-base.
>
> [ML] Per what is reported in Sections  2.3.5.1 (filter selector syntax)
> and 2.3.3.1 (index selector syntax), it seems to me that wildcard is not
> accepted.
>
> The only acceptable values are integers (e.g. 0, 1, -1)
>
> Neither any of the pre-defined functions seems helpful.
>
> Looking at the examples in section 2.3.5.3, $.entities[?@.roles[?@ ==
> 'administrative]] could work maybe.
>
>
> Another solution might be using the indexOf function that is defined by
> some JSONPath implementations such as JSONPath.com and should be
> registered as Function Extension (see Section 3.2) :
>
> $.entities[?(@.roles.indexOf('administrative')!=-1)]  //tested on
> jsonpath.com
>
> Anyway, the indexOf syntax should be redefined to be compliant with the
> jsonpath-base syntax:
>
> $.entities[?indexOf(@.roles,'administrative')!=-1]
>
>
> Best,
>
> Mario
>
> >
> >   - Section 5.2 at point 4 has:
> >
> >  When an entity has multiple roles, include "redacted" members
> >  for each role using the role index.  This will result in
> >  duplicate "redacted" members, but will enable the client to
> >  treat redaction consistently when there is a single role per
> >  entity or multiple roles per entity.
> >
> > It's not clear why this advice is present, when compared with e.g.
> > having the redacted members be a mapping from the server's
> > policies.  For example, if the policy is that administrative
> > contacts not be returned, then a single "redacted" entry with a
> > prePath like "$.entities[?(@.roles[*]=='administrative')]" clearly
> > conveys that message to the client, and the client will understand
> > that those entities will be removed regardless of any additional
> > roles that they might have.  How do multiple redacted members
> > enable the client to treat redaction consistently?
> >
> >   - Section 5.2 at point 5 has:
> >
> >  When there are multiple entities with the same role, include
> >  "redacted" members for each entity u

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Mario Loffredo]

Il 26/04/2023 02:16, Tom Harrison ha scritto:

On Mon, Apr 17, 2023 at 03:27:23PM +0200, Antoin Verschuren wrote:

The document editors have indicated that the following document is
ready for submission to the IESG to be considered for publication as
a Proposed Standard:

Redacted Fields in the Registration Data Access Protocol (RDAP) Response
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/

Please indicate your support or no objection for the publication of
this document by replying to this message on list (a simple “+1” is
sufficient).

If any working group member has questions regarding the publication
of this document please respond on the list with your concerns by
close of business everywhere, Monday, 1 May 2023.

If there are no objections the document will be submitted to the
IESG.

The Document Shepherd for this document is Gustavo Lozano Ibarra.

Looks good overall, some minor comments/suggestions.

Per previous mail from Pawel and Mario, some of the JSON path
expressions are not quite right for entities that have multiple roles.
There are some issues with the guidance added to the document to
account for this, though, and some further updates in this space that
would be useful.  (We rely on entities having multiple roles in our
server implementation at the moment, for reference, and returning a
copy of each entity per role as a workaround is not ideal,
particularly when addressing the comments here shouldn't be
difficult.)  To summarise these issues (mostly along the lines of the
comments from Pawel and Mario):

  - The first example use of prePath has a value of:

 $.entities[?(@.roles[0]=='administrative')]

But all that a client can infer from this path is that all entities
with "administrative" as their first role have been removed.  Since
there are no guarantees around ordering of roles within an entity,
this doesn't necessarily mean that all entities with
"administrative" as one of their roles have been removed from the
resulting object.  It would be better to use a more general
expression in this example (and the others like it) that captured
the intent more clearly.  Per earlier mail from Pawel, something
like:

 $.entities[?(@.roles[*]=='administrative')]

should do the job, though I wasn't able to determine the syntax
that would be acceptable for draft-ietf-jsonpath-base.


[ML] Per what is reported in Sections  2.3.5.1 (filter selector syntax) 
and 2.3.3.1 (index selector syntax), it seems to me that wildcard is not 
accepted.


The only acceptable values are integers (e.g. 0, 1, -1)

Neither any of the pre-defined functions seems helpful.

Looking at the examples in section 2.3.5.3, $.entities[?@.roles[?@ == 
'administrative]] could work maybe.



Another solution might be using the indexOf function that is defined by 
some JSONPath implementations such as JSONPath.com and should be 
registered as Function Extension (see Section 3.2) :


$.entities[?(@.roles.indexOf('administrative')!=-1)]  //tested on 
jsonpath.com


Anyway, the indexOf syntax should be redefined to be compliant with the 
jsonpath-base syntax:


$.entities[?indexOf(@.roles,'administrative')!=-1]


Best,

Mario



  - Section 5.2 at point 4 has:

 When an entity has multiple roles, include "redacted" members
 for each role using the role index.  This will result in
 duplicate "redacted" members, but will enable the client to
 treat redaction consistently when there is a single role per
 entity or multiple roles per entity.

It's not clear why this advice is present, when compared with e.g.
having the redacted members be a mapping from the server's
policies.  For example, if the policy is that administrative
contacts not be returned, then a single "redacted" entry with a
prePath like "$.entities[?(@.roles[*]=='administrative')]" clearly
conveys that message to the client, and the client will understand
that those entities will be removed regardless of any additional
roles that they might have.  How do multiple redacted members
enable the client to treat redaction consistently?

  - Section 5.2 at point 5 has:

 When there are multiple entities with the same role, include
 "redacted" members for each entity using the entity index
 instead of the role.  A JSONPath can be created that
 identifies the entity based on an index of a role selector
 nodelist, such as "$.entities[?(@.roles[0]=='technical')][0]"
 for the first entity with the "technical" role.  Using the
 entity index, such as "$.entities[1]", is simpler and
 recommended.

Similarly to the previous point, removing by index obscures the
server's intent.  To use the example given above, if the server's
policy is that the first entity with a technical role is omitted,
then the first expression (though with 'roles[*]' instead of
 

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Tom Harrison]

On Mon, Apr 17, 2023 at 03:27:23PM +0200, Antoin Verschuren wrote:
> The document editors have indicated that the following document is
> ready for submission to the IESG to be considered for publication as
> a Proposed Standard:
> 
> Redacted Fields in the Registration Data Access Protocol (RDAP) Response
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/
> 
> Please indicate your support or no objection for the publication of
> this document by replying to this message on list (a simple “+1” is
> sufficient).
> 
> If any working group member has questions regarding the publication
> of this document please respond on the list with your concerns by
> close of business everywhere, Monday, 1 May 2023.  
> 
> If there are no objections the document will be submitted to the
> IESG.
> 
> The Document Shepherd for this document is Gustavo Lozano Ibarra.

Looks good overall, some minor comments/suggestions.

Per previous mail from Pawel and Mario, some of the JSON path
expressions are not quite right for entities that have multiple roles.
There are some issues with the guidance added to the document to
account for this, though, and some further updates in this space that
would be useful.  (We rely on entities having multiple roles in our
server implementation at the moment, for reference, and returning a
copy of each entity per role as a workaround is not ideal,
particularly when addressing the comments here shouldn't be
difficult.)  To summarise these issues (mostly along the lines of the
comments from Pawel and Mario):

 - The first example use of prePath has a value of:

$.entities[?(@.roles[0]=='administrative')]

   But all that a client can infer from this path is that all entities
   with "administrative" as their first role have been removed.  Since
   there are no guarantees around ordering of roles within an entity,
   this doesn't necessarily mean that all entities with
   "administrative" as one of their roles have been removed from the
   resulting object.  It would be better to use a more general
   expression in this example (and the others like it) that captured
   the intent more clearly.  Per earlier mail from Pawel, something
   like:

$.entities[?(@.roles[*]=='administrative')]

   should do the job, though I wasn't able to determine the syntax
   that would be acceptable for draft-ietf-jsonpath-base. 

 - Section 5.2 at point 4 has:

When an entity has multiple roles, include "redacted" members
for each role using the role index.  This will result in
duplicate "redacted" members, but will enable the client to
treat redaction consistently when there is a single role per
entity or multiple roles per entity.

   It's not clear why this advice is present, when compared with e.g.
   having the redacted members be a mapping from the server's
   policies.  For example, if the policy is that administrative
   contacts not be returned, then a single "redacted" entry with a
   prePath like "$.entities[?(@.roles[*]=='administrative')]" clearly
   conveys that message to the client, and the client will understand
   that those entities will be removed regardless of any additional
   roles that they might have.  How do multiple redacted members
   enable the client to treat redaction consistently?

 - Section 5.2 at point 5 has:

When there are multiple entities with the same role, include
"redacted" members for each entity using the entity index
instead of the role.  A JSONPath can be created that
identifies the entity based on an index of a role selector
nodelist, such as "$.entities[?(@.roles[0]=='technical')][0]"
for the first entity with the "technical" role.  Using the
entity index, such as "$.entities[1]", is simpler and
recommended. 

   Similarly to the previous point, removing by index obscures the
   server's intent.  To use the example given above, if the server's
   policy is that the first entity with a technical role is omitted,
   then the first expression (though with 'roles[*]' instead of
   'roles[0]') conveys that message more clearly than removal by way
   of index.  (If the server's behaviour can't be conveyed by way of a
   JSON path, e.g. where an entity is omitted because they have opted
   out of being included in responses, then simply omitting the
   prePath and relying on a specific registered redacted name for the
   behaviour would make things clearer for the client than presenting
   an entity index that they can't resolve/use.)

 - Section 5.1 at point 1 has:

When the server is using the Redaction By Removal Method
(Section 3.1) or the Redaction by Replacement Value Method
(Section 3.4) with an alternate field value, the JSONPath
expression of the "prePath" member will not resolve
successfully with the redacted response.  The client can
first key off the "name" member for display logic 

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Keathley, Daniel]

+1

--Dan

On 4/24/23, 1:37 PM, "regext on behalf of Pawel Kowalik" 
mailto:regext-boun...@ietf.org> on behalf of 
kowa...@denic.de > 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. 


+1


Am 17.04.23 um 15:27 schrieb Antoin Verschuren:
> The document editors have indicated that the following document is ready for 
> submission to the IESG to be considered for publication as a Proposed 
> Standard:
>
>
> Redacted Fields in the Registration Data Access Protocol (RDAP) Response
> https://secure-web.cisco.com/1vptS-xC3KCDV4vyL4HNQZbRu0u8wpbu9Ls2whFKAUvrcDKjsvbhupXTLbrqudGwvWX4Wg-KpkgvIOui7oIREaQGm29w34L-zTOYSqsgrgvyFjsw3CYWz2ux2qjuWzHaCMo2iw3oDtBe7sTD2KvQ6rJMR7XsXTQ-3cEnLlG5QgB--sBm8GY9KjGiMu4R6JEbNvqKDOVorRR-V_uI4qw99pnwmmvTSBhG_jc409fr93zMd4XJEOZ2A5AMSzxXA-tbXnaA0Jgw65cLljUsGWOUXgD05bIO6TnBD5tFczSlTKxw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-redacted%2F11%2F
>  
> 
>
>
> Please indicate your support or no objection for the publication of this 
> document by replying to this message on list (a simple “+1” is sufficient).
>
> If any working group member has questions regarding the publication of this 
> document please respond on the list with your concerns by close of business 
> everywhere, Monday, 1 May 2023.
>
> If there are no objections the document will be submitted to the IESG.
>
> The Document Shepherd for this document is Gustavo Lozano Ibarra.
>
> Thanks,
>
> Jim and Antoin
> REGEXT WG Co-Chairs
> ___
> regext mailing list
> regext@ietf.org 
> https://secure-web.cisco.com/1rE06dFTjp-oebWLDrBf_KivMzuM7cg8BhpbOpW4rgjFPqYg5QcFxsEbtEytoDzTChbb5wGPqVPjy7KBq0kjHcjHOHtPVwjO-KRafkikrs_Z3L-xjZBH8g_Z0Mm8uf5Vz9QI09kOnMfSZj0hhvqeZIWiogcJtpWJEDlUFZibQtzV7y0Q2PlgfrtpUDrzBd3LFcYVCHh6T0xyyWAiaWi5jwtZbgfLBHm2oqzX4Ah5z-VzK72P90P_fYUd3xqQ34qTPBmtYMXlszWvnTI_fx-6SSRL-DCrn0gUKh55AxyHF5sY/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>  
> 


___
regext mailing list
regext@ietf.org 
https://secure-web.cisco.com/1rE06dFTjp-oebWLDrBf_KivMzuM7cg8BhpbOpW4rgjFPqYg5QcFxsEbtEytoDzTChbb5wGPqVPjy7KBq0kjHcjHOHtPVwjO-KRafkikrs_Z3L-xjZBH8g_Z0Mm8uf5Vz9QI09kOnMfSZj0hhvqeZIWiogcJtpWJEDlUFZibQtzV7y0Q2PlgfrtpUDrzBd3LFcYVCHh6T0xyyWAiaWi5jwtZbgfLBHm2oqzX4Ah5z-VzK72P90P_fYUd3xqQ34qTPBmtYMXlszWvnTI_fx-6SSRL-DCrn0gUKh55AxyHF5sY/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
 




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

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Pawel Kowalik]

+1

Am 17.04.23 um 15:27 schrieb Antoin Verschuren:

The document editors have indicated that the following document is ready for 
submission to the IESG to be considered for publication as a Proposed Standard:


Redacted Fields in the Registration Data Access Protocol (RDAP) Response
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/


Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a simple “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 1 May 2023.

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Gustavo Lozano Ibarra.

Thanks,

Jim and Antoin
REGEXT WG Co-Chairs
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Mario Loffredo]

+ 1

Mario

Il 17/04/2023 15:27, Antoin Verschuren ha scritto:

The document editors have indicated that the following document is ready for 
submission to the IESG to be considered for publication as a Proposed Standard:


Redacted Fields in the Registration Data Access Protocol (RDAP) Response
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/


Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a simple “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 1 May 2023.

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Gustavo Lozano Ibarra.

Thanks,

Jim and Antoin
REGEXT WG Co-Chairs
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


--
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

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

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Rick Wilhelm]

+1

Thanks
Rick

From: regext  on behalf of Jasdip Singh 

Date: Tuesday, April 18, 2023 at 10:38 AM
To: Antoin Verschuren , regext 

Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11
CAUTION: This email came from outside your organization. Don’t trust emails, 
links, or attachments from senders that seem suspicious or you are not 
expecting.

+1

Thanks,
Jasdip

On 4/17/23, 9:27 AM, "regext on behalf of Antoin Verschuren" 
mailto:regext-boun...@ietf.org> on behalf of 
ietf=40antoin...@dmarc.ietf.org <mailto:40antoin...@dmarc.ietf.org>> wrote:

The document editors have indicated that the following document is ready for 
submission to the IESG to be considered for publication as a Proposed Standard:

Redacted Fields in the Registration Data Access Protocol (RDAP) Response
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/<https://protect-us.mimecast.com/s/9p2wCv2rnZtyzJ6izGXWw?domain=datatracker.ietf.org>
 
<https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/<https://protect-us.mimecast.com/s/9p2wCv2rnZtyzJ6izGXWw?domain=datatracker.ietf.org/>>

Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a simple “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 1 May 2023.

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Gustavo Lozano Ibarra.

Thanks,

Jim and Antoin
REGEXT WG Co-Chairs
___
regext mailing list
regext@ietf.org <mailto:regext@ietf.org>
https://www.ietf.org/mailman/listinfo/regext<https://protect-us.mimecast.com/s/cONRCwpvorSR351FKwrBd?domain=ietf.org>
 
<https://www.ietf.org/mailman/listinfo/regext<https://protect-us.mimecast.com/s/cONRCwpvorSR351FKwrBd?domain=ietf.org>>



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext<https://protect-us.mimecast.com/s/cONRCwpvorSR351FKwrBd?domain=ietf.org>
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Jasdip Singh]

+1

Thanks,
Jasdip

On 4/17/23, 9:27 AM, "regext on behalf of Antoin Verschuren" 
mailto:regext-boun...@ietf.org> on behalf of 
ietf=40antoin...@dmarc.ietf.org > wrote:

The document editors have indicated that the following document is ready for 
submission to the IESG to be considered for publication as a Proposed Standard:

Redacted Fields in the Registration Data Access Protocol (RDAP) Response
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/ 


Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a simple “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 1 May 2023. 

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Gustavo Lozano Ibarra.

Thanks,

Jim and Antoin
REGEXT WG Co-Chairs
___
regext mailing list
regext@ietf.org 
https://www.ietf.org/mailman/listinfo/regext 




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

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

[Hollenbeck, Scott]

> -Original Message-
> From: regext  On Behalf Of Antoin Verschuren
> Sent: Monday, April 17, 2023 9:27 AM
> To: regext 
> Subject: [EXTERNAL] [regext] WGLC: draft-ietf-regext-rdap-redacted-11
>
> 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.
>
> The document editors have indicated that the following document is ready for
> submission to the IESG to be considered for publication as a Proposed 
> Standard:
>
>
> Redacted Fields in the Registration Data Access Protocol (RDAP) Response
> https://secure-
> web.cisco.com/1A_Z_cHLWpkgqZXhe14DUFQIdeqQjlGJ8G_kIZqvHKI_qJiv-
> AJXmE-
> jrzD8pfL81owfmvBl6tN6o_tKmNCaRxwzOb3Chasr4kjfXclTIUprgLmnAsjqFr4lIYO
> YkK-7wAXBEFRRpgTNMjZ84IrrRIZCF-
> tua3XoRZnvIq0tkgIuHBZl6EIfTQji5gVM12K-y-HafGn8FVz-uxmXR6vJqV-
> m8M4aB6ZhzLIeOq26saKaTWygv2lFJQuLk2-
> AoWOXVkMp9VozWTmXbVZGepExpljvF6Mq1TdwWS4yyGol-
> oHI/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-
> redacted%2F11%2F
>
>
> Please indicate your support or no objection for the publication of this
> document by replying to this message on list (a simple “+1” is sufficient).

[SAH] +1

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