Subject: Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-partial-response-02.txt

From: Tom Harrison <[email-masked]>
Date: Mon, 5 Aug 2019 00:41:48 +0000

Hi Mario,

On Wed, Jul 24, 2019 at 08:08:08PM +0200, Mario Loffredo wrote:
> Il 24/07/2019 16:29, Tom Harrison ha scritto:
>>   - Section 5 of RFC 7483 suggests that objects should always include a
>>     'self' link, regardless of whether they are top-level objects,
>>     embedded objects, or search result objects.  I think that including
>>     'self' links for all objects, even those returned in response to an
>>     'id' fieldset search, would be useful, because it saves the client
>>     from having to re-search when they want further details for only
>>     a small number of objects in a set of search results.
> 
> Your opinion disagrees with what is written in
> draft-blanchet-regext-rdap-deployfindings-05.  I, too, agree with
> Marc that self links can cause inifinite loops when the user is a
> software agent

I think that document's content is about links that refer to the
current object, but that appear with a link relation type other than
'self'.  If the link has a link relation type of 'self', then the
client should skip it during link processing.

> but, at the same time, I recognize that, when the id field set is
> applied, a self link for each result would be helpful to a human.
> 
> Definitively, I think that such a feature could be provided by an
> RDAP client smarter than a simple web browser.

This part of my response is a bit awkward, because it spans multiple
documents.  I forgot to include in my reverse-search mail that it
would be good to expand the supported object types to include IP
networks and ASNs, since those are the main searches that we (APNIC)
are looking to support.  Assuming that's OK, then including 'self'
links in partial responses is more useful than for
domain/nameserver/entity alone, because for IP networks it will save
the client from having to calculate the CIDR range based on the
startAddress and endAddress values (querying by the exact CIDR range
is necessary because of hierarchical delegations).

Given that including 'self' links will increase response sizes
substantially, and that the need for 'self' links will not be
consistent across clients or object types, I think that your
suggestion from the other mail about having an 'extendedId' fieldset
that includes 'self' links sounds like a good way of dealing with this
issue.

-Tom

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 5 Aug 2019 18:16:17 +0200

Hi Tom,

thanks a lot for your feedback. Please find my comments below.

> is necessary because of hierarchical delegations).

This concept is also stated in the "Introduction" section of the 
reverse-serach draft:

"Since entities can be in relation with all RDAP objects ([RFC7483]), 
the availability of a reverse search can be common to all RDAP query paths."

Therefore, I have no problem at all to make this capability available on 
the remaining objects. The only problem is that RDAP should be 
consequently extended so as to include both "autnums" and "ips" among 
the search path segments. When the reverse search draft was submitted 
for the very first time, the authors' main goal was to explore the 
reverse search capability only for the most known purpose. In addition, 
a reverse search capability available only on domains would have been 
compliant to RFC7482.

Defìnitively, I think that the additional search path segments couldn't 
be defined in the reverse-search draft but in a new version of  RFC7482 
published as a Proposed Standard document (just to refer to the last 
Scott's mail). Do you agree about this point?

> that includes 'self' links sounds like a good way of dealing with this

Let's ask the working group for an opinion about the two issues above. 
We can either discuss them in an Interim Meeting or postpone the 
discussion at the next IETF.

Briefly, the points to be discussed might be:

1) Should both "ips" and "autnums" be included among the search path 
segments?

2) Should the self-link be included in the definition of the "id" field 
set or should we define an ad-hoc field set containing the self-link?

Best,

mario

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [email-masked]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 5 Aug 2019 16:41:35 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Mario Loffredo
> Sent: Monday, August 5, 2019 12:16 PM
> To: Tom Harrison <[email-masked]>
> Cc: [email-masked]
> Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-
> ietf-regext-rdap-partial-response-02.txt
> 
> Hi Tom,
> 
> This concept is also stated in the "Introduction" section of the reverse-serach
> draft:
> 
> "Since entities can be in relation with all RDAP objects ([RFC7483]), the
> availability of a reverse search can be common to all RDAP query paths."
> 
> Therefore, I have no problem at all to make this capability available on the
> remaining objects. The only problem is that RDAP should be consequently
> extended so as to include both "autnums" and "ips" among the search path
> segments. When the reverse search draft was submitted for the very first
> time, the authors' main goal was to explore the reverse search capability only
> for the most known purpose. In addition, a reverse search capability available
> only on domains would have been compliant to RFC7482.
> 
> Defìnitively, I think that the additional search path segments couldn't be
> defined in the reverse-search draft but in a new version of  RFC7482
> published as a Proposed Standard document (just to refer to the last Scott's
> mail). Do you agree about this point?

I'd very much prefer to NOT add new functionality if we take on the task of updating the RFCs unless there are very, very compelling and significant omissions identified. New features means "RDAP 1.1 or 2.0", and with 1.0 production implementation, deployment, and operations still a work in progress for many folks I'd like to see what operational experience teaches us before we draw any conclusions about "what next?".

I don't recall why we didn't include search path query segments for IP networks or autonomous systems. Does that ring a bell for anyone?

Scott