Re: [regext] [Ext] Éric Vyncke's No Objection on draft-ietf-regext-dnrd-objects-mapping-09: (with COMMENT)

Gustavo Lozano <gustavo.lozano@icann.org> Thu, 08 October 2020 21:51 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 D953C3A0E29; Thu, 8 Oct 2020 14:51:17 -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 w5rBa8yiw2NC; Thu, 8 Oct 2020 14:51:16 -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 5CEED3A0CA8; Thu, 8 Oct 2020 14:51:16 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 098LpFc6001932 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 8 Oct 2020 21:51:15 GMT
Received: from MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.659.4; Thu, 8 Oct 2020 14:43:12 -0700
Received: from MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) by MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) with mapi id 15.02.0659.006; Thu, 8 Oct 2020 14:43:12 -0700
From: Gustavo Lozano <gustavo.lozano@icann.org>
To: =?utf-8?B?w4lyaWMgVnluY2tl?= <evyncke@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-regext-dnrd-objects-mapping@ietf.org" <draft-ietf-regext-dnrd-objects-mapping@ietf.org>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" <regext@ietf.org>, "Scott Hollenbeck" <shollenbeck@verisign.com>
Thread-Topic: =?utf-8?B?W0V4dF0gw4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWll?= =?utf-8?B?dGYtcmVnZXh0LWRucmQtb2JqZWN0cy1tYXBwaW5nLTA5OiAod2l0aCBDT01N?= =?utf-8?Q?ENT)?=
Thread-Index: AQHWexCw5ZH0MSGmYEqrWUPbBABxkamOgeeA
Date: Thu, 8 Oct 2020 21:43:12 +0000
Message-ID: <578146EE-E4EE-4EE0-B871-731F6917C499@icann.org>
References: <159838145911.3803.10916709398554015085@ietfa.amsl.com>
In-Reply-To: <159838145911.3803.10916709398554015085@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.38.20061401
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: text/plain; charset="utf-8"
Content-ID: <9430F8B35FA1CB4DA1652016CBFBB848@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-08_15:2020-10-08, 2020-10-08 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/_9WesMgPbuVXBkEXH-MByHRbPz8>
Subject: Re: [regext] =?utf-8?q?=5BExt=5D_=C3=89ric_Vyncke=27s_No_Objection_o?= =?utf-8?q?n_draft-ietf-regext-dnrd-objects-mapping-09=3A_=28with_COMMENT?= =?utf-8?q?=29?=
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: Thu, 08 Oct 2020 21:51:18 -0000

Thank you Éric,

Comments below are prefixed with Authors-.

A new version of the I-D has been published here: https://www.ietf.org/id/draft-ietf-regext-dnrd-objects-mapping-10.txt

Regards,
Gustavo

On 8/25/20, 11:51, "Éric Vyncke via Datatracker" <noreply@ietf.org> wrote:

    Éric Vyncke has entered the following ballot position for
    draft-ietf-regext-dnrd-objects-mapping-09: No Objection

    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.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!PtGJab4!rBU0vO-gjw6Fqrub9N1aq4rKO80xoO9oRs_cFwaPjhrsCZ0c_iYme3h4P_pcFT_5zKddow--MeY$ 
    for more information about IESG DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/__;!!PtGJab4!rBU0vO-gjw6Fqrub9N1aq4rKO80xoO9oRs_cFwaPjhrsCZ0c_iYme3h4P_pcFT_5zKddtQ4jY8o$ 



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Thank you for the work put into this document. Due to my heavy workload, I did
    not review in details the model itself.

    Please find below a couple of non-blocking COMMENTs (a reply to  my COMMENTs
    will be welcome).

    I hope that this helps to improve the document,

    Regards,

    -éric

    == COMMENTS ==

    A generic question about the point (5) of the document shepherd write-up:
    "The AD is asking for further review from the Internationalization
    Directorate, specifically on Section 10, which RECOMMENDS UTF-8 but allows
    UTF-16.  The working group cites RFC 5730, Section 5, and aligns with that.
    The AD would prefer to deprecate UTF-16, and notes that RFC 5730, is now
    well over 10 years old.  Other opinions will be useful."

    Did the WG receive any other opinions ? It is not clear from the write-up.

Authors- Scott replied here: https://mailarchive.ietf.org/arch/msg/regext/kENFq5jLnSGiIn6oeWOjumY1kcQ/

    -- Section 4.3 --
    Just curious here, why are the ASCII code expressed as a 16-bit unit while
    ASCII codes are 7-bit long ? E.g., '("+", ASCII value 0x002B)'

Authors- fixed in the next version of the I-D.

    -- Section 4.4 --
    Are you sure that CRC32 and SHA-256 belongs to a section named 'checksum' ?
    Those 2 techniques are different than checksums and much stronger for integrity
    checks. Suggest to renamed this section.

Authors- text updated in the next version of the I-D.

    In addition, should the algorithm be identified ?

Authors- text updated in the next version of the I-D.

    -- Section 4.5 --
    RFC 4291 is about the addressing structure of IPv6 (i.e., semantic), please
    replace this reference to RFC 5952 that is about how to write an IPv6 address
    (i.e., syntax).

Authors- fixed in the next version of the I-D.

    -- Section 4.6.1 --
    Just curious again... why not using plain SQL data definition language 'create
    table()' statements rather than using XML to describe relational tables? Of
    course, the XML file contains other information than the SQL data definition
    language but it is lacking some information from SQL.

    Also, it seems that using XML rather than SQL forces the primary key and
    foreign key to have the same name (e.g., <csvSample:fName/>)

Authors- XML is used to match the type definitions used the related provisioning protocol, which is EPP (RFC 5730 – 5733).  In this case the elements provided over the provisioning protocol can be directly used in the data escrow.

    -- Section 5.3.2.1.3 --
    Should the postal ZIP code be included ?

Authors- the postal code is supported with the <csvContact:fPc/> field with CSV and the <contact:pc> element with XML.

    == NITS ==

    -- Section 5.1.1.1 --
    Really cosmetic, but, having an expiration date in 2015 in the example in a
    document published in 2020 ;-)

Authors- fixed in the next version of the I-D.