> -----Original Message----- > From: regext <regext-boun...@ietf.org> On Behalf Of Mario Loffredo > Sent: Monday, August 5, 2019 12:16 PM > To: Tom Harrison <t...@apnic.net> > Cc: regext@ietf.org > Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft- > ietf-regext-rdap-partial-response-02.txt > > Hi Tom, > > thanks a lot for your feedback. Please find my comments below. > > Il 05/08/2019 02:41, Tom Harrison ha scritto: > > 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). > > 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
