[regext] AD review of draft-ietf-regext-data-escrow-04
Barry Leiba <barryleiba@computer.org> Fri, 14 February 2020 04:38 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 3D18212004E; Thu, 13 Feb 2020 20:38:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 mA9vCjaHnKOF; Thu, 13 Feb 2020 20:38:34 -0800 (PST)
Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) (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 86EA612004D; Thu, 13 Feb 2020 20:38:31 -0800 (PST)
Received: by mail-il1-f176.google.com with SMTP id s85so6968105ill.11; Thu, 13 Feb 2020 20:38:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=83viOOFP18lsLotH+h2b5sGtAsfct6BNtZaI26fJEPQ=; b=gdcIsy5uUA/iiRGBaK4diR3KMGqw5dlBwJWw5ZAABYZOQjENgW4d+ORiDWjx4HMYLy XZe6wdUyzZrJevGLMBfFuEraMt2bclKHL5U007koM3IerIEriJadpZBWfUCcTgkj+nIJ 8NOVAF6LvHtHnQxv3VFdHzyXzAeKQW47CFrMJuycBv5571IU9s0fRWwk+UzIWBIU5ytf VKkp+RZNb47Zzg3kgjURiclSYoFJIW8RdMXXJYP4IPhupeTSL6jJxhuRvN2wp9wY7fyv +/y+nmBsRDktPp1yBTILgGp/te7vwXfIxSWKsMKQ5pJcTLXCr4IEjBYBCraI7mpul0rZ HF4g==
X-Gm-Message-State: APjAAAXwYiPK2Opg2yqeitfp5DMKFbkwuxRmop04lIEM5i34c/8ZoKMa xAyR+yBGu59eCky0LDDtBgzV/QCDTURlGNUrOQL3Nw==
X-Google-Smtp-Source: APXvYqy7joL6CwfMfdXyPpKNL6msG6nDr+CJf14U0Mi5QtvI4JitbPMjrFROBIKlKnIIPiu/LyDv/M45ndAE9Ah85lQ=
X-Received: by 2002:a92:508:: with SMTP id q8mr1208149ile.187.1581655110318; Thu, 13 Feb 2020 20:38:30 -0800 (PST)
MIME-Version: 1.0
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 14 Feb 2020 04:38:19 +0000
Message-ID: <CALaySJJijZeiSiu3ChspN8rDVb=DCFhM9E76xwyBVQaEMedtpA@mail.gmail.com>
To: "draft-ietf-regext-data-escrow.all@ietf.org" <draft-ietf-regext-data-escrow.all@ietf.org>
Cc: regext <regext@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000020034059e81c75e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/UNo6YxapgjyerAYv0223zEuzjFk>
Subject: [regext] AD review of draft-ietf-regext-data-escrow-04
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: Fri, 14 Feb 2020 04:38:36 -0000
Good work on this document, and thanks. I have only some small points to
comment on, which can be fixed later, and I’ll request last call as soon as
I’ve sent this message. My apologies for being swamped and not getting to
this as soon as I should have.
Barry
— Section 3 —
While the main motivation for developing this specification is rooted
on the domain name industry, the specification has been designed to
be as general as possible.
This strikes me as awkward English. May I suggest a rewording?:
NEW
While the domain name industry has been the main target for
this specification, it has been designed to be as general as possible.
END
— Section 5.1 —
Each registry is responsible for maintaining its
own escrow deposits identifier space to ensure uniqueness.
Nit: Make it << deposits’ >>, with the trailing apostrophe to make it
possessive.
o An OPTIONAL "prevId" attribute that can be used to identify the
previous Incremental, Differential or Full Deposit. This
attribute MUST be used in Differential Deposits ("DIFF" type).
It seems that labelling this as OPTIONAL isn’t really right, because its
use depends upon the deposit type, right? Perhaps this?:
NEW
o A "prevId" attribute that can be used to identify the previous
Incremental, Differential or Full Deposit. This attribute is REQUIRED
in Differential Deposits ("DIFF" type), is OPTIONAL in Incremental
Deposits (“INCR” type), and is not used in Full Deposits (“FULL
type).
END
— Section 5.4 —
This section of the deposit SHOULD NOT be present in Full Deposits.
When rebuilding a registry it SHOULD be ignored if present in a Full
Deposit.
Questions about both “SHOULD”s:
For the “SHOULD NOT”, why might an implementation need to put that section
in? That is, why is this not “MUST NOT”?
For the “SHOULD”, why is it not “MUST”? What else but ignoring it could a
rebuilder possibly do?
— Section 10 —
Depending on local policies, some elements or most likely, the whole
deposit will be considered confidential. As such the registry
transmitting the data to the escrow agent SHOULD take all the
necessary precautions like encrypting the data itself and/or the
transport channel to avoid inadvertent disclosure of private data.
Nits: This needs a comma after “or” in “or, most likely,” and a comma after
“As such”. Also, “like encrypting” should be “such as encrypting”.
It is also of the utmost importance the authentication of the parties
passing data escrow deposit files.
NEW
Authentication of the parties passing data escrow deposit files
is also of the utmost importance.
END
Apart from that rewording, it seems odd that something “of the utmost
importance” is labelled as SHOULD, rather than MUST, yes?
RECOMMENDED to ensure not only the file was transmitted correctly
from the registry, but also the contents are also "meaningful".
Nits: this needs “that” before both “the file” and “the contents”.