Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt

Hi Scott,

please find my comments below.

Il 17/06/2020 15:23, Hollenbeck, Scott ha scritto:
>   
>
>   
>
> From: regext <regext-bounces@ietf.org> On Behalf Of Mario Loffredo
> Sent: Thursday, June 11, 2020 11:09 AM
> To: regext@ietf.org; internet-drafts@ietf.org; i-d-announce@ietf.org
> Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt
>
>   
>
> Hi Scott,
>
> please find below some possible changes to RFC7483bis.
>
>   
>
> 1) Section 1.2 - I would replace the following sentence:
>
> OLD
>
> simple data types conveyed in JSON strings
>
> NEW
>
> simple data types conveyed in JSON primitive types (strings, numbers, booleans, and null)
>
> [SAH] OK
>
> 2) Section 2.1 - I would replace the following sentence:
>
> OLD
>
> In other words, servers are free to not
>     include JSON members containing registration data based on their own
>     policies.
>
> NEW
>
> In other words, servers are free to not
>     include unrequired/optional JSON members containing registration data based on their own
>     policies.
>
>
>
> [SAH] Let me suggest a different rewording: "In other words, servers are free to omit unrequired/optional JSON members containing registration data based on their own policies"
>
Agreed.
> 3) Section 3 - There are some empty lines in the text.
>
>
>
> [SAH] I'll try to fix those.
>
>
> 4) Section 4.1 - I would rewrite the following sentence using MUST or REQUIRED:
>
> This data structure appears only in
>     the topmost JSON object of a response.
>
>
>
> [SAH] Suggestion: "This data structure MUST appear in the topmost JSON object of a response"
Agreed.
>
> 5) Section 4.4 - The following sentence  seems to be inconsistent with the content of some figures (e.g. Fig. 15, 17, 23, ...) where a "lang" element is included in jCard
>
>     The "lang" attribute may appear anywhere in an object class or data
>     structure except for in jCard objects.
>   
>
> [SAH] Agreed. I'll strike "except for in jCard objects".
>
>
> 6) Section 6 - I would uppercase the word "may" in the following sentence:
>
>     Some non-answer responses may return entity bodies with information
>     that could be more descriptive.
>
>   In addition,  which members of an error response are required?
>
>
>
> [SAH] Agreed on the use of MAY. The text says that an error includes all three fields (error code, title, and description). I believe that means that all three are REQIUIRED.
>
In my opinion "errorCode" should be required while "description" should 
be optional. About "title", I don't have a clear position.
> 7) Section 10.2.3 - The definition of "last changed" event type seems to be inconsistent with "upDate" defined in RFC 5731,5732,5733. For example, I report an extract from RFC5731 here in the following:
>
>     -  An OPTIONAL <domain:upDate> element that contains the date and
>        time of the most recent domain-object modification.  This element
>        MUST NOT be present if the domain object has never been modified.
>
> So, should we redefine the "last changed" event accordingly? Should we change all the examples where "last changed" date is equal to "registration" date?
>
> [SAH] I think we can leave this one alone. The meaning seems clear to me since we also have the registration event. We could change the examples, but before I do that I'd like to know what people have implemented. Do servers return this value for an object that has been registered, but never updated?

OK. I agree with you that we should wait for other opinions.

Mario

>
> Best,
>
> Mario
>
>   
>
> Il 08/06/2020 17:24, internet-drafts@ietf.org ha scritto:
>
>   
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Registration Protocols Extensions WG of the IETF.
>   
>          Title           : JSON Responses for the Registration Data Access Protocol (RDAP)
>          Authors         : Scott Hollenbeck
>                            Andy Newton
>   Filename        : draft-ietf-regext-rfc7483bis-00.txt
>   Pages           : 84
>   Date            : 2020-06-08
>   
> 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-ietf-regext-rfc7483bis/
>   
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-regext-rfc7483bis-00
> https://datatracker.ietf.org/doc/html/draft-ietf-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/
>   
>   
> _______________________________________________
> 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
#pleasestayathome