Skip to main content

Minutes interim-2019-regext-01: Tue 16:00
minutes-interim-2019-regext-01-201906111600-00

Meeting Minutes Registration Protocols Extensions (regext) WG
Date and time 2019-06-11 16:00
Title Minutes interim-2019-regext-01: Tue 16:00
State Active
Other versions plain text
Last updated 2019-07-12

minutes-interim-2019-regext-01-201906111600-00
Meeting started at 11:04 (UTC-5)
 
Attendees: Roger Carney (GoDaddy), Gordon Dick (Nominet), Joseph Yee (Afilias)
 
Agenda

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