Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

"Gould, James" <jgould@verisign.com> Thu, 27 April 2017 13:26 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 A2B6D1276AF for <regext@ietfa.amsl.com>; Thu, 27 Apr 2017 06:26:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 ioITXDeEVPXK for <regext@ietfa.amsl.com>; Thu, 27 Apr 2017 06:26:47 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3121200DF for <regext@ietf.org>; Thu, 27 Apr 2017 06:26:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=10154; q=dns/txt; s=VRSN; t=1493299606; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=hLXscJNvNMTrIdKpr+hxBAhaTkV41IWjkXGhlTFvKQQ=; b=R0JjPrb311ySWJDfZvudK4MXzXwyuKtPimogLxARX7RKKjsyYfFhHk6f /hZqu4jB7uBrqIveTz7lfejj147STpzoRhK3H3X1DatE2RQ4Qm+bciZuu Sk8LGoe0kHJ8RyvUh0RAngZchJs+oyWKSdzkvyaFEzOnkBmctcMrZfrGY 5ev8QLDEQWUXCBWYtErxXNafRxTlgrDcx4idjWttOmoZaZbTg3VJz+A2v tdxpiNiz74+V866zZiFwCAopnDaHIWz5bI9wgAZoQH0yW3YEL1NWRXhtt A37TXI6M4hswKKGjLfqRMZ2k78YeRUqcgZhS8IhDKkI0N9kbiSVXDXSNN g==;
X-IronPort-AV: E=Sophos;i="5.37,383,1488844800"; d="scan'208";a="2863789"
IronPort-PHdr: 9a23:Puy+ExM6swuVkjBzcnIl6mtUPXoX/o7sNwtQ0KIMzox0I/r8rarrMEGX3/hxlliBBdydsKMYzbKO+4nbGkU4qa6bt34DdJEeHzQksu4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1Ov71GonPhMiryuy+4ZPebgFHiTanfb9+MAi9oBnMuMURnYZsMLs6xAHTontPdeRWxGdoKkyWkh3h+Mq+/4Nt/jpJtf45+MFOTav1f6IjTbxFFzsmKHw65NfqtRbYUwSC4GYXX3gMnRpJBwjF6wz6Xov0vyDnuOdxxDWWMMvrRr0vRz+s87lkRwPpiCcfNj427mfXitBrjKlGpB6tvgFzz5LIbI2QMvd1Y6HTcs4ARWdZXshfSTFPAp+yYYUMAeoOP+hXr4jhqFUBohSzHhWsC/jqyjNUmnP7x6833uI8Gg/GxgwgGNcOvWzaoNv0M6cSTOS1w7TQwT7ea/1ZwzL955bTchwvvPqBWrBwccXWyUkyEwPKk06dqZL7MDOP1+QNqGmb7+VmVe61l2EnrARxryGpy8wxhIfJgYcVxUrF9SV/2Is1O8O3SFR6Yd6/EZtQuCeaN4pwQsw+WW1npCE6yrgAtJWmfyYK0IwqywPDZ/CdboSF4BzuWPyMLTp4in9pYqyzihmy/ES41+HwStO43EtIoyZZiNXAq38A2h/J5sSaSfZw+Fqq1yyV2ADJ8O5EJFg5la/cK5E83LE9joETsUHfHi/un0X2kbOWel0k+ue27+TnZa3rqYSGN49ylw3+NqsvmsmlDuQ5NggOWHWb+fig2LH950H5XqtFjuc3kqnCsZDaKsIbqrSlDA9S14Yv8xe/DzG439QEhXQLMU5JdAiag4XrNVzCOu30APexjli2jjtmyPDLMqXkAprXL3jDlLnhfax6605Z0Aczz99f55VJCrEFPf3+QVHxu8LCDh84KAy0wunnCNNn2owCXmKPB7eVMLnOvl+Q+uIvP+6MaZcPuDnjJPgq+fHvjWMilF8cY6apwZUXZGq/HvR8LEWTeWDsjcsZEWcWogo+S/Tnh0eCUT5OfHm9Qbg86yomCIKgDIfDWp6ij6GY0CimGZ1WY3pJClGKEXfzbYmLRukDO2quJZpIlDAeWLG6A6883xy0/Fvzy6dtI/D85ysZqZ/vkdRy4uTSkwp0+TEiS4zXyWyCQnFotmIFWzFw27pw6wQp0FqM3Lhkq/1VCdIV4OlGBFQUL5nZmqZVDM32VkaJXN6MRU3sCoGkDjYsSt4Z3dIUYl18FNPkhRfGiXn5S4QJnqCGUcRnupnX2GL8coMkky7L
X-IPAS-Result: A2HTAADl8AFZ//WZrQpZAxkBAQEBAQEBAQEBAQcBAQEBARQBAQEBAQEBAQEBAQcBAQEBAYJ/gQyBDAeDYYoYkSkhlWyBTDwHIQuFLkoCGoQ9GAEBAQEBAQEBAQEBAoEQgjMiAQwsGiELAQEBAQEBJgEBAQEBAQEBAQEBAR0CCDYSAQEYAQEBAQMBASEROhcEAgEGAg0BAwQBAQMCEQEBEAMCAgIlCxQBCAgCBAEJCYorjnOdYYImixwBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQuFSoIIC4JkgyCBKRYXCh4IAQGCPYJfBZAPjTsGAYcYhkuHKlWEYooliHSBfok1H4FDbxUaKhIBhl11hlINgSGBDQEBAQ
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id v3RDQifT029296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Apr 2017 09:26:45 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Thu, 27 Apr 2017 09:26:44 -0400
From: "Gould, James" <jgould@verisign.com>
To: Andreas Huber <ahuber@united-domains.de>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt
Thread-Index: AQHSvgyLHX5NOJA3TECezgNU1qiDK6HYBgAAgAExugA=
Date: Thu, 27 Apr 2017 13:26:44 +0000
Message-ID: <05BDD09D-EA7E-4088-9800-491766858BFC@verisign.com>
References: <149315587791.25495.417733685865005328@ietfa.amsl.com> <BN6PR02MB254751866384924580716F3EB11E0@BN6PR02MB2547.namprd02.prod.outlook.com> <2733b233-390a-3a56-20d3-94f8fab94660@united-domains.de>
In-Reply-To: <2733b233-390a-3a56-20d3-94f8fab94660@united-domains.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <983627DA66DDBF4FA06C20B42CD819F7@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Y9QGoKiombEXaoJ7eg8IpUOii-Y>
Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.22
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, 27 Apr 2017 13:26:49 -0000

I believe the classification <fee:class> should remain at the object-level, since the concept of standard or premium is done at the object-level and not at the command level.  There may be the use case where a premium domain has a higher fee for the create but has the same fee as a standard domain for the renew and transfer, but that is based on the fee schedule defined for one or more premium domain names.  The key is that the fee is more variable for premium domains than for standard domains, so it may be misleading to return “standard” for the renew and transfer commands of a premium domain if the premium fee and standard fee happens to be the same, since there is implied variability with the premium domain.   It’s best to leave the classification as an object-level attribute and not attempt to derive it based on a comparison between the fee schedules.  

  
—
 
JG



James Gould
Distinguished Engineer
jgould@Verisign.com

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

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

On 4/26/17, 11:12 AM, "regext on behalf of Andreas Huber" <regext-bounces@ietf.org on behalf of ahuber@united-domains.de> wrote:

    Hi Roger,
    
    thanks for version 0.17! This one should solve most of our "registrar" issues (Hopefully, some registries plan to implement this version soon).
    
    Some thoughts to open questions:
    
    * Premium Domain Availability without Fee-Ext.
    
    I would also vote to respond with "unavailable".
    
    The status "premium" of a domain could be understood in a similar way to the domain status reserved, blocked or registered. Without using the fee extension, it's not possible to register such names, therefore they're "unavailable" for the registrar just like reserved names.
    If we don't want to use the Fee-Ext. for a specific registry (because of contractual reasons or something else), we're not interested in the availability of premium names which we can't/won't register anyway.
    
    Second thought: From a registry's perspective, I understand a name is always "available" if it is not registered, blocked or reserved, independent of any fees. But, ;) since EPP is a personalized communication protocol (client needs to login and register extensions to use), then responses should be
    personalized to the client. For a client not using the fee extension, a premium name is technically "unavailable".
    
    
    * <fee:class> in check responses
    
    The last weeks a question regarding the <fee:class> element came up a couple of times.
    
    <fee:class> is a child of <fee:command> since version 0.13, therefore section 3.7. should be clarified.
    
    Is <fee:class> an attribute of a specific fee or an object? There are some misunderstandings, especially before version 0.13, which describes "class" as a child of <fee:cd>. Several discussions with registries pointed out, that they understand <fee:class> as "attribute" of the object. This results
    in conditions where a domain has a premium create but a standard renewal fee to be both tagged with "premium", because an object can only have one value of the same attribute.
    
    As an example (from section 3.7): "The <fee:class> element which appears in <check> responses is used to indicate the classification of an object." should be changed to something like "... the classification of a command fee".
    
    As a registrar, we need to know if a "command fee" (not an object) is premium (e.g. <fee:class>premium</fee:class>) or standard, if one wants to respond standard fees at all. Responding standard fees are in fact unnecessary, btw.
    
    
    Thanks,
    Andreas
    
    
    
    
    Am 25.04.2017 um 23:40 schrieb Roger D Carney:
    > Good Afternoon,
    > 
    >  
    > 
    > Here is the update draft document. This should include all of the agreed upon changes from the Chicago meeting (biggest change was the simplification of the <check> call).
    > 
    >  
    > 
    > One topic that was discussed in Chicago (and not resolved) was on the concept of “premium names” and what is returned from the server if no fee extension was passed into the <check>. Many thought to be more “backwards compatible”/”user friendly”, especially for those registrars that do not and may
    > not be participating in the allocation of “premium names”, that the server should respond as unavailable. Others expressed that if it is available then the server should respond available. Please share your thoughts on the list on this topic and if this draft should even try to account for this concept.
    > 
    >  
    > 
    > Please let me know if you have any questions.
    > 
    >  
    > 
    >  
    > 
    > Thanks
    > 
    > Roger
    > 
    >  
    > 
    >  
    > 
    > -----Original Message-----
    > From: regext [mailto:regext-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
    > Sent: Tuesday, April 25, 2017 4:31 PM
    > To: i-d-announce@ietf.org
    > Cc: regext@ietf.org
    > Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt
    > 
    >  
    > 
    >  
    > 
    > A New Internet-Draft is available from the on-line Internet-Drafts directories.
    > 
    > This draft is a work item of the Registration Protocols Extensions of the IETF.
    > 
    >  
    > 
    >         Title           : Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
    > 
    >         Authors         : Roger Carney
    > 
    >                           Gavin Brown
    > 
    >                           Jothan Frakes
    > 
    >                 Filename        : draft-ietf-regext-epp-fees-03.txt
    > 
    >                 Pages           : 33
    > 
    >                 Date            : 2017-04-25
    > 
    >  
    > 
    > Abstract:
    > 
    >    This document describes an Extensible Provisioning Protocol (EPP)
    > 
    >    extension mapping for registry fees.
    > 
    >  
    > 
    >  
    > 
    > The IETF datatracker status page for this draft is:
    > 
    > https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/
    > 
    >  
    > 
    > There are also htmlized versions available at:
    > 
    > https://tools.ietf.org/html/draft-ietf-regext-epp-fees-03
    > 
    > https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-03
    > 
    >  
    > 
    > A diff from the previous version is available at:
    > 
    > https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-03
    > 
    >  
    > 
    >  
    > 
    > 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 <mailto:regext@ietf.org>
    > 
    > https://www.ietf.org/mailman/listinfo/regext
    > 
    > 
    > 
    > _______________________________________________
    > regext mailing list
    > regext@ietf.org
    > https://www.ietf.org/mailman/listinfo/regext
    >