[regext] Robert Wilton's Discuss on draft-ietf-regext-data-escrow-07: (with DISCUSS and COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/



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

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.

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

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

   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.


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

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"

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.

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

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