[regext] Registry Fee "standard" Attribute Meeting Notes

"Gould, James" <jgould@verisign.com> Wed, 18 July 2018 12:40 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 46B0313119E for <regext@ietfa.amsl.com>; Wed, 18 Jul 2018 05:40:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, 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 K9GnYOUf8INT for <regext@ietfa.amsl.com>; Wed, 18 Jul 2018 05:40:27 -0700 (PDT)
Received: from mail4.verisign.com (mail4.verisign.com [69.58.187.30]) (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 6BC48131176 for <regext@ietf.org>; Wed, 18 Jul 2018 05:40:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=56852; q=dns/txt; s=VRSN; t=1531917627; h=from:to:subject:date:message-id:mime-version; bh=zxLcb3KDoVHOz7NttB9/nhKxmDzDC2aZtzOfEDV6NM8=; b=nhXOkJalfGw/19S9hw6GD5C5ZmJCAY351InVPOPuGSARFRo3gMhZz1X3 Gsu50b0hJaZhm6af17+H8L5x93BfqvZDGX5rzdvsD7auHTRDJE0ttW8Mi g8cdxsOaFpy1U0/pwjqtoShf1Phq2tLHUC3yUISbrca6UHLPYNb4koJoi Yr0upF8r6EyZaL9eYEA4UXMkEUSC1xUp9B9BplVTbj9jR7hClF4vL0FEH piG/sI4CSoBXfAnoYKKrQ+vO9iDCXe7cXytfdnCxclI60Gw0uWGt2LBgg 9kJy/ZN8Pk/Xd+JcPcyOG1ns8N1nEmGgPk6Fglm33yqjmW9C2FtHZQyqQ g==;
X-IronPort-AV: E=Sophos;i="5.51,370,1526356800"; d="png'150?scan'150,208,217,150";a="5245569"
IronPort-PHdr: 9a23:3ujzQhA21X/JVSAqBUpIUyQJP3N1i/DPJgcQr6AfoPdwSPTzr8bcNUDSrc9gkEXOFd2Cra4c1ayO6+jJYi8p2d65qncMcZhBBVcuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6JvjvGo7Vks+7y/2+94fcbglUhTexe69+IAmrpgjNq8cahpdvJLwswRXTuHtIfOpWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3sp683xtBnMVhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Xymp4aV2Rx/ykCoJNyA3/nzLisJ+j6xUrhOhqABwzIPPeoGZKP9+c7nBcd4AR2dMWNtaWSxbAoO7aosCF+QNM+dfr4ngo1sBsAOyDhSoCuz1zz9HmGT20aMn2OkmEwHG0wsgH88KsHvJt9j1KrkdUfq0zKnTzDXDYPVW1S3h54jPdxAsuPeBVq9+f8rWzEkgDQLFjlOIpIz7ITyVzOUNs3Oa7+pvU+KjkXIoqwZ0ojS32McjlJPJhoMOylDF+iV5xoc1JdukR0JhfdGkF55QuieHPIV1WsMvW3xktDogxrEbu5O2cjIGxIknyhPRcfCKfIyF7gr+WOqNOzt0mXBodK6lixqv/kWtyffwWtS33VpSoCpKjNrBumwI2hHW8MeKSf9w8Vyk1DuByQzc9+BJLEUvmqffKpMswLs9m5QdvEnBAyD7nlj9grWMeUU+4Oeo7vzqYrDhppCBKYB5khr+MqEymsynBuQ4LxQOU3Cb+eui0L3j+lX0TahWgPMuj6XWsIjUK8saqaKlHQNZyJgj5Aq4Dze8yNQUh2MII09fdBKZlYjpIFfOLOrkAve4hlSgiDZrx/bYMb39GpjBM2TPnK38cbt/5UNQ0hc/wNBR6p5OBbwMJOr/Wkrru9zZCh85PRa0w+HiCNhl1IMeVmWPArKdMKzPqlKI+PwgI/ONZI8OuTb9JP4l6+Tygn8+nF8RZbOp0ocPaHCkAvRmJF2UYWDyjdcOD2gLsRY+QffriFKcTT5TaWy+X6Um5jE0W8qaCtKJXI2ijayd9Ca2ApMQYXpJQBjYC3rnepWYc/YBdCzUJdVuxG8qT7+kHsUO0gyquEuy6bNiI/GesnkaupX+0NRd+eDJlAoz+joyBMOYhTLeB1pol38FEmdllJt0plZwnw+O
X-IPAS-Result: A2EwAQCQNE9b/zGZrQpZAxwBAQEEAQEKAQGCU0yBDYEnCoN0iASOE4Mfkj6BPzsIAQITDA+EPhmDBDQYAQIBAQEBAQECAQECgQUBC4I1IhFLLwgBMgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQgCCAdHASUBHQIIAUAdASUBAQEYAQkCBAUQAQ4MJwQKCAEGCA2DBQGrVoEuhFuFXw+KWj6BOAyCXoRlLQoLG4I6MYIkApY1gysDBgKFNAFTimFDg06IEYY4hAOHNQIEAgQFAhSBQYILcBU7KgGCPgmCHBd6AQiCQopSbw0ji0qBGgEB
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1466.3; Wed, 18 Jul 2018 08:40:25 -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.1466.003; Wed, 18 Jul 2018 08:40:25 -0400
From: "Gould, James" <jgould@verisign.com>
To: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: Registry Fee "standard" Attribute Meeting Notes
Thread-Index: AQHUHpSAXO2kl3lLE06Dx/B+tH3D4A==
Date: Wed, 18 Jul 2018 12:40:25 +0000
Message-ID: <4DC60586-6F72-4117-8F9E-0F2EDFE54146@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.e.1.180613
x-originating-ip: [10.170.148.18]
Content-Type: multipart/related; boundary="_004_4DC605866F7241178F9E0F2EDFE54146verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/dykfIv-Edy5ZAdWd1cTnPPnifzc>
Subject: [regext] Registry Fee "standard" Attribute Meeting Notes
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 18 Jul 2018 12:40:40 -0000

A group met at IETF-102 to discuss the question of inclusion of the “standard” attribute in the draft-ietf-regext-epp-fees.


  1.  Attendees
     *   Roger Carney – GoDaddy
     *   Jim Galvin - Afilias
     *   James Gould – Verisign
     *   Jody Kolker (remote) – GoDaddy
     *   Patrick Mevzek (remote) – Dot and Co
     *   Wadson Tseng - Afilias
     *   Rick Wilhelm – Verisign
     *   Joseph Chiu-Kit Yee – Afilias
  2.  Notes
     *   Discussed the background of the issue

                                                              i.      Roger posted the IETF-100 open question  to the mailing list

           *   The appropriate level of the <fee:class> element (<fee:command> or <fee:cd>)

                                                            ii.      Pat Moroney raised the concern of handling a non-standard create with a standard renew

                                                          iii.      Jim Gould provided a proposed solution with inclusion of the “standard” attribute

           *   Proposal moved the <fee:class> element to the <fee:cd> element and added the optional “standard” boolean attribute with a default of “false”
           *   A proposed XML schema and sample XML was posted in an attachment

                                                          iv.      Pat Moroney agreed with the proposal

                                                            v.      Patrick Mevzek and Alex Mayrhofer advocated against the “standard” attribute

                                                          vi.      Roger added the “standard” attribute in draft-ietf-regext-epp-fees-09, but to the check command instead of the check response

           *   The incorrect location of the “standard” attribute was identified by the document shepherd when reviewing this issue
     *   Discussed Alex Mayrhofer’s Feedback provided offline

                                                              i.      I did a quick review of my own message from back then, and I still stand by that opinion. The basis of that is that we should not artificially complicate things for registrars, because that could hurt adoption and interoperability.

                                                            ii.      I don’t bother about optional attributes in responses. it’s more about the required inclusion of the EPP extension for transactions which would not require the extension in the first place.

                                                          iii.      In the case the registry requires Fee Extension for the transfer, non-Fee-supporting registrars would be unable to transfer, even though the price is identical to standard names. I want to prevent that. Essentially – when the *price* for a transaction is equal to the standard price of the TLD, don’t require the extension.

                                                          iv.      Note – the group viewed the handling of the transfer of non-standard (premium) domain names as registry policy and independent to the inclusion of the “standard” attribute.

     *   Discussed the purpose of the “standard” attribute

                                                              i.      The group viewed the inclusion of the “standard” attribute as in line with the server data model (classification is an object-level attribute), and providing more information without a change in behavior

     *   Result

                                                              i.      Agreed to include the “standard” attribute but move it from the check command (commandType) to the check response (commandDataType)

     *   Action Items

                                                              i.      Jim Gould to present the result of the meeting at the IETF-102 REGEXT meeting for discussion

                                                            ii.      Jim Gould to post the meeting notes to the REGEXT mailing list

                                                          iii.      Roger Carney to post draft-ietf-regext-epp-fees-12 that moves the “standard” attribute from the check command (commandType) to the check response (commandDataType).

Please let me know if I missed anything.

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