Ballot for draft-ietf-regext-data-escrow
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
{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."