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

[Patrick Mevzek]

 On 2019-07-03 09:45 -0500, Pieter Vandepitte 
 wrote:> 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


(except that sometimes updates may be linked in the sense of one should 
stop if one is giving out errors; using pipelining is explicitly allowed 
by the RFC, may or may not be allowed by registries - so it is not just 
a matter of clients being not smart enough - and will certainly not 
solve the problem of conditionally continuing the batch or not)


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)...


There is (at least) one (existing[1]) use case that is absolutely not 
covered:

in some registry, some names are "bundled" together.

If you transfer/update one name from the bundle, you need to apply the 
same operation to others.
Currently it is done in a fashion where the first command is put in 
pending state until all other commands are done, at which point all are 
released as done.


In situations like that, you would need a way to send multiple commands 
in the same "batch", like a logical unit, or a DB transaction.
Or an EPP extension clearly describing bundles, identifying them, and 
being then able to send commands not on a domain but on a bundle of 
domains, and I do not think this extension exists anywhere.


EPP does not provide that and I am not sure it should provide that anyway.
I will try to read the underlying proposal at some time, but I wanted to 
react to add a use case that may not be known.


[1] upon checking, that specific behavior I described existed but ceased 
to recently when the registry changed its backend (now any single 
operation on a domain in a bundle does the same operation for all other 
domains in the bundle - that clearly solves the "batch" problem but then 
exposes to many other pitfalls)

--
Patrick Mevzek

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gould, James]

Peiter,

Thank you for re-reading the DSF draft and also thank you for the references to 
the other CSV initiatives.  I’ll review those initiatives and see what can be 
reused from them.

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)...

There are cases that cannot be easily done via EPP, such as executing a bulk 
transfer, or that need to be executed in a controlled manner to minimize the 
impact to the provisioning database, such as providing a bulk mechanism for 
populating the contact data.  EPP is designed to handle general provisioning 
operations, but is not designed to deal with special cases that are better 
handled via a bulk processing engine using DSF.  A pipelining EPP client can 
certainly handle a large volume of updates, but EPP may not provide the 
features needed for the job or the server can execute the job faster without 
the client-side constraints (connection / bandwidth) and without putting the 
provisioing database at risk.


—

JG

[cid:image001.png@01D255E2.EB933A30]

James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext  on behalf of Pieter Vandepitte 

Date: Wednesday, July 3, 2019 at 10:46 AM
To: "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting (2019JUN11) Notes

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  on behalf of Roger D Carney 

Date: Wednesday, 3 July 2019 at 14:17
To: "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 

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

[Pieter Vandepitte]

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  on behalf of Roger D Carney 

Date: Wednesday, 3 July 2019 at 14:17
To: "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.”



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] REGEXT Interim Meeting (2019JUN11) Notes

[Roger D Carney]

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/Structure/Reports
 (how does the Data Set File 
Format 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."



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext