Registry Data Escrow Specification
draft-ietf-regext-data-escrow-10

{No Objection once others are happy}

[nits]

S5.1

* Is the universe of "id"s within which "id" must be unique the set of all
  "id"s from a given depositor?  Or do the "id"s need to be globally unique?

S5.1.1

* "data-time" or perhaps "date-time"?

S5.1.4

* I wonder if swapping the order of the last two paragraphs makes sense.

Roman took many of my ideas, so I support his DISCUSS position and his comments.

Version -08 resolves my DISCUSS point.  Thanks for making that change.

Some of the BCP14 language in this document feels mushy.  "SHOULD/MUST take all necessary precautions" isn't very precise, while normally interoperability/normative language is supposed to be pretty crisp.

"gTLD" and "ccTLD" could stand to be included in the definitions section, either by prose or by reference if there is one.

This may reveal a weak point in my understanding of XML, but Section 5.1 says that the type of the deposit is FULL, INCR or DIFF.   Is this case-sensitive?

Section 5.1.1: Should "data-time" be "date-time"?

Section 5.1.2: About "version", although I think this is made explicit in the XML schema in Section 6.1, I suggest a sentence be added making it clear that this document specifies version "1.0".

Section 5.1.4, last paragraph: When would you not apply that SHOULD?  That strikes me as MUST territory.

Thank you for addressing my DISCUSS and COMMENT feedback.

Thank you for the work put into this document. I have appreciated the examples of section 13.

I am also support the "data at rest encryption" as noted by Roman's DISCUSS as by Carlos in his INTDIR review.

Please address the issues found by Carlos during the INTDIR review:
https://mailarchive.ietf.org/arch/msg/int-dir/8BJEPavSHK0BYTe_f1W1BFG-fwA

Finally, for my own curiosity, is there a reason why using the word "watermark" rather than "timestamp" ?

Regards,

-éric

Thanks for addressing my DISCUSS.

I support Roman's DISCUSS point about protecting the data at rest.

Thank you for the discussion and updates in response to my discuss points!

Thanks for addressing my discuss.

+1 to Roman’s concerns on encryption, but I’m happy when he’s happy.

Previous discuss comments:

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.

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