Thank you Robert,
Comments inline, prefixed with GL -
Regards,
Gustavo
On 4/8/20, 10:04, "Robert Wilton via Datatracker" <nore...@ietf.org> wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-regext-data-escrow-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=gZgTftWuC9SsZdq_QWTwb-T4RjxNiDq9i2krpdXgHfM&s=QHMiOWDTGvuiZh0DtVdWwx_J4DxECAFWGpr-Srux4pQ&e=
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dregext-2Ddata-2Descrow_&d=DwICaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=gZgTftWuC9SsZdq_QWTwb-T4RjxNiDq9i2krpdXgHfM&s=YhAtC7C7hDwiSnfUvetOd_lI7t6Q5KkhtITQ9Vv9OXE&e=
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Hi,
I spotted some issues with the terminology and the description of the
algorithm
that I would like you to please address.
Section 2: Terminology
The definitions provided for "Differential" vs "Incremental" are the
opposite
to their standard meaning in backups. The term definitions should be
reversed
to align with the common vernacular. I.e. differential is the diff against
the
last full backup, incremental is the backup since the backup (of any type)
was
performed.
GL - The definition of differential in the draft complies with the legal use in
the gTLD space. The amount of work required to make this change, make it
unrealistic. It's worth mentioning that data escrow is not the same as a backup.
5.1.3. Child <deletes> element
The specification for each object to be escrowed MUST declare the
identifier to be used to reference the object to be deleted.
An identifier is equally important in the add/update case as well to know
which
object needs to be updated. I would suggest pulling this sentence out of
this
subsection and adding a new subsection under 5 to briefly describe the
requirement on object identifiers and how they are used both in the delete
and
contents cases.
GL - Ok, I will update this in the draft.
5.1.4. Child <contents> element
When applying Incremental or Differential Deposits (when rebuilding
the registry from data escrow deposits) the relative order of the
<deletes> elements is important, as is the relative order of the
<contents> elements. All the <deletes> elements MUST be applied
first, in the order that they appear. All the <contents> elements
MUST be applied next, in the order that they appear.
I think that the text for processing deposits would be better outside of
section 5.1.4, since some of the text is referring to section 5.1.3, and
isn't
specific to the <contents> element.
Why does the relative order of <delete> elements matter? Is this because of
potential dependencies between the elements,
GL- Correct
if so, it would be useful if that
was explicitly stated. If not, then I don't understand why the order of
deletes would matter.
GL - Ok, I will update this in the draft.
Also, should there be a statement that an object SHOULD NOT exist multiple
times (either in the <deletes> or <contents> elements in a single deposit)?
GL - Ok , I will add this to the draft.
If an object is present in the <contents> section of several deposits
(e.g. Full and Differential) the registry data from the latest
deposit (as defined by the Timeline Watermark) SHOULD be used when
rebuilding the registry.
This doesn't just apply to objects in the <contents> section, but equally
applies if the object is present in any <deletes> or <contents> section.
I.e.
the status of whether an object exists and its contents must be taken from
the
latest deposit.
GL - Ok, I will update the draft.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Abstract:
This document specifies the format and contents of data escrow
deposits targeted primarily for domain name registries. However, the
specification was designed to be independent of the underlying
objects that are being escrowed, therefore it could be used for
purposes other than domain name registries.
Propose tweaking the abstract text to something like:
This document specifies the format and contents of data escrow
deposits targeted primarily for domain name registries. The
specification is designed to be independent of the underlying
objects that are being escrowed and therefore it could also be used for
purposes other than domain name registries.
GL- Ok, I will update the draft.
1. Introduction:
This document specifies a format for data escrow deposits independent
of the objects being escrowed. A specification is required for each
type of registry/set of objects that is expected to be escrowed.
I suggest changing "A specification" to "An independent specification"
GL - Ok, I will update the draft.
5. Protocol Description
It might be useful to have a sentence that states that a formal XML schema
is
defined in section 6, and this section describes how those fields are used
in
the escrow procedure.
GL - Ok, I will update the draft.
5.1.3. Child <deletes> element
This element SHOULD be present in deposits of type Incremental or
Differential. It contains the list of objects that were deleted
since the base previous deposit. Each object in this section SHALL
contain an ID for the object deleted.
The SHOULD is not really right because an incremental or differential backup
may contain no deletions.
This may be better stated as something like:
"For Incremental deposits, this element contains the list of objects that
have
been deleted since the previous deposit of any type. For Differential
deposits, this element contains the list of objects that have been deleted
since the previous full deposit."
GL- Ok, I will update the draft, but using the current definitions of
Differential and Incremental. See explanation in the DISCUSS section of this
email.
5.1.4. Child <contents> element
This element of the deposit contains the objects in the deposit. It
SHOULD be present in all type of deposits. It contains the data for
the objects to be escrowed. The actual objects have to be specified
individually.
In the case of Incremental or Differential Deposits, the objects
indicate whether the object was added or modified after the base
previous deposit. In order to distinguish between one and the other,
it will be sufficient to check existence of the referenced object in
the previous deposit.
I don't think that this is a SHOULD because the update might not contain any
new or updated objects.
Perhaps better stated as something like:
"For Full deposits this element contains all objects. For Incremental
deposits, this element contains the list of objects that have been created
or
updated since the previous deposit of any type. For Differential deposits,
this element contains the list of objects that have been created or updated
since the previous full deposit."
GL- Ok, I will update the draft, but using the current definitions of
Differential and Incremental. See explanation in the DISCUSS section of this
email.
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
