Re: [regext] [Ext] Alissa Cooper's Discuss on draft-ietf-regext-data-escrow-07: (with DISCUSS)

Gustavo Lozano <> Wed, 13 May 2020 19:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E8C73A07E3; Wed, 13 May 2020 12:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5ebpMjPOK_eZ; Wed, 13 May 2020 12:08:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B70AE3A07C6; Wed, 13 May 2020 12:08:28 -0700 (PDT)
Received: from ( []) by ( with ESMTPS id 04DJ8O3W010560 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 May 2020 19:08:25 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 13 May 2020 12:08:22 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1497.006; Wed, 13 May 2020 12:08:22 -0700
From: Gustavo Lozano <>
To: Alissa Cooper <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [Ext] [regext] Alissa Cooper's Discuss on draft-ietf-regext-data-escrow-07: (with DISCUSS)
Thread-Index: AQHWDnWPcnhC325um0SBDJH3yzj526imltIA
Date: Wed, 13 May 2020 19:08:22 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/16.36.20041300
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-source-routing-agent: Processed
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
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-13_09:2020-05-13, 2020-05-13 signatures=0
Archived-At: <>
Subject: Re: [regext] [Ext] Alissa Cooper's Discuss on draft-ietf-regext-data-escrow-07: (with DISCUSS)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 May 2020 19:08:30 -0000

Thank you Alissa,

Comments inline prefixed with GL-


On 4/9/20, 06:48, "regext on behalf of Alissa Cooper via Datatracker" < on behalf of> wrote:

    Alissa Cooper 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 
    for more information about IESG DISCUSS and COMMENT positions.

    The document, along with other ballot positions, can be found here: 


    I support Benjamin's DISCUSS and Roman's last DISCUSS point. 

GL - The latest version of the draft covers the feedback from Roman (DISCUSS cleared), and I also believe Benjamin's feedback (waiting for his response)

Regarding Section
    11, there are often legal agreements in place that govern all sorts of things
    about how protocols transfer data between parties, but those are not the main
    thing to document in an RFC. Section 11 should be documenting the technical
    considerations for how to protect the data that may be escrowed.

GL - draft-ietf-regext-data-escrow describes a standardized format for escrow, and it's not a document specifying escrow services (i.e., no definition of a transport protocol, signaling mechanism, etc.). Section 11 has been strengthen based on the comments from other IESG's members, and I believe it's in good shape now.

Here are the differences between 07 and 08, and 08 and 09:

I think that a draft describing the best security / operational practices for escrow service providers could be a good idea. In the case of the gTLD space, there is no urgency for such a document, as the security / operational requirements are detailed in legal agreements.

Hopefully, this clarifies my previous comments.

    regext mailing list