Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

"Gould, James" <jgould@verisign.com> Fri, 26 June 2020 14:18 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 9485D3A00D6 for <regext@ietfa.amsl.com>; Fri, 26 Jun 2020 07:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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 8XahY1PA3NYj for <regext@ietfa.amsl.com>; Fri, 26 Jun 2020 07:18:20 -0700 (PDT)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 BAF963A00D4 for <regext@ietf.org>; Fri, 26 Jun 2020 07:18:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=6286; q=dns/txt; s=VRSN; t=1593181101; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=exAMNu2K+hYByum2JlP3v2WwYLUhOotN+iqz8n8r9e4=; b=irTBCYDaFm55PyowuyX0CZoAkvoBj8EL08AkkJcFOzhpd/TFPpZFIjqd f1bZN8DSy7EXsaQkiPFZNgliGbIrdHngofkseQEOIkcd6vjvFDXEiFXuC bFdta5v/vb72EWjhQIrtcOgzkuqiFr0mxzseaHFDFGl5IyhBdcL/9wZmk 1d+fIGsFueaGfhl8q0uqOFjlPgL/FelO8avj7WOQ1P6HiKbEM0QBU/c+b 9OGnmm5KCTn0/Pw+rW/mPrvwBYW6o+BHH0N3RpORNG/BnvW14Lci0/1r2 wPs7QbWcFoMpNBBluc2+8YQ/bRmMB4B6htjVIRF9sxMwzWN2VAm32eR0c A==;
IronPort-SDR: m69BOeR3+U6k6XZRtFuRgtV39YdnNHtCxMiMuMDOgIm+l9oHLfTeIDbJLfshMfPb3WV1XLgT6c /uf+ErE+wIjXhdYjUwFBjmGc+Lx9/DnPeIRkWxP6azCSiX/OiW5o+f3rmgpKQUXkfNctbL5vCU q6VFVwQFVD142l9/4XhVEqIlqiccLDPKQpMYCHFcgo0h3YiG43J3ZifYvC6P7lCpPzT0/bUlzW O4maU2MmnP05QoIxaGAkSpiCdxb9tLw6lD+6fsPNJR4e4xYTdFCXj+Qt+CpK4FEkWmTd614k6G 1Dg=
X-IronPort-AV: E=Sophos;i="5.75,283,1589256000"; d="scan'208";a="1955593"
IronPort-PHdr: =?us-ascii?q?9a23=3AxPwLqhRMLBMD52ZSCDFOrKo2VNpsv+yvbD5Q0Y?= =?us-ascii?q?Iujvd0So/mwa67ZBOCt8tkgFKBZ4jH8fUM07OQ7/m9HzVRuN3e7DgrS99lb1?= =?us-ascii?q?c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUh?= =?us-ascii?q?rwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9IRmrrQjdrNQajI9/Jqo+yB?= =?us-ascii?q?bErWZDdvhLy29vOV+dhQv36N2q/J5k/SRQuvYh+NBFXK7nYak2TqFWASo/PW?= =?us-ascii?q?wt68LlqRfMTQ2U5nsBSWoWiQZHAxLE7B7hQJj8tDbxu/dn1ymbOc32Sq00WS?= =?us-ascii?q?in4qx2RhLklDsLOjgk+2zRl8d+jr9UoAi5qhJ/3YDafZ2VOvR9cKPTf9wVS2?= =?us-ascii?q?tBUdpeWSNOGY68c5AAD+8dMepEtYTwpV0Dpga+Cwm2A+PvzydFinH30609zu?= =?us-ascii?q?QhFRzJ0BQ9FNwKqnvUqcv6NLwcXeuoy6TIzzrDb/RL2Tf59YfFaQ4hru+WXb?= =?us-ascii?q?JxasrRyEYvFwXfglqMrozlOiqY2+IQuGeU8+RuT/igi3I7qw5vuDivwN8hh4?= =?us-ascii?q?fVi4wVyF3J6St3zogoKNC8VEN2Zd6qHZ9Nuy+UKYd7TMwsTmNmtion17ELpZ?= =?us-ascii?q?C2cDUFxpg6xxPRZeCLfpWG7x/lSe2fLzB4hHd/d7K+gRa/6VagxfPmVsm1y1?= =?us-ascii?q?ZKryVFkt/NtnALyxPf8NSISvx4/ku51zeC2Rrf6uZeIUA7jabUN58hwqUsmZ?= =?us-ascii?q?oUq0jMAij2mEDugK+XaEok5uao5/7gYrX8qZ+RMZJ/hALmMqk2h8CzHf40Ph?= =?us-ascii?q?UMUmWV4+iwyb3u8EPjTLhFjfA6irTVvIzAKcgGpKO1HxVZ3pss5hu8FTuqzd?= =?us-ascii?q?cVkH8aJ1xfYh2HlZLmO1TWLfD9CvewnkqjnS9wx/DDIr3hGpLNLmXfkLv5fb?= =?us-ascii?q?Zy9UpcyA0rwN1C+5xaEqwNL/LrVEH+tdPUEgI1Pxaqw+n7D9V9zJseVXiVDa?= =?us-ascii?q?CEKq/Sr0WI5vkpI+WWeIAVvzP9J+Ak5/7ok3A5hUcQcbS10ZcNdXy1HPprL1?= =?us-ascii?q?+EbXfsjNoNC2gHswkmQOzvklKCUDpTZ3ioX6I74zE2EICmDYjERoCwhLyOwT?= =?us-ascii?q?y2HoNIaWBcC1CMCnbod4qCW/sWdC2SJcphniQeVbe9U48hyQ2utAjixrR5Lu?= =?us-ascii?q?rU/SgYuoj41NRv+eDTkgsy9SBqAMmG0GGNSWB0nnsQRzMswa9wv1R3yk2f3q?= =?us-ascii?q?hgn/xYCdtT6utTUggkOp7T0eN7C8zpVwLAYNiJVFimTs+hATErQdJii+MJNg?= =?us-ascii?q?xBG9KnhwuF9C2wH7I9lLqKHIRy/q+WlyzNJ8F4wm2A/647k1QOQc1OLXXgiq?= =?us-ascii?q?Mps0CZHYPGnlWFv6enaapa2zTCvi/X12eBsVFEeA99TauDWmoQMBj4t9P8sw?= =?us-ascii?q?ntSKKqBfBvEAJExNXIYv9IZdr0iVluWvr5Oc/fbGT3kGC1U0XbjoiQZZbnLj?= =?us-ascii?q?1OlB7WD1IJxlge?=
X-IPAS-Result: =?us-ascii?q?A2F6BADtAvZe/zCZrQpdA4EJgUqBdYEkgTMKhCaQK0Qlg?= =?us-ascii?q?3OXUhcmCwEBAQEBAQEBAQcBIwwEAQEChEUCF4IVJTcGDgIDAQELAQEBBQEBA?= =?us-ascii?q?QEBBgMBAQEChkQMgjcieDwJPQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQUCCAUCTQUCRwEfAQQBIxE6GQICAQgaAh8HAgICGRcVEAIEA?= =?us-ascii?q?RKDJgGCXC+tHIEyhDoBhi4FgQkqhTNGhweBQj6BEScMEIFPfj6BBIFYAoFHL?= =?us-ascii?q?womgk0zgi0Eki+GZZtfAweCW4hHhieKTh2EDJsBkUiIPhKBSJAahB0CBAIEB?= =?us-ascii?q?QIVgWmBenAVOyoBgj4JRxcCDY41H4M6hRSFQnQOJgMCBgEHAQEDCY5hgREBA?= =?us-ascii?q?Q?=
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.1913.5; Fri, 26 Jun 2020 10:18:18 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%6]) with mapi id 15.01.1913.005; Fri, 26 Jun 2020 10:18:18 -0400
From: "Gould, James" <jgould@verisign.com>
To: "Thomas.Corte@knipp.de" <Thomas.Corte@knipp.de>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?
Thread-Index: AQHWS8BAxPyuP9a+wUiwqG3Zbf/+Y6jq8cYA
Date: Fri, 26 Jun 2020 14:18:18 +0000
Message-ID: <9EF7EBBA-9E2E-4478-9F5B-1AC3C50191C5@verisign.com>
References: <20200314164521.0B10EF406C9@rfc-editor.org> <ac9d9567-e847-8802-14e4-07c36e216c19@knipp.de> <5703B97E-20EF-4FCA-AA32-68AF595A088F@verisign.com> <04d5dfb5-d9ae-06a9-b137-4cedcefbc399@knipp.de>
In-Reply-To: <04d5dfb5-d9ae-06a9-b137-4cedcefbc399@knipp.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.16.200509
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <989DE90913BE0D4998E0DDDB579EED50@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/dqj6YnXaK_5BXr2n6R-0lcUIWpU>
Subject: Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?
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: Fri, 26 Jun 2020 14:18:23 -0000

Thomas,

The goal is to cover the case of a client not passing the fee extension at all, with the assumption that the fee extension would reference the create command.  It's simpler to make the case based on the existence or non-existence of the fee extension in the check command, but there may be cases were the renew fee matches the create fee.  It's up to the server to determine whether a particular domain will fail on create without the client having the correct non-standard fee.  I realize that there are corner cases where the client may know the fee, based on assuming that the create fee matches the renew fee, or the fees are provided out-of-band to EPP, but to cover the intent of the RFC the safest approach is to return avail="0" for a premium domain if the fee extension is not passed in the check command.

The server MUST return avail="0" in its response to a <check> command
for any object in the <check> command that does not include the
<fee:check> extension for which the server would likewise fail a
domain <create> command when no <fee> extension is provided for that
same object. 

-- 
 
JG



James Gould
Fellow Engineer
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

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

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

On 6/26/20, 9:46 AM, "regext on behalf of Thomas Corte (TANGO support)" <regext-bounces@ietf.org on behalf of Thomas.Corte@knipp.de> wrote:

    
    Hello James,
    
    thanks for your reply, I'll go back to check out the respective thread.
    
    On 6/25/20 21:40, Gould, James wrote:
    
    > JG - The RFC only specifies that the fee extension needs to be provided to support the create command, so checking the renewal fee is not applicable.   
    
    So, just to be sure, to the following check for a *renew* fee of a
    premium domain, the server should respond with avail="0" (as the check
    merely asks for a renewal price, not a creation price)?
    
    <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <command>
        <check>
          <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
            <domain:name>premium-a1.tango</domain:name>
          </domain:check>
        </check>
        <extension>
          <fee:check xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
            <fee:command name="renew">
              <fee:period unit="y">1</fee:period>
            </fee:command>
          </fee:check>
        </extension>
        <clTRID>e1f8b4cd61f84469436bf16585f976b3</clTRID>
      </command>
    </epp>
    
    While the following check asking for a creation price should be responded
    with avail="1"?
    
    <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <command>
        <check>
          <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
            <domain:name>premium-a1.tango</domain:name>
          </domain:check>
        </check>
        <extension>
          <fee:check xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
            <fee:command name="create">
              <fee:period unit="y">1</fee:period>
            </fee:command>
          </fee:check>
        </extension>
        <clTRID>e1f8b4cd61f84469436bf16585f976b3</clTRID>
      </command>
    </epp>
    
    Just trying to clarify this, as the RFC isn't all that clear about which
    exact conditions the fee check extension must meet in order to qualify
    for a positive availability check of free premium domains.
    
    Best regards,
    
    Thomas
    
    -- 
    TANGO REGISTRY SERVICES®
    Knipp Medien und Kommunikation GmbH                    Thomas Corte
    Technologiepark                             Phone: +49 231 9703-222
    Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
    D-44227 Dortmund                      E-Mail: Thomas.Corte@knipp.de
    Germany
    
    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://secure-web.cisco.com/1d4W9Y-JRwUyOsQ5LPwv-1m17UOtveZT4o2_R0VWZfpbiTqJanWb6E-ksO15h7ClxoQY3q9NGnpriFo71j-Jz3SWN4WQcemobVYCyNQp3gp_mAdwxpm-wlzqcs8vUSfe2t-A7ZIYAlHo9X9Bx1otNjXIk8Zq-YRdB6RWikXkuNjOFtRnO2RX89P5ciZ5jM7_thR1kE8aILbzhJMq0uWRyPbLAFIAf3ZOwPH5IZ4oUskSUB4se2h6c4ZgbpfMzl0P0ZPvKG2RzjnF3PXa-m62nDg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext