Re: [regext] I-D Action: draft-ietf-regext-validate-04.txt

"Gould, James" <jgould@verisign.com> Mon, 15 October 2018 16:08 UTC

Return-Path: <jgould@verisign.com>
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 AA0B8130EA5 for <regext@ietfa.amsl.com>; Mon, 15 Oct 2018 09:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.289
X-Spam-Level:
X-Spam-Status: No, score=-4.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 CTT_QUySsYht for <regext@ietfa.amsl.com>; Mon, 15 Oct 2018 09:08:30 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 B830E130EAC for <regext@ietf.org>; Mon, 15 Oct 2018 09:08:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=21351; q=dns/txt; s=VRSN; t=1539619709; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=B6yf5cZijlq6IO5BzUY8hD6XTUiFGL0HdOYupDdEDnU=; b=g5Hakk5I7g3Db8or7xltXzHnJb+spCV2FTmvsJJ5j0/TxZc4hSV/T6Uv mqdDBVLQ6ZFgBGQDzGaer0RYyiDydx8UhatvJiNbSVVnZhveiMt5zGdzp AUUrEQP0TkCUD+Mx55lwxikUBf3BqStQGDp8IpmdTA1wjjDXkzLMZ8H+y XZaqOZoxZsbwi65ekspU2ZHqsu/j1kmBYptcSk9b7XR7hzSZnr950OSCe E5cdDm2SorjX72r94u0KNVq9d3PXN+iNhnYj+i+8Cq2B61cmIdpwcbA2B gqnPFr9TevQ+gWi/AiZQQQmML4zkJQP5Kxj4Hbinluu2xSWUKhbgBgZxV w==;
X-IronPort-AV: E=Sophos;i="5.54,385,1534809600"; d="scan'208,217";a="6014366"
IronPort-PHdr: 9a23:CwycAB1loHHy2DzRsmDT+DRfVm0co7zxezQtwd8ZseIeLvad9pjvdHbS+e9qxAeQG9mDtLQc06L/iOPJYSQ4+5GPsXQPItRndiQuroEopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZvJuTyB4Xek9m72/q99pHPYQhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfMQA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7S60/Vza/4KdxUBLmiDkJOSMl8G/ZicJwgqBUrxygpxNjzIHZe5uaOOZ7fq7HYd8XX2hMU8BMXCJBGIO8aI4PAvIPMehZqIn9ul8OogamCQKxAO3g0DpIiWHt3aE0zu8sFgPG3AMnH9ITtHTbsc74NLkMXuCvzanI1jTDb/xQ2Tvn9IfIdRUhrOiKULltf8TRzkwvGBnEjlWWsYHlIS2a1v4Ms2iA7upgWuSvi28hqw5tuDSg2sAsiozRioIU1F/E6St5zJwyJd2iR052Z8OvHphItyyCKod6XtkuT3xqtSs00LEKpJ62cSYQxJkoxBPTc+GLf5SS7h7+VuudPS10iG9qdb+8nRq+7EutxvXyVsaq01tGsi9In9zWuX0O0xHc8c2KR/Vj8ki82DuC0hvc5+VFLE02kKfWJZAsz7wtmZcVrE/NBDX5mF/sg6+Tbkgk/++o5Pn5bbj+vZ+cMpN0ihn5MqQzhsyzGeQ4PRYKX2ic4emxyaHt81XkTLpKlvM4najWvIzHKcgBuK62HwhV0pw76xqlFTipzc4UnWcdLFJefhKLlZTmO1bLIPzgDPe/hUqjkCtzyvzbIrHtGIjBI3rNnbv7YLpw60BRxBA8wN1c/55UD6sOIPP3Wk//rtzYCRo5PhS2w+boD9V9y4ceVn+UD6+HLqzSq16I5vkuI+mDYo8ZoiryK/8g5/L2l382hUcdfbW13ZsQcH24BOppI0qHbnvjntcMCmYKsRQiTOzkklGCViRTZ3nhF547s3shBY2rHZvrR42xjvqGxijxVslMa29LGkykEHr0ecODQfhaOwyIJco02BMDSLytD8cD3BSjr0Wyn7hoKffQ9gUGuIjiz9l64avYkhRkpm88NNiUz2zYFzI8pWgPXTJjhK0=
X-IPAS-Result: A2EtAADkusRb/zCZrQpfAx4BBgcGgVEJCwGBDIFdgScKg2utVRSBKxcdBwwBGAEKC4N4RgIXhGg0DQ0BAwEBAQEBAQIBAQKBBQELgjYiES8cLwkBBQEBAQEBAScBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEIAggHNRIBGgIBAwEBIUsbAgEGAkICAgIlCyUCBBODIAGBHXOLGptNgS6EMwc9hFyLY4FCPoESJx+CTIMbAQECAQEWgRQBEgEJIgsKJoI8MYImAo4oFY9tAwYChlOKHYFPTIQkiV+MPgWJQwIEAgQFAhSBQ4EdcXAVGiEqAYJBCYV7hRSFPm8NJIhsDR6BAYEfAQE
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1531.3; Mon, 15 Oct 2018 12:08:27 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1531.003; Mon, 15 Oct 2018 12:08:27 -0400
From: "Gould, James" <jgould@verisign.com>
To: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] [regext] I-D Action: draft-ietf-regext-validate-04.txt
Thread-Index: AQHUYaOU7phsqSSRnkCtYECAIFNFzaUgf1WA
Date: Mon, 15 Oct 2018 16:08:27 +0000
Message-ID: <A9E8A9D3-AA26-4EE9-BDC1-C36D2FF70E27@verisign.com>
References: <153929082044.7093.3400710754084011140@ietfa.amsl.com>
In-Reply-To: <153929082044.7093.3400710754084011140@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.f.0.180709
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_A9E8A9D3AA264EE9BDC1C36D2FF70E27verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/B_sg_f7xx5rhIOHpT6szS3moNZU>
Subject: Re: [regext] I-D Action: draft-ietf-regext-validate-04.txt
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, 15 Oct 2018 16:08:41 -0000

Roger,



In implementing draft-ietf-regext-validate-04, below is my feedback:



  1.  Section 2.2 “Validate Id”
     *   I recommend creating 2 numbered paragraphs for the two different scenarios and end the first sentence with a colon “:”.  You could then change the “First if the <validate:id> is passed” with “1. If the <validate:id> element is passed” and “Second scenario would be if the request includes additional elements” with “2. If the <validate:id> element includes additional elements”.
     *   Nit – Change “>validate:postalIinfo>” to “<validate:postalInfo>”
  2.  Section 2.3 “Validate PostalInfo, Voice, Fax, Email, AuthInfo”
     *   I would directly refer to the validate elements by element name that mirror the associated elements in RFC 5733.  My recommendation is to be as explicit as possible here.  You reference section 2.3 for the elements in section 3.1.1 “EPP <check> Command”, but you really don’t describe the elements section 2.3.
  3.  Section 3.1.1 “EPP <check> Command”
     *   I recommend putting the attribute in double quotes as in ‘…two required attributes: contactType, which describes…’ to ‘…two required attributes: “contactType”, which describes…’ and ‘…tld, which provides…’ to ‘”tld”, which provides…’.
     *   I still don’t like the use of the <validate:kv> elements as a “flexible mechanism to share data between the client and the server”.  It would be best to enable the use of the EPP extensions to be passed directly to the validate mapping without the need for transforming them to key, value pairs.   The client and server would need to negotiate, most likely out-of-band, on the acceptable set of key, value pairs, or a new IANA registry would need to be defined to globally define the set of acceptable validate keys.



Thanks,



—

JG







James Gould

Distinguished Engineer

jgould@Verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/>



On 10/11/18, 4:47 PM, "regext on behalf of internet-drafts@ietf.org" <regext-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote:





    A New Internet-Draft is available from the on-line Internet-Drafts directories.

    This draft is a work item of the Registration Protocols Extensions WG of the IETF.



            Title           : Validate Mapping for the Extensible Provisioning Protocol (EPP)

            Authors         : Roger Carney

                              Joseph Snitker

                Filename        : draft-ietf-regext-validate-04.txt

                Pages           : 16

                Date            : 2018-10-11



    Abstract:

       This document describes an Extensible Provisioning Protocol (EPP)

       mapping for the validation of contact and eligibility data.





    The IETF datatracker status page for this draft is:

    https://datatracker.ietf.org/doc/draft-ietf-regext-validate/



    There are also htmlized versions available at:

    https://tools.ietf.org/html/draft-ietf-regext-validate-04

    https://datatracker.ietf.org/doc/html/draft-ietf-regext-validate-04



    A diff from the previous version is available at:

    https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-validate-04





    Please note that it may take a couple of minutes from the time of submission

    until the htmlized version and diff are available at tools.ietf.org.



    Internet-Drafts are also available by anonymous FTP at:

    ftp://ftp.ietf.org/internet-drafts/



    _______________________________________________

    regext mailing list

    regext@ietf.org

    https://www.ietf.org/mailman/listinfo/regext