Re: [regext] REGEXT Interim Meeting (2019JUN11) Notes

Pieter Vandepitte <pieter.vandepitte@dnsbelgium.be> Wed, 03 July 2019 14:45 UTC

Return-Path: <pieter.vandepitte@dnsbelgium.be>
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 3B6A01202DC for <regext@ietfa.amsl.com>; Wed, 3 Jul 2019 07:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dnsbelgium.be
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 KvaV_It4aezr for <regext@ietfa.amsl.com>; Wed, 3 Jul 2019 07:45:47 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150122.outbound.protection.outlook.com [40.107.15.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B205120320 for <regext@ietf.org>; Wed, 3 Jul 2019 07:45:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnsbelgium.be; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AI5M2vLxZnPHP+/Xmpr62RlsLvpb7RfDmGcOGjIfmXY=; b=z2aSodS8IeAv8nUxdWdv4L3aaXfBK2tppt2+5KyErSj92MgZLyLVHm0X+4PtCEMxY5A+BJJAmL6vfLpK8OKMgLsxnUAe4qkY0SfWSyKmrGgfJY6YLzDDyxZAaTwc2TZF5lySRoY0YyEXGZM68ALwMW52NC4YvEe5q5yfFps9DbM=
Received: from VI1PR10MB3664.EURPRD10.PROD.OUTLOOK.COM (10.186.163.142) by VI1PR10MB2079.EURPRD10.PROD.OUTLOOK.COM (52.134.28.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Wed, 3 Jul 2019 14:45:30 +0000
Received: from VI1PR10MB3664.EURPRD10.PROD.OUTLOOK.COM ([fe80::a509:7b4c:1bda:ad88]) by VI1PR10MB3664.EURPRD10.PROD.OUTLOOK.COM ([fe80::a509:7b4c:1bda:ad88%2]) with mapi id 15.20.2052.010; Wed, 3 Jul 2019 14:45:30 +0000
From: Pieter Vandepitte <pieter.vandepitte@dnsbelgium.be>
To: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [regext] REGEXT Interim Meeting (2019JUN11) Notes
Thread-Index: AQHVMa32da0HbRMqJ0OKChETDrsVsg==
Date: Wed, 03 Jul 2019 14:45:30 +0000
Message-ID: <4AC76D0F-F0F4-42B9-9A0F-29C37D5EA2F1@dnsbelgium.be>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pieter.vandepitte@dnsbelgium.be;
x-originating-ip: [2a02:1802:5f:131:dc42:f5a2:3900:2260]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 385f55de-2a79-4bbc-c818-08d6ffc518ac
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1PR10MB2079;
x-ms-traffictypediagnostic: VI1PR10MB2079:
x-ms-exchange-purlcount: 7
x-microsoft-antispam-prvs: <VI1PR10MB20792E691932E0F4E1BCD669E2FB0@VI1PR10MB2079.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00872B689F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(136003)(396003)(39830400003)(366004)(51914003)(199004)(189003)(99286004)(186003)(86362001)(14454004)(6486002)(102836004)(6506007)(53546011)(229853002)(2501003)(33656002)(966005)(606006)(2906002)(68736007)(25786009)(2351001)(8676002)(6436002)(46003)(81166006)(486006)(316002)(44832011)(1730700003)(8936002)(476003)(2616005)(81156014)(6116002)(71200400001)(256004)(508600001)(14444005)(36756003)(91956017)(76116006)(66556008)(73956011)(66946007)(5660300002)(66446008)(66476007)(74482002)(64756008)(6512007)(6306002)(54896002)(53936002)(7736002)(236005)(71190400001)(5640700003)(6246003)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR10MB2079; H:VI1PR10MB3664.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: dnsbelgium.be does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: zeQg9ApcHjH0LEb1skIp8L2at7sOUg9mw6YfjkHzeI7aQ7Z+XJsBmzeLn6EhEdNkGkkjnWIdh2QW2fYu5uBMV4Owsq3FIPd1NfOzmGQdf1kRM51Gg5L5TwHV02Fs7UyKIEVywGEuo2CM2z4U0p2/igcAKA1diBWOGo2L0zLz7nsBP7KzWrZBmb9HKLkzi1iye+bKe61BZjGmeU0COv3Y/unnM+8DMItiBhSPvxhcd20/GzMZQ17SVAlnQtSBLwrdmZruaZffukre1oWfGC4Q0Nw/SlYY4PDuGVe9zNJOJYIpKYJKbB6arjJIzpeNks85HMBTCID4IEcef9he949X0fNiRiIa7YQJBgc/W9ffEcTa/wsahpAw9A2ejirCYGXRhrESEqdBdpVH4aFbwwlk+KdAI9mOrmiDmFwSY4PNtw4=
Content-Type: multipart/alternative; boundary="_000_4AC76D0FF0F442B99A0F29C37D5EA2F1dnsbelgiumbe_"
MIME-Version: 1.0
X-OriginatorOrg: dnsbelgium.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 385f55de-2a79-4bbc-c818-08d6ffc518ac
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 14:45:30.5419 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 695195de-c0cb-4478-9204-2a861e60e59c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pieterv@dnsbelgium.be
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR10MB2079
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/G_972rjwMqzZDKdFHNG7UTQvfFI>
Subject: Re: [regext] REGEXT Interim Meeting (2019JUN11) Notes
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, 03 Jul 2019 14:45:51 -0000

Thanks for the minutes. This also triggered me to re-read the DSF draft :)

Regarding reporting,

I don’t know the details of the conversations in that meeting, but keep in mind that we are not the first ones to invent the wheel...

There are initiatives like CSV on the web (https://www.w3.org/TR/tabular-data-primer/), DCAT (https://www.w3.org/TR/vocab-dcat/ ) or https://schema.org to describe data sets and/or catalogs....

Regarding the draft,

Without questioning the usefulness of this draft, I don’t see the use case for EPP (intro), so I would try to come up with other examples.
The current EPP specifications do not prevent a client to perform “bulk updates”, it’s just the clients that are not smart enough. If clients would operate asynchronously (not waiting for a server response), the only overhead is the verbosity of XML (vs. message RTT when operating synchronously). I doubt that this is a real issue (except if you’re provisioning billions of objects/updates)...

Also, it would be nice if the draft would build upon existing initiatives (like the ones above) to describe the data set metadata...

Just my 2 cents...

Pieter

From: regext <regext-bounces@ietf.org> on behalf of Roger D Carney <rcarney@godaddy.com>
Date: Wednesday, 3 July 2019 at 14:17
To: "regext@ietf.org" <regext@ietf.org>
Subject: [regext] REGEXT Interim Meeting (2019JUN11) Notes

Meeting minutes from our quick Interim Meeting on June 11th, enjoy! See everyone in a few weeks.

Meeting started at 11:04 (UTC-5)

Attendees: Roger Carney (GoDaddy), Gordon Dick (Nominet), Joseph Yee (Afilias)


Agenda

  1.  Reporting Repository<https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/>/Structure<https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-report-structure/>/Reports<https://datatracker.ietf.org/doc/draft-sattler-registry-domain-fee-report/> (how does the Data Set File Format<https://datatracker.ietf.org/doc/draft-gould-regext-dataset/> fit in).

We talked for about 15 minutes, I suggested that we would schedule a meeting before the next IETF, maybe the first couple weeks of July.

We agreed that expanding the specific communications protocol from just sFTP to a small number of them (sFTP or HTTPS or ??) would be good for the registry side. As for using the Data Set File format suggested by Gould, we thought that it seemed to be overly complex/heavy handed for this scenario, though we would like to have a fuller discussion around how/where it does fit.

Jim Gould was not able to make it, but he did send me these notes: “I just wanted to let you know that the Data Set File format draft has not been updated yet to support reports, but I have a domain model defined that would support defined bulk operations with the definition and data in a single file and report definition with the definition in a separate file with a reference to the report data file.  The report defining and data can be contained in a single file, but I anticipate that it will be a separate file.  The meta data about the report including its format is in the definition along with the definition of a type that can be registered in an IANA registry.  A registry could implement  a registered report and even extend it by adding more fields.  Clients that are not interested in the additional fields can process the field based on the IANA registered definition.  Both standard reports and custom reports can be defined using a common set of meta data and a common set of field elements.  The field elements are defined using XML schema types and can be fully validated by a processor.  Custom field elements can be defined.  The field definition approach is taken from the CSV data escrow format and the existing Data Set Format draft.  The key with the approach is that we can define the Wild West using a standards based mechanism that will support automation and provide a lighter weight mechanism for standardization with the use of an IANA registry that contains the report definition with a unique type identifier.  There can also be sub-types to support additional granularity.  I intend to make a dent in updating the draft this month.”