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

Mario Loffredo <mario.loffredo@iit.cnr.it> Wed, 17 June 2020 17:07 UTC

Return-Path: <mario.loffredo@iit.cnr.it>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28583A0AB4; Wed, 17 Jun 2020 10:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCSJukAB341O; Wed, 17 Jun 2020 10:07:39 -0700 (PDT)
Received: from smtp.iit.cnr.it (mx3.iit.cnr.it [146.48.98.150]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF063A0AAC; Wed, 17 Jun 2020 10:07:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 5C099601152; Wed, 17 Jun 2020 19:07:36 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mx3.iit.cnr.it
Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx3.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Fg3kNzARsob; Wed, 17 Jun 2020 19:07:33 +0200 (CEST)
Received: from [192.12.193.108] (pc-loffredo.nic.it [192.12.193.108]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id 685BA60015D; Wed, 17 Jun 2020 19:07:33 +0200 (CEST)
To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org>, "internet-drafts@ietf.org" <internet-drafts@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
References: <159162988692.27209.10007278285596026415@ietfa.amsl.com> <ea6ab7f4-1540-0367-b3cb-b2abd2187752@iit.cnr.it> <5d79521690f0478fb51764fb90159538@verisign.com>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
Message-ID: <efb9e5de-c1a5-06f9-805b-994cb9e5d85c@iit.cnr.it>
Date: Wed, 17 Jun 2020 19:05:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <5d79521690f0478fb51764fb90159538@verisign.com>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: it
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/u02RCPEbHRR7ih9orPfq6h0QUxk>
Subject: Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 17:07:42 -0000

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