Mario, My response is in-line
On Wed, Jan 23, 2019 at 07:15:02PM +0100, Mario Loffredo wrote: > Hi Andy, > > thanks for your feedback. My comments are below. > > Il 23/01/2019 16:30, Andy Newton ha scritto: > > On Fri, Jan 18, 2019 at 05:04:20PM +0100, Antoin Verschuren wrote: > > > Hi all, > > > > > > As discussed on the mailinglist, we have selected 5 documents that people > > > most want to be added to our milestone list. > > > To be able to to that the documents should first be adopted as working > > > group documents. > > > This is a formal adoption request for > > > draft-loffredo-regext-rdap-reverse-search > > > > > > The draft is available here: > > > https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/ > > > > > > Please review this draft to see if you think it is suitable for adoption > > > by REGEXT, and comment to the list, clearly stating your view. > > > Please also indicate if you are willing to contribute text, review, be a > > > document shepherd, etc. > > First, I wish to thank Mario and his co-authors for opening this line of > > work. > > I have a few comments on this draft (and I'll let the chairs determine if > > I'm > > agreeing with adoption or not). > > > > 1. From an operational point of few, I think there maybe a need > > differentiate > > the support of the different searches. In my (limited opinion), the > > requirement > > to support reverse searches by handle and email address are different than > > the > > requirement to support reverse search of name and physical address. > > Therefore, > > I think operators and policy people need a way to differentiate the various > > searches in their documentation. Perhaps this can be done by breaking the > > searches into multiple drafts and therefore registry A can say the support > > RFC > > XXXX while registry B can say they support RFC YYYY. Just a thought. > > Honestly, I don't see any difference but, anyway, we can discuss about that. > > Another point of discussion could be if we need other reverse search > capabilities not limited to the classic domains-entities relationship and > currently uncovered by RDAP. I'm not really raising a technical issue. It's really about operators feeling the need to support all the queries in the draft vs just some and how they would communicate that to their consituencies. Let me think about it some more. > > > 2. I don't know if we want to tackle the issue of distributing reverse > > searches. But that is an issue here. > > What do you mean exactly for "distributing search"? Do you mean "across > different RDAP servers" ? Yes. > > > 3. The complexity of the query parameters makes me wonder if we should > > consider > > another mechanism for these more complex extensions... One such mechanism > > would > > be a general extension of using POST with GraphQL, and then doing profiles > > of > > reverse search (and other things) on top of that. > > I have thought to the use of a POST method as well as to GraphQL but I > didn't want to propose something outside the constraints of RFC7482 :-) > > I think this proposal is related to the other two drafts (partial response, > sorting-and-paging) and to the implementation of more complex queries. Ok. If you considered it but found the approach less-than-desirable, that's good enough for me. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
