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

Gustavo Lozano <gustavo.lozano@icann.org> Tue, 12 May 2020 23:18 UTC

Return-Path: <gustavo.lozano@icann.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 F1F013A0C74; Tue, 12 May 2020 16:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 CRZFhrXLRIPa; Tue, 12 May 2020 16:18:18 -0700 (PDT)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 3D54C3A0A9C; Tue, 12 May 2020 16:18:18 -0700 (PDT)
Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 04CNIEcf031252 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 12 May 2020 23:18:14 GMT
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 May 2020 16:18:13 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Tue, 12 May 2020 16:18:12 -0700
From: Gustavo Lozano <gustavo.lozano@icann.org>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
CC: "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>
Thread-Topic: [Ext] Roman Danyliw's Discuss on draft-ietf-regext-data-escrow-05: (with DISCUSS and COMMENT)
Thread-Index: AQHV9Znu0pEHPOyRlkae1S/+2cvToKhsztUAgDKjgQCABgmsAA==
Date: Tue, 12 May 2020 23:18:12 +0000
Message-ID: <002A945C-7C25-40F0-BF30-0EB309A5F76D@icann.org>
References: <158370695225.6735.13200718369022557320@ietfa.amsl.com> <D83A99EB-B5D6-4C8B-B082-F7AC7DEA9448@icann.org> <da86e0d950e4413c83fd644a5125bdd9@cert.org>
In-Reply-To: <da86e0d950e4413c83fd644a5125bdd9@cert.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: text/plain; charset="utf-8"
Content-ID: <CF66CDB4B336CF42812154DCB6F6B43D@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-12_08:2020-05-11, 2020-05-12 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/jxmKI4jb-s-vkZ1BUtJJgO06lJw>
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: Tue, 12 May 2020 23:18:20 -0000

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=5VVmTq-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=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-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=5VVmTq-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=5VVmTq-uX52GxxToLwgOSAom3q2rFGbbO1Yquy6M048&e= 

    Thanks.

    Regards,
    Roman