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

["Gould, James" <[e-mail]>]

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
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

Verisign.com <http://verisigninc.com/> 




On 1/25/24, 10:32 PM, "Tom Harrison" <[e-mail] <mailto:[e-mail]>> 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 +0000, 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:
> 
> * <relation>: The type of relation defined in Section 3.2.2
> * <IP Address>: IP Address defined in Section 3.1.1 of RFC9082
> * <CIDR prefix>: CIDR block defined in Section 3.1.1 of RFC9082
> * <CIDR length>: Prefix length defined in Section 3.1.1 of RFC9082
> * <domain name>: Fully qualified domain name defined in Section 3.1.3 of RFC9082
> * <autonomous system number or range> - Should this be <autonomous system number> or <autonomous system range> with the following definitions?
> * <autonomous system number>: Autonomous system number defined in Section 3.1.2 of RFC9082.
> * <autonomous system range>: Unclear what the appropriate reference is for the <autonomous system range>, 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 <relation> matches the values in Section 3.2.2.
> * What is the definition of <object-value>?


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.


> * <status>: 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
> <relation> 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-specific link relations are defined, because
the only known use cases for status filtering involve
the "top" and "up" relations and the "active" status.


> * “…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.


Updated text:


This section mandates specific behaviour for the "up"
link relation, but does not define that link relation
(see <xref target="RFC8288" />). This is acceptable,
because this behaviour:


does not conflict with the current description
of the link relation; and


is not generally applicable, but instead
limited to the context of RDAP INR objects
only.


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


There are now updates for this in the first paragraph in this section
instead, since it is about similar things.


> * The “rirSearch1”, “ips”, and “autnums” extension
> identifiers don’t need to be in the sample rdapConformance,
> since they are not included in the response.


See the reply to Mario for more detail on this point.


> * The “,…” could be removed from the sample rdapConformance
> unless the use of ,…” is included in the “Conventions Used in
> This Document”


We don't understand this point. 9083 (e.g.) uses ellipses in objects
without documenting that in a specific section. 


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


Per earlier comment, see the reply to Mario for more detail on this
point.


-Tom