Ahead of the REGEXT meeting later today, I took the opportunity to review draft-ietf-regext-rdap-geofeed-02. Overall, I found the extension to cover some useful aspects for implementers. Below is my review feedback that can be further discussed at the meeting:
1. It's interesting that the extension doesn't define a new RDAP response member but defines a new "links" "rel" type and a new media type. This defines a new form of extension that could be leveraged in the future. This form of extension can be considered in the content of draft-ietf-regext-rdap-extensions. 2. I'm curious whether the "geo" type could be used for other RDAP objects (existing or new). a. Should the draft be made more generic to apply to any RDAP object, inclusive of the IP Network object class? b. Wouldn't it be better to have the extension identifier set to "geo" to match the new "rel" type used by the extension? 3. I'm unsure whether there is the need to redefine the "links" JSON values that is defined in Section 4.2 of RFC 9083 other than the use of the "rel" value of "geo" and the recommendation to use "application/geofeed+csv" for the "type" value. 4. I recommend including a registration of the "Geofeed links" redacted "name" in the RDAP JSON Values registry with the "redacted name" type field. If registered, the "description" member can be changed to a "type" member. Thanks, -- JG [cid87442*image001.png@01D960C5.C631DA40] 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/>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
