Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis

"Gould, James" <jgould@verisign.com> Mon, 05 October 2020 15:41 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 A23C83A0489 for <regext@ietfa.amsl.com>; Mon, 5 Oct 2020 08:41:09 -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 T7172_T-0njJ for <regext@ietfa.amsl.com>; Mon, 5 Oct 2020 08:41:06 -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 A8D493A07F9 for <regext@ietf.org>; Mon, 5 Oct 2020 08:41:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=15268; q=dns/txt; s=VRSN; t=1601912466; h=from:to:date:message-id:content-id: content-transfer-encoding:mime-version:subject; bh=Tq9Hn28xEX1rrk4OPeqTi2soi5qdZAER3pEzrbzgmsQ=; b=QISRxSX2zQ6SnLgYJ043OtRNy4lv0rSbkonX9mSNI71Z526szJ/epzR/ taC1llfHHmIE4Wln0v96DgHq4p9t7X4ZeihCtv+0CrGQFBJ7Xuqx0GsxO FnbAgM3aAudrAKegYSAul9d90jZ8m6TwDpOqltYrIio4QYZ1GSQp6mAd8 6hwizjUsnVVA/Ma+ukwPN16G2qkpaxQvu1PAkKHLZ+6dkrewZCtvqxXyJ HMLLNdD/QqbNz3gZv6DokNGpyf17FGcdxUb11iHwcPsTHCzNIFwHf62Ey b21lD04GVhnV2Yrv/8eLuzDVwAgxLnIs7Wt0/sxIMM8mwXv+PV3/nIkYh w==;
IronPort-SDR: dlfGRvbIFM7FIxfXYQStrS8KeyJkn3K2kzzqZEg07qo5P/O4ss1Mci7ggDEiEyNEanJXjcELLc kUlljAN36wi1RBJWFH0iMJv/szdHi+XaoBXjpCufZXrqk2bUqupXkPkOUTyL7u2gsPT/hxf7DG 7iF2E5U26g1zm5dxB3vFoNIGBhEqvF868Yq2ZO0Zotw714ll3dLGq9hChNl4Xdet7rJu5dmT46 KbWUdo3vw96GiFmuaBoM3vXT6L2n3jg9ph9VWROhWRsdXJsPVMvZEqAPXRRZB5MDrNSq9hVKqS 4Eg=
X-IronPort-AV: E=Sophos;i="5.77,338,1596513600"; d="scan'208";a="3127064"
IronPort-PHdr: =?us-ascii?q?9a23=3Ag1EH2BVHu4r2HSW45PtsFWU+ZPjV8LGtZVwlr6?= =?us-ascii?q?E/grcLSJyIuqrYZReEuqdThVPEFb/W9+hDw7KP9fy5Bipcu93Q6jgrS99lb1?= =?us-ascii?q?c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUh?= =?us-ascii?q?rwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9IRmrrwjdrMYbjZVtJqs11B?= =?us-ascii?q?fCv2dFdflRyW50P1yYggzy5t23/J5t8iRQv+wu+stdWqjkfKo2UKJVAi0+P2?= =?us-ascii?q?86+MPkux/DTRCS5nQHSWUZjgBIAwne4x7kWJr6rzb3ufB82CmeOs32UKw0VD?= =?us-ascii?q?G/5KplVBPklCEKPCMi/WrJlsJ/kr5UoBO5pxx+3YHUZp2VNOFjda/ZZN8WWH?= =?us-ascii?q?ZNUtpUWyFHH4iybZYAD/AZMOhYsYfzukcOoxW9CwaiBePg1jBGiXDt0K0myO?= =?us-ascii?q?shFB3K0BA6Et8MtnnfsdX7NL0VUeCw1KTEwzTNb/RL2Tf59YfEag0qr/WWUr?= =?us-ascii?q?J1b8XR0kcjHB7Cg1WSpozlOC6V1uAQvGWA8epvS/ivi288qwFwrTivwN0ghZ?= =?us-ascii?q?XOhoIQ013J8zhyz4kpK9OiUkF7fcKkH4VKtyGcL4Z4TccvTn9mtSs01rALuJ?= =?us-ascii?q?G2cTQXxZop2xPSdvyKfouI7B/hW+icLil1iG9ldr+xmxu//0itx+/+W8Sq31?= =?us-ascii?q?tHoCpLn9/RvX4D0BzT79KISvp7/kq5xzaAyRrT6uBfIUA1mqrbLZ8hwrgsmZ?= =?us-ascii?q?YJrUvDGSr2lF3qg6+XbUUr5u+o5/77bbXho5+QL450hR/iMqQggMC/Bv44Mg?= =?us-ascii?q?cIUmOG+uq8zKXu8VDlTLlQk/E7kKfUvIrHKckbqKO1GQBY34U75xqiEzuqys?= =?us-ascii?q?kUkHsbIF5fZR6KgIvkN0vTLP37C/q0nk6iny1xx//cO73sGpDNLn/en7j/Zb?= =?us-ascii?q?t98EtcyBYrzdBY+pJUFqkNIPLtVU/1s9zVFgI0PRCszer6CNpzzowQVmOTDq?= =?us-ascii?q?OEKq/Sr0OH5uU1I+mUfoMaoivyJ+I75/70ln85n0URcrWu3ZsScHy4H/JmLF?= =?us-ascii?q?uFYXf0n9sNDX0Gshc8QeHkklGOTD5eanioU68z5Tw3EIemAp3CRoCpjryBxi?= =?us-ascii?q?C7HphOa2BEBVCMFmrod4GZVPoXdiKdPNVhkj0fVbigRI8h0wuiuxP9y7piNu?= =?us-ascii?q?bU4DEXtYr/1Nhp4O3ejRMy+iZvD8uA0mGNV3p0k3gSSD8s3aB/p1ZxylGd3q?= =?us-ascii?q?hkm/ZYD8Bc5+tVUgcmMp7R1+l6BMroWgLAedeFUlKmQtKoATE/VNI+3cIBY0?= =?us-ascii?q?FmFtWjjxDDwzCmDKMTl7yRHpA0877c1WDrJ8lh03bGyLUhj14+T8tAL2Kmgr?= =?us-ascii?q?B/9wnVB4PSjUqZk6eqdb8A3C/C7muM0W2OvERAWg5qTarFRWwfZlfRrdnh/E?= =?us-ascii?q?PNUbCuBqooMwtd0sOCK7VFasHnjVlcQ/fjItveMCqNnDL6Bx+TyrKUd6LjYW?= =?us-ascii?q?QbmiPQFAJMxwIa5nqHLRMWDz2gpSTYASA4URqlQ0To9eR4on6wTQt89AqNc1?= =?us-ascii?q?Ern+6u+hkRgfGaQf4Y3ZoatT0gsDR7GhC22NeAT5LKogN7faIaZdQz7k1K2W?= =?us-ascii?q?Xxtg1heJemNeZjmhRWJwF+pULpkRFwBItanMQthHIr0Ex5L7je0U8XM3vS0p?= =?us-ascii?q?n0JLzRAmT2/Quze+jd3VSUmIKZ86MR6fIQplHipx25UEEl9iMjm5NP3nSR9o?= =?us-ascii?q?niDQcOX9T2SEl9v0xgqr7XcjUV5o7I2ztrK6bi4RHY3Nd8TsQi1xKsO599Oa?= =?us-ascii?q?aJD0W6R88VANWqJMQ0lkKodRMLOqZZ86tibJDuTOePxKP+ZLUopzmhl2kSpd?= =?us-ascii?q?klik8=3D?=
X-IPAS-Result: =?us-ascii?q?A2HtAwC7PXtf/zCZrQpdA4EJhGmBNAqEM5E5g3qXbxcmC?= =?us-ascii?q?wEBAQEBAQEBAQgBHxAEAQEChEgCF4IjJjgTAgMBAQsBAQEFAQEBAQEGAwEBA?= =?us-ascii?q?QKGRQyCNykBcz0JPQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEEAggFAk0FAkcBHgEBBAEdBhE6FwYBCBEEAQEDAiYCBDAVCAoEARKDJ?= =?us-ascii?q?gGCXKdhdoEyikmBDiqGW4JEhC2BQj6BESccgk0+giM5AgKBRSQLCiaCUDOCL?= =?us-ascii?q?QSQEzaCcIcom2KBCgMHgmeIfoZYiw4fgw6BKIhalA+SDgx6gXmHABKBY5Fng?= =?us-ascii?q?0ECBAIEBQIVgWuBe3AVOyoBgj4JRxcCDY4rF4NOih0BOHQCDCYDAgYBCQEBA?= =?us-ascii?q?wmNN4ERAQE?=
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.1979.3; Mon, 5 Oct 2020 11:41:04 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.1979.003; Mon, 5 Oct 2020 11:41:04 -0400
From: "Gould, James" <jgould@verisign.com>
To: "jasdips@arin.net" <jasdips@arin.net>, "Hollenbeck, Scott" <shollenbeck@verisign.com>, "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "galvin@elistx.com" <galvin@elistx.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
Thread-Index: AQHWmy3ves1mluvql0CMj6FOQNb2JQ==
Date: Mon, 5 Oct 2020 15:41:04 +0000
Message-ID: <A823DBB3-CF78-4FC2-8F3A-D1065A5331F2@verisign.com>
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: <2BA414FA412ED1448C729F921E95D79F@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/afneJo-IHFZzk3X9g8XwH5JkY_c>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
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, 05 Oct 2020 15:41:10 -0000

>> The phrase 'registry-unique identifier' connotes a unique lookup key for entities, irrespective of their type. It puts the onus on a registry to ensure so. Does that not suffice?

There are cases where the entity lookup key is not unique, since the RDAP entity object can support multiple independent registry objects (contact and registrar).  The recommended text provides guidance for this use case:

  The <handle> parameter represents an entity (such as a contact,
  registrant, or registrar) identifier whose syntax is specific to the
  registration provider.  For example, for some DNRs, contact
  identifiers are specified in [RFC5730] and [RFC5733], and registrar
  identifiers are specified using the IANA Registrar ID assigned by
  ICANN.  The server SHOULD define a scheme for the <handle> parameter
  to differentiate between the supported entity object types (e.g.,
  contact and registrar), such as using different <handle> formats,
  using a <handle> precedence order, or a combination of formats and
  precedence order.

The question is whether the RDAP protocol should provide guidance with how to handle overlapping non-unique handles.  

-- 
 
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 10/5/20, 11:21 AM, "Jasdip Singh" <jasdips@arin.net> wrote:

    Hi.
    
    Section 5.1 of 7483bis ( https://secure-web.cisco.com/1RB1WjHV1xP4ZSnvfV4N05YxMIUObjUDb1GSrtNRvknotxXZOR4r6KW5Mj3Gn99W8QZ13Y0iFQ04zJ7R_BKOXERI2tpouy1xS_xtTQKTLonQ90L6F_w_cgXMfIozB57eTNsab-6w2lvmRt77MpWM-K5Pu5LK-Fqk54dm9dQy3cLegMP53VV8WzcfvWEZRurzAyRPmNaz15FXIiRxZE7bmMEHJZ8KryIFe8Cn0m3YBCQOeaWD3mfU90e79jvRsN6fGjwj4e6YlktqOb45uycsLagfTLuJ9gZ6tH62OL5d8K_Y/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-rfc7483bis-01%23section-5.1 ) defines handle as:
    
      handle -- a string representing a registry-unique identifier of the entity
    
    The phrase 'registry-unique identifier' connotes a unique lookup key for entities, irrespective of their type. It puts the onus on a registry to ensure so. Does that not suffice?
    
    Jasdip
    
    On 10/5/20, 9:15 AM, "regext on behalf of Gould, James" <regext-bounces@ietf.org on behalf of jgould=40verisign.com@dmarc.ietf.org> wrote:
    
        Scott,
        
        >> I'm still not comfortable with this. If we suggest that the server MUST or SHOULD do something to define a scheme, we leave open the issue of how a client discovers that scheme - and if we add a processing step to discover the scheme, we've changed the protocol from the client's 
        >> perspective. I still believe that this is an issue best addressed in an implementation profile document and not the protocol specification.
        
        I believe that providing guidance in the protocol to the real-world overlapping of entity handles (contact and registrar) as necessary.  The protocol would have explicit language on how to handle the case of overlapping entity handles.  A discovery mechanism is not needed, since we didn't have a need to create one based on the approach taken.  
        
        -- 
         
        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://secure-web.cisco.com/1bFp-HGXba90S-TZ720loQzOpgdlPHGtU1fQDrQ9fNgiBVvG2oS5BdIzJWl-ABbwRYIlChnZa-3-BARuMmAflz70zFR_bKIJwhdh0Nr1ZcSKNw7BWdMwC2ymrNNvJ7x52GuJAD5RE9q6FlpO0x4HgCZERFWRRmVLdn48hUgR6lqWjyR6qJwDpIZnLVA5YGBPSGHTynKhyv-_P3tY2ymxlwtAb56j-wQMA2mll8TNEFQ3XQ6-mkIFWQd_3j-DtwfmEgQ4K50V1RGMHkR3QiZL0pg/http%3A%2F%2Fverisigninc.com%2F>
        
        On 10/5/20, 9:00 AM, "regext on behalf of Hollenbeck, Scott" <regext-bounces@ietf.org on behalf of shollenbeck=40verisign.com@dmarc.ietf.org> wrote:
        
            > -----Original Message-----
            > From: regext <regext-bounces@ietf.org> On Behalf Of Mario Loffredo
            > Sent: Saturday, October 3, 2020 3:18 AM
            > To: James Galvin <galvin@elistx.com>om>; regext@ietf.org
            > Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
            >
            >
            > Il 02/10/2020 22:15, James Galvin ha scritto:
            > > The WGLC for this document was scheduled to end today.  While there is
            > > support to move the document forward there is one minor comment that
            > > has been raised during the last call.
            > >
            > > The chairs would like to hear from other working group members as to
            > > what to do with this comment.  Rather than close the last call and
            > > risk another last call, we are extending this last call for another
            > > week.  If we can come to a consensus as to how to proceed before the
            > > end of last call than the document can stay on track to be submitted
            > > to the IESG after the last call.
            > >
            > > The WG last call will end at close of business on Friday, 9 October 2020.
            > >
            > >
            > > Here are the comments as seen on the mailing list.  Please respond
            > > with your suggestions regarding these two comments.
            > >
            > >
            > > James Gould:
            > >
            > > Yes, lumping the registrar object with the contact object under a
            > > single RDAP entity object interface is the rub.  We solved the problem
            > > in the RDAP Profile, by supporting entity lookup by IANA ID (number)
            > > and registrar name (string) for the registrar objects, and by ROID
            > > (“((\w|_){1,80}-\w{1,8}") for the contact objects. Where there is
            > > overlap, which is registrar name (string) and ROID
            > > ((“((\w|_){1,80}-\w{1,8}") the contact takes precedence.  My
            > > recommendation is to provide guidance in the section 3.1.5 "Entity
            > > Path Segment Specification" for this real world case:
            > >
            > > The <handle> parameter represents an entity (such as a contact,
            > > registrant, or registrar) identifier whose syntax is specific to the
            > > registration provider.  For example, for some DNRs, contact
            > > identifiers are specified in [RFC5730] and [RFC5733], and registrar
            > > identifiers are specified using the IANA Registrar ID assigned by
            > > ICANN.  The server SHOULD define a scheme for the <handle> parameter
            > > to differentiate between the supported entity object types (e.g.,
            > > contact and registrar), such as using different <handle> formats,
            > > using a <handle> precedence order, or a combination of formats and
            > > precedence order.
            > >
            > > The SHOULD could be a MUST, but the point is to provide guidance to
            > > implementers of the protocol.
            > >
            > > Two responses have been offered:
            > >
            > > Jasdip Singh response:
            > >
            > > One thought is if it could be in the RDAP profile doc for the DNRs
            > > (https://secure-
            > web.cisco.com/1_AKsyXhtRLN9h4LEAG65owtJMhHrfLUp94HAp7iv6U5KRK_-
            > 2Mtzd56Rf4smGoyDJ4eiIqM3a4E73iWsnhGOX4YnFCyWF_xzCaslHxhJOxiqbH
            > hiSRwAiyk8mMkECJoYKSlQ1kmb4u3-
            > _sD2Be3SyrMHZApsS3iBtbY3MemXbSWSv4c6DFlq8sfMzGMjqy4PQekUbt9Lt
            > HcNRfwPHXhN9IFFpecud-xKW8luC4RDIz7jmjeFU9N11h-
            > lUPrhogswglEugCXCl95vnmjQ5lqytQ/https%3A%2F%2Fhttp://secure-web.cisco.com/1KzaMJBYCbHehlcyM7qgPzBHHaQvr1dOBGVjKZpsDWq867Y5KK33Xpj7gO1ijGMStZiT2-3TBK7ej3U5yYTxNbvIluknka0M48pQzXdUZwKvNgHeKhpieimICcERv8ytTgpOTh6oH_p_deFEo_xT15mJU5eJufBCSCEnu_AQMtR3VgaaURwLueY0Bw-Am4T5mb12dNiJHS_Uy6RpnXYUflqWBeQ0NCXczhOd7XkXyO62Kk1SHZ5UHdFFWrOFdBbuRuOkpX8FDJHhiWXx2xy2thQ/http%3A%2F%2Fwww.icann.org%2Fre
            > sources%2Fpages%2Frdap-operational-profile-2016-07-26-en).
            > > That way no need to update the spec.
            > >
            > > James Gould response:
            > >
            > > The RDAP Profile is dependent on the RFC, so I wouldn't create a
            > > circular dependency.  My recommendation is to take the lessons learned
            > > in implementing the RFC and provide guidance on how to handle it in
            > > the RFC directly.
            > >
            > >
            > The proposed update seems reasonable to me. However, we don't have to
            > make assumptions regarding how handle is generated by RDAP servers. In
            > my opinion, the document should simply give guidance to RDAP
            > implementers about how to disambiguate cases where overlap may occur.
            > Therefore, I would change the sentence as in the following:
            >
            > OLD
            >
            > The server SHOULD define a scheme
            > for the <handle> parameter to differentiate
            >
            > NEW
            >
            > Where overlap may occur, the server SHOULD define a scheme for the
            > <handle> parameter to differentiate
            
            I'm still not comfortable with this. If we suggest that the server MUST or SHOULD do something to define a scheme, we leave open the issue of how a client discovers that scheme - and if we add a processing step to discover the scheme, we've changed the protocol from the client's perspective. I still believe that this is an issue best addressed in an implementation profile document and not the protocol specification.
            
            Scott
            _______________________________________________
            regext mailing list
            regext@ietf.org
            https://secure-web.cisco.com/14qQ5GBAbqizg1W93npsiyV-qaIPAEr0IPtYJq1e7X-_7EoaNxVfB1TEiGzncUFjJiWvcnx6HykFwrZ-ABrD6xiCsFOMEGvVa2nDcW_IEtcp3Kp7hIrt7QPfU1p8toWJrW6Cam0kzs62ESNznCXJSwbu2i9LvV_B2lJ_5iFZL_W3yetKjwXg0uiEC8RQ26Ce90KoEXMuk-nZ5uY-UUHWe1MXXF9N0PIwrFts920hzq-qzWa1SHCEGSw3o0Odax04AFTW15t-zXQUXQWTY0UPnWd5ve9mRKR1zu3ao84TP6yA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
            
        
        _______________________________________________
        regext mailing list
        regext@ietf.org
        https://secure-web.cisco.com/1_vHElpaUxk73mNxduCQugGlhT7YA0zpB1lFQlYCz2-KemyeQkHh9WyivFL5YIQPLNxfxOuYG9eCGm1FLypFLgXbMKYnXBKrf9f-t-KI_I8orT16HiTxOjpo5VrqRvzRn0Cj4ShQni2QAudK0ZUGRzZO2jteaxZBzJh9t-PY3m6nph0DOr1Pa-WSeg61hD9RmeHTTk8glBkviu3gz-Ow1jH1p28EqYCGiyBIKkW_qKgy7X_gDPySCkxWObGmQUnZdrk4doKSZnWX4VKFU2miBngkejzBugO_MzQ7TgvVBWkE/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext