Antoin,
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. I also recommend defining the convention of
using the ‘*’ to support the partial string searching specified in Section 4.1
of RFC9082.
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.
3. Section 3 “Relation Searches”
* Nit - Shorten “in order to” to “to”
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.
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>?
* <status>: Either “active” or “inactive” defined in Section 3.2.
2. Section 3.2.1 “Definitions”
* I would expand INR as in Internet Number Resource (INR) in the first
reference.
* Nit – Change “a most-specific object” to “the most-specific object”
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.
4. Section 3.3 “Status”
* Are the supported status values “active” and “inactive”?
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”.
* 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.
* “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.
* “…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.
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.
* The “rirSearch1”, “ips”, and “autnums” extension identifiers don’t
need to be in the sample rdapConformance, since they are not included in the
response.
* The “,…” could be removed from the sample rdapConformance unless the
use of ,…” is included in the “Conventions Used in This Document”
* Nit – “is able to” can be replaced with “can”.
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.
Thanks,
--
JG
James Gould
Fellow Engineer
jgo...@verisign.com
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 12/11/23, 9:28 AM, "regext on behalf of Antoin Verschuren"
<regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of
ietf=40antoin...@dmarc.ietf.org <mailto:40antoin...@dmarc.ietf.org>> 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.
Reminder,
This WGLC will end tonight. So far we only had 3 notifications of support. (And
a comment from the document shepherd)
Please indicate your support if you didn’t already do so for us to judge
consensus.
Regards,
Your co-chairs Jim and Antoin
> Op 27 nov. 2023, om 15:51 heeft Antoin Verschuren
> <ietf=40antoin...@dmarc.ietf.org <mailto:40antoin...@dmarc.ietf.org>> het
> volgende geschreven:
>
> The document editors have indicated that the following document is ready for
> submission to the IESG to be considered for publication as a Proposed
> Standard:
>
>
> RDAP RIR Search
> https://secure-web.cisco.com/1Pv1vWxBdAGZHpNswyOgy6eLUI9kf3TteHefKNKwWGYnlGXJzoSce7aLoJqioEYPNZ-47OiBE5UWNbwd6QrWd3XHyWvJHZ56JD5wGQFc5b5H1M8yclAinWd7JsecZ8wCK91jgJ2cnNLiugEQpJtjUrTjb4JvCmJT0IHu4pWjyn5iGjUEK9zCP4YmbW2-vdP0QROAa73PyH5sjJH4LKzjCrVR0og-Z6l2JjeySfqtEWlvMzBHVRjvR98XyQ9StyEp_oX1Y_EXWsU3PreKcXFs9JJEjFaGnO-wOFdUEwQ4WJVQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-rir-search%2F05%2F
>
> <https://secure-web.cisco.com/1Pv1vWxBdAGZHpNswyOgy6eLUI9kf3TteHefKNKwWGYnlGXJzoSce7aLoJqioEYPNZ-47OiBE5UWNbwd6QrWd3XHyWvJHZ56JD5wGQFc5b5H1M8yclAinWd7JsecZ8wCK91jgJ2cnNLiugEQpJtjUrTjb4JvCmJT0IHu4pWjyn5iGjUEK9zCP4YmbW2-vdP0QROAa73PyH5sjJH4LKzjCrVR0og-Z6l2JjeySfqtEWlvMzBHVRjvR98XyQ9StyEp_oX1Y_EXWsU3PreKcXFs9JJEjFaGnO-wOFdUEwQ4WJVQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-rir-search%2F05%2F>
>
>
> Please indicate your support or no objection for the publication of this
> document by replying to this message on list (a simple “+1” is sufficient).
>
> If any working group member has questions regarding the publication of this
> document please respond on the list with your concerns by close of business
> everywhere, Monday, 11 December 2023.
>
> If there are no objections the document will be submitted to the IESG.
>
> The Document Shepherd for this document is Mario Loffredo.
>
> Thanks,
>
> Jim and Antoin
> REGEXT WG Co-Chairs
> _______________________________________________
> regext mailing list
> regext@ietf.org <mailto:regext@ietf.org>
> https://secure-web.cisco.com/1CkNqc517PhhOde0djSOsm67Af-NQhtT8ARBxSJrHaA5TtRUboADi5dqlUy_l91YChrpq-Ve3dbCu4BVKKEeKNx7OluyY0334Ytm9LHg_QJSzoJs4kD9d4UfrDVWEga8hd4zffmUtsX5sqtOvXdLIx1bvtqFC6U_2QRhcmvs9P-tddXV0CHzzwVnsZXqAvo8TCz83J0X7wmnChfqQ9SI8N19e8TyCbK3npL3rwSuRj1Tp1ckNP1wxIKLdmEpLXb-6hir3OS0obBk4p_gSwW1hNkARJNZXhjl1D4ByuVbSq6k/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>
> <https://secure-web.cisco.com/1CkNqc517PhhOde0djSOsm67Af-NQhtT8ARBxSJrHaA5TtRUboADi5dqlUy_l91YChrpq-Ve3dbCu4BVKKEeKNx7OluyY0334Ytm9LHg_QJSzoJs4kD9d4UfrDVWEga8hd4zffmUtsX5sqtOvXdLIx1bvtqFC6U_2QRhcmvs9P-tddXV0CHzzwVnsZXqAvo8TCz83J0X7wmnChfqQ9SI8N19e8TyCbK3npL3rwSuRj1Tp1ckNP1wxIKLdmEpLXb-6hir3OS0obBk4p_gSwW1hNkARJNZXhjl1D4ByuVbSq6k/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
_______________________________________________
regext mailing list
regext@ietf.org <mailto:regext@ietf.org>
https://secure-web.cisco.com/1CkNqc517PhhOde0djSOsm67Af-NQhtT8ARBxSJrHaA5TtRUboADi5dqlUy_l91YChrpq-Ve3dbCu4BVKKEeKNx7OluyY0334Ytm9LHg_QJSzoJs4kD9d4UfrDVWEga8hd4zffmUtsX5sqtOvXdLIx1bvtqFC6U_2QRhcmvs9P-tddXV0CHzzwVnsZXqAvo8TCz83J0X7wmnChfqQ9SI8N19e8TyCbK3npL3rwSuRj1Tp1ckNP1wxIKLdmEpLXb-6hir3OS0obBk4p_gSwW1hNkARJNZXhjl1D4ByuVbSq6k/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
<https://secure-web.cisco.com/1CkNqc517PhhOde0djSOsm67Af-NQhtT8ARBxSJrHaA5TtRUboADi5dqlUy_l91YChrpq-Ve3dbCu4BVKKEeKNx7OluyY0334Ytm9LHg_QJSzoJs4kD9d4UfrDVWEga8hd4zffmUtsX5sqtOvXdLIx1bvtqFC6U_2QRhcmvs9P-tddXV0CHzzwVnsZXqAvo8TCz83J0X7wmnChfqQ9SI8N19e8TyCbK3npL3rwSuRj1Tp1ckNP1wxIKLdmEpLXb-6hir3OS0obBk4p_gSwW1hNkARJNZXhjl1D4ByuVbSq6k/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
