Re: [HR-rt] [regext] Human Rights Review of draft-ietf-regext-verificationcode

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

Return-Path: <jgould@verisign.com>
X-Original-To: hr-rt@ietfa.amsl.com
Delivered-To: hr-rt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B109130F67; Mon, 8 Oct 2018 12:59:00 -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, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=unavailable 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 fIm7uow3Cgz7; Mon, 8 Oct 2018 12:58:55 -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 B680C13112E; Mon, 8 Oct 2018 12:58:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=107462; q=dns/txt; s=VRSN; t=1539028734; h=from:to:cc:subject:date:message-id:mime-version; bh=mYVIqthqA8vmOBvKwIJvhnuSjFUrEZKAfF1Wgw6KdOM=; b=HPFV2og+eFVxAoIoyF1LjzvVZnVr1IpJbwVrQrXqugYm3a6iMt0j85YF Is2Sizd0pD2H/M/3KRmutq1H71d2YADCluMfTCpNDXAALJ2RRArWxpYYj Kbioxq3u7GDmsdUDiyqjuKDPfu4anwA6qOdVuwkXl3HtHdug2e94NEjX6 rzOoQyWLAh5Bwggd3XIJilK+qo9zx546mekjyIvfKAvp35GfZZ27ZNVj6 QpyKF5aNWBijqqkWZOq2tXiksSZMoNEn3Mz4/XQ+3FwMv37I34SJucwNw 5dnjMNKmDMdmn6iK3DTydc9TQQPqcRrKhQ22gxNOUxWqpgwwdRBv7O4E9 A==;
X-IronPort-AV: E=Sophos;i="5.54,357,1534809600"; d="png'150?scan'150,208,217,150";a="5927961"
IronPort-PHdr: =?us-ascii?q?9a23=3AdlKJHBBJCx0mcvDFupIUUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSP36r8uwAkXT6L1XgUPTWs2DsrQY07WQ6/iocFdDyK7JiGoFfp1IWk1Nou?= =?us-ascii?q?QttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBAj0OxZr?= =?us-ascii?q?KeTpAI7SiNm82/yv95HJbAhEmDiwbaluIBmqsA7cqtQYjYx+J6gr1xDHuGFIe+?= =?us-ascii?q?NYxWNpIVKcgRPx7dqu8ZBg7ipdpesv+9ZPXqvmcas4S6dYDCk9PGAu+MLrrxjD?= =?us-ascii?q?QhCR6XYaT24bjwBHAwnB7BH9Q5fxri73vfdz1SWGIcH7S60/VDK/5KlpVRDokj?= =?us-ascii?q?8KOT4n/m/Klsx+gqFVrxygpxNjzIHZe5uVOOZ7fq7HYd8XX2hMU8BMXCJBGIO8?= =?us-ascii?q?aI4PAvIPMehZqIn9ul8OogamCQKxAO3g0DpIiWHt3aE0zu8sFgPG3AMnH9ITtH?= =?us-ascii?q?Tbsc74NLkMXuCvzanI1jTDb/xQ2Tvn9IfIdRUhrOiKULltf8TRzkwvGBnEjlWW?= =?us-ascii?q?sYHlIS2a1v4Ms2iA7upgWuSvh3Q7pAF2pzij3tkshZfThoIU0VDE9Cp5wIA0Jd?= =?us-ascii?q?2+VEF3e8KrEJxVty2CLYt2TN8tT3h2tykny70GpZm7fDIQxJQg3R7fZOSLc4eP?= =?us-ascii?q?4hLkW+aRJSl3iGh5d7K4gha+6VKvyvfgVsm1zFlKqjRKnsTIu3wX0BzT8MeHRu?= =?us-ascii?q?N8/ki/xTaP2Rrf6uZeIUA7k6fQNp0vwqYom5YOrUjPBDL6lUf4gaOMa0kp+ual?= =?us-ascii?q?5/7ob7jlvpOQKpN4hhvjPqkshsCzG/k0PwcNUmSB5Oix16Xv/UPnT7hJkvE7l6?= =?us-ascii?q?zUv4rZKMkfvaG0BgFY3pg+5Bu+Cjqpy9AVkHgFIV9Adh+KgYrkNEzILfvlF/mw?= =?us-ascii?q?mU6sny1ux/3eO73hBYjCIWbbnbf6eLZ991ZcyA0uzdBD/55UCq8OIPb0WkLpqd?= =?us-ascii?q?HWEgc3PxG0zOj/B9ty158SVX+VDq+HLKzStkWI5vo1L+aWeYAZoij9K+I+5/7o?= =?us-ascii?q?l3M2hVgdfayx0ZsWbnC3AOhmLl2EbXbwmNsNDGUHswQkQOD3iFCPXyRfanmxUq?= =?us-ascii?q?4k4zE0EoOmDYPNRoC3h7yB2T+2Hp9ZZmBBF1CMFWrnep6aW/gSciKSI9Rhkj0L?= =?us-ascii?q?VbinUYMuyRautArix7p9MuXU4jEYtY7k1NVt6O3TiAsy9Sd0D8uHyG6CVXx7k3?= =?us-ascii?q?gUSD83x6BzuE19ylGe3qh5mfNUD9tT5+lGUg0iL57T0/R6C8zuWgLGZtqJUkip?= =?us-ascii?q?Qtq4DjA+UtI82N4ObFhhG9WslBzD2DCqA7ANnbyRGJM06r7c32T2J8tly3bGzr?= =?us-ascii?q?Atj0M6QsZUNG2mnLJ/9wbJC47OiUWZmL6gdb4A0y7V6GeD0W2OsVlYUA5qSaXK?= =?us-ascii?q?QWsSZkrMrdTl6EPOVbiuCa4oMlgJ9cnXYKRXcMbphF9PSN/oOc+bYmS9mm72Ag?= =?us-ascii?q?yHjPvYY5fwYGUU1izRIEMFiEUS+3qHPE45HCj35yqUFjFhGELzS0Lh7ec4r2m0?= =?us-ascii?q?BAdg1QyFYl19/7u45hBTguaTHaA9xLUB7W0OrChwEBL1/dvTBsHK715jc6JBZd?= =?us-ascii?q?8V/lpd1HnYuAo7NZulefMxzmUCehh66hu9ny58DZ9NxJAn?=
X-IPAS-Result: =?us-ascii?q?A2EVAADAtrtb/zCZrQpaBwMcAQEBBAEBBwQBAYFRBwEBCwG?= =?us-ascii?q?BDkgFgRCBJwqDa4gVjj2DAI8FhGQUgRADGBcdBAMIAQMBGAEOB4N4RhmESDQND?= =?us-ascii?q?QEDAQEBAQEBAgEBAoEFDII2Ig0ELxwvCQEBBAEBAQEBAQEBASQBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEIAggFAiMSBgwBARgBAgEDAQEDARQBC?= =?us-ascii?q?AIIAUALEgEIEQMBAgYBAQEYAQkCBAUQAQ4BCx0KBAENBAEGCIJIKAEiAYIQA6R?= =?us-ascii?q?dgS6EKwEHBz2FCQ+LUIFCPoESJx+CTIMbAQECAQEWgRQBBwQBBQIBAggODwMLC?= =?us-ascii?q?QEdCYI6MYImAog7DBIMhSsVhXGDVIFUg19RAwYChWsBYIdYgjqBTkuEGolEhzO?= =?us-ascii?q?EcQSGaYI6AgQCBAUCFIFCbTBxcBU7KgGCQQmCHRd7AQSCRoUUhT5vAQwkinoBg?= =?us-ascii?q?S2BHwEB?=
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, 8 Oct 2018 15:58:51 -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, 8 Oct 2018 15:58:51 -0400
From: "Gould, James" <jgould@verisign.com>
To: "gurshabad@cis-india.org" <gurshabad@cis-india.org>, "regext@ietf.org" <regext@ietf.org>
CC: "hr-rt@irtf.org" <hr-rt@irtf.org>, "hrpc@irtf.org" <hrpc@irtf.org>
Thread-Topic: Re: [regext] Human Rights Review of draft-ietf-regext-verificationcode
Thread-Index: AQHUX0FVR9Ku6RuhQ0K/OfO1NO2hBg==
Date: Mon, 8 Oct 2018 19:58:51 +0000
Message-ID: <B1B8FB84-53DD-4DC5-B4B4-805DB57ED38C@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.f.0.180709
x-originating-ip: [10.170.148.18]
Content-Type: multipart/related; boundary="_004_B1B8FB8453DD4DC5B4B4805DB57ED38Cverisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/hr-rt/4YnSq5fXfHMWYq8fJsK3cn9IsIw>
Subject: Re: [HR-rt] [regext] Human Rights Review of draft-ietf-regext-verificationcode
X-BeenThere: hr-rt@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Human Rights Protocol Considerations Review Team <hr-rt.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hr-rt>, <mailto:hr-rt-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hr-rt/>
List-Post: <mailto:hr-rt@irtf.org>
List-Help: <mailto:hr-rt-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hr-rt>, <mailto:hr-rt-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Oct 2018 19:59:00 -0000

Gurshabad,


I posted draft-ietf-regext-verificationcode-04 (https://tools.ietf.org/html/draft-ietf-regext-verificationcode-04) that incorporates your feedback with the “The data verified by the VSP MUST be stored by the VSP along with the generated verification code to address any compliance issues.” sentence, with the additional “The VSP MUST store the proof of verification and the generated verification code; and MAY store the verified data.” sentence added to the Security Considerations section.  Let me know if you have any additional feedback.

Thanks,

—

JG

[cid:image001.png@01D255E2.EB933A30]

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

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

From: James Gould <jgould@verisign.com>;
Date: Thursday, October 4, 2018 at 9:23 AM
To: "jgould=40verisign.com@dmarc.ietf.org"; <jgould=40verisign.com@dmarc.ietf.org>;, "gurshabad@cis-india.org"; <gurshabad@cis-india.org>;, "regext@ietf.org"; <regext@ietf.org>;
Cc: "hr-rt@irtf.org"; <hr-rt@irtf.org>;, "hrpc@irtf.org"; <hrpc@irtf.org>;
Subject: Re: [EXTERNAL] Re: [regext] Human Rights Review of draft-ietf-regext-verificationcode

Gurshabad,

In reviewing your feedback for technical issues, I identified an item to be addressed.  Quoting from your note:

        The draft notes that, “the data verified by the VSP MUST be stored by
        the VSP along with the generated verification code to address any
        compliance issues.”

        Registrants whose personal information will be shared in this way have
        no control over these aspects, which negatively impacts their privacy.

In consideration of this comment, I plan to revise this sentence in the Introduction:

“The data verified by the VSP MUST be stored by the VSP along with the generated verification code to address any compliance issues.”

in a subsequent draft to be:

“The VSP MUST store the proof of verification and the generated verification code; and MAY store the verified data.”

I will also add text the Security Considerations section to ensure that the storage of the data that was verified by the VSP is stored securely and in line with applicable privacy laws and regulations.




—

JG







James Gould

Distinguished Engineer

jgould@Verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



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



On 10/3/18, 9:14 AM, "regext on behalf of Gould, James" <regext-bounces@ietf.org on behalf of jgould=40verisign.com@dmarc.ietf.org>; wrote:



    Thanks for the review, Gurshabad. I'll consider your feedback in the context of technical issues with the draft.  The registration of domain names in some jurisdictions may be subject to various requirements that involve verification by a party other than the registry.  The draft is intended for interoperability and is independent of the verification process. The EPP extension takes no position on specific verification processes which are a "local matter" for the implementation. For these reasons, I disagree with your assertion that implementation of the proposed extension will impact domain registrants' right to freedom of expression, right to freedom of assembly and association, and right to privacy. Rather the EPP extension, as the draft describes, is a proposal for a standard framework for the common industry practice of providing proof of verification to meet legal and/or security requirements within a given top-level domain.



    —



    JG







    James Gould

    Distinguished Engineer

    jgould@Verisign.com



    703-948-3271

    12061 Bluemont Way

    Reston, VA 20190



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



    On 9/20/18, 5:02 PM, "regext on behalf of Gurshabad Grover" <regext-bounces@ietf.org on behalf of gurshabad@cis-india.org>; wrote:



        Hi all,



        Firstly, thanks to James Gould and the regext working group for

        developing draft-ietf-regext-verificationcode.



        As part of efforts in the Human Rights Protocol Considerations (HRPC)

        group, I have reviewed the human rights considerations (using RFC 8280

        as a framework) in draft-ietf-regext-verificationcode-03. Please find

        the review below. Hope that some of these concerns can be addressed

        moving forward.





        HR Review: Verification Code Extension for the EPP

        ==================================================



        An assessment of human rights considerations in

        draft-ietf-regext-verificationcode-03.



        Introduction

        ------------

        The ‘Verification Code Extension for the Extensible Provisioning

        Protocol (EPP)’ ([VCEPP], hereinafter also referred to as the “draft”)

        describes an extension in the EPP object mappings which supports adding

        a verification code provided by a third-party known as the Verification

        Service Provider (VSP). If the registrant’s data is not “verified” by

        the VSP, it may be prohibited from requesting the execution of EPP

        transform commands.



        This is a review of the human rights considerations in the the draft.

        (See [RFC 8280], ‘Research Into Human Rights Protocol Considerations’).

        We believe that the draft does not make adequate considerations for

        human rights: The implementation of the proposed extension will impact

        domain registrants’ right to freedom of expression, right to freedom of

        assembly and association, and right to privacy.



        Human Rights Considerations

        ---------------------------



        # Privacy ([RFC8280], section 6.2.2)



        From [RFC8280]: “Could your protocol improve data minimization?” and

        “Does your document identify potentially sensitive data logged [...]

        and/or for how long that data needs to be retained for technical reasons?”



        The draft leaves the precise data shared with the VSP “up to the

        policies of the locality” and outside the scope of the draft. In the

        'domain-registrant' type of verification, both the registrant contact

        information and domain name are sent to the VSP. The registrant contact

        information is sensitive personal information, including name, address,

        telephone number and email address. [RFC5733]



        The draft notes that, “the data verified by the VSP MUST be stored by

        the VSP along with the generated verification code to address any

        compliance issues.” The information is retained and “may be accessed at

        a later time.”



        Registrants whose personal information will be shared in this way have

        no control over these aspects, which negatively impacts their privacy.



        # Content Agnosticism ([RFC8280], section 6.2.3)



        From [RFC8280]: “Does your protocol make decisions based on the payload

        [...]? Does your protocol prioritize certain content or services over

        others [...]?”



        Section 1 of the draft states that the “Verification Service Provider

        (VSP) is a certified party to verify that data is in compliance with the

        policies of a locality.” Therefore, the extension facilitates the

        prioritization of certain individuals based on how the VSP judges

        whether the registrants’ data is compliant. Registrants’ data which is

        not in “compliance” with the local regulations will not receive a

        verification code from the VSP, which gives the VSP the power to

        restrict individuals from registering/modifying a domain name, and

        limits their right to freedom of expression.



        # Censorship Resistance ([RFC8280], section 6.2.6)



        From [RFC8280]: “Can your protocol contribute to filtering in such a way

        that it could be implemented to censor data or services?  [...]”



        By design, the extension facilitates filtering: the VSP will receive the

        power to “verify” data on arbitrary grounds when determining whether

        registrant data is in “compliance” with local regulations. The draft

        also identifies examples of these scenarios: the VSP will check whether

        “the domain name is not prohibited”, or whether the “registrant is a

        valid individual, organization, or business in the locality.” On these

        grounds, the VSP can accept or reject attempts to register domain names.

        Thus, the extension explicitly provides filtering and censorship

        abilities to the VSP, which are inimical to the registrants’ freedom of

        expression.



        # Open Standards ([RFC8280], section 6.2.7)



        From [RFC8280], “Are you aware of any patents that would prevent your

        standard from being fully implemented [RFC6701] [RFC8179]?”



        There is an IPR declaration filed by Verisign Inc. for an older version

        of the draft mentioning the relevant [PATENT]. The declaration

        facilitates mostly open development, giving minimal assertion rights

        over the license for Verisign Inc.



        From [RFC8280]: “Is your protocol fully documented in such a way that it

        could be easily implemented, improved, built upon, and/or further

        developed?”



        Several key details that will form the complete mechanism for the

        verification code are not included in the draft (as it only describes

        the extension), but have been offered in the [PATENT]. This includes a

        description of the grace period within which “the requirement set of

        verification codes may be sent before the object becomes non-compliant”,

        and a clear depiction of the flow of the request detailed in Fig. 1 of

        the [PATENT].



        # Decentralisation ([RFC8280], section 6.2.14)



        From [RFC8280]: “What is the potential for discrimination against users

        of your protocol?”



        There is immense potential for discrimination against registrants whose

        data will be subject to “verification” by the VSP. The proposed

        extension provides the VSP powers to discriminate against registrants

        based on the information it receives, which may include names and

        addresses, and which may be further compared to other “local data

        sources” [VCEEPP] to indicate legal sex, religious affiliation, or

        ethnicity.



        From [RFC8280]: “Can your protocol be used to negatively implicate users

        (e.g., incrimination, accusation)?”



        There is potential for negative implication: a malicious registrant may

        submit a request for a domain name considered legally “prohibited” by

        the locality, accompanied with someone else's personal information.

        Registrant information is sent to the VSP, an entity that may be

        associated with law enforcement, which creates potential misuse for

        false incrimination/accusation.



        # Reliability ([RFC8280], section 6.2.14)



        No fallback mechanism is specified within the draft for when the VSP is

        offline or unavailable. In the event that the VSP is not available to

        process the sent object, the registrants’ requests will not be performed.



        Similarly, when considering how long the VSP takes to process a

        particular request, Section 0057 of the [PATENT] states that a “pending

        compliance status indicator may indicate that the object is not

        compliant by [...] a time, or grace period, in which the requirement set

        of verification codes may be sent before the object becomes

        non-compliant.” Therefore, if the VSP does not respond within the grace

        period, the object will be considered “non-compliant”. The proposed

        extension thus creates a problematic assumption of  “non-compliance”,

        which is at odds with the presumption of innocence.



        # Confidentiality ([RFC8280], section 6.2.15)



        From [RFC8280]: “What options exist for [...] implementers to choose to

        limit the information shared with each entity?”



        No such mechanisms are present which allow the registrants to limit the

        information that will be accessed by the VSP.



        # Integrity ([RFC8280], section 6.2.16)



        From [RFC8280]: “Does your protocol maintain, assure, and/or verify the

        accuracy of payload data? Does your protocol in any way allow the data

        to be (intentionally or unintentionally) altered?”



        The XML Signature maintains authenticity and integrity of the

        verification code. However, we are not sure whether the object can be

        altered by the VSP before appending the verification code to the shared

        object. If so, it creates the potential for false implication (also see

        section on Decentralisation) by the VSP.



        # Outcome transparency ([RFC8280], section 6.2.19)



        From [RFC8280]: “Are the effects [...] fully and easily comprehensible

        [...]?”



        As highlighted earlier in the review, many details (some out of the

        scope of the draft) may be opaque to registrants with the implementation

        of the proposed extension, including but not limited to, the exact data

        shared with the VSP.



        Additionally, as the [PATENT] notes, a “rejection of the verification

        request may be transmitted [...]” by the VSP. Therefore, while the

        proposed extension technologically facilitates a legal mechanism, there

        are no built-in measures that facilitate human rights related to legal

        transparency, remedy, or due process. For example, the VSP has no option

        to append an explanation for sending back a rejection.



        Conclusion

        ----------

        In summary, the proposed extension in its implementation allows the VSP

        to have enormous censorship and discriminatory power. The arbitrary and

        opaque mechanism to “verify” compliance with local regulations gives

        disproportionate powers to impede freedom of expression, right to

        privacy, freedom of association, and the right to non-discrimination.



        Some of the concerns highlighted in this review have already been

        pointed out in the past in and outside the IETF. [NLLZMSG][ART-19] We

        hope that the WG considers the potential adverse human rights impact

        that the proposed extension creates before recommending its

        standardisation. We understand that some of the concerns in the review

        do not stem purely from the proposed extension, but due to the

        unavoidable consequences of implementing the extension. The WG could

        consider adding the details of those to the draft as well, so as to make

        its impact on human rights clearer.



        References

        ----------

        [RFC8280] ten Oever, N., Cath, C., “Research into Human Rights Protocol

        Considerations”, RFC 8280, October 2017,

        <https://www.rfc-editor.org/info/rfc8280>;.

        [VCEEPP] Gould, J., “Verification Code Extension for the Extensible

        Provisioning Protocol (EPP)”, draft-ietf-regext-verificationcode-03,

        April 2018,

        <https://datatracker.ietf.org/doc/draft-ietf-regext-verificationcode/>;.

        [IP-DECL] Ward, M., “Verisign Inc.'s Statement about IPR related to

        draft-gould-eppext-verificationcode”, October 2015,

        <https://datatracker.ietf.org/ipr/2703/>

        [RFC5730] Hollenbeck, S., “Extensible Provisioning Protocol (EPP)”, RFC

        5730, August 2009,

        <https://www.rfc-editor.org/info/rfc5730>

        [RFC5731] Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain

        Name Mapping”, RFC 5731, August 2009,

        <https://www.rfc-editor.org/info/rfc5731>;.

        [RFC5732] Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Host

        Mapping”, RFC 5732, August 2009,

        <https://www.rfc-editor.org/info/rfc5732>;.

        [RFC5733] Hollenbeck, S., “Extensible Provisioning Protocol (EPP)

        Contact Mapping”, RFC 5733, August 2009,

        <https://www.rfc-editor.org/info/rfc5733>;.

        [PATENT] Waldron, J., et al. “Domain Name Operation Verification Code

        Generation and/or Verification”, United States Patent Serial No.

        14/868,972, September 2015,

        <https://patents.google.com/patent/US20170093793A1/en?oq=United+States+Patent+Serial+No.+14%2f868%2c972>;.

        [NLLZMSG] ten Oever, N., “Re: [regext] I-D Action:

        draft-ietf-regext-verificationcode-01.txt”, IETF Mail Archive: regext,

        April 2017,

        <https://mailarchive.ietf.org/arch/msg/regext/EIK0E7ins874q8DmP37yg7AzAQI>;.

        [ART-19] Article 19 Digital, “Corporate actors must not facilitate human

        rights violations through new Chinese rules”, Article 19, December 2016,

        <https://www.article19.org/resources/corporate-actors-must-not-facilitate-human-rights-violations-through-new-chinese-rules/>;.



        Acknowledgements

        ----------------

        Thanks to Paul Kurian for research inputs. Thanks to Amelia

        Andersdotter, Mallory Knodel, Sunil Abraham and Swaraj Barooah for their

        feedback. Please note that acknowledgement here does not necessarily

        imply endorsement of the contents of the review.



        --

        Thank you.

        Gurshabad









    _______________________________________________

    regext mailing list

    regext@ietf.org

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