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

From: Roman Danyliw <[email-masked]>
Date: Fri, 8 May 2020 20:06:02 +0000

Hi Gustavo!

Details inline ...

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Gustavo Lozano
> Sent: Monday, April 6, 2020 5:48 PM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; James Gould <[email-masked]>;
> [email-masked]; [email-masked]
> 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" <[email-masked]> 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://tools.ietf.org/rfcdiff?url2=draft-ietf-regext-data-escrow-06.txt

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.

>     ** 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.

-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.

>     ----------------------------------------------------------------------
>     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.

>     ** 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

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

Thanks.

Regards,
Roman

---

From: Gustavo Lozano <[email-masked]>
Date: Tue, 12 May 2020 23:18:12 +0000

Thank you Roman,

Comments inline prefixed in GL-

Regards,
Gustavo

On 5/8/20, 13:06, "Roman Danyliw" <[email-masked]> wrote:

    Hi Gustavo!

    Details inline ...

    > 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= 

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

    > 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= 

GL - Updated in version 09. See, https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-data-escrow-09

GL - Updated in version 09. See, https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-data-escrow-09

    > 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.

    > 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

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 13 May 2020 12:41:08 +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

> Sent: Tuesday, May 12, 2020 7:18 PM
> Cc: [email-masked]; [email-masked]; James Gould
> <[email-masked]>; [email-masked]
> 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
> 
>     > GL- The elements are used in
> 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=
>     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.
> 
>     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.
> 
> 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.
> 
> 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
>