Hi Scott,
here in the following a further feedback:
Section 5.3: the type boolean is missing in the definition of zoneSigned
Section 5.3.: the two nameservers related to the domain in Figure 24
have the same "handle" value. In addition, even if, instances of
different object classes are allowed to have the same "handle" value,
it might be better to assign different values to all the handles
included in Figures 23 and 24
Best,
Mario
Il 24/02/2020 16:15, Hollenbeck, Scott ha scritto:
Thanks, Mario. I’m waiting to see if anyone else has anything to say
before I jump into your suggestions and questions.
Scott
*From:* Mario Loffredo <[email protected]>
*Sent:* Wednesday, February 19, 2020 4:17 AM
*To:* Hollenbeck, Scott <[email protected]>; [email protected]
*Subject:* [EXTERNAL] Re: [regext] FW: I-D Action:
draft-hollenbeck-regext-rfc7483bis-00.txt
Hi Scott,
here in the following my feedback.
Section 4.1.: Change "lunarNIC_level_0" with "lunarNic_level_0"
Section 4.2: I would replace "on the Internet" with "on the Web"
Section 4.2: It seems to me that, according to Section 3 of RFC5988,
the members "value", "rel" and "href" are all required.
Section 4.3: I would clearly define which members of the
"notice/remark" object are required and which ones are optional by
using key words described in RFC2119. Maybe the second paragraph could
be written like in the following:
" Both are arrays of objects. Each object contains an "title"
string representing the title of the object, an "type"
string denoting a registered type of remark or notice (see
Section 10.2.1), an array of strings named "description" for the
purposes of conveying any descriptive text, and an "links"
array as described in Section 4.2. The
"description" JSON value MUST be specified. All other JSON values are
OPTIONAL. "
Section 4.5: I would clearly define which members of the "event"
object are required and which ones are optional by using the key words
described in RFC2119. Maybe the paragraph below Figure 11 could be
written like in the following:
" The "events" array consists of objects, each with the following
members:
o "eventAction" -- a string denoting the reason for the event
o "eventActor" -- an identifier denoting the actor
responsible for the event
o "eventDate" -- a string containing the time and date the event
occurred.
o "links" -- see Section 4.2
Both the "eventAction" and "eventDate" JSON values MUST be specified. All other JSON values are
OPTIONAL. "
Section 4.8: I would clearly define that both the members of the
"publicId" object are required.
Section 5.1: I wonder which kinds of relationships model both the
entity properties "networks" and "autnums". I mean, do they model the
reverse relationships between, respectively, a network or an autnum
and the related entities or something else?
Section 5.2: Self link's URIs in the example should contain either the
ldhName or the unicodeName. Similarly for other examples including
self links to domain or nameserver objects
Section 5.2: The sentence "Figure 18 is an example of a nameserver
object with all values given." seems a bit mileading to me because the
example doesn't include the "entities" property. Maybe it could be
written like in the following:
"Figure 18 is an example of a nameserver object with nearly all the information
given."
Section 6: Is the "description" property required in the error response ?
Section 10.2.3: Does the "transfer" event action refer to "transfer
between registrars" instead of "transfer between registrants" ?
Appendix C: I would enclose in quotes the word label in the sentence
"... It uses the label attribute..."
Best,
Mario
Il 18/02/2020 13:31, Hollenbeck, Scott ha scritto:
FYI, folks. This is the first version of 7483bis. It contains updates to
address the known errata, described here:
https://www.rfc-editor.org/errata_search.php?rfc=7483
I need to fix the Unicode characters again, though. I'll do that with the
next update. In the meantime, I could use help in documenting existing RDAP
server implementations as described in the Implementation Status section. If
you'd like to include a description of your implementation, please let me know
and I'll get it in. I could also use help in confirming that xml2rfc didn't
inadvertently change anything during the conversion from RFC format back to I-D
format. Lastly, let's start to talk about any other needed clarifications. Are
you aware of any? Send 'em to the list for discussion.
Scott
-----Original Message-----
From: I-D-Announce<[email protected]>
<mailto:[email protected]> On Behalf [email protected]
<mailto:[email protected]>
Sent: Tuesday, February 18, 2020 7:21 AM
To:[email protected] <mailto:[email protected]>
Subject: [EXTERNAL] I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : JSON Responses for the Registration Data Access
Protocol (RDAP)
Authors : Scott Hollenbeck
Andy Newton
Filename : draft-hollenbeck-regext-rfc7483bis-00.txt
Pages : 80
Date : 2020-02-18
Abstract:
This document describes JSON data structures representing
registration information maintained by Regional Internet Registries
(RIRs) and Domain Name Registries (DNRs). These data structures are
used to form Registration Data Access Protocol (RDAP) query
responses.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7483bis/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-hollenbeck-regext-rfc7483bis-00
https://datatracker.ietf.org/doc/html/draft-hollenbeck-regext-rfc7483bis-00
Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
I-D-Announce mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories:http://www.ietf.org/shadow.html
orftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
regext mailing list
[email protected] <mailto:[email protected]>
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
[email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/regext
