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

[Gustavo Lozano <[e-mail]>]

Thank you Robert,

Comments inline, prefixed with GL -

Regards,
Gustavo

On 4/8/20, 10:04, "Robert Wilton via Datatracker" <[e-mail]> 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.