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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Thu, 07 May 2020 12:09 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 A1F753A003E for <regext@ietfa.amsl.com>; Thu, 7 May 2020 05:09:51 -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 7bKiC7vTc9Aw for <regext@ietfa.amsl.com>; Thu, 7 May 2020 05:09:50 -0700 (PDT)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 44DE93A003D for <regext@ietf.org>; Thu, 7 May 2020 05:09:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2529; q=dns/txt; s=VRSN; t=1588853390; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=3pZxukyQKOfLvxdw0XbRbJ4lZo26FCN8jf1GYC9oIl4=; b=qaQR0BmN6rGCaDMR8/yo/YcO3kzpC3Car3WvSlPb0ElyQUUpa4cBk6n6 o6mVwpEGw0GFWK/IPbUANw0/ZUOA5SXxbd/Ofdr2pGbu3Xsfcni6w485i uuryU86uj1yHpTSLoh/YrUYsipp6PnwP/kVnh5nc2YQzbUPiuQT4o2h+Z m1p4vDWpiXkzW544xvwhXERhxMsrECtsOpY81uoldAbGnHSabwlEcfyB2 makGtDqfKyGgVpueu9d6vodswy7rwUPWR3LwIJXqiSfLaBXjX51BA8x1K TTqanZmvGME+gyOcL8IrDXlpoF0KF/RCfoedWAk8eY00PQpayIWlLkFs1 g==;
IronPort-SDR: YbqHLsx2o5RVj+qZsZh+daxAqCEdBCO2kJQEI+k77O1Y4VhhRz+NoiLDWpw98T2ap8Eo/d+kyK W+mponW+DBjj0hEVa6LpITylGlT0Y2WgstvaYlFrUDTmTqPIACaXvKKZQEcRib1kqzklO3u7Ty v/NsGoGt1YZOkkSzliiqGc1ioqY5aVksIweZqu1t1TOzhUrof23wprIgWveKVan1rQh+aMTAbw cDnwE+yYthSHgIyv7k+H69F270nVzU5EOKz9Lmu4A4OWOYR46PXpXUVEk8oJkTWOKx2IzLAdS4 WZA=
X-IronPort-AV: E=Sophos;i="5.73,363,1583211600"; d="scan'208";a="1384313"
IronPort-PHdr: 9a23:Ie6zExxnvnnCTdTXCy+O+j09IxM/srCxBDY+r6Qd0uoULPad9pjvdHbS+e9qxAeQG9mCtrQU06GK7ejJYi8p2d65qncMcZhBBVcuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6JvjvGo7Vks+7y/2+94fcbglVhDexe7B/IAm5oQjet8QdnJdvJLs2xhbVuHVDZv5YxXlvJVKdnhb84tm/8Zt++ClOuPwv6tBNX7zic6s3UbJXAjImM3so5MLwrhnMURGP5noHXWoIlBdDHhXI4wv7Xpf1tSv6q/Z91SyHNsD4Ubw4RTKv5LptRRT1iikIKiQ5/XnXhMJukaxbvByvqR9xw4HWYYGaKPVwcazGcNMGXGpBXNpdWzBdDo+iaYYEEuoPPfxfr4n4v1YCoxmwBQ6oBOPr1DBIgGT50rMm3OQiCQ3NwREuEM4JsHTIsNX5OroZXOeuzKnIyjXDa/dW1in76IfTbB8uvfKMUKluccXP00kvFhjFjlSfqYzjJT+ayuMNs22C4udmSOmghHIppRtrrTiz2scjlJPJhoQNx13Z9Sh0wJo4KMO6RUNmZdOpH4ZduS6GO4ZyXs8uXn1ktSg0xLAbupO2czQGxIgnyRDfd/CJfYqF7Bz9WeuVPTp1gm9udrGnhxuq7ESs1vfwWtS23VtEtCZJj9nBu34X2xHc6cWLUuZx8lu71TqS1Q3f9vtILV07mKfYMZIt3709m5wOukrZBCD2gl/5jKqOe0Uh/ein9vrob639pp+ZK490kgb+MrkymsCnAeQ3LAwOX2+D9OmhyLPt5VD1T7VSgPM5k6bVrI3WKd4FpqGlBA9VyJ4j5wylADi7ytgYg2MHLElDeB6dk4fpPFTOLOj5Dfe5nVusjC9my+3aMrH7H5nALHbOnK38cbt95UNQ0gU+wNNH65JREL4BIfbzWkHrtNzfCx80Kxe0w+bgCNV50oMRR2SPDbSHP6zOsl+F/fwvLPeWZI8Uozb9Kvcl5/j0gXAlnl8deLGl3YELZ3CgAvRmP0KZbGLpgtgbC2cKvw0+QPbuiF2FXz5TaWyyULwh6TE8E4+mDIbDRpy3jLOd2ie7BIdaZmFaClqUC3fna52EW+sQaCKVOsJhiCILVbe/RI4uyRGjrw76xKR7Lura4CEYsojj1Ncmr9HUwFs3/CZ1CIKZ1G+DVWx4mUsJRiNw16Zl501hgB/X1KFigvseEdtd6elEXgASNJ/Aied8EZbzRlSFNp2TRVmrUsmOADwtQJQ22dBEKxJnFtqvngzr3ie2DfkSjbPdV7Iu9aeJlVj2I8JwzXzL36plx2ItRddTfyXyna548wzeAYTEmEaxiauwdL8d0yiL/2CGmznd9HpEWRJ9BP2WFUsUYVHb+Iz0
X-IPAS-Result: A2HNAgBB+bNe/zCZrQpmHAEBAQEBAQcBARIBAQQEAQFAgUeBfYJMCpUim14LAQEBAQEBAQEBBwEvBAEBhEQCgiw4EwIDAQELAQEBBQEBAQEBBQMBAQEChkuCOyKDaQEBAQECATo4EwQCAQgRBAEBHxAyHQgCBAESCIJTgyivfnSBNIVQhQiBOIxegUI+gRGDED6KQASyUQMHgkiYDiWCW4hhkWSQF50cAgQCBAUCFYFpgXlwgzlQGA2Qeo4QdDcCBggBAQMJkTaBEAEB
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; Thu, 7 May 2020 08:09:48 -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; Thu, 7 May 2020 08:09:48 -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: AQHV5wWQ6lg3nGr8IkuuyG9xLp1YYKiby4HwgAEv3wCAAAXgUA==
Date: Thu, 07 May 2020 12:09:48 +0000
Message-ID: <87e1de63027b4b4395181ccf8c87d42b@verisign.com>
References: <158202847369.14106.8963334452011519309@ietfa.amsl.com> <bb1c73111e9f48ff83f8b1e454faf954@verisign.com> <bb0c899d-ac1f-7646-f45c-4b7c1955d3a1@iit.cnr.it> <76649585f0a7421c939da605251e6ed3@verisign.com> <90d78f71-6ef0-7726-63ff-a7dfdf31497c@iit.cnr.it>
In-Reply-To: <90d78f71-6ef0-7726-63ff-a7dfdf31497c@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/-oC3kiT1c1_muN9DY45qFZux2hk>
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: Thu, 07 May 2020 12:09:52 -0000

> -----Original Message-----
> From: Mario Loffredo <mario.loffredo@iit.cnr.it>
> Sent: Thursday, May 7, 2020 3:43 AM
> To: Hollenbeck, Scott <shollenbeck@verisign.com>; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-
> rfc7483bis-00.txt
> 
> Hi Scott,
> 
> please find my comments below.
> 
> Il 06/05/2020 20:50, Hollenbeck, Scott ha scritto:
> > Thanks, Mario! More below.

[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:
> >
> > "  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?
> 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?
> >
> > [SAH] Maybe one of the RIR guys can address this question. Jasdip? Tom?
> Anyone?

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

Scott