Hi George,
thanks for your feedback.
Il 31/07/2020 15:08, George Michaelson ha scritto:
My understanding of the sense of the room, is that it is beholden on
the numbers space to construct words for Security Considerations which
address the _problem statement_ inherent in privacy and security, Not
to specify fixes, but to document the issues and the sense Jim Reid
brought into the room was to advise operators to factor their
local/national/jurisdictional law into this, and respect it.
-G
Honestly, being involved in the management of a ccTLD, I'm not so
experienced in the specific issues related to the numbers space. This is
the reason why the "Privacy Considerations" section is mostly tailored
to the namespace.
Obviously, any suggestion to make privacy and security considerations
more comprehensive is welcome.
Best,
Mario.
On Fri, Jul 31, 2020 at 11:05 PM Mario Loffredo
<mario.loffr...@iit.cnr.it> wrote:
Hi Scott,
thanks a lot for your feddback.
Please find my comments to your feedback below.
Il 31/07/2020 14:29, Hollenbeck, Scott ha scritto:
draft-ietf-regext-rdap-reverse-search currently states that "This document has no
actions for IANA". I believe that's primarily because there's nothing new or
different being returned in the search results, which is where RDAP servers describe the
features they support.
Exactly.
There is, however, a case to be made for registering a value in the RDAP
extensions registry: a response to a help query (or any other query) can be
used to indicate that the server supports reverse search. I'd like to suggest
this change for Section 7:
OLD:
This document has no actions for IANA.
NEW:
IANA is requested to register the following value in the RDAP Extensions
Registry:
Extension identifier: reverse_search_1_0 (or whatever makes sense)
Registry operator: Any
Published specification: This document.
Contact: IESG <i...@ietf.org>
Intended usage: This extension describes reverse search query patterns for RDAP.
Scott
I agree.
Furthermore, my opinion is that Section 4.1 of RFC7483bis should be
updated to treat this use case. I mean, a server should signal in
rdapConformance not only the extensions used in building the response
but all the supported features.
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
