Re: [regext] Erik Kline's No Objection on draft-ietf-regext-rdap-sorting-and-paging-17: (with COMMENT)

Hi Erik,

thanks a lot for your review. Please find my comments inline.

Il 21/09/2020 08:52, Erik Kline via Datatracker ha scritto:
> Erik Kline has entered the following ballot position for
> draft-ietf-regext-rdap-sorting-and-paging-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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> [[ comments ]]
>
> [ section 2.3 ]
>
> * My current understanding is that it's not possible to request a sort by
>    IP address in general (i.e. without regard to IP address family).  Otherwise,
>    since some IPv6 addresses (admittedly not any within the current 2000::/3
>    GUA space) might be numerically less then some IPv4 addresses, I think there
>    would probably need to be some text around relative ordering between IPv4 and
>    IPv6 addresses regardless of numerical equivalent values.
>
>    But again: my reading is that sort can only be by ipV4 or ipV6 (and not just
>    some generalized "ip" parameter), so this shouldn't be necessary.
[ML] I think sorting by ipv4 or ipv6 is less confusing for consumers and 
more easy to implement for producers. Anyway, an RDAP server is free to 
provide the "ip" sorting property.
>
> [[ nits ]]
>
> [ section 2.1 ]
>
> * s/value of sort "parameter"/value of the "sort" parameter/ perhaps?
[ML] Yes, absolutely.
>
> [ section 2.4 ]
>
> * I think the cursor value "b2Zmc2V0PTEwMCxsaW1pdD01MAo=" might decode to
>    'offset=100,limit=50\n' (with a trailing newline).  The base64 encoding
>    without the trailing newline might be 'b2Zmc2V0PTEwMCxsaW1pdD01MA==', but
>    someone should double-check me on that.
>
[ML] You're right. I used a quick converter available on the web. I have 
just executed the conversion by the Base64 Java class methods and the 
correct encoding is "b2Zmc2V0PTEwMCxsaW1pdD01MA==".

Best,

Mario

>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo