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] CALL FOR ADOPTION: draft-regext-brown-epp-ttl

[Jody Kolker]

+1 to adopt.

-Original Message-
From: regext  On Behalf Of Antoin Verschuren
Sent: Tuesday, April 25, 2023 3:54 PM
To: regext 
Subject: [regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl

Caution: This email is from an external sender. Please do not click links or 
open attachments unless you recognize the sender and know the content is safe. 
Forward suspicious emails to isitbad@.



This is a formal adoption request for Extensible Provisioning Protocol (EPP) 
mapping for DNS Time-To-Live (TTL) values:

https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/

Please review this draft to see if you think it is suitable for adoption by 
REGEXT and comment to this message on the list, clearly stating your view.
Optionally indicate if you are willing to contribute text, review text, or be a 
document shepherd.

This Call For Adoption will close on Sunday, 14 May.

If there are no objections, the chairs will consider this document adopted.

Thanks,

Your REGEXT co-chairs Jim and Antoin
___
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

[regext] FW: ROW12 -> Call for Proposals & Registration

[Hollenbeck, Scott]

FYI, folks.



Scott



From: row-commit...@googlegroups.com  On Behalf 
Of nicoleta munteanu
Sent: Wednesday, April 26, 2023 8:41 AM
Subject: [EXTERNAL] ROW12 -> Call for Proposals & Registration



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.

ROW12 Call for Proposals and Registrataion | June 20th, 2023 | 13:00 - 16:00 
UTC | Zoom Video Conference



The 12th Registration Operations Workshop (ROW12) will be 
held via remote participation on June 20th, 2023, 13:00 - 16:00 UTC. See 
additional time zones 
here.





—> Registration is NOW available! Click 
here
 to register.



—> The Call for presentation & panel proposals is still OPEN!

   The Program Committee is interested in:

*   Topic related presentation proposals
*   Topic suggestions for focused panel discussions
*   Suggestions for additional topics



   Please submit a short abstract describing your proposal to our NEW email 
address r...@cofomo.com by May 19th, 2023. We will 
accommodate time zones for presenters in setting the agenda. Below is a 
non-exhaustive list of broad topics for ROW12. We also encourage any 
discussions/suggestions for additional topics on ROW’s mailing list: 
regi...@googlegroups.com. For further details 
on past workshop topics, see https://regiops.net/events

*   Registries and DNS Hosting:

   *RPKI from a registry operator’s perspective
   *Experience with Universal Acceptance deployments
   *CDS/CDNSKEY or CSYNC deployment experience
   *Accommodating third party providers (i.e., not the registrant or 
registrar themselves)

*   Registries and Internet Ecosystem:

   *Registry database access
   *Interaction with Public Safety and Law Enforcement
   *Regulation, Current or Coming
   *Implementing Full-scale security, including Routing to Nameservers

*   Registry Industry Coming of Age:

   *Handling turnover of staff or platform providers, transitioning
   *Evolving the role of the registry within the Internet 
economy/environment (meaning, gov’t/others)



   —> Important dates:

*   Deadline to submit proposals: May 19th, 2023
*   Program Committee to notify selected authors by May 23rd, 2023
*   Speaker materials required from selected presenters by June 9th, 2023

*   ROW12 event: June 20th, 2023, 13:00-16:00 UTC



We hope that you can join us!!!

Register NOW and feel free to disseminate this Call to other lists where it 
might be of interest. Thank you.



ROW Program Committee

Stay tuned for further updates! Follow 
@ROWevents

ROW website: https://regiops.net

Contact us: r...@cofomo.com

ROW mailing list: regi...@googlegroups.com

ROW series: co-sponsored by Verisign & 
ICANN,
 organized by Cofomo Québec 
Inc.

(cross-posting to multiple lists - sorry for any duplicates)

--
You received this message because you are subscribed to the Google Groups "Row 
Comm

Re: [regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl

[Hugo Salgado]

On 22:54 25/04, Antoin Verschuren wrote:
> This is a formal adoption request for Extensible Provisioning Protocol (EPP) 
> mapping for DNS Time-To-Live (TTL) values:
> 
>   https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/
> 
> Please review this draft to see if you think it is suitable for adoption by 
> REGEXT and comment to this message on the list, clearly stating your view.
> Optionally indicate if you are willing to contribute text, review text, or be 
> a document shepherd.
> 

I support this adoption and will to review and contribute.

Regards,

Hugo Salgado



signature.asc
Description: PGP signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl

[Hollenbeck, Scott]

> -Original Message-
> From: regext  On Behalf Of Antoin Verschuren
> Sent: Tuesday, April 25, 2023 4:54 PM
> To: regext 
> Subject: [EXTERNAL] [regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl
>
> 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.
>
> This is a formal adoption request for Extensible Provisioning Protocol (EPP)
> mapping for DNS Time-To-Live (TTL) values:
>
>   https://secure-
> web.cisco.com/1vtHPNRjRoP018Btc9HtpkrlEP8X4IRXSodTHdma89uV-
> 59o3wBXYUKsuEJOIDko-dUIR-
> fujfpHzenyYS1YNt2Ml2Siv917k4vaR1en_cDLK8eopYMt4g7eplcfjaVmqC7kWm6b
> N8AbjmViEiqfzC1u8H5i4qRqbFx_stlr9G8_tPX0uZP5-yZGRc7SHrC_f9IpS-
> zeJb3S1mFPFaDaM92LPOOzro93GndI8mSrj5EpW-
> A5yMkrOVgDGQ9VewJqC6_b0UZnFgZ0z_2G-
> G8Y1088XlYiMifLDbaoAdSt9VLI/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2
> Fdraft-regext-brown-epp-ttl%2F
>
> Please review this draft to see if you think it is suitable for adoption by 
> REGEXT
> and comment to this message on the list, clearly stating your view.
> Optionally indicate if you are willing to contribute text, review text, or be 
> a
> document shepherd.

[SAH] I support adoption and am willing to review and contribute text as needed.

Scott

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

Re: [regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl

[Jothan Frakes]

+1 to adopt

Jothan Frakes
Tel: +1.206-355-0230



On Wed, Apr 26, 2023 at 8:25 AM Hollenbeck, Scott  wrote:

> > -Original Message-
> > From: regext  On Behalf Of Antoin Verschuren
> > Sent: Tuesday, April 25, 2023 4:54 PM
> > To: regext 
> > Subject: [EXTERNAL] [regext] CALL FOR ADOPTION:
> draft-regext-brown-epp-ttl
> >
> > 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.
> >
> > This is a formal adoption request for Extensible Provisioning Protocol
> (EPP)
> > mapping for DNS Time-To-Live (TTL) values:
> >
> >   https://secure-
> > web.cisco.com/1vtHPNRjRoP018Btc9HtpkrlEP8X4IRXSodTHdma89uV-
> > 59o3wBXYUKsuEJOIDko-dUIR-
> > fujfpHzenyYS1YNt2Ml2Siv917k4vaR1en_cDLK8eopYMt4g7eplcfjaVmqC7kWm6b
> > N8AbjmViEiqfzC1u8H5i4qRqbFx_stlr9G8_tPX0uZP5-yZGRc7SHrC_f9IpS-
> > zeJb3S1mFPFaDaM92LPOOzro93GndI8mSrj5EpW-
> > A5yMkrOVgDGQ9VewJqC6_b0UZnFgZ0z_2G-
> > G8Y1088XlYiMifLDbaoAdSt9VLI/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2
> > Fdraft-regext-brown-epp-ttl%2F
> >
> > Please review this draft to see if you think it is suitable for adoption
> by REGEXT
> > and comment to this message on the list, clearly stating your view.
> > Optionally indicate if you are willing to contribute text, review text,
> or be a
> > document shepherd.
>
> [SAH] I support adoption and am willing to review and contribute text as
> needed.
>
> Scott
>
> ___
> 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

[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

[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

[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

[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] [EXTERNAL] CALL FOR ADOPTION: draft-regext-brown-epp-ttl

[Rick Wilhelm]

+1 for adoption

From: regext  on behalf of Antoin Verschuren 

Date: Tuesday, April 25, 2023 at 4:54 PM
To: regext 
Subject: [EXTERNAL] [regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl
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.

This is a formal adoption request for Extensible Provisioning Protocol (EPP) 
mapping for DNS Time-To-Live (TTL) values:

https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/

Please review this draft to see if you think it is suitable for adoption by 
REGEXT and comment to this message on the list, clearly stating your view.
Optionally indicate if you are willing to contribute text, review text, or be a 
document shepherd.

This Call For Adoption will close on Sunday, 14 May.

If there are no objections, the chairs will consider this document adopted.

Thanks,

Your REGEXT co-chairs Jim and Antoin
___
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

[regext] creating invalid RDAP with redaction

[Andrew Newton]

On Mon, Apr 17, 2023 at 9:27 AM Antoin Verschuren
 wrote:
>
> 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).

I'd like to see this published, but have one issue.

Perhaps this is in the document and I just didn't see it, but there
should be a clear statement that no redaction may create invalid RDAP
according to RFC 9083. Doing so is not the intent of the document, but
I'd rather that be stated clearly lest we have a number of very long
mailing list threads on the topic in a couple of years. Allowing the
creation of invalid RDAP would create havoc for clients.

Generally, most things in RDAP are optional. But there are a couple of
things here and there which are not. For example, 'eventDate' in
events is not optional. Neither is `objectClassName`.

Section 3 of RFC 9083 also lists formats for certain strings. For
example, `eventDate` must be an RFC3339 format. And `ldhName` in
domains must be a domain name.

Also, if a note was added somewhere that said "90% of the complexity
in this specification is because of JCard", it would not hurt my
feelings. :)

Finally, many thanks to the authors. This is a complicated topic.

-andy

___
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] creating invalid RDAP with redaction

[Gould, James]

Andy, 

Yes, JCard certainly added complexity to the draft __.  I believe a statement 
can be broader than RFC 9083 to state something like the following at the start 
of Section 3:

"Redaction in RDAP can be handled in multiple ways.  The resulting redacted 
RDAP response MUST comply with the RDAP RFCs, such as [RFC 9083].".  

Thanks,

-- 

JG 



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


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

Verisign.com  




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



On Mon, Apr 17, 2023 at 9:27 AM Antoin Verschuren
mailto:40antoin...@dmarc.ietf.org>> wrote:
>
> 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).


I'd like to see this published, but have one issue.


Perhaps this is in the document and I just didn't see it, but there
should be a clear statement that no redaction may create invalid RDAP
according to RFC 9083. Doing so is not the intent of the document, but
I'd rather that be stated clearly lest we have a number of very long
mailing list threads on the topic in a couple of years. Allowing the
creation of invalid RDAP would create havoc for clients.


Generally, most things in RDAP are optional. But there are a couple of
things here and there which are not. For example, 'eventDate' in
events is not optional. Neither is `objectClassName`.


Section 3 of RFC 9083 also lists formats for certain strings. For
example, `eventDate` must be an RFC3339 format. And `ldhName` in
domains must be a domain name.


Also, if a note was added somewhere that said "90% of the complexity
in this specification is because of JCard", it would not hurt my
feelings. :)


Finally, many thanks to the authors. This is a complicated topic.


-andy


___
regext mailing list
regext@ietf.org 
https://secure-web.cisco.com/1OybIRk2kA7yFpTXg3EYdtSNsk2vCbaz28utSJtwEIGlW5tIEnquC9lfvnGE5PYQL-3EJ958t_cMjFoZgwv_2q3GYuLl6nTmesdusciZvVvFCWi9ZTj6csFBEwKpdYSRD6t-SkpLUbSnSFsWzMoeIg9wkRHDpf7a5YMrKD6kKcH29VjVMZtetOTEXMlPmuHCKBtnjWTkH0O3xRxrVHybvIkvEwNk-8zgPfUhwCA0VyaBVGjlPW-EbCL_lE_r-pjB_kTQ2y7NXECWtxnrsRgW75MLF_vi-_LUR_8VDYampPIo/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
 




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

Re: [regext] creating invalid RDAP with redaction

[Andrew Newton]

On Wed, Apr 26, 2023 at 3:16 PM Gould, James  wrote:
>
> Andy,
>
> Yes, JCard certainly added complexity to the draft __.  I believe a statement 
> can be broader than RFC 9083 to state something like the following at the 
> start of Section 3:
>
> "Redaction in RDAP can be handled in multiple ways.  The resulting redacted 
> RDAP response MUST comply with the RDAP RFCs, such as [RFC 9083].".

+1

-andy

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

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