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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 6 May 2020 16:11:52 +0000

Thanks for the feedback, Jasdip. More below…

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,

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

[SAH] I’m not so sure. I haven’t found a normative style guide that describes spacing conventions, and I see inconsistent use of spaces in our own standard for JSON data interchange (see Section 13 of RFC 7159). I think I’d like to leave these alone.

3.      5.3 Should maxSigLife have a more normative reference (RFC 4034) than RFC 5910?

[SAH] maxSigLife doesn’t appear in RFC 4034, so I think 5910 is the appropriate reference.

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.

[SAH] Will fix.

6.      5.4 Should startAddress be clarified as "a string representing the starting…”? Similarly, for endAddress description.

[SAH] Will fix.

7.      5.5 Should the "Autonomous System Number Entity Object Class” title be “The Autonomous System Number Object Class”?

[SAH] Will fix.

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

[SAH] will fix.

9.      5.5 Should name be clarified as "a string representing an identifier…”?

[SAH] Will fix.

Thanks,

Jasdip

---

From: Jasdip Singh <[email-masked]>
Date: Wed, 6 May 2020 16:41:32 +0000

I agree with your comments, Scott. Thanks.

Jasdip

On May 6, 2020, at 12:11 PM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

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

Hello Scott,

You are right. :)

  1.  5.3 Should maxSigLife have a more normative reference (RFC 4034) than RFC 5910?

No, you are right.

  1.  5.3 Figure 24: Handle in the entity object is XXXX but it is xxxx in links’ URIs.
  2.  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.

[SAH] Will fix.

  1.  5.4 Should startAddress be clarified as "a string representing the starting…”? Similarly, for endAddress description.

[SAH] Will fix.

  1.  5.5 Should the "Autonomous System Number Entity Object Class” title be “The Autonomous System Number Object Class”?

[SAH] Will fix.

  1.  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)?

[SAH] will fix.

  1.  5.5 Should name be clarified as "a string representing an identifier…”?

[SAH] Will fix.
Thanks,
Jasdip

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 6 May 2020 18:50:38 +0000

Thanks, Mario! More below.

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,

here in the following my feedback.

Section 4.1.: Change "lunarNIC_level_0" with "lunarNic_level_0" 

[SAH] I'll change lunarNic to lunarNIC. I'm also going to change the text in 4.1 a bit to be clear that these string literals are the values that should be registered with IANA and returned in RDAP responses. There won't be any confusing mention of prefixes.

Section 4.2: I would replace "on the Internet" with "on the Web"

[SAH] Is there any chance that one or more of the URLs might refer to something other than an http-accessible resource? I'm not sure, so I think I'd like to keep this as "Internet" rather than "Web".

Section 4.2: It seems to me that, according to Section 3 of RFC5988, the members "value", "rel" and "href" are all required.

[SAH] I agree, so I'll change "The "href" JSON value MUST be specified" to "The "value", "rel" and "href" JSON values MUST be specified".

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. "
 
[SAH] I agree, will fix.

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.  "
 
[SAH] I'm not sure about this one. The current text doesn't say anything about any of these values being OPTIONAL (it says "The "events" array consists of objects, each with the following members"), so, by default, I understand the text to mean that they're all REQUIRED. I could say "The "events" array consists of objects, each with the following REQUIRED members". Would that work?

Section 4.8: I would clearly define that both the members of the "publicId" object are required.

[SAH] OK. I'll change "with each object containing the following members" to "with each object containing the following REQUIRED members".

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?

[SAH] Maybe one of the RIR guys can address this question. Jasdip? Tom? Anyone?

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

[SAH] Agreed, will fix.

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."
 
[SAH] I'll change this to "with all appropriate values given". I don't believe entities are commonly associated with name servers.

Section 6: Is the "description" property required in the error response ?

[SAH] According to the current text, yes.

Section 10.2.3: Does the "transfer" event action refer to "transfer between registrars" instead of "transfer between registrants" ? 

[SAH] I think the intention was "between registrars", but it's also possible for objects like domains to be transferred between registrants. The current IANA registry entry says "from one registrant to another". We may need to submit an erratum for this since the IESG is the controller for values in this registry.

Appendix C: I would enclose in quotes the word label in the sentence "... It uses the label attribute..." 

[SAH] Agreed, will fix. Thanks for the detailed review!

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 6 May 2020 19:49:32 +0000

From: Mario Loffredo <[email-masked]>
Sent: Tuesday, February 25, 2020 9:02 AM
To: Hollenbeck, Scott <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt - Further feedback

Hi Scott,

here in the following a further feedback:

Section 5.3: the type boolean is missing in the definition of zoneSigned

[SAH] Which "type" boolean are you referring to, Mario?

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

[SAH] I think I'd like to leave these as-is. It might not be optimal to re-use the "XXXX" pattern, but I don't think there's any confusion about these being nothing more than representative of handle values.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 6 May 2020 20:18:39 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Patrick Mevzek
> Sent: Monday, April 27, 2020 3:51 AM
> To: [email-masked]
> On Tue, Feb 18, 2020, at 07:31, Hollenbeck, Scott wrote:
> > Lastly, let's
> > start to talk about any other needed clarifications. Are you aware of
> > any? Send 'em to the list for discussion.
> 
> First, please excuse me in advance if I didn't understood things right, as my
> points below are maybe more than a clarification so I do not know if the bis
> version is expected just to fix the nitpicks/errata or really revisit some points.
> 
> If the latter feel free to disregard most of the below. They are in part related
> to previous discussions here and also Marc's draft on deployment findings.
> 
> 
> 2.1
> I think there should be far more explanations (or even enforcement) of the
> relationship, if any, from the specific label used in rdapConformance and
> then used as prefix for extended names.
> 
> Like, to be able to use "lunarNic_beforeOneSmallStep" and
> "lunarNic_harshMistressNotes"
> does that mean that there should be (and hence registered at IANA)
> "lunarNic_level_0" in rdapConformance?
> This seems to be the case, comparing text between 2.1 and 4, but I think it
> should be more stressed out if it is a requirement.
> 
> There should be more explanation also on what is registered at IANA, since
> there is confusion, about the "level_0" ending. Is that mandatory?
> Suggested?

Agreed. I'm thinking of doing this to the text:

OLD:
The string literal "rdap_level_0" signifies conformance with this
specification.  When custom JSON values are inserted into responses,
conformance to those custom specifications MUST use a string prefixed
with the appropriate identifier from the IANA RDAP Extensions
registry specified in [RFC7480].  For example, if the fictional
Registry of the Moon wants to signify that their JSON responses are
conformant with their registered extensions, the string used might be
"lunarNIC_level_0".  These prefixes aid the identification of
specifications for software implementers, and failure to use them
could result in slower adoption of extensions.

NEW:
The string literal "rdap_level_0" signifies conformance with this
specification.  When custom JSON values are inserted into responses,
conformance to those custom specifications MUST be indicated by
including a unique string literal value registered in the IANA RDAP
Extensions registry specified in [RFC7480].  For example, if the
fictional Registry of the Moon wants to signify that their JSON
responses are conformant with their registered extensions, the string
used might be "lunarNIC_level_0".  These registered values aid the
identification of specifications for software implementers, and
failure to use them could result in slower adoption of extensions.

> 4.2 Links
> 
> I think there should be more explanation of what "value" (the context URI)
> means in the case of RDAP. It is optional like all others except href, but is
> visible in examples, so more guidance would be welcome.

Do you have text to suggest?

> 4.8 publicIDs
> 
> I am under the impression that the same structure as for links could be
> reused.
> Also "type" should be better explained or even be in a IANA registry.
> 
> Unfortunately I lost my previous notes but I think I sensed there  a possible
> interoperability problem, but now I am not so sure. Sorry about that, will try
> to remember that point again.

We can't change the structure as part of this effort, but if there's an issue here we can create a ticket for it. I'm open to suggested text for a better description of the "type" value.

> 5.2 Maybe nitpick
> 
>        "ldhName" : "ns1.xn--fo-5ja.example",
>        "unicodeName" : "ns1.foo.example",
> 
> It is absolutely not clear that the unicodeName does indeed have a non ASCII
> character (hence the ldhName), as just copying the string from the
> document into any viewer shows purely ASCII characters.
> Maybe we should use guidance from RFC 7997?
> And since it is JSON:
> 
>        "ldhName" : "ns1.xn--fo-5ja.example",
>        "unicodeName" : "ns1.f\u00f3o.example",

This is a bug in 7483 and/or the RFC publication process. Those examples are supposed to contain non-ASCII characters. The challenge here is that the characters in question are part of U-labels, so we have to use something that's appropriate for representing a U-label. I think that means that I need to make sure the Unicode characters are preserved when xml2rfc produces the text for the I-D.

> 5.4 Nitpick
> 
> "href" : "http://example.net/ip/2001:C00::/23",
> 
> Why uppercase characters are technically allowed per RFC7482 §3.1.1 as it
> says RFC 4291 formats are allowed and 5952 is only RECOMMENDED (which
> specifically calls for lowercase only), it is still RECOMMENDED, so there should
> be valid reasons to ignore it, and in this example it is not clear why it is not
> followed, so maybe simpler to just follow the recommendation?

Agreed.

> Also, the explanation for "status" should refer to section 4.6
> like other parts do.

Agreed.

> 9.
> If we are not in the just errata types of changes, I really recommend
> a more "programmatic" way to signal truncation, instead
> of having to rely on a specific string. Like using a boolean.
> Deployments in the wild show that this string varies among servers.
> I know that it is a registered string in IANA registry (so servers shouldn't vary
> in theory), but I still
> feel uneasy for an automated interface to have to rely on human strings
> to decide what to do.
> (especially when one of the reason given to favor JSON over XML is that
> it is less bulky)

Let’s defer this.

> 15.2 Nitpicks
> 
> https://secure-web.cisco.com/1n_IpHslw-
> LLCMuu5QUV4Lywyxl7Zw7jsRk_jlusbxbaqWngp5UJ7qt6awNKo2l5LsxsudaH-
> y_HhXmqEdM3Wk8jPzDczGsJHH5JtRro34OgWuP5kApjBYrFKvmko4IbzYv0XkJ
> uev1U7OxhgV6fgtQOcx22hKHtmD9gyKumALcGjCHJKw_3m6YEheOfUH8A-
> N6kj4hcxKFY2K3wkcG9rY4Pu0UBWHD2F8w4_zkBOWEMBort77E5KNoR8zWX
> Qx-
> o4eak_DarWCMZsSs4elpwGrw/https%3A%2F%2Fdevcentral.f5.com%2Fs%2
> Fweblogs%2Fmacvittie%2Farchive%2F2011%2F04%2F27%2Fthe-stealthy-
> ascendancy-of-json.aspx is today a 404, so not really useful.

I found a current reference that I'll use for a replacement:

https://devcentral.f5.com/s/articles/the-stealthy-ascendancy-of-json

> For
> http://secure-web.cisco.com/141YW_PfA508VT6T6Dqt7nKZJDQ8czL4-
> FVZF408HiR1o4DWzE_X3CnPn0bl1Is2dqvB8fHsDFbA-
> l60a1AhiZdCohCSsA_EBybtY1NIgNEu9HaMmjUH82G8aYEM5Ty_9-FCEzj5AIU-
> qT1J_u11rBOYcRwPRlAwx7qPhw-
> lPquUcIG4trMyOLoXdEQm1Ai0IqIbKzCfLF7PgU8RKaoQ746sQu85RANh8x_8Bt
> WjLweo4ekahjSTrBcftAzUeG5881Ds5I2B48C2ilzNQWpng4VN8iGoaQ8z6Q8uB
> hwlmJuA/http%3A%2F%2Fwww.iana.org%2Fdomains%2Fidn-tables
> maybe use https:// instead.
> 
> Same for http://secure-web.cisco.com/1Z-
> vlcEAhtgcUzjGDACcnU1o3wnRnWFLS7Np9g1GhHdXyggixazay3-
> opBNnCsvm3rPO3CdB08cy25xNV97GX5N0Q1fjryYF90SHT2xSVpnfGSiGKy-s2-
> dPw3MHMFZ5d1o7ZNdGE-
> cw0zJjL0j59aeP_lyQSz76nTC1PZWMcQ_FsYltVPcvstUtKcp6i_FJP4ltiknXdcSBX
> q1cv8BfZkKAssogfHVobluV33ajG33Qd3pVoODzpInnKYMWu3CZw7JPI_31yLX
> ZC03bEUvzIbQ/http%3A%2F%2Fwww.cs.montana.edu%2Fizurieta%2Fpubs%
> 2Fcaine2009.pdf
> 
> (both do an automatic redirect from http:// to https:// anyway)

Agreed.

> And with all planned changes to RFC7483, it is time to introduce
> rdap_level_1
> in rdapConformance values?
> If we say: "we shouldn't because clients will not be upgraded, etc.",
> then I believe rdapConformance is not useful, if it can not be used as an
> upgrade
> path. We might as well consider then that rdap_level_0 is a kind of
> hardcoded
> constant.

I'm of the mind that rdap_level_1 will be required if/when we actually describe protocol *changes* that require a new Proposed Standard specification. I don't think we're there yet.

Thanks for the feedback, Patrick!

Scott

---

From: Jasdip Singh <[email-masked]>
Date: Wed, 6 May 2020 20:50:59 +0000

Yah, it models the reverse relationship. An entity could be an organization or a point of contact. When former, “networks" and “autnums" in that entity's query response represent the IP and ASN resources the registry has issued to it (following the visibility rules in place).

Jasdip

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 7 May 2020 09:15:10 +0200

Hi Scott,

Il 06/05/2020 21:49, Hollenbeck, Scott ha scritto:
>
> *From:* Mario Loffredo <[email-masked]>
> *Sent:* Tuesday, February 25, 2020 9:02 AM
> *To:* Hollenbeck, Scott <[email-masked]>; [email-masked]
> *Subject:* [EXTERNAL] Re: [regext] FW: I-D Action: 
> draft-hollenbeck-regext-rfc7483bis-00.txt - Further feedback
>
> Hi Scott,
>
> */[SAH] Which “type” boolean are you referring to, Mario?/*
>
/*The same used in the definition of "delegationSigned".*/
>
> 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
>
> */[SAH] I think I’d like to leave these as-is. It might not be optimal 
> to re-use the “XXXX” pattern, but I don’t think there’s any confusion 
> about these being nothing more than representative of handle values./*
>
/*OK*/

/*Mario
*/

> *//*
> */Scott/*
-- 
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
#pleasestayathome

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 7 May 2020 09:43:22 +0200

Hi Scott,

please find my comments below.

> [SAH] I'll change lunarNic to lunarNIC. I'm also going to change the text in 4.1 a bit to be clear that these string literals are the values that should be registered with IANA and returned in RDAP…
OK.
> [SAH] Is there any chance that one or more of the URLs might refer to something other than an http-accessible resource? I'm not sure, so I think I'd like to keep this as "Internet" rather than "Web…

No problem. I suggested "Web" instead of "Internet" because it seemed to 
me more compliant with the definition included in RFC5988 and RFC8288.

> [SAH] I agree, so I'll change "The "href" JSON value MUST be specified" to "The "value", "rel" and "href" JSON values MUST be specified".
OK
>     "description" JSON value MUST be specified. All other JSON values are
OK
> [SAH] I'm not sure about this one. The current text doesn't say anything about any of these values being OPTIONAL (it says "The "events" array consists of objects, each with the following members")…
All the "event" objects appearing in the doc include both the 
"eventAction" and "eventDate" members and only sometimes the remaining 
two members so we can derived that only "eventAction" and "eventDate" 
are required.
> [SAH] OK. I'll change "with each object containing the following members" to "with each object containing the following REQUIRED members".
OK
> 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
OK
> [SAH] I'll change this to "with all appropriate values given". I don't believe entities are commonly associated with name servers.
OK
> [SAH] According to the current text, yes.
OK
> [SAH] Agreed, will fix. Thanks for the detailed review!

OK

Best,

Mario

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 7 May 2020 12:02:45 +0000

From: Mario Loffredo <[email-masked]>
Sent: Thursday, May 7, 2020 3:15 AM
To: Hollenbeck, Scott <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt - Further feedback

Hi Scott,

   From: Mario Loffredo <[email-masked]><mailto:[email-masked]>
   Sent: Tuesday, February 25, 2020 9:02 AM
   To: Hollenbeck, Scott <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
   Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt - Further feedback

   Hi Scott,

   The same used in the definition of "delegationSigned".

   [SAH] OK, Now I understand. Will fix.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 7 May 2020 12:09:48 +0000

> Sent: Thursday, May 7, 2020 3:43 AM

[snip]

> > 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:
> >
> > [SAH] I'm not sure about this one. The current text doesn't say anything
> about any of these values being OPTIONAL (it says "The "events" array
> consists of objects, each with the following members"), so, by default, I
> understand the text to mean that they're all REQUIRED. I could say "The
> "events" array consists of objects, each with the following REQUIRED
> members". Would that work?
> All the "event" objects appearing in the doc include both the "eventAction"
> and "eventDate" members and only sometimes the remaining two members
> so we can derived that only "eventAction" and "eventDate"
> are required.

It's also possible that the examples are broken. Unfortunately, this is a place where the spec is unclear. What have people actually implemented?

[snip]

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

Jasdip responded to this yesterday. Does anything need to change as a result?

Scott