Subject: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 18 Feb 2020 12:31:14 +0000

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-masked]> On Behalf Of [email-masked]
Sent: Tuesday, February 18, 2020 7:21 AM
To: [email-masked]
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-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Jasdip Singh <[email-masked]>
Date: Tue, 18 Feb 2020 16:28:25 +0000

Hello Scott,

Here is my (mostly minor) feedback:

  1.  4.8 For consistency with other examples, add spaces before and after ‘:’ in the publicIds example.
  2.  5.1 Similarly, add spaces before and after ‘:' in the entity example. (There could be other places in the whole doc.)
  3.  5.3 Should maxSigLife have a more normative reference (RFC 4034) than RFC 5910?
  4.  5.3 Figure 24: Handle in the entity object is XXXX but it is xxxx in links’ URIs.
  5.  5.4 Figure 26: Handle in the entity object is XXXX but it is xxxx in links’ URIs. Lastly, RFC 5952 recommends lowercase v6 notation (section 4.3); may lowercase (C00) in http://example.net/ip/2001:C00::/23 and likes.
  6.  5.4 Should startAddress be clarified as "a string representing the starting…”? Similarly, for endAddress description.
  7.  5.5 Should the "Autonomous System Number Entity Object Class” title be “The Autonomous System Number Object Class”?
  8.  5.5 So as to hold 4-byte ASNs (0 to 4294967295), should we clarify the JSON number as uint32 (unsigned) (as per https://developers.google.com/discovery/v1/type-format)?
  9.  5.5 Should name be clarified as "a string representing an identifier…”?

Thanks,
Jasdip

On Feb 18, 2020, at 7:31 AM, Hollenbeck, Scott <shollenbeck=[email-masked]<mailto:shollenbeck=[email-masked]>> wrote:

Scott

-----Original Message-----
From: I-D-Announce <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, February 18, 2020 7:21 AM
To: [email-masked]
Subject: [EXTERNAL] I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt

Abstract:

_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 19 Feb 2020 10:17:06 +0100

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

-- 
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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 24 Feb 2020 15:14:50 +0000

Thanks, Jasdip. I’m waiting to see if anyone else has anything to say before I jump into your suggestions and questions.

Scott

From: Jasdip Singh <[email-masked]>
Sent: Tuesday, February 18, 2020 11:28 AM
To: Hollenbeck, Scott <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt

Hello Scott,

Thanks,

Jasdip

   Scott

   -----Original Message-----
   From: I-D-Announce <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
   Sent: Tuesday, February 18, 2020 7:21 AM
   To: [email-masked]<mailto:[email-masked]>
   Subject: [EXTERNAL] I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt

   Abstract:

   [email-masked]<mailto:[email-masked]>

   _______________________________________________
   regext mailing list
   [email-masked]<mailto:[email-masked]>
   https://www.ietf.org/mailman/listinfo/regext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 24 Feb 2020 15:15:42 +0000

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-masked]>
Sent: Wednesday, February 19, 2020 4:17 AM
To: Hollenbeck, Scott <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt

Hi Scott,

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:

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:

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:

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

   Scott

   -----Original Message-----
   From: I-D-Announce <[email-masked]><mailto:[email-masked]> On Behalf Of [email-masked]<mailto:[email-masked]>
   Sent: Tuesday, February 18, 2020 7:21 AM
   To: [email-masked]<mailto:[email-masked]>
   Subject: [EXTERNAL] I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt

   Abstract:

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 25 Feb 2020 15:02:21 +0100

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-masked]>
> *Sent:* Wednesday, February 19, 2020 4:17 AM
> *To:* Hollenbeck, Scott <[email-masked]>; [email-masked]
> *Subject:* [EXTERNAL] Re: [regext] FW: I-D Action: 
> draft-hollenbeck-regext-rfc7483bis-00.txt
>
> Hi Scott,
>
> 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:
>
> 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 
> 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?
>
> ldhName or the unicodeName. Similarly for other examples including 
> self links to domain or nameserver objects
>
>     From: I-D-Announce<[email-masked]>  <mailto:[email-masked]>  On Behalf [email-masked]  <mailto:[email-masked]>
>
>     To:[email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>
>     Internet-Draft directories:http://www.ietf.org/shadow.html  orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>     [email-masked]  <mailto:[email-masked]>
>
> Web:http://www.iit.cnr.it/mario.loffredo
>