Thank you Roman,

Comments inline prefixed with GL-.

Regards,
Gustavo

On 3/8/20, 15:35, "Roman Danyliw via Datatracker" <[email protected]> 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
    
    

_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext

Reply via email to