Mohamed Boucadair has entered the following ballot position for draft-ietf-regext-rdap-rir-search-17: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Tom and Jasdip, Thanks for the effort put into this well-written specification. Appreciate the Operations considerations and Implementation sections. Please find below some comments: # ASN is also IP-related! CURRENT: are various IP- and ASN-related search options provided by RIRs via their Whois services for which there is no corresponding RDAP functionality. Maybe consider: NEW: are various IP-related search options (e.g., IP address, IP prefix, and ASN) provided by RIRs via # Normative language CURRENT: Indentation and whitespace in examples are provided only to illustrate element relationships, and are not a REQUIRED feature of this protocol. I understood this is somehow a convention in RDAP, but I still think the use of normative language here is not correct. Combing both “not” and “REQUIRED” is making things worse. # IP network information CURRENT: Searches for IP network information by handle are specified using the form: An ASN is also an IP network information. Consider calling out address and/or prefix here. # Extension & Version pattern CURRENT: 'ips/rirSearch1/<relation>/<IP address>': Used to identify an IP network search using a relation and an IP address to match a set of IP networks. Why a version is used here but not for the other extensions defined in this document? # Compliance with HTTP BCP (RFC9205) CURRENT: server SHOULD respond with an HTTP 501 (Not Implemented) [RFC9110] response code if it receives such a request. Server operators MAY also opt not to support "status" filtering for values other than "active" for the "rdap-up" and "rdap-top" link relations, in which case the server SHOULD respond with an HTTP 501 (Not Implemented) [RFC9110] response code if it receives such a request. … via a lookup URL (see Section 3.1 of [RFC9082]). If there is no result for the search, the server returns an HTTP 404 (Not Found) [RFC9110] response code. The use of normative language is IMO not compliant with the guidance in RFC9205 about error handling, especially this part: Applications using HTTP MUST NOT re-specify the semantics of HTTP status codes, even if it is only by copying their definition. It is NOT RECOMMENDED they require specific reason phrases to be used; Cheers, Med _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
