Re: [regext] [Ext] Roman Danyliw's Discuss on draft-ietf-regext-data-escrow-05: (with DISCUSS and COMMENT)

Roman Danyliw <rdd@cert.org> Wed, 13 May 2020 12:42 UTC

Return-Path: <rdd@cert.org>
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 1D2273A10DD; Wed, 13 May 2020 05:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 ePNtVps_764c; Wed, 13 May 2020 05:42:00 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5FB3A10DF; Wed, 13 May 2020 05:41:37 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 04DCfBU4022947; Wed, 13 May 2020 08:41:11 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 04DCfBU4022947
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1589373671; bh=iROQWx+yWLtR9unQjeJN47TgxUB6UR4nAm7Nfx39dsI=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=bMLluTokDJ6GcSTA1GHpspCWfUnsu1vQ1sm4IaTbNn0DDHWF2SjuLP9hEjVgibQvY IrEfMFZNLcqyJDr0v5qH2kWUFTRkrPHlAkM2I2yjxh7cr8N6Rif1KFRx4/yq8ypk0n rU30KQUDHDSsKQ+zFT93Uk66sL1uCtJlznHVfMNY=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 04DCf9lw037658; Wed, 13 May 2020 08:41:09 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 13 May 2020 08:41:09 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Wed, 13 May 2020 08:41:08 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%22]) with mapi id 15.01.1847.007; Wed, 13 May 2020 08:41:08 -0400
From: Roman Danyliw <rdd@cert.org>
To: Gustavo Lozano <gustavo.lozano@icann.org>, The IESG <iesg@ietf.org>
CC: "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" <regext@ietf.org>, James Gould <jgould@verisign.com>, "draft-ietf-regext-data-escrow@ietf.org" <draft-ietf-regext-data-escrow@ietf.org>
Thread-Topic: [Ext] Roman Danyliw's Discuss on draft-ietf-regext-data-escrow-05: (with DISCUSS and COMMENT)
Thread-Index: AQHV9ZnweucuB9mkNkuRtjJzIeea46htEeMAgDHoXACABsTRAIAAlXJA
Date: Wed, 13 May 2020 12:41:08 +0000
Message-ID: <cbd0f9b7d4fe4508bcda9ca48e8f9035@cert.org>
References: <158370695225.6735.13200718369022557320@ietfa.amsl.com> <D83A99EB-B5D6-4C8B-B082-F7AC7DEA9448@icann.org> <da86e0d950e4413c83fd644a5125bdd9@cert.org> <002A945C-7C25-40F0-BF30-0EB309A5F76D@icann.org>
In-Reply-To: <002A945C-7C25-40F0-BF30-0EB309A5F76D@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.241]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/B4bncEciUMFvVRmglvv3q3AefH0>
Subject: Re: [regext] [Ext] Roman Danyliw's Discuss on draft-ietf-regext-data-escrow-05: (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: Wed, 13 May 2020 12:42:07 -0000

Hi Gustavo!

Thanks for the iterative updates and the work to write this document. This last update in -09 addresses all of my discuss and comment items.  I've cleared my ballot.

Thanks,
Roman

> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> On Behalf Of Gustavo Lozano
> Sent: Tuesday, May 12, 2020 7:18 PM
> To: Roman Danyliw <rdd@cert.org>rg>; The IESG <iesg@ietf.org>
> Cc: regext-chairs@ietf.org; regext@ietf.org; James Gould
> <jgould@verisign.com>om>; draft-ietf-regext-data-escrow@ietf.org
> Subject: Re: [Ext] Roman Danyliw's Discuss on draft-ietf-regext-data-escrow-05:
> (with DISCUSS and COMMENT)
> 
> Thank you Roman,
> 
> Comments inline prefixed in GL-
> 
> Regards,
> Gustavo
> 
> On 5/8/20, 13:06, "Roman Danyliw" <rdd@cert.org> wrote:
> 
>     Hi Gustavo!
> 
>     Details inline ...
> 
>     > -----Original Message-----
>     > From: iesg <iesg-bounces@ietf.org> On Behalf Of Gustavo Lozano
>     > Sent: Monday, April 6, 2020 5:48 PM
>     > To: Roman Danyliw <rdd@cert.org>rg>; The IESG <iesg@ietf.org>
>     > Cc: regext-chairs@ietf.org; James Gould <jgould@verisign.com>om>;
>     > regext@ietf.org; draft-ietf-regext-data-escrow@ietf.org
>     > Subject: Re: [Ext] Roman Danyliw's Discuss on draft-ietf-regext-data-
> escrow-05:
>     > (with DISCUSS and COMMENT)
>     >
>     > Thank you Roman,
>     >
>     > Comments inline prefixed with GL-.
>     >
>     > Regards,
>     > Gustavo
>     >
>     > On 3/8/20, 15:35, "Roman Danyliw via Datatracker" <noreply@ietf.org>
> wrote:
>     >
>     >     Roman Danyliw has entered the following ballot position for
>     >     draft-ietf-regext-data-escrow-05: 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=DwIDaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5
>     > cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-
>     > 0BvgAgfmwfE0&m=mZiY3vrtmE8jDSOwutDwyVp05-
>     >
> t7_L16WP_03hPCzqg&s=P9KLpSAcMUTfkhs5glpoL88QP9Ldd32tUFnepFguGWk
>     > &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=DwIDaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&
>     > r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-
>     > 0BvgAgfmwfE0&m=mZiY3vrtmE8jDSOwutDwyVp05-
>     > t7_L16WP_03hPCzqg&s=7K3FKE9852x_hU-
>     > eH090G1p9WbPh98ULLL0ZfDm8Xcc&e=
>     >
>     >
>     >
>     >     ----------------------------------------------------------------------
>     >     DISCUSS:
>     >     ----------------------------------------------------------------------
>     >
>     >     ** Section 6.1.  Please provide a normative reference to XML Schema.
>     >
>     > GL- Added in version 06 of the draft, here:
>     > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dregext-2Ddata-2Descrow-
> 2D06.txt&d=DwIGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=
> VbweciUcwYQpIOZDSxl0ezGd1hGDtd-
> 0BvgAgfmwfE0&m=Uad6XeFSCKunJd3kwxQn_LM4Uops92_q7II97J3IZK8&s=5V
> VmTq-uX52GxxToLwgOSAom3q2rFGbbO1Yquy6M048&e=
> 
>     I see the newly added normative references of [W3C.REC-xmlschema-1-
> 20041028] and [W3C.REC-xmlschema-2-20041028] in -08.  Thanks for that.
> The remaining simple edit would be to actually reference these somewhere in
> the text.  Right now these are just listed as references.
> 
> GL - I thought that I added the text in version 08, but it was not the case.
> Updated in version 09. See, https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-
> data-escrow-09
> 
>     >     ** Section 6.1. The schema defines types “clIDType” and “rrType” but
> their
>     > use
>     >     isn’t explained in the text and they don’t appear to be used in the
> definition
>     >     of <deposit>.
>     >
>     > GL- The elements are used in
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dregext-2Ddnrd-
> 2D&d=DwIGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=Vbwe
> ciUcwYQpIOZDSxl0ezGd1hGDtd-
> 0BvgAgfmwfE0&m=Uad6XeFSCKunJd3kwxQn_LM4Uops92_q7II97J3IZK8&s=yf_
> 62BCuiq4VQOB1baYX-ZaVUAonuwbn0fV86LpbwV8&e=
>     > objects-mapping. The elements are in the schema for backward
> compatibility.
>     > There is a comment in the schema explaining that these are auxiliary
> elements.
> 
>     -08 cleaned this up.  Thank you.
> 
>     >     ** Section 11.  Was a requirement to secure the deposit data at rest
>     >     considered?  The text here suggests that such details needed to be
> worked
>     > out
>     >     individually.  However, Section 9 notes that the whole deposit is likely to
> be
>     >     confidential.  It would seem best practice to store such sensitive
> information
>     >     encrypted.
>     >
>     > GL- The draft describes a format used to interchange information, and it's
> for
>     > the parties to establish the security requirements based on the particular
> use
>     > case. In the gTLD space, legal agreements mandate the security
> requirements.
>     > There are use-cases that may not require any security mechanism at transit
>     > and/or rest. For example, a deposit that contains the same information
>     > available in the public DNS.
> 
>     Understood.  Thanks for the edits in Section 11.  However, I was primarily
> looking for symmetry with the following text "As such, the registry transmitting
> the data to the escrow agent SHOULD take all the necessary precautions ..."
> This text provides a normative SHOULD about transport security.  The text
> should provide a similar SHOULD about storing any confidential data in
> deposits in an encrypted format at rest.
> 
> GL - Updated in version 09. See, https://www.ietf.org/rfcdiff?url2=draft-ietf-
> regext-data-escrow-09
> 
>     >     ----------------------------------------------------------------------
>     >     COMMENT:
>     >     ----------------------------------------------------------------------
>     >
>     >     ** I didn’t follow how this draft fits with EPP or RDAP per the REGEXT
>     > charter
>     >     (and neither of these protocols are references).
>     >
>     > GL- I think that the following text of the charter covers this draft:
>     >
>     > The working group may also take on work to develop specifications that
>     > describe the following types of information exchanged between entities
>     > involved in Internet identifier registration that are using the RDAP or EPP
>     > protocols:
>     >
>     > ...
>     >
>     > * Data formats for files exchanged between registration entities that need
>     > insertion in or extraction from EPP or RDAP.
>     >
>     > ...
>     >
>     >     ** Section 5.1. @resend.  How does the registry know the escrow
> deposit
>     > failed
>     >     to increment this attribute and resend?
>     >
>     > GL- The draft describes a format used to interchange information, and it's
> for
>     > the parties (i.e., escrow agent and client) to define the signaling
> mechanisms
>     > for their particular implementation.
> 
>     Understood.  There is an expectation of a signaling protocol.  It might be
> worth mention that and noting that the associated details are out of scope.
> 
> GL - Updated in version 09. See, https://www.ietf.org/rfcdiff?url2=draft-ietf-
> regext-data-escrow-09
> 
>     >     ** Section 5.1.2.  <version>.  The schema indicates that this should be set
> to
>     >     1.0, but this isn’t said in the text.
>     >
>     > GL- Added in version 06 of the draft, here:
>     > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dregext-2Ddata-2Descrow-
> 2D06.txt&d=DwIGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=
> VbweciUcwYQpIOZDSxl0ezGd1hGDtd-
> 0BvgAgfmwfE0&m=Uad6XeFSCKunJd3kwxQn_LM4Uops92_q7II97J3IZK8&s=5V
> VmTq-uX52GxxToLwgOSAom3q2rFGbbO1Yquy6M048&e=
> 
>     Thanks.
> 
>     >  How should an implementation process a
>     >     version number it doesn’t recognize?
>     >
>     > GL- The parties shall define this for their particular use-case.
>     >
>     >
>     >     ** Section 10.  Per “As such, the registry transmitting the data to the
> escrow
>     >     agent _should_ take all the necessary precautions …”, why isn’t this a
>     > “_MUST_
>     >     take all necessary precautions …”?  Under what circumstances would
>     > transport
>     >     security not be desirable?
>     >
>     > GL- "should" replaced with SHOULD in version 06 of the draft, here:
>     > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dregext-2Ddata-2Descrow-
> 2D06.txt&d=DwIGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=
> VbweciUcwYQpIOZDSxl0ezGd1hGDtd-
> 0BvgAgfmwfE0&m=Uad6XeFSCKunJd3kwxQn_LM4Uops92_q7II97J3IZK8&s=5V
> VmTq-uX52GxxToLwgOSAom3q2rFGbbO1Yquy6M048&e=
> 
>     Thanks.
> 
>     Regards,
>     Roman
>