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

Gustavo Lozano <gustavo.lozano@icann.org> Mon, 06 April 2020 21:50 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 EF7813A0DCE; Mon, 6 Apr 2020 14:50:55 -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 HX16RvyR17qG; Mon, 6 Apr 2020 14:50:48 -0700 (PDT)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.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 34F6D3A0D89; Mon, 6 Apr 2020 14:47:55 -0700 (PDT)
Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa4.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 036LlquI022836 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 6 Apr 2020 21:47:52 GMT
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 Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 14:47:50 -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; Mon, 6 Apr 2020 14:47:50 -0700
From: Gustavo Lozano <gustavo.lozano@icann.org>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-regext-data-escrow@ietf.org" <draft-ietf-regext-data-escrow@ietf.org>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" <regext@ietf.org>, James Gould <jgould@verisign.com>
Thread-Topic: [Ext] Roman Danyliw's Discuss on draft-ietf-regext-data-escrow-05: (with DISCUSS and COMMENT)
Thread-Index: AQHV9Znu0pEHPOyRlkae1S/+2cvToKhsztUA
Date: Mon, 6 Apr 2020 21:47:50 +0000
Message-ID: <D83A99EB-B5D6-4C8B-B082-F7AC7DEA9448@icann.org>
References: <158370695225.6735.13200718369022557320@ietfa.amsl.com>
In-Reply-To: <158370695225.6735.13200718369022557320@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.35.20030802
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: <B1748387D1ED414CB696AB4B4A428F7F@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-06_10:2020-04-06, 2020-04-06 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/G4CeEeTsy61n-8USW61PuBn0Cis>
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: Mon, 06 Apr 2020 21:50:57 -0000

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=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&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://tools.ietf.org/rfcdiff?url2=draft-ietf-regext-data-escrow-06.txt
    

    ** 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://tools.ietf.org/html/draft-ietf-regext-dnrd-objects-mapping. The elements are in the schema for backward compatibility. There is a comment in the schema explaining that these are auxiliary elements.

    ** 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.
    
    ----------------------------------------------------------------------
    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.
    
    ** 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://tools.ietf.org/rfcdiff?url2=draft-ietf-regext-data-escrow-06.txt

 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://tools.ietf.org/rfcdiff?url2=draft-ietf-regext-data-escrow-06.txt