Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Hollenbeck, Scott]

From: regext  On Behalf Of Jasdip Singh
Sent: Tuesday, February 20, 2024 12:51 PM
To: Hollenbeck, Scott ; a...@hxr.us
Cc: i...@antoin.nl; mario.loffr...@iit.cnr.it; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search



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.

Hello Andy, Scott,



Let’s take a specific example from the RIR search draft (a specification with 
multiple extension identifiers defined) to test-drive these options. Say, an IP 
network search response:



{

  "rdapConformance": [ "rdap_level_0", "rirSearch1",

  "ips", "ipSearchResults", ... ],

  ...

  "ipSearchResults": [

{

  "objectClassName": "ip network",

  "handle": "-RIR",

  "startAddress": "192.0.2.0",

  "endAddress": "192.0.2.127",

  ...

  "links": [

...,

   {

 "value": "https://rdap.example.com/ip/192.0.2.0/25";,

 "rel": "up",

 "href": "https://rdap.example.com/ips/rirSearch1/up/192.0.2.0/25";,

 "type": "application/rdap+json"

  },

   {

 "value": "https://rdap.example.com/ip/192.0.2.0/25";,

 "rel": "down",

 "href": "https://rdap.example.com/ips/rirSearch1/down/192.0.2.0/25";,

 "type": "application/rdap+json"

   },

  {

 "value": "https://rdap.example.com/ip/192.0.2.0/25";,

 "rel": "top",

 "href": "https://rdap.example.com/ips/rirSearch1/top/192.0.2.0/25";,

 "type": "application/rdap+json"

   },

   {

 "value": "https://rdap.example.com/ip/192.0.2.0/25";,

 "rel": "bottom",

 "href": "https://rdap.example.com/ips/rirSearch1/bottom/192.0.2.0/25";,

 "type": "application/rdap+json"

  }

 ]

},

{

  "objectClassName": "ip network",

  "handle": "-RIR",

  "startAddress": "192.0.2.0",

  "endAddress": "192.0.2.255",

  ...

}

  ]

}



Though the specification defines 5 extension identifiers (“rirSearch1 “, “ips”, 
“ipSearchResults”, “autnum”, and “autnumSearchResults”), note how the example 
only includes “rirSearch1 “, “ips”, and “ipSearchResults”:

*   “ipSearchResults” for the "ipSearchResults" member.
*   “ips” and “rirSearch1“ for the construction of the “href” values in the 
“links” member of an IP network object for link relations.



IMO, this presently points to Option 2 from the choices Mario posed for the WG. 
Per the “construction of response” guidance from RFC 9083, is that OK in your 
opinion?



[SAH] Yes, I believe so, Jasdip. A client that receives this response will need 
to understand the bits defined by the “rirSearch1 “, “ips”, and 
“ipSearchResults” identifiers. There’s nothing in that response related to 
“autnum” or “autnumSearchResults”, so those identifiers don’t need to be 
included in the rdapConformance data structure.



Scott

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

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Jasdip Singh]

Hello Andy, Scott,

Let’s take a specific example from the RIR search draft (a specification with 
multiple extension identifiers defined) to test-drive these options. Say, an IP 
network search response:

{
  "rdapConformance": [ "rdap_level_0", "rirSearch1",
  "ips", "ipSearchResults", ... ],
  ...
  "ipSearchResults": [
{
  "objectClassName": "ip network",
  "handle": "-RIR",
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.127",
  ...
  "links": [
...,
   {
 "value": "https://rdap.example.com/ip/192.0.2.0/25";,
 "rel": "up",
 "href": "https://rdap.example.com/ips/rirSearch1/up/192.0.2.0/25";,
 "type": "application/rdap+json"
  },
   {
 "value": "https://rdap.example.com/ip/192.0.2.0/25";,
 "rel": "down",
 "href": "https://rdap.example.com/ips/rirSearch1/down/192.0.2.0/25";,
 "type": "application/rdap+json"
   },
  {
 "value": "https://rdap.example.com/ip/192.0.2.0/25";,
 "rel": "top",
 "href": "https://rdap.example.com/ips/rirSearch1/top/192.0.2.0/25";,
 "type": "application/rdap+json"
   },
   {
 "value": "https://rdap.example.com/ip/192.0.2.0/25";,
 "rel": "bottom",
 "href": "https://rdap.example.com/ips/rirSearch1/bottom/192.0.2.0/25";,
 "type": "application/rdap+json"
  }
 ]
},
{
  "objectClassName": "ip network",
  "handle": "-RIR",
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.255",
  ...
}
  ]
}

Though the specification defines 5 extension identifiers (“rirSearch1 “, “ips”, 
“ipSearchResults”, “autnum”, and “autnumSearchResults”), note how the example 
only includes “rirSearch1 “, “ips”, and “ipSearchResults”:

  *   “ipSearchResults” for the "ipSearchResults" member.
  *   “ips” and “rirSearch1“ for the construction of the “href” values in the 
“links” member of an IP network object for link relations.

IMO, this presently points to Option 2 from the choices Mario posed for the WG. 
Per the “construction of response” guidance from RFC 9083, is that OK in your 
opinion?

Jasdip

From: regext  on behalf of Hollenbeck, Scott 

Date: Tuesday, February 20, 2024 at 12:31 PM
To: a...@hxr.us 
Cc: i...@antoin.nl , mario.loffr...@iit.cnr.it 
, regext@ietf.org 
Subject: Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search
Andy, I agree that that's an incorrect interpretation. Content is part of the 
response, too, and as such it has to be included when the response is 
constructed/formed/assembled/whatever.

Scott

> -Original Message-
> From: Andrew Newton (andy) 
> Sent: Tuesday, February 20, 2024 12:23 PM
> To: Hollenbeck, Scott 
> Cc: ietf=40antoin...@dmarc.ietf.org ;
> mario.loffredo=40iit.cnr...@dmarc.ietf.org ;
> regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-
> search
>
> 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.
>
> "construction of the response" can be interpreted strictly to mean only the
> JSON structure of the response. IMHO, that is an incorrect interpretation nor
> does it track with RDAP as it is used because profile extensions such as the
> ICANN and NRO extensions also dictate content not just structure.
>
> -andy
>
>
> On Tue, Feb 20, 2024 at 10:20 AM Hollenbeck, Scott
>  wrote:
> >
> > I don’t understand the confusion regarding the text in 9083. It might not
> include BCP 14 key words, but I believe the intention is clear. Looking at the
> two sentences:
> >
> >
> >
> > “A response to a "help" request will include identifiers for all of the
> specifications supported by the server.”
> >
> >
> >
> > *will include* isn’t a BCP 14 MUST, but I don’t think it’s ambiguous.
> >
> >
> >
> > “A response to any other request will include only identifiers for the
> specifications used in the construction of the response.”
> >
> >
> >
> > Similarly, *will include only identifiers for the specifications used in the
> construction of the response* describ

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Hollenbeck, Scott]

Andy, I agree that that's an incorrect interpretation. Content is part of the 
response, too, and as such it has to be included when the response is 
constructed/formed/assembled/whatever.

Scott

> -Original Message-
> From: Andrew Newton (andy) 
> Sent: Tuesday, February 20, 2024 12:23 PM
> To: Hollenbeck, Scott 
> Cc: ietf=40antoin...@dmarc.ietf.org ;
> mario.loffredo=40iit.cnr...@dmarc.ietf.org ;
> regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-
> search
>
> 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.
>
> "construction of the response" can be interpreted strictly to mean only the
> JSON structure of the response. IMHO, that is an incorrect interpretation nor
> does it track with RDAP as it is used because profile extensions such as the
> ICANN and NRO extensions also dictate content not just structure.
>
> -andy
>
>
> On Tue, Feb 20, 2024 at 10:20 AM Hollenbeck, Scott
>  wrote:
> >
> > I don’t understand the confusion regarding the text in 9083. It might not
> include BCP 14 key words, but I believe the intention is clear. Looking at the
> two sentences:
> >
> >
> >
> > “A response to a "help" request will include identifiers for all of the
> specifications supported by the server.”
> >
> >
> >
> > *will include* isn’t a BCP 14 MUST, but I don’t think it’s ambiguous.
> >
> >
> >
> > “A response to any other request will include only identifiers for the
> specifications used in the construction of the response.”
> >
> >
> >
> > Similarly, *will include only identifiers for the specifications used in the
> construction of the response* describes the identifiers that are to be 
> included
> in any other response. If a client needs to implement something other than
> 9083 to correctly interpret and process a response, any identifier that
> describes a specification that’s needed to “understand” the response will be
> included. If that’s not clear, what am I missing?
> >
> >
> >
> > Scott
> >
> >
> >
> > From: regext  On Behalf Of Antoin Verschuren
> > Sent: Monday, February 19, 2024 10:42 AM
> > To: Mario Loffredo 
> > Cc: regext 
> > Subject: [EXTERNAL] Re: [regext] WG LAST CALL
> > draft-ietf-regext-rdap-rir-search
> >
> >
> >
> > 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.
> >
> > So, if I understand this correctly, the chairs asked the document shepherd 
> > to
> declare that there were no substantial changes made during WGLC between
> versions 05 and 07 and all raised issues were addressed.
> >
> >
> >
> > The answer below I interpret as: We would like the permission from the WG
> to not only substantially change draft-ietf-regext-rdap-rir-search in a next
> version that we want to send to the IESG, but on top of that also clarify or
> even change the interpretation of RFC 9083.
> >
> >
> >
> > If this is the question, then we need to have a discussion what this will 
> > mean
> to other documents and it’s interpretation of RFC 9083 first, and perhaps
> even write this clarification down in a separate document if that is needed.
> >
> > When that is done and consensus is reached,  we must issue a new WGLC for
> the next version of draft-ietf-regext-rdap-rir-search if that will contain 
> these
> substantial changes suggested by the WG.
> >
> >
> >
> > In order to reach consensus, all comments and support during a complete
> WGLC must be for a stable document. Otherwise we don’t know if people
> agree with what version of the document and which interpretation of RFC
> 9083.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Antoin
> >
> >
> >
> >
> >
> > Op 19 feb. 2024, om 13:07 heeft Mario Loffredo
>  het volgende geschreven:
> >
> >
> >
> > Hi Antoin,
> >
> > after a private discussion between  James, Tom, Jasdip and me, we agreed on
> the following:
> >
> > 1) Some minor edits that don't substantially change the draft but
> > clarify the meaning of some sentences will be done in next version
> >
> > 2) We would like the WG members express their own opinions on the
> substantial matter below.
> >
> > RFC 9083 states the following for rdapConformance includ

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Andrew Newton (andy)]

"construction of the response" can be interpreted strictly to mean
only the JSON structure of the response. IMHO, that is an incorrect
interpretation nor does it track with RDAP as it is used because
profile extensions such as the ICANN and NRO extensions also dictate
content not just structure.

-andy


On Tue, Feb 20, 2024 at 10:20 AM Hollenbeck, Scott
 wrote:
>
> I don’t understand the confusion regarding the text in 9083. It might not 
> include BCP 14 key words, but I believe the intention is clear. Looking at 
> the two sentences:
>
>
>
> “A response to a "help" request will include identifiers for all of the 
> specifications supported by the server.”
>
>
>
> *will include* isn’t a BCP 14 MUST, but I don’t think it’s ambiguous.
>
>
>
> “A response to any other request will include only identifiers for the 
> specifications used in the construction of the response.”
>
>
>
> Similarly, *will include only identifiers for the specifications used in the 
> construction of the response* describes the identifiers that are to be 
> included in any other response. If a client needs to implement something 
> other than 9083 to correctly interpret and process a response, any identifier 
> that describes a specification that’s needed to “understand” the response 
> will be included. If that’s not clear, what am I missing?
>
>
>
> Scott
>
>
>
> From: regext  On Behalf Of Antoin Verschuren
> Sent: Monday, February 19, 2024 10:42 AM
> To: Mario Loffredo 
> Cc: regext 
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL 
> draft-ietf-regext-rdap-rir-search
>
>
>
> 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.
>
> So, if I understand this correctly, the chairs asked the document shepherd to 
> declare that there were no substantial changes made during WGLC between 
> versions 05 and 07 and all raised issues were addressed.
>
>
>
> The answer below I interpret as: We would like the permission from the WG to 
> not only substantially change draft-ietf-regext-rdap-rir-search in a next 
> version that we want to send to the IESG, but on top of that also clarify or 
> even change the interpretation of RFC 9083.
>
>
>
> If this is the question, then we need to have a discussion what this will 
> mean to other documents and it’s interpretation of RFC 9083 first, and 
> perhaps even write this clarification down in a separate document if that is 
> needed.
>
> When that is done and consensus is reached,  we must issue a new WGLC for  
> the next version of draft-ietf-regext-rdap-rir-search if that will contain 
> these substantial changes suggested by the WG.
>
>
>
> In order to reach consensus, all comments and support during a complete WGLC 
> must be for a stable document. Otherwise we don’t know if people agree with 
> what version of the document and which interpretation of RFC 9083.
>
>
>
> Regards,
>
>
>
> Antoin
>
>
>
>
>
> Op 19 feb. 2024, om 13:07 heeft Mario Loffredo 
>  het volgende geschreven:
>
>
>
> Hi Antoin,
>
> after a private discussion between  James, Tom, Jasdip and me, we agreed on 
> the following:
>
> 1) Some minor edits that don't substantially change the draft but clarify the 
> meaning of some sentences will be done in next version
>
> 2) We would like the WG members express their own opinions on the substantial 
> matter below.
>
> RFC 9083 states the following for rdapConformance included in non-“help” RDAP 
> responses:
>
> · The data structure named "rdapConformance" is an array of strings, 
> each providing a hint as to the specifications used in the construction of 
> the response.
>
> · A response to any other request will include only identifiers for 
> the specifications used in the construction of the response.
>
> There is no normative language that specifies exactly what identifiers are 
> included in the response, where there is the language of “hints” and “used in 
> construction of the response”.  Below are options for what identifiers are 
> included in the “rdapConformance” array that could be captured in the RDAP 
> Extensions draft:
>
> Option 1) only the extension identifiers used to build the response with 
> regard to the fields
>
> Option 2) all of the extension identifiers that impact the build of the 
> response, hence with regard to fields, values, and query members / query 
> parameters used for the response (i.e. Option 1 + extension query identifiers 
> and extension identifiers impacting response values)
>
> Option 3)

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Hollenbeck, Scott]

I don’t understand the confusion regarding the text in 9083. It might not 
include BCP 14 key words, but I believe the intention is clear. Looking at the 
two sentences:



“A response to a "help" request will include identifiers for all of the 
specifications supported by the server.”



*will include* isn’t a BCP 14 MUST, but I don’t think it’s ambiguous.



“A response to any other request will include only identifiers for the 
specifications used in the construction of the response.”



Similarly, *will include only identifiers for the specifications used in the 
construction of the response* describes the identifiers that are to be included 
in any other response. If a client needs to implement something other than 9083 
to correctly interpret and process a response, any identifier that describes a 
specification that’s needed to “understand” the response will be included. If 
that’s not clear, what am I missing?



Scott



From: regext  On Behalf Of Antoin Verschuren
Sent: Monday, February 19, 2024 10:42 AM
To: Mario Loffredo 
Cc: regext 
Subject: [EXTERNAL] Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search



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.

So, if I understand this correctly, the chairs asked the document shepherd to 
declare that there were no substantial changes made during WGLC between 
versions 05 and 07 and all raised issues were addressed.



The answer below I interpret as: We would like the permission from the WG to 
not only substantially change draft-ietf-regext-rdap-rir-search in a next 
version that we want to send to the IESG, but on top of that also clarify or 
even change the interpretation of RFC 9083.



If this is the question, then we need to have a discussion what this will mean 
to other documents and it’s interpretation of RFC 9083 first, and perhaps even 
write this clarification down in a separate document if that is needed.

When that is done and consensus is reached,  we must issue a new WGLC for  the 
next version of draft-ietf-regext-rdap-rir-search if that will contain these 
substantial changes suggested by the WG.



In order to reach consensus, all comments and support during a complete WGLC 
must be for a stable document. Otherwise we don’t know if people agree with 
what version of the document and which interpretation of RFC 9083.



Regards,



Antoin







   Op 19 feb. 2024, om 13:07 heeft Mario Loffredo 
mailto:mario.loffredo=40iit.cnr...@dmarc.ietf.org>>
 het volgende geschreven:



   Hi Antoin,

   after a private discussion between  James, Tom, Jasdip and me, we agreed on 
the following:

   1) Some minor edits that don't substantially change the draft but clarify 
the meaning of some sentences will be done in next version

   2) We would like the WG members express their own opinions on the 
substantial matter below.

   RFC 9083 states the following for rdapConformance included in non-“help” 
RDAP responses:

   · The data structure named "rdapConformance" is an array of strings, 
each providing a hint as to the specifications used in the construction of the 
response.

   · A response to any other request will include only identifiers for 
the specifications used in the construction of the response.

   There is no normative language that specifies exactly what identifiers are 
included in the response, where there is the language of “hints” and “used in 
construction of the response”.  Below are options for what identifiers are 
included in the “rdapConformance” array that could be captured in the RDAP 
Extensions draft:

   Option 1) only the extension identifiers used to build the response with 
regard to the fields

   Option 2) all of the extension identifiers that impact the build of the 
response, hence with regard to fields, values, and query members / query 
parameters used for the response (i.e. Option 1 + extension query identifiers 
and extension identifiers impacting response values)

   Option 3)  all of the extension identifiers defined by specs used to build 
the response (i.e. Option 2 + any extension identifier defined by referenced 
specs)



   Option 1 corresponds to a literal interpretation of normative language in 
RFC 9083, while Option 2 extends its meaning.

   Option 3 is further extensive and corresponds to the interpretation used in 
rir-search. To better explain their position, the authors asked me to add the 
following note (please Tom and Jasdip elaborate, if you think I missed 
something or didn't present correctly your point of view):

   "documents may mandate specific behaviour around identifiers for the 
purposes of signalling, and it's fine for this sort of thing to override the 
requirement above. (nro_rdap_profile_asn_flat_0 and 
nro_rdap_profile_asn_hierarchical_0 are examples of this, where the document 

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Mario Loffredo]

Hi Antoin,

please find my comments below.

Il 19/02/2024 16:41, Antoin Verschuren ha scritto:
So, if I understand this correctly, the chairs asked the document 
shepherd to declare that there were no substantial changes made during 
WGLC between versions 05 and 07 and all raised issues were addressed.


The answer below I interpret as: We would like the permission from the 
WG to not only substantially change draft-ietf-regext-rdap-rir-search 
in a next version that we want to send to the IESG, but on top of that 
also clarify or even change the interpretation of RFC 9083.


If this is the question, then we need to have a discussion what this 
will mean to other documents and it’s interpretation of RFC 9083 
first, and perhaps even write this clarification down in a separate 
document if that is needed.
When that is done and consensus is reached,  we must issue a new WGLC 
for  the next version of draft-ietf-regext-rdap-rir-search if that 
will contain these substantial changes suggested by the WG.



[ML] Yes, that is the question.

I would also like to outline that, in this case, the difference between 
correcting nits (i.e. ,  some unnecessary extension identifiers included 
in the rdapConformance array as it is shown in some examples) and 
changing substantially the draft depends just on the interpretation of 
RFC9083 and such a question revealed to be matter for WG discussion when 
the different interpretations came up.



Best,

Mario

In order to reach consensus, all comments and support during a 
complete WGLC must be for a stable document. Otherwise we don’t know 
if people agree with what version of the document and which 
interpretation of RFC 9083.


Regards,

Antoin


Op 19 feb. 2024, om 13:07 heeft Mario Loffredo 
 het volgende geschreven:


Hi Antoin,

after a private discussion between  James, Tom, Jasdip and me, we 
agreed on the following:


1) Some minor edits that don't substantially change the draft but 
clarify the meaning of some sentences will be done in next version


2) We would like the WG members express their own opinions on the 
substantial matter below.


*/RFC 9083 states the following for rdapConformance included in 
non-“help” RDAP responses:/*


*/·The data structure named "rdapConformance" is an array of strings, 
each providing a hint as to the specifications used in the 
construction of the response./*


*/·A response to any other request will include only identifiers for 
the specifications used in the construction of the response./*


*/There is no normative language that specifies exactly what 
identifiers are included in the response, where there is the language 
of “hints” and “used in construction of the response”.  Below are 
options for what identifiers are included in the “rdapConformance” 
array that could be captured in the RDAP Extensions draft:/*


/*Option 1) only the extension identifiers used to build the response 
with regard to the fields*/


/*Option 2) all of the extension identifiers that impact the build of 
the response, hence with regard to fields, values, and query members 
/ query parameters used for the response (i.e. Option 1 + extension 
query identifiers and extension identifiers impacting response values)*/


/*Option 3)  all of the extension identifiers defined by specs used 
to build the response (i.e. Option 2 + any extension identifier 
defined by referenced specs) */


*//*


Option 1 corresponds to a literal interpretation of normative 
language in RFC 9083, while Option 2 extends its meaning.


Option 3 is further extensive and corresponds to the interpretation 
used in rir-search. To better explain their position, the authors 
asked me to add the following note (please Tom and Jasdip elaborate, 
if you think I missed something or didn't present correctly your 
point of view):


"documents may mandate specific behaviour around identifiers for the 
purposes of signalling, and it's fine for this sort of thing to 
override the requirement above. (nro_rdap_profile_asn_flat_0 and 
nro_rdap_profile_asn_hierarchical_0 are examples of this, where the 
document itself requires implementations to pick one or the other, 
and that's fine.)"




Best,

Mario


Il 05/02/2024 15:35, Antoin Verschuren ha scritto:

Hi All,

After some prolonged discussion, the chairs will now close this working group 
last call that should have ended 11 December 2023.
We have had comments and approval during WGLC from 4 working group participants 
and the document shepherd and no objections.
That has lead to 2 new versions of the document during WGLC that started with 
version 05.

The document shepherd for this document is Mario Loffredo.

In order for the document to progress and sent to the IESG, the document 
shepherd will need to do a final review of the following:

1. Please confirm all suggested changes have been addressed in version 07.
2. Please ask James Gould to confirm his changes have been addressed as he 
promised to do another review.
3. Make sure 

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Antoin Verschuren]

So, if I understand this correctly, the chairs asked the document shepherd to 
declare that there were no substantial changes made during WGLC between 
versions 05 and 07 and all raised issues were addressed.

The answer below I interpret as: We would like the permission from the WG to 
not only substantially change draft-ietf-regext-rdap-rir-search in a next 
version that we want to send to the IESG, but on top of that also clarify or 
even change the interpretation of RFC 9083.

If this is the question, then we need to have a discussion what this will mean 
to other documents and it’s interpretation of RFC 9083 first, and perhaps even 
write this clarification down in a separate document if that is needed.
When that is done and consensus is reached,  we must issue a new WGLC for  the 
next version of draft-ietf-regext-rdap-rir-search if that will contain these 
substantial changes suggested by the WG.

In order to reach consensus, all comments and support during a complete WGLC 
must be for a stable document. Otherwise we don’t know if people agree with 
what version of the document and which interpretation of RFC 9083.

Regards,

Antoin


> Op 19 feb. 2024, om 13:07 heeft Mario Loffredo 
>  het volgende geschreven:
> 
> Hi Antoin,
> 
> after a private discussion between  James, Tom, Jasdip and me, we agreed on 
> the following:
> 
> 1) Some minor edits that don't substantially change the draft but clarify the 
> meaning of some sentences will be done in next version
> 
> 2) We would like the WG members express their own opinions on the substantial 
> matter below.
> 
> RFC 9083 states the following for rdapConformance included in non-“help” RDAP 
> responses:
> 
> · The data structure named "rdapConformance" is an array of strings, 
> each providing a hint as to the specifications used in the construction of 
> the response.
> 
> · A response to any other request will include only identifiers for 
> the specifications used in the construction of the response.
> 
> There is no normative language that specifies exactly what identifiers are 
> included in the response, where there is the language of “hints” and “used in 
> construction of the response”.  Below are options for what identifiers are 
> included in the “rdapConformance” array that could be captured in the RDAP 
> Extensions draft:
> 
> Option 1) only the extension identifiers used to build the response with 
> regard to the fields
> 
> Option 2) all of the extension identifiers that impact the build of the 
> response, hence with regard to fields, values, and query members / query 
> parameters used for the response (i.e. Option 1 + extension query identifiers 
> and extension identifiers impacting response values)
> 
> Option 3)  all of the extension identifiers defined by specs used to build 
> the response (i.e. Option 2 + any extension identifier defined by referenced 
> specs)
> 
> 
> Option 1 corresponds to a literal interpretation of normative language in RFC 
> 9083, while Option 2 extends its meaning.
> 
> Option 3 is further extensive and corresponds to the interpretation used in 
> rir-search. To better explain their position, the authors asked me to add the 
> following note (please Tom and Jasdip elaborate, if you think I missed 
> something or didn't present correctly your point of view):
> 
> "documents may mandate specific behaviour around identifiers for the purposes 
> of signalling, and it's fine for this sort of thing to override the 
> requirement above. (nro_rdap_profile_asn_flat_0 and 
> nro_rdap_profile_asn_hierarchical_0 are examples of this, where the document 
> itself requires implementations to pick one or the other, and that's fine.)"
> 
> 
> 
> Best,
> 
> Mario
> 
> 
> 
> Il 05/02/2024 15:35, Antoin Verschuren ha scritto:
>> Hi All,
>> 
>> After some prolonged discussion, the chairs will now close this working 
>> group last call that should have ended 11 December 2023.
>> We have had comments and approval during WGLC from 4 working group 
>> participants and the document shepherd and no objections.
>> That has lead to 2 new versions of the document during WGLC that started 
>> with version 05.
>> 
>> The document shepherd for this document is Mario Loffredo.
>> 
>> In order for the document to progress and sent to the IESG, the document 
>> shepherd will need to do a final review of the following:
>> 
>> 1. Please confirm all suggested changes have been addressed in version 07.
>> 2. Please ask James Gould to confirm his changes have been addressed as he 
>> promised to do another review.
>> 3. Make sure the Nits are addressed.
>> 4. Confirm that all changes between version 05 and version 07 are editorial 
>> and not substantive.
>> 5. When all the above concerns are addressed, please write the document 
>> shepherd writeup.
>> 
>> Thanks to everyone that contributed to this review!
>> 
>> Regards,
>> 
>> Jim and Antoin
>> REGEXT WG Co-Chairs
>> 
>> 
>>> Op 27 nov. 2023, om 15:51 heeft Antoin Ver

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Mario Loffredo]

Hi Antoin,

after a private discussion between  James, Tom, Jasdip and me, we agreed 
on the following:


1) Some minor edits that don't substantially change the draft but 
clarify the meaning of some sentences will be done in next version


2) We would like the WG members express their own opinions on the 
substantial matter below.


*/RFC 9083 states the following for rdapConformance included in 
non-“help” RDAP responses:/*


*/·The data structure named "rdapConformance" is an array of strings, 
each providing a hint as to the specifications used in the construction 
of the response./*


*/·A response to any other request will include only identifiers for the 
specifications used in the construction of the response./*


*/There is no normative language that specifies exactly what identifiers 
are included in the response, where there is the language of “hints” and 
“used in construction of the response”.  Below are options for what 
identifiers are included in the “rdapConformance” array that could be 
captured in the RDAP Extensions draft:/*


/*Option 1) only the extension identifiers used to build the response 
with regard to the fields*/


/*Option 2) all of the extension identifiers that impact the build of 
the response, hence with regard to fields, values, and query members / 
query parameters used for the response (i.e. Option 1 + extension query 
identifiers and extension identifiers impacting response values)*/


/*Option 3)  all of the extension identifiers defined by specs used to 
build the response (i.e. Option 2 + any extension identifier defined by 
referenced specs) */


*//*


Option 1 corresponds to a literal interpretation of normative language 
in RFC 9083, while Option 2 extends its meaning.


Option 3 is further extensive and corresponds to the interpretation used 
in rir-search. To better explain their position, the authors asked me to 
add the following note (please Tom and Jasdip elaborate, if you think I 
missed something or didn't present correctly your point of view):


"documents may mandate specific behaviour around identifiers for the 
purposes of signalling, and it's fine for this sort of thing to override 
the requirement above. (nro_rdap_profile_asn_flat_0 and 
nro_rdap_profile_asn_hierarchical_0 are examples of this, where the 
document itself requires implementations to pick one or the other, and 
that's fine.)"



Best,

Mario


Il 05/02/2024 15:35, Antoin Verschuren ha scritto:

Hi All,

After some prolonged discussion, the chairs will now close this working group 
last call that should have ended 11 December 2023.
We have had comments and approval during WGLC from 4 working group participants 
and the document shepherd and no objections.
That has lead to 2 new versions of the document during WGLC that started with 
version 05.

The document shepherd for this document is Mario Loffredo.

In order for the document to progress and sent to the IESG, the document 
shepherd will need to do a final review of the following:

1. Please confirm all suggested changes have been addressed in version 07.
2. Please ask James Gould to confirm his changes have been addressed as he 
promised to do another review.
3. Make sure the Nits are addressed.
4. Confirm that all changes between version 05 and version 07 are editorial and 
not substantive.
5. When all the above concerns are addressed, please write the document 
shepherd writeup.

Thanks to everyone that contributed to this review!

Regards,

Jim and Antoin
REGEXT WG Co-Chairs



Op 27 nov. 2023, om 15:51 heeft Antoin 
Verschuren  het volgende geschreven:

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:


RDAP RIR Search
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/05/


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, 11 December 2023.

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

The Document Shepherd for this document is Mario Loffredo.

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


--
Dott. Mario Loffredo
Senior Technologist
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.or

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Antoin Verschuren]

Hi All,

After some prolonged discussion, the chairs will now close this working group 
last call that should have ended 11 December 2023.
We have had comments and approval during WGLC from 4 working group participants 
and the document shepherd and no objections.
That has lead to 2 new versions of the document during WGLC that started with 
version 05.

The document shepherd for this document is Mario Loffredo.

In order for the document to progress and sent to the IESG, the document 
shepherd will need to do a final review of the following:

1. Please confirm all suggested changes have been addressed in version 07.
2. Please ask James Gould to confirm his changes have been addressed as he 
promised to do another review.
3. Make sure the Nits are addressed.
4. Confirm that all changes between version 05 and version 07 are editorial and 
not substantive.
5. When all the above concerns are addressed, please write the document 
shepherd writeup.

Thanks to everyone that contributed to this review!

Regards,

Jim and Antoin
REGEXT WG Co-Chairs


> Op 27 nov. 2023, om 15:51 heeft Antoin Verschuren 
>  het volgende geschreven:
> 
> 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:
> 
> 
> RDAP RIR Search
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/05/
> 
> 
> 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, 11 December 2023.  
> 
> If there are no objections the document will be submitted to the IESG.
> 
> The Document Shepherd for this document is Mario Loffredo.
> 
> 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] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Jasdip Singh]

Thanks Scott. Looks like most folks have interpreted it the way you have. :)

We'd clarify (not redefine) section 4.1 of RFC 9083 vis-a-vis the 
a-spec-with-multiple-extension-identifiers scenario in the next version of the 
RDAP Extensions draft. Though such a scenario should be rare but could happen 
again.

Jasdip

On 1/30/24, 2:40 PM, "Hollenbeck, Scott" mailto:shollenb...@verisign.com>> wrote:

Yes, the former, Jasdip. As in, the client should know which extensions it 
needs to process _in a specific response_.

Scott

> -Original Message-
> From: Jasdip Singh mailto:jasd...@arin.net>>
> Sent: Tuesday, January 30, 2024 10:20 AM
> To: Hollenbeck, Scott  <mailto:shollenb...@verisign.com>>; gal...@elistx.com 
> <mailto:gal...@elistx.com>;
> t...@apnic.net <mailto:t...@apnic.net>
> Cc: mario.loffredo=40iit.cnr...@dmarc.ietf.org 
> <mailto:40iit.cnr...@dmarc.ietf.org>  <mailto:mario.loffr...@iit.cnr.it>>;
> ietf=40antoin...@dmarc.ietf.org <mailto:40antoin...@dmarc.ietf.org> 
> mailto:i...@antoin.nl>>; regext@ietf.org 
> <mailto:regext@ietf.org>
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-
> search
>
> 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 Scott,
>
> Just to clarify, when a specification defines multiple extension identifiers 
> (like
> the RIR Search does), would you interpret what's in RFC 9083 (section 4.1) to
> only include those identifiers for a response that were relevant for the
> construction of the response (e.g., not including "autnums" and
> "autnumSearchResults" for an IP search result, and vice-versa), versus
> including all the identifiers for every response type from that specification?
> IIUC, you are pointing to the former (only relevant identifiers), right?
>
> Jasdip
>
> On 1/29/24, 10:05 AM, "regext on behalf of Hollenbeck, Scott"  boun...@ietf.org <mailto:boun...@ietf.org> <mailto:regext-boun...@ietf.org 
> <mailto:regext-boun...@ietf.org>> on behalf of
> shollenbeck=40verisign@dmarc.ietf.org 
> <mailto:40verisign@dmarc.ietf.org>
> <mailto:40verisign@dmarc.ietf.org 
> <mailto:40verisign@dmarc.ietf.org>>> wrote:
>
> I'd very much prefer to stay with a literal reading of what's in RFC 9083:
>
> "A response to a "help" request will include identifiers for all of the
> specifications supported by the server. A response to any other request will
> include only identifiers for the specifications used in the construction of 
> the
> response. The set of returned identifiers MAY vary depending on the
> authorization level of the client."
>
> Scott
>
> > -Original Message-
> > From: regext mailto:regext-boun...@ietf.org>
> > <mailto:regext-boun...@ietf.org <mailto:regext-boun...@ietf.org>>> On 
> > Behalf Of James Galvin
> > Sent: Monday, January 29, 2024 9:59 AM
> > To: Tom Harrison mailto:t...@apnic.net> 
> > <mailto:t...@apnic.net <mailto:t...@apnic.net>>>
> > Cc: Mario Loffredo  > <mailto:40iit.cnr...@dmarc.ietf.org>
> > <mailto:40iit.cnr...@dmarc.ietf.org <mailto:40iit.cnr...@dmarc.ietf.org>>>; 
> > Antoin Verschuren
> > mailto:40antoin...@dmarc.ietf.org> 
> > <mailto:40antoin...@dmarc.ietf.org <mailto:40antoin...@dmarc.ietf.org>>>;
> > regext mailto:regext@ietf.org> <mailto:regext@ietf.org 
> > <mailto:regext@ietf.org>>>
> > Subject: [EXTERNAL] Re: [regext] WG LAST CALL
> > draft-ietf-regext-rdap-rir- search
> >
> > 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.
> >
> > Speaking as your Chairs:
> >
> > Mario brings up an interesting question for which the Chairs need to
> > hear some other opinions.
> >
> > On the one hand, there does seem to be some ambiguity regarding the
> > proper use of the rdapConformance array. If this is a concern, then
> > the Chairs believe that the WG needs to decide which way they would
> > like to resolve this question. More importantly, the question is
> > substantive and we will need to close the WG Last Call, resolve the
> > issue, and then proceed with another WG Last Call.
> >
> > On the other hand, this ambiguity does not seem to be of broad
> > concern. If that’s true, then the document as currently 

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Hollenbeck, Scott]

Yes, the former, Jasdip. As in, the client should know which extensions it 
needs to process _in a specific response_.

Scott

> -Original Message-
> From: Jasdip Singh 
> Sent: Tuesday, January 30, 2024 10:20 AM
> To: Hollenbeck, Scott ; gal...@elistx.com;
> t...@apnic.net
> Cc: mario.loffredo=40iit.cnr...@dmarc.ietf.org ;
> ietf=40antoin...@dmarc.ietf.org ; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-
> search
>
> 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 Scott,
>
> Just to clarify, when a specification defines multiple extension identifiers 
> (like
> the RIR Search does), would you interpret what's in RFC 9083 (section 4.1) to
> only include those identifiers for a response that were relevant for the
> construction of the response (e.g., not including "autnums" and
> "autnumSearchResults" for an IP search result, and vice-versa), versus
> including all the identifiers for every response type from that specification?
> IIUC, you are pointing to the former (only relevant identifiers), right?
>
> Jasdip
>
> On 1/29/24, 10:05 AM, "regext on behalf of Hollenbeck, Scott"  boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of
> shollenbeck=40verisign@dmarc.ietf.org
> <mailto:40verisign@dmarc.ietf.org>> wrote:
>
> I'd very much prefer to stay with a literal reading of what's in RFC 9083:
>
> "A response to a "help" request will include identifiers for all of the
> specifications supported by the server. A response to any other request will
> include only identifiers for the specifications used in the construction of 
> the
> response. The set of returned identifiers MAY vary depending on the
> authorization level of the client."
>
> Scott
>
> > -Original Message-
> > From: regext  > <mailto:regext-boun...@ietf.org>> On Behalf Of James Galvin
> > Sent: Monday, January 29, 2024 9:59 AM
> > To: Tom Harrison mailto:t...@apnic.net>>
> > Cc: Mario Loffredo  > <mailto:40iit.cnr...@dmarc.ietf.org>>; Antoin Verschuren
> > mailto:40antoin...@dmarc.ietf.org>>;
> > regext mailto:regext@ietf.org>>
> > Subject: [EXTERNAL] Re: [regext] WG LAST CALL
> > draft-ietf-regext-rdap-rir- search
> >
> > 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.
> >
> > Speaking as your Chairs:
> >
> > Mario brings up an interesting question for which the Chairs need to
> > hear some other opinions.
> >
> > On the one hand, there does seem to be some ambiguity regarding the
> > proper use of the rdapConformance array. If this is a concern, then
> > the Chairs believe that the WG needs to decide which way they would
> > like to resolve this question. More importantly, the question is
> > substantive and we will need to close the WG Last Call, resolve the
> > issue, and then proceed with another WG Last Call.
> >
> > On the other hand, this ambiguity does not seem to be of broad
> > concern. If that’s true, then the document as currently written could
> > be left as is, the WG Last Call could be closed, and if the remaining
> > changes are confirmed to be editorial then the document can be submitted
> to the IESG.
> >
> > Do WG members believe this issue is of concern and needs to be resolved?
> >
> > Please respond on the list. If there are no concerns then the document
> > will be left as is and the WG Last Call will be closed on Sunday, 4 February
> 2024.
> >
> > Antoin and Jim
> >
> >
> >
> > On 28 Jan 2024, at 19:36, Tom Harrison wrote:
> >
> > > Hi Mario,
> > >
> > > On Fri, Jan 26, 2024 at 09:21:16AM +0100, Mario Loffredo wrote:
> > >> Il 26/01/2024 04:29, Tom Harrison ha scritto:
> > >>> On Thu, Nov 30, 2023 at 08:21:42AM +0100, Mario Loffredo wrote:
> > >>>> 2) Per what is stated in section 4.1 0f RFC9083, the
> > >>>> rdapConformance array in the examples Section 4 should include
> > >>>> only the extensions used in the response.
> > >>>> For sure the response including the ipSearchResults array will
> > >>>> never include the autnumSearchResults array and viceversa ;-) The
> > >>>> same goes for the responses including the links about ips or
&g

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Jasdip Singh]

Hi Scott,

Just to clarify, when a specification defines multiple extension identifiers 
(like the RIR Search does), would you interpret what's in RFC 9083 (section 
4.1) to only include those identifiers for a response that were relevant for 
the construction of the response (e.g., not including "autnums" and 
"autnumSearchResults" for an IP search result, and vice-versa), versus 
including all the identifiers for every response type from that specification? 
IIUC, you are pointing to the former (only relevant identifiers), right?

Jasdip

On 1/29/24, 10:05 AM, "regext on behalf of Hollenbeck, Scott" 
mailto:regext-boun...@ietf.org> on behalf of 
shollenbeck=40verisign@dmarc.ietf.org 
<mailto:40verisign@dmarc.ietf.org>> wrote:

I'd very much prefer to stay with a literal reading of what's in RFC 9083:

"A response to a "help" request will include identifiers for all of the 
specifications supported by the server. A response to any other request will 
include only identifiers for the specifications used in the construction of the 
response. The set of returned identifiers MAY vary depending on the 
authorization level of the client."

Scott

> -Original Message-
> From: regext mailto:regext-boun...@ietf.org>> On 
> Behalf Of James Galvin
> Sent: Monday, January 29, 2024 9:59 AM
> To: Tom Harrison mailto:t...@apnic.net>>
> Cc: Mario Loffredo  <mailto:40iit.cnr...@dmarc.ietf.org>>; Antoin
> Verschuren  <mailto:40antoin...@dmarc.ietf.org>>; regext  <mailto:regext@ietf.org>>
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-
> search
>
> 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.
>
> Speaking as your Chairs:
>
> Mario brings up an interesting question for which the Chairs need to hear
> some other opinions.
>
> On the one hand, there does seem to be some ambiguity regarding the proper
> use of the rdapConformance array. If this is a concern, then the Chairs 
> believe
> that the WG needs to decide which way they would like to resolve this
> question. More importantly, the question is substantive and we will need to
> close the WG Last Call, resolve the issue, and then proceed with another WG
> Last Call.
>
> On the other hand, this ambiguity does not seem to be of broad concern. If
> that’s true, then the document as currently written could be left as is, the 
> WG
> Last Call could be closed, and if the remaining changes are confirmed to be
> editorial then the document can be submitted to the IESG.
>
> Do WG members believe this issue is of concern and needs to be resolved?
>
> Please respond on the list. If there are no concerns then the document will be
> left as is and the WG Last Call will be closed on Sunday, 4 February 2024.
>
> Antoin and Jim
>
>
>
> On 28 Jan 2024, at 19:36, Tom Harrison wrote:
>
> > Hi Mario,
> >
> > On Fri, Jan 26, 2024 at 09:21:16AM +0100, Mario Loffredo wrote:
> >> Il 26/01/2024 04:29, Tom Harrison ha scritto:
> >>> On Thu, Nov 30, 2023 at 08:21:42AM +0100, Mario Loffredo wrote:
> >>>> 2) Per what is stated in section 4.1 0f RFC9083, the
> >>>> rdapConformance array in the examples Section 4 should include only
> >>>> the extensions used in the response.
> >>>> For sure the response including the ipSearchResults array will
> >>>> never include the autnumSearchResults array and viceversa ;-) The
> >>>> same goes for the responses including the links about ips or
> >>>> autnums. Instead, the help response should include all the
> >>>> extensions implemented. As a result of this, the first two
> >>>> paragraphs of Section 6 should be modified as well.
> >>>
> >>> We think that the existing text/behaviour should be left as-is in
> >>> this respect. Section 4.1 of 9083 says:
> >>>
> >>> A response to a "help" request will include identifiers for all of
> >>> the specifications supported by the server. A response to any
> >>> other request will include only identifiers for the specifications
> >>> used in the construction of the response.
> >>>
> >>> and that any response which makes use of any part of the RIR search
> >>> specification should therefore include all of the identifiers
> >>> defined by the RIR search specification, since each of those
> >>> identifiers will be "for [one of] the specifications used in the
> >&g

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Hollenbeck, Scott]

I'd very much prefer to stay with a literal reading of what's in RFC 9083:

"A response to a "help" request will include identifiers for all of the 
specifications supported by the server. A response to any other request will 
include only identifiers for the specifications used in the construction of the 
response. The set of returned identifiers MAY vary depending on the 
authorization level of the client."

Scott

> -Original Message-
> From: regext  On Behalf Of James Galvin
> Sent: Monday, January 29, 2024 9:59 AM
> To: Tom Harrison 
> Cc: Mario Loffredo ; Antoin
> Verschuren ; regext 
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-
> search
>
> 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.
>
> Speaking as your Chairs:
>
> Mario brings up an interesting question for which the Chairs need to hear
> some other opinions.
>
> On the one hand, there does seem to be some ambiguity regarding the proper
> use of the rdapConformance array.  If this is a concern, then the Chairs 
> believe
> that the WG needs to decide which way they would like to resolve this
> question.  More importantly, the question is substantive and we will need to
> close the WG Last Call, resolve the issue, and then proceed with another WG
> Last Call.
>
> On the other hand, this ambiguity does not seem to be of broad concern.  If
> that’s true, then the document as currently written could be left as is, the 
> WG
> Last Call could be closed, and if the remaining changes are confirmed to be
> editorial then the document can be submitted to the IESG.
>
> Do WG members believe this issue is of concern and needs to be resolved?
>
> Please respond on the list.  If there are no concerns then the document will 
> be
> left as is and the WG Last Call will be closed on Sunday, 4 February 2024.
>
> Antoin and Jim
>
>
>
> On 28 Jan 2024, at 19:36, Tom Harrison wrote:
>
> > Hi Mario,
> >
> > On Fri, Jan 26, 2024 at 09:21:16AM +0100, Mario Loffredo wrote:
> >> Il 26/01/2024 04:29, Tom Harrison ha scritto:
> >>> On Thu, Nov 30, 2023 at 08:21:42AM +0100, Mario Loffredo wrote:
> >>>> 2) Per what is stated in section 4.1 0f RFC9083, the
> >>>> rdapConformance array in the examples Section 4 should include only
> >>>> the extensions used in the response.
> >>>> For sure the response including the ipSearchResults array will
> >>>> never include the autnumSearchResults array and viceversa ;-) The
> >>>> same goes for the responses including the links about ips or
> >>>> autnums.  Instead, the help response should include all the
> >>>> extensions implemented.  As a result of this,  the first two
> >>>> paragraphs of Section 6 should be modified as well.
> >>>
> >>> We think that the existing text/behaviour should be left as-is in
> >>> this respect.  Section 4.1 of 9083 says:
> >>>
> >>>  A response to a "help" request will include identifiers for all of
> >>>  the specifications supported by the server.  A response to any
> >>>  other request will include only identifiers for the specifications
> >>>  used in the construction of the response.
> >>>
> >>> and that any response which makes use of any part of the RIR search
> >>> specification should therefore include all of the identifiers
> >>> defined by the RIR search specification, since each of those
> >>> identifiers will be "for [one of] the specifications used in the
> >>> construction of the response".  An alternative reading along the
> >>> lines of your suggestion would require associating identifiers with
> >>> specific functionality in the document.  While that's relatively
> >>> straightforward in this case, it would require extra, possibly
> >>> unintuitive guidance in the document as to when identifiers should
> >>> be included.  It's also not clear that it yields much benefit for
> >>> the client, either: while it would be possible in theory for a
> >>> client to implement/understand only part of an extension, such that
> >>> a response with a subset of the available identifiers could be
> >>> processed without having to go to the trouble of
> >>> implementing/understanding the whole extension, that doesn't seem
> >>> like something that would come up

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[James Galvin]

Speaking as your Chairs:

Mario brings up an interesting question for which the Chairs need to hear some 
other opinions.

On the one hand, there does seem to be some ambiguity regarding the proper use 
of the rdapConformance array.  If this is a concern, then the Chairs believe 
that the WG needs to decide which way they would like to resolve this question. 
 More importantly, the question is substantive and we will need to close the WG 
Last Call, resolve the issue, and then proceed with another WG Last Call.

On the other hand, this ambiguity does not seem to be of broad concern.  If 
that’s true, then the document as currently written could be left as is, the WG 
Last Call could be closed, and if the remaining changes are confirmed to be 
editorial then the document can be submitted to the IESG.

Do WG members believe this issue is of concern and needs to be resolved?

Please respond on the list.  If there are no concerns then the document will be 
left as is and the WG Last Call will be closed on Sunday, 4 February 2024.

Antoin and Jim



On 28 Jan 2024, at 19:36, Tom Harrison wrote:

> Hi Mario,
>
> On Fri, Jan 26, 2024 at 09:21:16AM +0100, Mario Loffredo wrote:
>> Il 26/01/2024 04:29, Tom Harrison ha scritto:
>>> On Thu, Nov 30, 2023 at 08:21:42AM +0100, Mario Loffredo wrote:
 2) Per what is stated in section 4.1 0f RFC9083, the rdapConformance
 array in the examples Section 4 should include only the extensions
 used in the response.
 For sure the response including the ipSearchResults array will never
 include the autnumSearchResults array and viceversa ;-)
 The same goes for the responses including the links about ips or
 autnums.  Instead, the help response should include all the
 extensions implemented.  As a result of this,  the first two
 paragraphs of Section 6 should be modified as well.
>>>
>>> We think that the existing text/behaviour should be left as-is in this
>>> respect.  Section 4.1 of 9083 says:
>>>
>>>  A response to a "help" request will include identifiers for all of
>>>  the specifications supported by the server.  A response to any
>>>  other request will include only identifiers for the specifications
>>>  used in the construction of the response.
>>>
>>> and that any response which makes use of any part of the RIR search
>>> specification should therefore include all of the identifiers defined
>>> by the RIR search specification, since each of those identifiers will
>>> be "for [one of] the specifications used in the construction of the
>>> response".  An alternative reading along the lines of your suggestion
>>> would require associating identifiers with specific functionality in
>>> the document.  While that's relatively straightforward in this case,
>>> it would require extra, possibly unintuitive guidance in the document
>>> as to when identifiers should be included.  It's also not clear that
>>> it yields much benefit for the client, either: while it would be
>>> possible in theory for a client to implement/understand only part of
>>> an extension, such that a response with a subset of the available
>>> identifiers could be processed without having to go to the trouble of
>>> implementing/understanding the whole extension, that doesn't seem like
>>> something that would come up much in practice, given that most
>>> extensions are quite short/straightforward.  What do you think?
>>
>> Think it would be good to involve the WG in the diiscussion.
>> Literally RFC 9083 states that only the identifiers of those
>> extensions used in building a response can be included in the
>> rdapConformance array.
>>
>> Have always thought that its purpose was to inform clients about the
>> extension prefixes they should be ready to recognize when
>> deserializing the response.
>
> I'm not sure that it's limited to extension prefixes for the purposes
> of deserialisation only.  For example, the core extension identifier
> for the NRO RDAP profile (i.e. nro_rdap_profile_0) is not used as a
> prefix for any response fields, but is still included in most
> responses from a server that implements that profile, since the
> behaviour defined there affects how the response is
> constructed/interpreted.
>
>> For this reason, including in the rdapConformance array an extension
>> identifier that is not used in the response could be misleading for
>> clients.
>>
>> Besides, mentioning in rdapConformance only the extensions used in
>> the response doesn't mean that either the server or the client can
>> have a partial knowledge of the specification defining them.
>
> It's at least possible to imagine a scenario where this is the case,
> even if it may be unlikely to happen in practice.  Under the approach
> you have set out, a specification that defines two or more extension
> identifiers needs to describe when those extension identifiers should
> be included in responses.  If one identifier is used for behaviour
> that is specific to that identifi

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Tom Harrison]

Hi Mario,

On Fri, Jan 26, 2024 at 09:21:16AM +0100, Mario Loffredo wrote:
> Il 26/01/2024 04:29, Tom Harrison ha scritto:
>> On Thu, Nov 30, 2023 at 08:21:42AM +0100, Mario Loffredo wrote:
>>> 2) Per what is stated in section 4.1 0f RFC9083, the rdapConformance
>>> array in the examples Section 4 should include only the extensions
>>> used in the response.
>>> For sure the response including the ipSearchResults array will never
>>> include the autnumSearchResults array and viceversa ;-)
>>> The same goes for the responses including the links about ips or
>>> autnums.  Instead, the help response should include all the
>>> extensions implemented.  As a result of this,  the first two
>>> paragraphs of Section 6 should be modified as well.
>>
>> We think that the existing text/behaviour should be left as-is in this
>> respect.  Section 4.1 of 9083 says:
>> 
>>  A response to a "help" request will include identifiers for all of
>>  the specifications supported by the server.  A response to any
>>  other request will include only identifiers for the specifications
>>  used in the construction of the response.
>> 
>> and that any response which makes use of any part of the RIR search
>> specification should therefore include all of the identifiers defined
>> by the RIR search specification, since each of those identifiers will
>> be "for [one of] the specifications used in the construction of the
>> response".  An alternative reading along the lines of your suggestion
>> would require associating identifiers with specific functionality in
>> the document.  While that's relatively straightforward in this case,
>> it would require extra, possibly unintuitive guidance in the document
>> as to when identifiers should be included.  It's also not clear that
>> it yields much benefit for the client, either: while it would be
>> possible in theory for a client to implement/understand only part of
>> an extension, such that a response with a subset of the available
>> identifiers could be processed without having to go to the trouble of
>> implementing/understanding the whole extension, that doesn't seem like
>> something that would come up much in practice, given that most
>> extensions are quite short/straightforward.  What do you think?
> 
> Think it would be good to involve the WG in the diiscussion.
> Literally RFC 9083 states that only the identifiers of those
> extensions used in building a response can be included in the
> rdapConformance array.
> 
> Have always thought that its purpose was to inform clients about the
> extension prefixes they should be ready to recognize when
> deserializing the response.

I'm not sure that it's limited to extension prefixes for the purposes
of deserialisation only.  For example, the core extension identifier
for the NRO RDAP profile (i.e. nro_rdap_profile_0) is not used as a
prefix for any response fields, but is still included in most
responses from a server that implements that profile, since the
behaviour defined there affects how the response is
constructed/interpreted.

> For this reason, including in the rdapConformance array an extension
> identifier that is not used in the response could be misleading for
> clients.
> 
> Besides, mentioning in rdapConformance only the extensions used in
> the response doesn't mean that either the server or the client can
> have a partial knowledge of the specification defining them.

It's at least possible to imagine a scenario where this is the case,
even if it may be unlikely to happen in practice.  Under the approach
you have set out, a specification that defines two or more extension
identifiers needs to describe when those extension identifiers should
be included in responses.  If one identifier is used for behaviour
that is specific to that identifier and isolated from the behaviour
for the other identifiers, then the server may opt to support only
that behaviour, and a client may similarly be written such that it
understands only that behaviour from the specification.  (This is not
a problem of itself, it's just that it's the only benefit that I can
see that comes from using that approach.)

> Otherwise wouldn't understand the need to distinguish between the
> rdapConformance value in the help response and that in the other
> responses.

To avoid any doubt here, under our approach a response would not
include the identifiers for an extension if that extension was
unrelated to the response.  For example, in the RIR search case, a
server that (e.g.) did not include relation links in IP responses
would omit the identifiers for the RIR search extension from those
responses.  The help response still serves the same purpose as before
when using this approach.

-Tom

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

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Tom Harrison]

Hi James,

On Fri, Jan 26, 2024 at 01:21:05PM +, Gould, James wrote:
> Thanks for making the drafts updates.  I will do a detailed review
> of the updated draft.  
> 
> For the "..." convention, we had to explicitly define it in RFC 8334
> with " The use of "..." is used as shorthand for elements defined
> outside this document.".  I believe that was based on feedback from
> the IESG.  It's something to consider as the document proceeds.

Thanks for this.  Similar text has now been added and will be included
in the next submission.

-Tom

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

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Andrew Newton]

Thanks Tom. Looks good to me.

-andy

On Thu, Jan 25, 2024 at 10:28 PM Tom Harrison  wrote:
>
> Hi Andy,
>
> Thanks for your feedback.
>
> On Thu, Dec 07, 2023 at 02:55:21PM -0500, Andy Newton wrote:
> > 1. The elidation in figure 2 (section 3.4) should be pointed out. At
> > first I mistook the hrefs as some sort of relative URLs.
>
> These have been updated to use concrete URLs now.
>
> > 2. It would be helpful if section 4 noted that the object instances
> > returned in the arrays are defined in RFC 9083. IMHO, the beginning
> > words of "As with RFC 9083" don't make that clear.
>
> This has been updated.
>
> > 3. Perhaps this is beyond the scope of the draft, but is the intent to
> > have the links for up/down/bottom/top be placed in responses for IP
> > and autumn lookups as well?
>
> Yep, that's right.  The intent here is that each object will include
> at most one link for each type of relation, and each link will be
> relative to the object itself, per the example in section 3.4.  (It's
> not mandatory that these links be included in all objects, either.)
>
> > And using the example tree in figure 1, if a search of
> > /ips/rirSearch1/up/192.0.2.0/25 returns 192.0.2.0/24, would that
> > returned object then have all the child and bottom links in that
> > tree?
>
> It would have a single child link and a single bottom link.  The child
> link href would resolve to a search that returned 192.0.2.0/25 and
> 192.0.2.128/25, while the bottom link href would resolve to a search
> that returned 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32,
> 192.0.2.128/26, and 192.0.2.192/26.
>
> > 4. It took me some time to figure out the purpose of the rirSearch1
> > extension identifier (it's because of /domains in RFC 9083).
>
> That's true.  It's also present in order to facilitate future updates
> (by incrementing the number at the end of the identifier).
>
> > Considering this document registers 5 extension identifiers, this
> > draft presents the use case for allowing IETF extensions to forgo
> > the need of using identifier prefixes if there is a good reason.
> > That said, have you considered registering one extension identifier
> > and using a prefix because "rirSearch1" appears in all paths and
> > ruins the aesthetic symmetry with 9083 anyway? Something like "rs1"
> > for RIR Search 1 and then paths of /rs1_autnums/..., /rs1_ips/...,
> > and /rs1_domains/...
>
> The paths for the basic searches do not include rirSearch1, which
> means that their forms are consistent with those from 9082/9083.  On
> the more general question: if we rely on a single identifier only,
> then that means that the reverse search definitions end up with
> "searchable resource type" values like "rs1_ips" and "rs1_autnums".
> Apart from being confusing, given the reverse search document's
> definition of corresponding unprefixed "related resource type" values
> and use of unprefixed "searchable resource type" values for the other
> object classes, it also means that the search definitions would need
> to be updated whenever a new version of the RIR search document was
> completed.  Although using multiple identifiers comes with its own
> costs, we think the benefits outweigh those costs here.
>
> -Tom

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

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Gould, James]

Tom,

Thanks for making the drafts updates.  I will do a detailed review of the 
updated draft.  

For the "..." convention, we had to explicitly define it in RFC 8334 with " The 
use of "..." is used as shorthand for elements defined outside this document.". 
 I believe that was based on feedback from the IESG.  It's something to 
consider as the document proceeds.  

Thanks,

-- 

JG 



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


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

Verisign.com  




On 1/25/24, 10:32 PM, "Tom Harrison" mailto:t...@apnic.net>> 
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. 


Hi James,


Thanks for your feedback. Comments on non-nits inline:


On Mon, Dec 11, 2023 at 08:21:57PM +, Gould, James wrote:
> I did my review of draft-ietf-regext-rdap-rir-search-05, and below
> is my primarily editorial feedback:
> 
> 1. Section 1.1 “Requirements Language”
> * Recommend make this Section 2 “Conventions Used in This
> Document” for consistency with the RDAP RFCs.


This has been updated.


> I also recommend defining the convention of using the ‘*’ to
> support the partial string searching specified in Section 4.1
> of RFC9082.


This has been added to section 2.1 (Basic Searches -> Path Segments),
since it's specific to the basic searches.


> 2. Section 2.1 “Path Segments”
> * I would use the term “semantics” instead of “logic”.
> Section 3.2 of RFC9082 does reference Section 4.1 of RFC9082,
> but I still believe it’s best to explicitly define the use of
> partial string searching in the “Conventions Used in this
> Document” section.


Since the search paths are defined more fully in the subsequent
sections anyway, this sentence has now been omitted (missed in the
-06 submission, but will include it in the next one). 


> 4. Section 3.1 “Path Segments”
> * It would be helpful to define the variables in the path segments with the 
> relevant references, such as:
> 
> i. The variables used in the path segments include:
> 
> * : The type of relation defined in Section 3.2.2
> * : IP Address defined in Section 3.1.1 of RFC9082
> * : CIDR block defined in Section 3.1.1 of RFC9082
> * : Prefix length defined in Section 3.1.1 of RFC9082
> * : Fully qualified domain name defined in Section 3.1.3 of 
> RFC9082
> *  - Should this be  number> or  with the following definitions?
> * : Autonomous system number defined in Section 
> 3.1.2 of RFC9082.
> * : Unclear what the appropriate reference is for 
> the , where autonomous system ranges are referenced 
> in Section 3.2.1.


This section has been updated along the lines of the above text.
"autonomous system number or range" was preserved, since both should
be supported, but a definition for the syntax for a range has now been
added.


> 1. Section 3.2 “Relation Search”
> * It would help to define the variables in the search path.
> * My assumption is that the  matches the values in Section 3.2.2.
> * What is the definition of ?


We were going to add this, but it doesn't seem to add much, given the
updates to section 3.1 above, so we've left it as-is.


> * : Either “active” or “inactive” defined in Section 3.2.


We don't intend to limit the status to "active" or "inactive", but
more to the point, section 3.3 covers off on status in some detail, so
we're not sure about adding this extra text in.


> 2. Section 3.2.1 “Definitions”
> * I would expand INR as in Internet Number Resource (INR) in
> the first reference.


This has been updated.


> 3. Section 3.2.2 “Relations”
> * I recommend using double quotes for the titles of each of
> the sub-sections, since the relations are literals.


This has been updated.


> 4. Section 3.3 “Status”
> * Are the supported status values “active” and “inactive”?


All statuses should be supported, but servers can opt to limit their
support to the "active" status on "up"/"top" relations only, if they
prefer. The text has now been updated to suit.


> 5. Section 3.4 “Link Relations”
> * “The response returned by a server when fetching the link
> target for a link within an RDAP object with one of those link
> relations MUST be the same response that would be returned for
> the corresponding search.” Is hard to follow and I recommend
> rewording it. Maybe it’s too many references to the word
> “link”.


Updated text:


When constructing these link objects, the server MUST set link
targets that yield the same response as for the corresponding
search.


> * Can “top-active” and “up-active” also be used for
>  values? It looks like that is the case based on the
> Link Relations Registry entries, but the values are somewhat
> embedded in the text.


They can be used in this way. The existing text on this point appears
clear to us:


Two additional link relations are defined that
correspond to relation searches with a "status" of
"active": "top-active

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Mario Loffredo]

Hi Tom,

please find my comment below.

Il 26/01/2024 04:29, Tom Harrison ha scritto:

Hi Mario,

Thanks for your feedback.

On Thu, Nov 30, 2023 at 08:21:42AM +0100, Mario Loffredo wrote:

+1

Have just two further notes:

1) Think it would be good to add normative language about partial
matching referencing Section 4.1 of RFC 9082 .

Thanks, this has been added.


2) Per what is stated in section 4.1 0f RFC9083, the rdapConformance
array in the examples Section 4 should include only the extensions
used in the response.
For sure the response including the ipSearchResults array will never
include the autnumSearchResults array and viceversa ;-)
The same goes for the responses including the links about ips or
autnums.  Instead, the help response should include all the
extensions implemented.  As a result of this,  the first two
paragraphs of Section 6 should be modified as well.

We think that the existing text/behaviour should be left as-is in this
respect.  Section 4.1 of 9083 says:

 A response to a "help" request will include identifiers for all of
 the specifications supported by the server.  A response to any
 other request will include only identifiers for the specifications
 used in the construction of the response.

and that any response which makes use of any part of the RIR search
specification should therefore include all of the identifiers defined
by the RIR search specification, since each of those identifiers will
be "for [one of] the specifications used in the construction of the
response".  An alternative reading along the lines of your suggestion
would require associating identifiers with specific functionality in
the document.  While that's relatively straightforward in this case,
it would require extra, possibly unintuitive guidance in the document
as to when identifiers should be included.  It's also not clear that
it yields much benefit for the client, either: while it would be
possible in theory for a client to implement/understand only part of
an extension, such that a response with a subset of the available
identifiers could be processed without having to go to the trouble of
implementing/understanding the whole extension, that doesn't seem like
something that would come up much in practice, given that most
extensions are quite short/straightforward.  What do you think?



Think it would be good to involve the WG in the diiscussion. Literally 
RFC 9083 states that only the identifiers of those extensions used in 
building a response can be included in the rdapConformance array.


Have always thought that its purpose was to inform clients about the 
extension prefixes they should be ready to recognize when deserializing 
the response.


For this reason, including in the rdapConformance array an extension 
identifier that is not used in the response could be misleading for 
clients.


Besides, mentioning in rdapConformance only the extensions used in the 
response doesn't mean that either the server or the client can have a 
partial knowledge of the specification defining them.


Otherwise wouldn't understand the need to distinguish between the 
rdapConformance value in the help response and that in the other responses.


But my interpretation might be too restrictive as well as yours might be 
too permissive. Better to listen to other opinions and finally agree on 
a shared interpretation.



Best,

Mario



-Tom

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


--
Dott. Mario Loffredo
Senior Technologist
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] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Tom Harrison]

Hi James,

Thanks for your feedback.  Comments on non-nits inline:

On Mon, Dec 11, 2023 at 08:21:57PM +, Gould, James wrote:
> I did my review of draft-ietf-regext-rdap-rir-search-05, and below
> is my primarily editorial feedback:
> 
>   1.  Section 1.1 “Requirements Language”
>  *   Recommend make this Section 2 “Conventions Used in This
>  Document” for consistency with the RDAP RFCs.

This has been updated.

>  I also recommend defining the convention of using the ‘*’ to
>  support the partial string searching specified in Section 4.1
>  of RFC9082.

This has been added to section 2.1 (Basic Searches -> Path Segments),
since it's specific to the basic searches.

>   2.  Section 2.1 “Path Segments”
>  *   I would use the term “semantics” instead of “logic”.
>  Section 3.2 of RFC9082 does reference Section 4.1 of RFC9082,
>  but I still believe it’s best to explicitly define the use of
>  partial string searching in the “Conventions Used in this
>  Document” section.

Since the search paths are defined more fully in the subsequent
sections anyway, this sentence has now been omitted (missed in the
-06 submission, but will include it in the next one). 

>   4.  Section 3.1 “Path Segments”
>  *   It would be helpful to define the variables in the path segments 
> with the relevant references, such as:
> 
>   i.  The variables used in the path segments include:
> 
>*   : The type of relation defined in Section 3.2.2
>*   : IP Address defined in Section 3.1.1 of RFC9082
>*   : CIDR block defined in Section 3.1.1 of RFC9082
>*   : Prefix length defined in Section 3.1.1 of 
> RFC9082
>*   : Fully qualified domain name defined in Section 
> 3.1.3 of RFC9082
>*- Should this be 
>  or  with the following 
> definitions?
>   *   : Autonomous system number 
> defined in Section 3.1.2 of RFC9082.
>   *   :  Unclear what the appropriate 
> reference is for the , where autonomous system 
> ranges are referenced in Section 3.2.1.

This section has been updated along the lines of the above text.
"autonomous system number or range" was preserved, since both should
be supported, but a definition for the syntax for a range has now been
added.

>   1.  Section 3.2 “Relation Search”
>  *   It would help to define the variables in the search path.
>  *   My assumption is that the  matches the values in Section 
> 3.2.2.
>  *   What is the definition of ?

We were going to add this, but it doesn't seem to add much, given the
updates to section 3.1 above, so we've left it as-is.

>  *   : Either “active” or “inactive” defined in Section 3.2.

We don't intend to limit the status to "active" or "inactive", but
more to the point, section 3.3 covers off on status in some detail, so
we're not sure about adding this extra text in.

>   2.  Section 3.2.1 “Definitions”
>  *   I would expand INR as in Internet Number Resource (INR) in
>  the first reference.

This has been updated.

>   3.  Section 3.2.2 “Relations”
>  *   I recommend using double quotes for the titles of each of
>  the sub-sections, since the relations are literals.

This has been updated.

>   4.  Section 3.3 “Status”
>  *   Are the supported status values “active” and “inactive”?

All statuses should be supported, but servers can opt to limit their
support to the "active" status on "up"/"top" relations only, if they
prefer.  The text has now been updated to suit.

>   5.  Section 3.4 “Link Relations”
>  *   “The response returned by a server when fetching the link
>  target for a link within an RDAP object with one of those link
>  relations MUST be the same response that would be returned for
>  the corresponding search.” Is hard to follow and I recommend
>  rewording it.  Maybe it’s too many references to the word
>  “link”.

Updated text:

When constructing these link objects, the server MUST set link
targets that yield the same response as for the corresponding
search.

>  *   Can “top-active” and “up-active” also be used for
>   values?  It looks like that is the case based on the
>  Link Relations Registry entries, but the values are somewhat
>  embedded in the text.

They can be used in this way.  The existing text on this point appears
clear to us:

Two additional link relations are defined that
correspond to relation searches with a "status" of
"active": "top-active" and "up-active".

>  *   “The equivalent link relations for "down" and "bottom" are
>  not defined, because it is not expected that they will be
>  used.” Is not clear.  I recommend removing it or clarifying why
>  it is not expected to be used.

Updated text:

Two additional link relations are defined that
correspond to relation searches with a "status" of
"active": "top-active" and "up-active".  No other
status

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Tom Harrison]

Hi Mario,

Thanks for your feedback.

On Thu, Nov 30, 2023 at 08:21:42AM +0100, Mario Loffredo wrote:
> +1
> 
> Have just two further notes:
> 
> 1) Think it would be good to add normative language about partial
> matching referencing Section 4.1 of RFC 9082 .

Thanks, this has been added.

> 2) Per what is stated in section 4.1 0f RFC9083, the rdapConformance
> array in the examples Section 4 should include only the extensions
> used in the response.
> For sure the response including the ipSearchResults array will never
> include the autnumSearchResults array and viceversa ;-)
> The same goes for the responses including the links about ips or
> autnums.  Instead, the help response should include all the
> extensions implemented.  As a result of this,  the first two
> paragraphs of Section 6 should be modified as well.

We think that the existing text/behaviour should be left as-is in this
respect.  Section 4.1 of 9083 says:

A response to a "help" request will include identifiers for all of
the specifications supported by the server.  A response to any
other request will include only identifiers for the specifications
used in the construction of the response.

and that any response which makes use of any part of the RIR search
specification should therefore include all of the identifiers defined
by the RIR search specification, since each of those identifiers will
be "for [one of] the specifications used in the construction of the
response".  An alternative reading along the lines of your suggestion
would require associating identifiers with specific functionality in
the document.  While that's relatively straightforward in this case,
it would require extra, possibly unintuitive guidance in the document
as to when identifiers should be included.  It's also not clear that
it yields much benefit for the client, either: while it would be
possible in theory for a client to implement/understand only part of
an extension, such that a response with a subset of the available
identifiers could be processed without having to go to the trouble of
implementing/understanding the whole extension, that doesn't seem like
something that would come up much in practice, given that most
extensions are quite short/straightforward.  What do you think?

-Tom

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

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Tom Harrison]

Hi Andy,

Thanks for your feedback.

On Thu, Dec 07, 2023 at 02:55:21PM -0500, Andy Newton wrote:
> 1. The elidation in figure 2 (section 3.4) should be pointed out. At
> first I mistook the hrefs as some sort of relative URLs.

These have been updated to use concrete URLs now.

> 2. It would be helpful if section 4 noted that the object instances
> returned in the arrays are defined in RFC 9083. IMHO, the beginning
> words of "As with RFC 9083" don't make that clear.

This has been updated.

> 3. Perhaps this is beyond the scope of the draft, but is the intent to
> have the links for up/down/bottom/top be placed in responses for IP
> and autumn lookups as well?

Yep, that's right.  The intent here is that each object will include
at most one link for each type of relation, and each link will be
relative to the object itself, per the example in section 3.4.  (It's
not mandatory that these links be included in all objects, either.)

> And using the example tree in figure 1, if a search of
> /ips/rirSearch1/up/192.0.2.0/25 returns 192.0.2.0/24, would that
> returned object then have all the child and bottom links in that
> tree?

It would have a single child link and a single bottom link.  The child
link href would resolve to a search that returned 192.0.2.0/25 and
192.0.2.128/25, while the bottom link href would resolve to a search
that returned 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32,
192.0.2.128/26, and 192.0.2.192/26.

> 4. It took me some time to figure out the purpose of the rirSearch1
> extension identifier (it's because of /domains in RFC 9083).

That's true.  It's also present in order to facilitate future updates
(by incrementing the number at the end of the identifier).

> Considering this document registers 5 extension identifiers, this
> draft presents the use case for allowing IETF extensions to forgo
> the need of using identifier prefixes if there is a good reason.
> That said, have you considered registering one extension identifier
> and using a prefix because "rirSearch1" appears in all paths and
> ruins the aesthetic symmetry with 9083 anyway? Something like "rs1"
> for RIR Search 1 and then paths of /rs1_autnums/..., /rs1_ips/...,
> and /rs1_domains/...

The paths for the basic searches do not include rirSearch1, which
means that their forms are consistent with those from 9082/9083.  On
the more general question: if we rely on a single identifier only,
then that means that the reverse search definitions end up with
"searchable resource type" values like "rs1_ips" and "rs1_autnums".
Apart from being confusing, given the reverse search document's
definition of corresponding unprefixed "related resource type" values
and use of unprefixed "searchable resource type" values for the other
object classes, it also means that the search definitions would need
to be updated whenever a new version of the RIR search document was
completed.  Although using multiple identifiers comes with its own
costs, we think the benefits outweigh those costs here.

-Tom

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

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Gould, James]

Antoin,



I did my review of draft-ietf-regext-rdap-rir-search-05, and below is my 
primarily editorial feedback:



  1.  Section 1.1 “Requirements Language”
 *   Recommend make this Section 2 “Conventions Used in This Document” for 
consistency with the RDAP RFCs.  I also recommend defining the convention of 
using the ‘*’ to support the partial string searching specified in Section 4.1 
of RFC9082.
  2.  Section 2.1 “Path Segments”
 *   I would use the term “semantics” instead of “logic”.  Section 3.2 of 
RFC9082 does reference Section 4.1 of RFC9082, but I still believe it’s best to 
explicitly define the use of partial string searching in the “Conventions Used 
in this Document” section.
  3.  Section 3 “Relation Searches”
 *   Nit - Shorten “in order to” to “to”
  4.  Section 3.1 “Path Segments”
 *   It would be helpful to define the variables in the path segments with 
the relevant references, such as:

   i.  The 
variables used in the path segments include:

   *   : The type of relation defined in Section 3.2.2
   *   : IP Address defined in Section 3.1.1 of RFC9082
   *   : CIDR block defined in Section 3.1.1 of RFC9082
   *   : Prefix length defined in Section 3.1.1 of RFC9082
   *   : Fully qualified domain name defined in Section 
3.1.3 of RFC9082
   *- Should this be  or  with the following definitions?
  *   : Autonomous system number defined 
in Section 3.1.2 of RFC9082.
  *   :  Unclear what the appropriate 
reference is for the , where autonomous system ranges 
are referenced in Section 3.2.1.
  1.  Section 3.2 “Relation Search”
 *   It would help to define the variables in the search path.
 *   My assumption is that the  matches the values in Section 
3.2.2.
 *   What is the definition of ?
 *   : Either “active” or “inactive” defined in Section 3.2.
  2.  Section 3.2.1 “Definitions”
 *   I would expand INR as in Internet Number Resource (INR) in the first 
reference.
 *   Nit – Change “a most-specific object” to “the most-specific object”
  3.  Section 3.2.2 “Relations”
 *   I recommend using double quotes for the titles of each of the 
sub-sections, since the relations are literals.
  4.  Section 3.3 “Status”
 *   Are the supported status values “active” and “inactive”?
  5.  Section 3.4 “Link Relations”
 *   “The response returned by a server when fetching the link target for a 
link within an RDAP object with one of those link relations MUST be the same 
response that would be returned for the corresponding search.” Is hard to 
follow and I recommend rewording it.  Maybe it’s too many references to the 
word “link”.
 *   Can “top-active” and “up-active” also be used for  values?  
It looks like that is the case based on the Link Relations Registry entries, 
but the values are somewhat embedded in the text.
 *   “The equivalent link relations for "down" and "bottom" are not 
defined, because it is not expected that they will be used.” Is not clear.  I 
recommend removing it or clarifying why it is not expected to be used.
 *   “…for the RDAP INR context only, though, and in that context it does 
not conflict with the current description of that link relation” sentence 
fragment is hard to follow.  There is a reference to the RDAP INR context and 
then there is a reference to “that context” and “current description”, which 
are not clearly defined.
  6.  Section 4 “Responding To Searches”
 *   “for /ips searches, the array is "ipSearchResults"” can provide 
additional detail, such as “for /ips searches, the array is "ipSearchResults" 
of “ip network” objects, defined in Section 5.4 of RFC9083.
 *   “for /autnums searches, the array is "autnumSearchResults"” can 
provide additional detail, such as “for /autnums searches, the array is 
"autnumSearchResults" of “atnum” objects, defined in Section 5.5 of RFC9083.
 *   The “rirSearch1”, “ips”, and “autnums” extension identifiers don’t 
need to be in the sample rdapConformance, since they are not included in the 
response.
 *   The “,…” could be removed from the sample rdapConformance unless the 
use of ,…” is included in the “Conventions Used in This Document”
 *   Nit – “is able to” can be replaced with “can”.
  7.  Section 6 “RDAP Conformance”
 *   "rirSearch1", "ips", "autnums" can be removed from the rdapConformance 
since they are path segment extensions and not included in the response.



Thanks,



--



JG







James Gould

Fellow Engineer

jgo...@verisign.com 




703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 









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





Caution: This email originated from outside the orga

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Antoin Verschuren]

Reminder,

This WGLC will end tonight. So far we only had 3 notifications of support. (And 
a comment from the document shepherd)
Please indicate your support if you didn’t already do so for us to judge 
consensus.

Regards,

Your co-chairs Jim and Antoin


> Op 27 nov. 2023, om 15:51 heeft Antoin Verschuren 
>  het volgende geschreven:
> 
> 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:
> 
> 
> RDAP RIR Search
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/05/
> 
> 
> 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, 11 December 2023.  
> 
> If there are no objections the document will be submitted to the IESG.
> 
> The Document Shepherd for this document is Mario Loffredo.
> 
> 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] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Andrew Newton]

This is a great draft, and I'm glad that this work is going forward. I
do have a few comments.

1. The elidation in figure 2 (section 3.4) should be pointed out. At
first I mistook the hrefs as some sort of relative URLs.

2. It would be helpful if section 4 noted that the object instances
returned in the arrays are defined in RFC 9083. IMHO, the beginning
words of "As with RFC 9083" don't make that clear.

3. Perhaps this is beyond the scope of the draft, but is the intent to
have the links for up/down/bottom/top be placed in responses for IP
and autumn lookups as well? And using the example tree in figure 1, if
a search of /ips/rirSearch1/up/192.0.2.0/25 returns 192.0.2.0/24,
would that returned object then have all the child and bottom links in
that tree?

4. It took me some time to figure out the purpose of the rirSearch1
extension identifier (it's because of /domains in RFC 9083).
Considering this document registers 5 extension identifiers, this
draft presents the use case for allowing IETF extensions to forgo the
need of using identifier prefixes if there is a good reason. That
said, have you considered registering one extension identifier and
using a prefix because "rirSearch1" appears in all paths and ruins the
aesthetic symmetry with 9083 anyway? Something like "rs1" for RIR
Search 1 and then paths of /rs1_autnums/..., /rs1_ips/..., and
/rs1_domains/...

-andy


On Mon, Nov 27, 2023 at 9:51 AM 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:
>
>
> RDAP RIR Search
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/05/
>
>
> 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, 11 December 2023.
>
> If there are no objections the document will be submitted to the IESG.
>
> The Document Shepherd for this document is Mario Loffredo.
>
> 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] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Mario Loffredo]

+1

Have just two further notes:

1) Think it would be good to add normative language about partial 
matching referencing Section 4.1 of RFC 9082 .


2) Per what is stated in section 4.1 0f RFC9083, the rdapConformance 
array in the examples Section 4 should include only the extensions used 
in the response.
For sure the response including the ipSearchResults array will never 
include the autnumSearchResults array and viceversa ;-)

The same goes for the responses including the links about ips or autnums.
Instead, the help response should include all the extensions implemented.
As a result of this,  the first two paragraphs of Section 6 should be 
modified as well.



Best,

Mario


Il 27/11/2023 15:51, 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:


RDAP RIR Search
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/05/


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, 11 December 2023.

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

The Document Shepherd for this document is Mario Loffredo.

Thanks,

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


--
Dott. Mario Loffredo
Senior Technologist
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] WG LAST CALL draft-ietf-regext-rdap-rir-search

[Hollenbeck, Scott]

+1

Scott

> -Original Message-
> From: regext  On Behalf Of Antoin Verschuren
> Sent: Monday, November 27, 2023 9:51 AM
> To: regext 
> Subject: [EXTERNAL] [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search
>
> 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:
>
>
> RDAP RIR Search
> https://secure-
> web.cisco.com/1UuxfbolW7YXzDgcyZ_2FpBDirrNeF581vVQQ8tgGs-
> glduthYeR_V3X6bHileUO49Qby7YgpAWW_7LHLTIuKfNJjnNU4X7hMXCwNu0
> QLdF8S3Bihgh_2r_1zpmpX3Pg3md8kgGd81m4hhATrjO9CoD-
> kKZrvFzT1RisSFYw_uqK8cH2rCRzdKOJVk5tRiMFimWJBwqtLjIHsitxGTt4-
> W6LI_OY-UntBOsj3oyrI0v_ItWZx-i91hZ-OJ_5ykyzK89hYj-
> eJnCLd_8Oo__1hrW7dIhhPMBHvBXAfS2ywU8Y/https%3A%2F%2Fdatatrack
> er.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-rir-search%2F05%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, 11 December 2023.
>
> If there are no objections the document will be submitted to the IESG.
>
> The Document Shepherd for this document is Mario Loffredo.
>
> Thanks,
>
> Jim and Antoin
> REGEXT WG Co-Chairs
> ___
> regext mailing list
> regext@ietf.org
> https://secure-web.cisco.com/1oE-9tv7XuS7DVQ37QycaphgMSZQ7ZNwyN-
> aEl9wFkEakZu1akC4sQfA1H4WSnJ-AuIThUqMihwvlq51HeLlX7IwN5kK-
> t3PrbiAeVXyI2SkW0NxSJ8yeUfQeq_sHChtgDfG5JIFgknFojnE4HA6heMrusWa
> T7vuKht-nwMlli0rZV8aplYZn5l-ITjld4VHCMc8Iw1EN7QzmqK_z5zuSM3nfqk5-
> Eb5QPoQkpANPAywF07MkPCaQk5cXqq80uv6dYfkFnmw0t1981CvQQ1NK3kU
> c-
> 27eTjFHrLbfN5z2k7E/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo
> %2Fregext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

[George Michaelson]

+1

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

[regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

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


RDAP RIR Search
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/05/


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, 11 December 2023.  

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

The Document Shepherd for this document is Mario Loffredo.

Thanks,

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