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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Wed, 06 May 2020 18:50 UTC

Return-Path: <shollenbeck@verisign.com>
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 D6E193A0A98 for <regext@ietfa.amsl.com>; Wed, 6 May 2020 11:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 yGRaNpHXizCW for <regext@ietfa.amsl.com>; Wed, 6 May 2020 11:50:41 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D2A3A0A92 for <regext@ietf.org>; Wed, 6 May 2020 11:50:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=5219; q=dns/txt; s=VRSN; t=1588791043; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=BlBw5JriD+n/MarVkhQYWLuyKJgBZ4WjlWYDqCSjkk8=; b=DQpJFkB7Zgzs+ObBYsrvg5b5UDewTKJBIUWkRI2nZXJtgPPtjHe0GcYN mJDo9fOW+Iko/oNLCOXNynoz1+FcDzFdOU+zGEAbV9YlKyoWwiXVT12o+ tuxdc0c5NHaOtAMM6MaIIzrd1VlZsb/HUPeOmyDeL2WwqPZI4K20tZZnn M+ZhsarVlbEp9N1fIiUOL937UabCj883dEGyHV3w5q9NW4t6PJ2ilSCCe 7a1A9iDTuZ7uJVgxxbtFDLJ8pcwXv0vLDqiE/zbleIlltLtv3tIR1QNpK oYlStJgS12mS3fjdL8DaV7OyxN865HvV0PDef5CdodPciOUzSQZo+q4Jw g==;
IronPort-SDR: JgC+WQHqiuuf+Us6QEoXVbRuNWC6h1SC796opps4POi82J2kwnEvMr2tJhb/Q9Q4vgeWocQGtI 7T1F+2a+fSp2DdYaZQT3XjZSMvUnd7Dy4eaN52nG0oS68v6GhrFeD02FCIzkxcvhj1Rnv7z/g8 y4SgResTmauLhzxQi9HHYOQDK8uE5pREZh+n9JQkFNoSkPIzojzjGxBOGDIOSz+pI2Qoj84ZoO j8wk9w7p4fOdSldA0Z+8rEJPdr8F4Wx7b0SJuaTyt/Xko6mSROWspkHuBP8T7rPUTN07sBDcDH 4Vk=
X-IronPort-AV: E=Sophos;i="5.73,360,1583193600"; d="scan'208";a="1517398"
IronPort-PHdr: =?us-ascii?q?9a23=3A/KFZaBSMIHTo1ifKKw0VVgWQLNpsv+yvbD5Q0Y?= =?us-ascii?q?Iujvd0So/mwa67ZBaOt8tkgFKBZ4jH8fUM07OQ7/m9HzNQqs/b6jgrS99lb1?= =?us-ascii?q?c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUh?= =?us-ascii?q?rwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9IRmrrQjdrMsbjIhtJqos1B?= =?us-ascii?q?fFvGZDdvhLy29vOV+dhQv36N2q/J5k/SRQuvYh+NBFXK7nYak2TqFWASo/PW?= =?us-ascii?q?wt68LlqRfMTQ2U5nsBSWoWiQZHAxLE7B7hQJj8tDbxu/dn1ymbOc32Sq00WS?= =?us-ascii?q?in4qx2RhLklDsLOjgk+2zRl8d+jr9UoAi5qhJ/3YDafZ2VOvR9cKPTf9waRH?= =?us-ascii?q?ZOUMleWCFaHoO8dokPA/YdMepEsYXwoUYFoxukBQmrAePi0jFEiH3x3a0+1+?= =?us-ascii?q?QuDwfG0xc+EN0Ss3TYtMj+OroOXuCy0KnI0TvPZO5R1Dfm6IjIdRQhofWSUr?= =?us-ascii?q?J2asXe11UgFwDeg1WOt4PlJTKV1v8Ms2iU6epsT/6gi2kiqwxopDWk28gjhJ?= =?us-ascii?q?XTiI0P1lDE6Tt2wJwzJdCgVUN2Yd6pHYdOuiyYKoZ7RswvTnxntiomzrAKpY?= =?us-ascii?q?O3cDQExZop2hPSaPOKf5SU7hzjVOidPTl2iXBrdr+hgxu/7U6twfD/WMmsyF?= =?us-ascii?q?tGszZJnsPRun0P2RHf8NWLR/tz80u71juC1Bjf5vxYLUwuiKbWKYItzqQtmp?= =?us-ascii?q?ccsknPBDL6lUbwgaSLbEsr4PKo5P7iYrj+o5+cMJJ7hR/mP6Q1n8y/Hfw4Mg?= =?us-ascii?q?8TX2iH4ei81KPs/Un+QLhSk/A4jrHXvI3aKsoDqaC2AhNZ3ps55xahEzim18?= =?us-ascii?q?4YnWEdIF1fZR2LlZbpO0vVIPD+F/uwn1OskDJzy/DHOL3uHInNI2DenLv9Z7?= =?us-ascii?q?px9kxRxQQpwdxC559ZBKsNLf3wV0PpsdzXFB45Mwi6w+b9D9V905sTWXmPAq?= =?us-ascii?q?+eNKPStUGH5uQ0LOaSeIAVuy3wK+Y76P70jH85gl4dfaav3ZcNdH+4GfFmL1?= =?us-ascii?q?2DYXXwmtcBDXsKvg0mQezvklKCSz9TZ3GoU6I44TE7BoymDZ3dSY+wh7yMxy?= =?us-ascii?q?a7HpxKZmxcFl+MF23oe5+FW/cQcCiSONNukiQYVbi9TI8szQuuuxH1y7V5Ie?= =?us-ascii?q?vU5jYVtZP929hp6e3fjxYy9SZ7D5fV72bYBWR9hGIPATsx0q5lrEB64laCze?= =?us-ascii?q?5zheYeFMAZr6dMWx07MtjYyOJ0Ed3+XSrAf8vPQ1C8BNS6V3V5BMg8zNIef2?= =?us-ascii?q?58FsmsyBfZ0GDiV6UYmLGbGLQ1/77SmX/rKJAu5WzB0fxrr14iRsZJP2Cthe?= =?us-ascii?q?o3zAPUG5KD2xGCl6Gucaka1iPG90+dwHCPp0BXVkh7VqCTDiNXXVffsdmsvh?= =?us-ascii?q?CKdLSpE7lyagY=3D?=
X-IPAS-Result: =?us-ascii?q?A2HNAgDRBrNe/zCZrQpmHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UeBfYEbgTEKlSmbXgsBAQEBAQEBAQEHAS8EAQGERAKCJjgTAgMBAQsBAQEFA?= =?us-ascii?q?QEBAQEFAwEBAQKGS4I7IoNpAQEBAQM6OBcCAQgRBAEBHxAyHQgCBAEJCQiCU?= =?us-ascii?q?0y2W3SBNIVQhQiBOIxegUI+gRGDED6KQASYA5pOAweCSJJphSUlgw6aEpAXn?= =?us-ascii?q?RwCBAIEBQIVgWmBeXAvgwpQGA2Qeo4QdDcCBggBAQMJkTaBEAEB?=
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 6 May 2020 14:50:38 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1913.005; Wed, 6 May 2020 14:50:38 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt
Thread-Index: AQHV5wWQ6lg3nGr8IkuuyG9xLp1YYKiby4Hw
Date: Wed, 6 May 2020 18:50:38 +0000
Message-ID: <76649585f0a7421c939da605251e6ed3@verisign.com>
References: <158202847369.14106.8963334452011519309@ietfa.amsl.com> <bb1c73111e9f48ff83f8b1e454faf954@verisign.com> <bb0c899d-ac1f-7646-f45c-4b7c1955d3a1@iit.cnr.it>
In-Reply-To: <bb0c899d-ac1f-7646-f45c-4b7c1955d3a1@iit.cnr.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/kWZ9ix80uaUAHqXjJsf_L2IN-Ys>
Subject: Re: [regext] FW: I-D Action: draft-hollenbeck-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, 06 May 2020 18:50:50 -0000

Thanks, Mario! More below.

 

From: Mario Loffredo <mario.loffredo@iit.cnr.it> 
Sent: Wednesday, February 19, 2020 4:17 AM
To: Hollenbeck, Scott <shollenbeck@verisign.com>om>; regext@ietf.org
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