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

"Gould, James" <jgould@verisign.com> Mon, 13 July 2020 19:46 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 339723A0743 for <regext@ietfa.amsl.com>; Mon, 13 Jul 2020 12:46:43 -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 aBBALjvBJWUK for <regext@ietfa.amsl.com>; Mon, 13 Jul 2020 12:46:41 -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 682943A0602 for <regext@ietf.org>; Mon, 13 Jul 2020 12:46:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=4796; q=dns/txt; s=VRSN; t=1594669601; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=GlhbD+NTEZnn9GkWo22LtwDcZs6pW0vIyqbdkyHBmPE=; b=TTL+xHPAEMPDLDWAj+NLMAEuvBydeN5Yg2taSx+djwGJCqPZBrGSt6bc T2tMJzY6Rem41tPJAbE0NzW5uO44288bTcvL8SvTOb82qbvxjbVbKFSvy YI43MUdhqjANhdsZFDvXR3HFXyMOFPCYk16CHDt5hDSk4AuhxB1zf8SZ3 37EdiXFLG4nqENVismcVxIV3zP8SarXNA6aevXErLl3AemqyhLtia03ka q0ozjKNBuB1REELdTJGukJbDOYLR2FYtyJJ3QoSK3xm2UxfDD2xx9hLza vscO1kGfY/B8H1liFJJN/BYncWLINX6NOEN8tLwYX1OIj7KVtJ9XOqZWz w==;
IronPort-SDR: vameey1a1YBrvKvpoFYkFiaKmtyLuIXHG2JHGOUXT9rwjH1u8lpCT8AfJUB4x1Ip1F8vi0SJHC +wEhtOFbrlUCBVW0On3RPZTtet+S9bnf8hHvD5592wt53irjM6pApQtnJwqtjIscDMzngCLdHk +ufTKQSIZ1kFU8tT5YTzG0/EGy+QJaIj69DVatNBXCSyz5JSw0m/CFFbXFNxedR06aGUhFP+EC bB2m5Jjk1fD1L2HqwsLA0dyo8IfFF7ZyDQ8lXC2FA8tvWsYKoVR2W8MGfTWJtUIVuMeoIIRBcd pRY=
X-IronPort-AV: E=Sophos;i="5.75,348,1589256000"; d="scan'208";a="2154726"
IronPort-PHdr: =?us-ascii?q?9a23=3AWJOAdhXl8J2FjkSgVzfxz62/yAbV8LGtZVwlr6?= =?us-ascii?q?E/grcLSJyIuqrYZRSBvKdThVPEFb/W9+hDw7KP9fy5Bypasd3Y6y5KWacPfi?= =?us-ascii?q?dNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV?= =?us-ascii?q?3wOgVvO+v6BJPZgdip2OCu4Z3TZBhDiCagbb9oIxi6sATcutMIjYZhJao91x?= =?us-ascii?q?XEr3pVcOlK2G1kIk6ekQzh7cmq5p5j9CpQu/Ml98FeVKjxYro1Q79FAjk4Km?= =?us-ascii?q?45/MLkuwXNQguJ/XscT34ZkgFUDAjf7RH1RYn+vy3nvedgwiaaPMn2TbcpWT?= =?us-ascii?q?S+6qpgVRHlhDsbOzM/7WrajNF7gqBGrxK7vxFxw5DabpyJNPRwfa3dc9EVSm?= =?us-ascii?q?RAXslNWCJODZixb5cUAOoEIepUs5PwqlkIoBCjBQesHuTvyjpQi3P43KM61P?= =?us-ascii?q?khEQXb0wA4AtkAtG7brNDrO6cJX+y+0a7FzTfMb/NRxDf97JXHfws/of6SR7?= =?us-ascii?q?JwcNHRyUggFwPDlFmftYvlPzaM2+kLrmOU4PZuW/i1hG47twF+vCKvxsE0h4?= =?us-ascii?q?TLiY8Y107I+Dl2zos0JdC1S0p2b9G5HJVeuCyXN5d6T80/T29ntys317ILtY?= =?us-ascii?q?C0cSUU1pkq2h7SZfKHfYSU/B7uUvuaLzl/hHJgYr2/hhCy/FC+yuLiTMm00U?= =?us-ascii?q?1KritKktnKt3AN0QDc5tKbRft6+0etwSqA1wHI6u5YJkA4j7bUK5kkwrIol5?= =?us-ascii?q?ocr1jDHiHslEXxlq+WeUMp8fWr5eT/erjqu4OQO5Vphgz8PKkigNGzDOQ2Pw?= =?us-ascii?q?QUUGWW/fyw2KD/8UHjXblHjOE6nrPEvJ3VJskXvLO1DgxT340+8RiwFS2m38?= =?us-ascii?q?4dnXQfKVJFfw+IgJbxNlHVJfD4Ee+/g1OxkDd33/zGPqPuApHKLnXbjbrvYa?= =?us-ascii?q?5z51NcxwQrwt5Q5o5YBq8bLPLtRkDxs8bYDgcjPwOu3unrEst91pkFWWKJGK?= =?us-ascii?q?OWLKTSsVqQ6uIuJemDepMVtS7gJ/Q5/fLikH00lFEHcaW03ZYaZmq0E/tiLk?= =?us-ascii?q?mBZHrjmNYBEWMEvgokS+zqjUWPUTxcZ3a1QqI84iw0BZm4DYjdXICtgaeB3C?= =?us-ascii?q?a0Hp1QfGxJFleMEXLwe4WeR/gMcD6SItNmkjEcS7ahS4gh1RS0uw/h0bZqMO?= =?us-ascii?q?3U+jcEtZ39z9V15OvTlRAq9TxsFciSzn+CRXlunmwUXz82wLx/oUtlx1eZz6?= =?us-ascii?q?d4jOJXFNNP5/5SUwc1K4Lcz+JgB9D1QALBcYTBdFHzCOmmBjQ4VZQaxMUSbm?= =?us-ascii?q?5+HdS6llbP0mDiV4MVkLmCH9of9bjA0lDyIcdl0zDK2f9lxxM8T8RCJXGOh6?= =?us-ascii?q?Nj+U7UHYGD2xGDmqmnZbg03SPR+iGE12XY729CVwslG4rCQHQTIgP0pNH0/Q?= =?us-ascii?q?mKG72hDqkjPiNfxNSDMapFbJviilAQF6SrA8jXf2/kwzT4Ph2P3L7ZNIc=3D?=
X-IPAS-Result: =?us-ascii?q?A2F3BAAjuQxf/zGZrQpdAx4BAQsSDECBPwuBdYEkgTMKh?= =?us-ascii?q?CmRGoNzl1k9CwEBAQEBAQEBAQcBHxAEAQEChEoCF4IFJTcGDgIDAQELAQEBB?= =?us-ascii?q?QEBAQEBBgMBAQEChkQMgjcieD0JPQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQUCCAdNB0cBHwEEASMROhkCAgEIGgISAQwHAgICGRcVE?= =?us-ascii?q?AIEARKDJgGCXKpVgTKKYAWBCSqFORE2P4ZNgUI+gREnHIJNPoEEgyEvCiYBA?= =?us-ascii?q?oJMM4ItBJI/hm6bbwMHgl2HVXyLE4V3HoQPmxuRbIhEEoFMkDGEIQIEAgQFA?= =?us-ascii?q?hWBaYF8cBU7KgGCPglHFwINhB6KGB+DOopWdA4mAwIGAQcBAQMJjgUPgSSBE?= =?us-ascii?q?QEB?=
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.1913.5; Mon, 13 Jul 2020 15:46:39 -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; Mon, 13 Jul 2020 15:46:39 -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/+Y6jq8cYAgBX4LgCABRsxgA==
Date: Mon, 13 Jul 2020 19:46:39 +0000
Message-ID: <36C57CBC-D931-4B87-B4DE-27A75CA28E38@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> <9EF7EBBA-9E2E-4478-9F5B-1AC3C50191C5@verisign.com> <5f1f0f3f-d801-3591-68b6-f9ee044e3305@knipp.de>
In-Reply-To: <5f1f0f3f-d801-3591-68b6-f9ee044e3305@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: <FF9353945DDDDE41851084C12DD72C45@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/7hJcqqvxj67Sja1z8KyRcX8iIjc>
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: Mon, 13 Jul 2020 19:46:43 -0000

Thomas, 

Signaling support for fee-1.0 in the login services is not material for this use case.  The key element is whether the create of the premium domain name will fail if the client does not know the correct fee and the fee extension is required to be passed on create.  I don't see a code breakage scenario here, but I don't know what mix of extensions you're dealing with.  
  
-- 
 
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 7/10/20, 5:48 AM, "regext on behalf of Thomas Corte (TANGO support)" <regext-bounces@ietf.org on behalf of Thomas.Corte@knipp.de> wrote:

    Hello,
    
    On 6/26/20 16:18, Gould, James wrote:
    
    > 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. 
    
    Another clarifying question: the above only needs to happen if the client
    at least signaled its general understanding of the fee-1.0 extension in
    the EPP <login> command, correct?
    
    Otherwise (i.e., if the server needs to report premiums as unavailable
    even to clients who are not aware of fee-1.0), this RFC would be asking
    for a change in a server's behavior just by virtue of introducing support
    for fee-1.0, which would mean that clients not using any fee extension
    (or an older version which didn't yet have this requirement) would see an
    unexpected code-breaking change, no?
    
    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/1XzwM8MKi6M1-HWG_c8XsyUrX-tt-VgbAlfTCUGb9Lx3MPgi6UDluTdlcRJFP7royaFdSgSNGny3bfC_scy0lFWmNl2_VVRop-NJI7XZAzEB1O09cQoiuiWOf9SYkj1kOJgngNMpWzGKkNFu2Lq7fRoaaJuKQ-dMEeX6ea3dw76nsG7kwWiPr5kvbge0cv48mJ2SaTaGuPbv5QK-_UsaJLuvPu58h3fo0Q3TqOm2Pj_lwO3Bi490P_YnBubP0klINpMjZwVB12xL3FsXgxjU9vQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext