IETF Logo Mail Archive

Re: [regext] CALL FOR ADOPTION: draft-gould-casanova-regext-unhandled-namespaces

"Gould, James" <jgould@verisign.com> Tue, 28 January 2020 16:51 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 04146120020 for <regext@ietfa.amsl.com>; Tue, 28 Jan 2020 08:51:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 YgWXhOYHFwCg for <regext@ietfa.amsl.com>; Tue, 28 Jan 2020 08:51:40 -0800 (PST)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.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 ED92A1200EC for <regext@ietf.org>; Tue, 28 Jan 2020 08:51:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3818; q=dns/txt; s=VRSN; t=1580230293; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=i9SVzT3E/bdAeLAiU1B/Y0TQhugWA1SY1y5SMx5tmXk=; b=ip6sF14gbjS1Xiqln/Nid7E5eOV+bl5a+s/UUFpNM65Y6wHgATRc4j1q F7J4ptp4sluYWpEjrWOffnT4SxtLzNNShLYMKlOilFSdnmVOUFFmr0IA7 PZ33AozZJ59AQNZt5Z8OvqinsHKFm2wCWO8OGMfvDso+8u6RPhJn2yvDN GHQGWVrakXSmaIF4wm7RGJEFKPiOkGZSL2UnbeSUhkf0l5J9fRxdNkm1I +PPK6jgVbyp40VjPAua23btOyljc3HaCZPHrqrQJ2RhJgrglL3R6kebE6 OE6Re+2Ni+V4hX7pfbvlthIdIW4KQAuOA4pRF1J9NipYzrHWbdMD+sNLi w==;
IronPort-SDR: lQ+tQTSFi7UiGA0YmbD10IeO6ecql55NIqBMcAJgmLlARLB/rbuks6tDUIsLMI81HAQ8PzzHfx bnZCOkCS/Sn31niMEySjKWZR28za0Y5122Ql2MctTaWk3cHPZYGYwkm7h2/tlAM1BTR5Clklm1 zexirNUpOMbeTXoanivuxN/0/EV/hKqWMh9EASVSzSacp/GlhL/dpbjkJcPz2cH+m4MT1rscdQ mP4pYw0/F0SzwObTkYO19vAl1NwsYcFSpfdidAONkCxeP6n+KYD+zoXPXiPUvvbXDn6C36nIL8 KlU=
X-IronPort-AV: E=Sophos;i="5.70,374,1574121600"; d="scan'208";a="616462"
IronPort-PHdr: 9a23:mLEh8BXYvkLC7HtCkseq3GR9DuHV8LGtZVwlr6E/grcLSJyIuqrYZRSCv6dThVPEFb/W9+hDw7KP9fy5BSpbvd3R7zhCKMUKC0Zez51O3kQJO42sMQXDNvnkbig3ToxpdWRO2DWFC3VTA9v0fFbIo3e/vnY4ExT7MhdpdKyuQtaBx8u42Pqv9JLNfg5GmCSyYa9oLBWxsA7dqtQajZFtJ6osxRbFuHVFdutZyW5rJ1+YghLw6tut8JJ5/Clcpvws+9RcXanmeqgzUKBVAikhP20p/sPgqAPNTRGI5nsSU2UWlgRHDg3Y5xzkXZn/rzX3uPNl1CaVIcP5Q7Y0WS+/76hwUx/nlD0HNz8i/27JjMF7kb9Wrwigpxx7xI7UfZ2VOf9jda7TYd8WWWxMVdtKWidfHo2zcZcAD+sZPeZZsYb9oUcOrQCjDgWoHe/j1yNEimPz0aA8zu8vExzJ3BY4EtwOrnrascn1OqkRX+C7zqbHwzTDYO9Z1zjy84XIbgsuofSQUb5sa8fcy08iHB7FgFWKrozlOiuY2uoMvWic8upgUf+gh3Y6oA91uDevw9kjipLHiokIzV3E9yp5wIEoJd28VUF2esCkH4VKtyGbLIt2Q8wiQ2dytCkmzb0GvIe2cS4Xw5opwB7fbuaIc4mO4h/7SuaePy14hHN+eLK+iBay90mgyuvgWcWuzFlKqS9FnsHNtn8TyxzT5NKLSvxn/keu3zuEygPd6vlcLEwpiabXMYMtz7w+m5YJrEjOHiH7lF/5gaKSbkko5/Sk5/76brjkupOQLZJ4hw79P6g0h8CyAvw0MgYQUGWY5eix0bju8lf6TbhOlfI7l6fUvI7HKskao6O2GAtY34ch5hu6ATqr3tYVkmQBIVlYYhyIlZLpNEvLIP3gCPe/hEmjnylzyvDdO73hHo3NLn/ekLf9Zbp961BTyA40zd1H+p9aFqkPLO/zVUHpu9LXDwM1PxKuz+b5FNp90ZkeWXqVDqCDLazeq0GI5vg0I+mKfoMapDH9K/096/7vi382h0MdcLG00ZcLcny0A/ZrLkuDbXbxgtoMH30GswU6QeDyjV2NSz9TZ3K8X6Im4TE7DZqrDYXMRoCqnbyB2Dq0E4ZIZm9YEFCMEGzod4SLW/cKci6dPshhkjkcWbi7V4AhzQ2utBP9y7d/NurU/zYVuo/k1Nhp/eLTkww9+iBzD8iHz26NSGR0lHsSRzAqxKB/vVB9ylCb3KhinfNYGsJc5vxVUgohNJ7T0fB6C97oVgLGZNeJRwXuftLzOTgtVNM6wJcrblhvFtbq2gjG9yatH7YTm7eMQpcz9/SYlzLrKslw22ru1aQ9gR8hWMQFfTm8i6Fy5xT7BoPVnQOejan8JooG2yuYvkiE0G6C+Al6WQt9Su+NCXIQYVbSofzn61nDVL6hD/IsNQ4Xmp3KEbdDdtC81QYOf/zkItmLJjvpw2o=
X-IPAS-Result: A2FeAgAUZjBe/zGZrQpiAxwBAQEBAQcBAREBBAQBAYF7gXiBHYExCoQKkRolg26XDhcbCgkBAQEBAQEBAQEHARgNCgEBAoN5RQIXgjQ4EwIDAQELAQEBBAEBAQEBBQMBAQEChiAMgjspAWkvCTkBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggHNBkHNRIBAR4BAQEDAQEbBhE6GwIBCA4KAgISARMCAgIlCxUQAgQBEhuDCwGDCq1WgTKESUGFP4EOKow4gUI+gTgMFIJMPoJkAQEDAYFJLQomAQKCRjKCLASQUZ8HAweCOYdCiVeFOYJIeIcSjkSBZo5gh1RoKJIpAgQCBAUCFYFpgXtwFTsqAYJBCUcYDY5VgzuFFIU/dA4kiz0PgSKBEAEB
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.1779.2; Tue, 28 Jan 2020 11:51:22 -0500
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.1779.002; Tue, 28 Jan 2020 11:51:22 -0500
From: "Gould, James" <jgould@verisign.com>
To: Patrick Mevzek <pm@dotandco.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] CALL FOR ADOPTION: draft-gould-casanova-regext-unhandled-namespaces
Thread-Index: AQHV1aorUw6f0Mz8wEOJzJ4HiQcDFqgASwcA
Date: Tue, 28 Jan 2020 16:51:22 +0000
Message-ID: <BD597A01-7394-4FA7-B6E6-24DEEC56DE70@verisign.com>
References: <7498F6EF-3BDD-4FEE-B30E-53BDCB3B9B8D@antoin.nl> <94998f24-4736-47f9-9da7-d0653d1f0676@www.fastmail.com>
In-Reply-To: <94998f24-4736-47f9-9da7-d0653d1f0676@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.12.200112
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F67ED8AD3895DA458710BFFC3CA8847A@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/1Pxqg1qrI9SpC9zyAr3-o90guMo>
Subject: Re: [regext] CALL FOR ADOPTION: draft-gould-casanova-regext-unhandled-namespaces
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: Tue, 28 Jan 2020 16:51:46 -0000

Patrick,

My feedback to your comments are included below.  

-- 
 
JG



James Gould
Distinguished 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 1/28/20, 2:11 AM, "regext on behalf of Patrick Mevzek" <regext-bounces@ietf.org on behalf of pm@dotandco.com> wrote:

    On Fri, Jan 24, 2020, at 09:50, Antoin Verschuren wrote:
    > This is a formal adoption request for Extensible Provisioning Protocol 
    > (EPP) Unhandled Namespaces: 
    > https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-namespaces/
    > 
    > Please review this draft to see if you think it is suitable for 
    > adoption by REGEXT, and comment to the list, clearly stating your view.
    
    The subject can be interesting to the working group and might warrant an RFC
    (although registries and registrars worked for 20 years without trouble
    in handling this case, so one might imagine it is maybe too late or
    not a big enough problem).

JG - This topic came up with the introduction of a new poll message with the Change Poll Message in https://tools.ietf.org/html/rfc8590.  It's primarily an issue associated with the poll queue, where it's unclear how the server can introduce a new poll message without breaking the protocol.  I don't believe anyone can make the case that this is not a protocol issue.  The practice outlined in draft-gould-casanova-regext-unhandled-namespaces provides a concrete solution.     
    
    However, as discussed previously, in its current form this draft will
    introduce interoperability problems[1], so this just exchanges one problem with another.
    
    So I am mildly convinced work is required, and mildly unconvinced that
    the draft as it stands completely address the issue.
    
    [1] TL;DR: a registrar has no way to automatically discover
    a registry is using the mechanism outlined in this document,
    as not announced in the greeting part.

JG - draft-gould-casanova-regext-unhandled-namespaces addresses a protocol and subsequently an interoperability issue, since the server will be capable of fully honoring the services the client includes in the login command.  I'm not sure how a practice that fully follows the EPP RFCs and fully honors the client login services will introduce an interoperability problem based on the lack of discoverability of the practice in the greeting.        
    
    -- 
      Patrick Mevzek
      pm@dotandco.com
    
    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://www.ietf.org/mailman/listinfo/regext

v2.15.0 | Report a Bug | By Email