Subject: [regext] IANA Considerations in draft-ietf-regext-rdap-reverse-search

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 31 Jul 2020 12:29:29 +0000

draft-ietf-regext-rdap-reverse-search currently states that "This document has no actions for IANA".  I believe that's primarily because there's nothing new or different being returned in the search results, which is where RDAP servers describe the features they support. There is, however, a case to be made for registering a value in the RDAP extensions registry: a response to a help query (or any other query) can be used to indicate that the server supports reverse search. I'd like to suggest this change for Section 7:

OLD:
This document has no actions for IANA.

NEW:
IANA is requested to register the following value in the RDAP Extensions Registry:

Extension identifier: reverse_search_1_0 (or whatever makes sense)
Registry operator: Any
Published specification: This document.
Contact: IESG <[email-masked]>
Intended usage: This extension describes reverse search query patterns for RDAP.

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 31 Jul 2020 15:02:40 +0200

Hi Scott,

thanks a lot for your feddback.

Please find my comments to your feedback below.

Il 31/07/2020 14:29, Hollenbeck, Scott ha scritto:
> draft-ietf-regext-rdap-reverse-search currently states that "This document has no actions for IANA".  I believe that's primarily because there's nothing new or different being returned in the search results, which is where RDAP servers describe the features they support.
Exactly.
> There is, however, a case to be made for registering a value in the RDAP extensions registry: a response to a help query (or any other query) can be used to indicate that the server supports reverse search. I'd like to suggest this change for Section 7:
>
> OLD:

I agree.

Furthermore, my opinion is that Section 4.1 of RFC7483bis should be 
updated to treat this use case. I mean, a server should signal in 
rdapConformance not only the extensions used in building the response 
but all the supported features.

Best,

Mario

>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

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

---

From: George Michaelson <[email-masked]>
Date: Fri, 31 Jul 2020 23:08:09 +1000

My understanding of the sense of the room, is that it is beholden on
the numbers space to construct words for Security Considerations which
address the _problem statement_ inherent in privacy and security, Not
to specify fixes, but to document the issues and the sense Jim Reid
brought into the room was to advise operators to factor their
local/national/jurisdictional law into this, and respect it.

-G

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 31 Jul 2020 13:21:27 +0000

> -----Original Message-----
> From: Mario Loffredo <[email-masked]>
> Sent: Friday, July 31, 2020 9:03 AM
> To: Hollenbeck, Scott <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Re: [regext] IANA Considerations in draft-ietf-regext-
> rdap-reverse-search
>
> Hi Scott,
>
> > draft-ietf-regext-rdap-reverse-search currently states that "This document
> has no actions for IANA".  I believe that's primarily because there's nothing
> new or different being returned in the search results, which is where RDAP
> servers describe the features they support.
> Exactly.
> > There is, however, a case to be made for registering a value in the RDAP
> extensions registry: a response to a help query (or any other query) can be
> used to indicate that the server supports reverse search. I'd like to suggest
> this change for Section 7:
> >
> > OLD:
> > Registry operator: Any Published specification: This document.
> Furthermore, my opinion is that Section 4.1 of RFC7483bis should be updated
> to treat this use case. I mean, a server should signal in rdapConformance not
> only the extensions used in building the response but all the supported
> features.

So maybe this?

OLD:
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.

NEW:
The data structure named "rdapConformance" is an array of strings, each providing a hint as to the specifications that describe the query and response formats supported by the server.

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 31 Jul 2020 15:48:39 +0200

Hi Scott,

> The data structure named "rdapConformance" is an array of strings, each providing a hint as to the specifications that describe the query and response formats supported by the server.

How about "query and response extensions" ?

Mario

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 31 Jul 2020 14:10:34 +0000

> Sent: Friday, July 31, 2020 9:49 AM
> >> Subject: [EXTERNAL] Re: [regext] IANA Considerations in
> >> draft-ietf-regext- rdap-reverse-search
> >>
> >> Hi Scott,
> >>
> >> has no actions for IANA".  I believe that's primarily because there's
> >> nothing new or different being returned in the search results, which
> >> is where RDAP servers describe the features they support.
> >> Exactly.
> >> extensions registry: a response to a help query (or any other query)
> >> can be used to indicate that the server supports reverse search. I'd
> >> like to suggest this change for Section 7:
> >>> OLD:
> >>> IANA is requested to register the following value in the RDAP
> >>> Extensions
> >> Registry:
> >>> Intended usage: This extension describes reverse search query
> >>> patterns
> >> for RDAP.
> >>> Scott
> >> I agree.
> >>
> > 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.
> >
> > NEW:
> > The data structure named "rdapConformance" is an array of strings, each
> providing a hint as to the specifications that describe the query and response
> formats supported by the server.
> >
> > Scott
>

That would exclude the core protocol specifications. Is this better?

"The data structure named "rdapConformance" is an array of strings, each of which describes a query or response specification supported by the server."

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 31 Jul 2020 16:25:01 +0200

> "The data structure named "rdapConformance" is an array of strings, each of which describes a query or response specification supported by the server."

OK. I wrote "extensions" in my previous message to mean "in addition to 
rdap_level_0".

Mario

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 31 Jul 2020 09:33:49 -0500

> but all the supported features.

I am not sure to agree.

A server could advertise everything it supports in some reply to an help query
or another one that could be created, as a generic advertisement of features.

But I believe a specific reply (message) should just list what pertains to this specific reply.

Considering that, in the future, for the same query, the reply can be different based on the client and its level of access.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Jasdip Singh <[email-masked]>
Date: Fri, 31 Jul 2020 14:35:22 +0000

IMHO, the current wording in 7843bis seems clear enough, especially the phrase "specifications used in the construction of the response." It is about what specifications were used for the returned response. No?

Jasdip

On 7/31/20, 10:28 AM, "regext on behalf of Mario Loffredo" <[email-masked] on behalf of [email-masked]> wrote:

    
    Mario

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 31 Jul 2020 16:34:12 +0200

Hi George,

thanks for your feedback.

> local/national/jurisdictional law into this, and respect it.

Honestly, being involved in the management of a ccTLD, I'm not so 
experienced in the specific issues related to the numbers space. This is 
the reason why the "Privacy Considerations" section is mostly tailored 
to the namespace.

Obviously, any suggestion to make privacy and security considerations 
more comprehensive is welcome.

Best,

Mario.

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 31 Jul 2020 17:35:51 +0200

Hi Patrick,

> Considering that, in the future, for the same query, the reply can be different based on the client and its level of access.
The server might inlcude in rdapConformance either the hints to all the 
supported features or the only hints to the features allowed to the 
consumer.

This also applies to the help response. Definitively, it's a matter of 
server policy.

Mario

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 31 Jul 2020 10:51:09 -0500

> This also applies to the help response. Definitively, it's a matter of 

If you introduce options (the list is either related to the content OR the full list of server features), how is a client supposed to know in which case he is? He can't right now,
which is why I don't think such options should be added.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 31 Jul 2020 16:21:20 +0000

> From: regext <[email-masked]> On Behalf Of Patrick Mevzek
> Sent: Friday, July 31, 2020 11:51 AM
> To: [email-masked]
> > The server might inlcude in rdapConformance either the hints to all
> > the supported features or the only hints to the features allowed to
> > the consumer.
> >
> If you introduce options (the list is either related to the content OR the full
> list of server features), how is a client supposed to know in which case he is?
> He can't right now, which is why I don't think such options should be added.

As it's currently written, 7482bis says this about the help query:

"The help path segment can be used to request helpful information (command syntax, terms of service, privacy policy, rate-limiting policy, supported authentication methods, supported extensions, technical support contact, etc.) from an RDAP server.  The response to "help" should provide basic information that a client needs to successfully use the service."

Note "supported extensions". This is why I'm saying that we need to register all extensions with IANA and include them in the rdapConformance data structure even if they don't describe a response extension. To Patrick's question above, I think it's a good idea to be consistent about it. The help response should include supported extensions that are available to that client. Note, though, that the list of supported extensions might vary if the client is identified and authenticated. In that case, some clients MAY have access to extensions that other clients don't.

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 31 Jul 2020 18:18:20 +0200

Hi Jasdip,

> IMHO, the current wording in 7843bis seems clear enough, especially the phrase "specifications used in the construction of the response." It is about what specifications were used for the returned…

In my opinion, the sentence "specifications used in the construction of 
the response" seems to be limited to those specifications introducing 
some response extensions or complying the response with a specific 
profile. The current reverse search proposal affects only the query 
formats.

Cheers,

Mario

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 31 Jul 2020 11:28:43 -0500

On Fri, Jul 31, 2020, at 11:21, Hollenbeck, Scott wrote:
> Note "supported extensions". This is why I'm saying that we need to 
> register all extensions with IANA

I agree.

> and include them in the 
> rdapConformance data structure even if they don't describe a response 
> extension. 

I agree, everything should be listed in the reply to an help query.

I am just saying that for any other reply that is a specific one on a specific resource
then the rdapConformance should just list the "extensions" needed to understand this
specific response, and not list absolutely all extensions the server knows about
(and that are irrelevant for this specific response).

The list of what is written in the response should certainly not be just server policy,
especially if there is no automated way to learn about this policy. Otherwise if you include
options like that (the list presented might be the list of all server extensions OR only the subset needed for this specific response) AND there is no way for the client to know which
case he is in, it immediately creates interoperability problems. I prefer no such options
and the protocol clearly defining the content. Or if such options are really needed
(if help response is always all extensions, and any other response is just the specific extensions needed, then nothing more is needed), there should be  a signal to know which
case we are in.

> The help response should include supported 
> extensions that are available to that client.

Yes, the help response allows to "discover" all possible extensions from a specific client.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Jasdip Singh <[email-masked]>
Date: Fri, 31 Jul 2020 16:42:21 +0000

Hello Mario,

Please find my comment below.

Jasdip

On 7/31/20, 12:21 PM, "Mario Loffredo" <[email-masked]> wrote:

[JS] Right, this proposal extends RDAP query scenarios but rdapConformance is about response capabilities for various query scenarios, including this one. So if a reverse search query is responded to, including the new extension in the rdapConformance portion of the response indicates that capability. And, the current description of rdapConformance in 7843bis being response-centric seems to suffice as-is for the newly proposed extension.

---

From: Jasdip Singh <[email-masked]>
Date: Fri, 31 Jul 2020 16:50:05 +0000

Agree with Patrick's points about rdapConformance in the help response informing about all capabilities and rdapConformance being more specific for a particular query response.

Jasdip 

On 7/31/20, 12:29 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    I agree.

    

    
    
    -- 
      Patrick Mevzek
      [email-masked]

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 31 Jul 2020 19:12:36 +0200

Hi all,

if I understood well the rdapConformance content in the help response 
should be different from that included in the other responses. Right?

I misunderstood Scott's proposal as a mean by which a server could 
inform a client about the supported features any time regardless the 
response content.

In that sense, I proposed the server could distinguish the 
rdapConformance content according the user profile.

I have no objection to this solution but I think that the two cases 
above should be outlined in RFC7483bis.

Best,

Mario