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

Barry Leiba <barryleiba@computer.org> Thu, 07 May 2020 17:37 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9FE3A0C31; Thu, 7 May 2020 10:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_fjcpq7vByN; Thu, 7 May 2020 10:37:01 -0700 (PDT)
Received: from mail-il1-f170.google.com (mail-il1-f170.google.com [209.85.166.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215EC3A0C19; Thu, 7 May 2020 10:36:58 -0700 (PDT)
Received: by mail-il1-f170.google.com with SMTP id b18so2747974ilf.2; Thu, 07 May 2020 10:36:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FzmC/WOIoHCQ4/zTPhzChXy5l4UEcgtePah+97bZ/p4=; b=Qm8UDvRbSjp495e0pjY24dAErmPBQw++omVjEHuGgTVAtY9c6p3kik6p9vNxzePb5Z 5PIn4Rdo0yGyYi6IHjXu5Ga91fVlo2iTZJVRD62/N9xilPazaw5hGZMa0epXTLMIssCe 36TG+2q0U2e+TDN2PDf2FABiN2HgghDTwm/HDHFUOrBgusPsm9rv3Se92G7JGUvQbLw4 RPf5WWvensORtI/dJijYbWnNMGwzIT999yveuYJ+ENzywu8ikwqBHoefRTXMRDhblF23 tWZM/bWL3jMWBSdWq2RO0Ts6xhd9R/Efp/bZB3MJqyfBF4UtnbqzjplT32SlAPztFRZA OhLw==
X-Gm-Message-State: AGi0PuY61DRdogu329wb9YWtgQiB06IDiWipRF23FA+1UvFYQ+4R166G HgQuLv7DN2OrOkEjUU3SUYntcHi4CJUpr+RZzsM=
X-Google-Smtp-Source: APiQypJ9P15Q4rQqmsmFGhyi8TK1T5Lo0iA0Mv4+iPeQT+yO84Bj6/RrTTh4eUPq7aDMF5ZKFZZXKsDdIcQZE5LKcGQ=
X-Received: by 2002:a92:ca81:: with SMTP id t1mr15577454ilo.187.1588873017102; Thu, 07 May 2020 10:36:57 -0700 (PDT)
MIME-Version: 1.0
References: <158636547907.1936.4743911700628916243@ietfa.amsl.com> <4156BA6C-0BE7-46DB-97AF-E5C1CF3E7BBE@icann.org> <MN2PR11MB4366A23710BFC6F4BB7F0CFFB5A50@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB4366A23710BFC6F4BB7F0CFFB5A50@MN2PR11MB4366.namprd11.prod.outlook.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Thu, 7 May 2020 13:36:46 -0400
Message-ID: <CALaySJJ_wnpyabc4dSnBM0_TaQ1x4K3GWLzTRcQcUEiqh=tzRQ@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
Cc: Gustavo Lozano <gustavo.lozano@icann.org>, The IESG <iesg@ietf.org>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>, James Gould <jgould@verisign.com>, "regext@ietf.org" <regext@ietf.org>, "draft-ietf-regext-data-escrow@ietf.org" <draft-ietf-regext-data-escrow@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/4KMl93HwoBI7KXvKW88oSwopaHs>
Subject: Re: [regext] [Ext] Robert Wilton's Discuss on draft-ietf-regext-data-escrow-07: (with DISCUSS and COMMENT)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2020 17:37:03 -0000

I'm afraid I have to agree with Gustavo that the terms used here need
to match what's used in the domain this is written for.  It's often
the case that things mean different things in different domains, and
sometimes those domains are similar enough that we wish it weren't the
case.  When it is, that's sad... but.

Unless someone in the working group wants to tell us that Gustavo is
wrong and we should go with what Rob suggests, I think the discussion
has been had.  I *would* like to hear some input from the working
group on this, though, before we make any final decisions.

Barry

On Thu, May 7, 2020 at 12:03 PM Rob Wilton (rwilton)
<rwilton=40cisco.com@dmarc.ietf.org> wrote:
>
> Hi Gustavo,
>
>
> > -----Original Message-----
> > From: Gustavo Lozano <gustavo.lozano@icann.org>
> > Sent: 17 April 2020 00:59
> > To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; The IESG <iesg@ietf.org>
> > Cc: draft-ietf-regext-data-escrow@ietf.org; regext-chairs@ietf.org;
> > regext@ietf.org; James Gould <jgould@verisign.com>
> > Subject: Re: [Ext] Robert Wilton's Discuss on draft-ietf-regext-data-
> > escrow-07: (with DISCUSS and COMMENT)
> >
> > Thank you Robert,
> >
> > Comments inline, prefixed with GL -
> >
> > Regards,
> > Gustavo
> >
> > On 4/8/20, 10:04, "Robert Wilton via Datatracker" <noreply@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=V
> > bweciUcwYQpIOZDSxl0ezGd1hGDtd-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=VbweciU
> > cwYQpIOZDSxl0ezGd1hGDtd-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.
> >
>
> I don't see a huge difference between a remote backup vs data escrow.  E.g., if I use an online backup service then it seems that they are storing data securely on my behalf that I can subsequently recover if required.  It feels like the concepts are so very similar that using the same set of terms with different meanings could easily cause confusion.
>
> The choice here is between having
> (i) a protocol that matches legal data escrow definitions but could easily be confused by people who see this as a type of remote backup
> (ii) a protocol specification that matches the widely used common definitions for these terms (e.g. https://en.wikipedia.org/wiki/Incremental_backup, https://en.wikipedia.org/wiki/Differential_backup), but that is opposite to the legal definitions.
>
> It seems to me that the legal definitions are really self-contained within their documents, and potentially could be updated over time.  However, I see no way that we can convince the world in general to reverse their understanding/usage of these terms, and hence if you are to use these terms, I still believe that they should align to their common usage rather than the legal definitions.
>
> Of course, an alternative solution would be to define and use completely different terms for the incremental and differential deposits, e.g. full deposit, full-delta deposit, minimal-delta deposit.
>
> Thanks,
> Rob
>