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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 05 October 2020 12:53 UTC

Return-Path: <shollenbeck@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 0CD673A09FF for <regext@ietfa.amsl.com>; Mon, 5 Oct 2020 05:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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 A4zZxQjrj8a7 for <regext@ietfa.amsl.com>; Mon, 5 Oct 2020 05:53:37 -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 D30B53A09FD for <regext@ietf.org>; Mon, 5 Oct 2020 05:53:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=13622; q=dns/txt; s=VRSN; t=1601902417; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=jMUHawtP53h7RLWj3I2+WDeXMFE/3SAWwygHFqMuo2c=; b=c7iIkz/Lc2psGdx7iaWR3ZPaQ4OIQ3r75uSilT2VbHlk7Y18IhxK0xAi c6/DElkj6t/bUNSMcUtK36ZvxnYWP+5x1/+/iDLTb9YaZGNETITiO6nUm mUiAj+NRwNwhRaOyMFx3ELGoX9XLiyiKwrjyTlocnmlHkPmgpZD2zgocp hHSXbHsMyVYaPno5BZ/I/nK/3iQsu+6RQkVAZRU+qDBRw2eXVhMHoUEvP zM/HPq4aJ/GjNVHPY7JwSQglAtIGUw3wCpSr224kC9fjUNTye8BvePxTZ /kZIFHAbROo10SWc0LftEoV2/+hvS5A4zHimCGh4jQi869lyz9slo61M/ g==;
IronPort-SDR: iEYTc8FmWRNDC3ZCLQDhLkOKjb4g9PiH69+7Sga3Fhfh8ChnBVcJ3uMjSg8qB6m8Emts+u/SJf Drjj/6u14hLDncbUScn9PDz+iPM1LFcsG7Nll10D1BPdKuhb0aV3lmIfhiBEsd5FEGypxsGtG+ DqHUAK7RWaZTLU+NaP/AwJoW1R6IKzvuCTLo2xa+m6XZ4QCQhXVMNNhjQcvU+OJnBeKCEnsnYK DfAadAbTy5WxpAxEbDBSu/lhQm8JlvBCmQslcI2xuPJqfcq0m0iqD3K52wf4DabWqDRfib8uwZ 0HI=
X-IronPort-AV: E=Sophos;i="5.77,338,1596513600"; d="scan'208,217";a="3125139"
IronPort-PHdr: =?us-ascii?q?9a23=3A9gatCBVPoecUZI4H7gKmd4kz2aLV8LGtZVwlr6?= =?us-ascii?q?E/grcLSJyIuqrYZRWAvKdThVPEFb/W9+hDw7KP9fy5Bipcu93c7zgrS99lb1?= =?us-ascii?q?c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUh?= =?us-ascii?q?rwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9IRmrrwjdrMYbjZVtJqsxyB?= =?us-ascii?q?bCv2dFdflRyW50P1yYggzy5t23/J5t8iRQv+wu+stdWqjkfKo2UKJVAi0+P2?= =?us-ascii?q?86+MPkux/DTRCS5nQHSWUZjgBIAwne4x7kWJr6rzb3ufB82CmeOs32UKw0VD?= =?us-ascii?q?G/5KplVBPklCEKPCM//WrKiMJ/kbhbrQqhqRJh3oDUfI+bOvlwfqzffNMVWW?= =?us-ascii?q?VOU91LWCBdAIOxdZcDA/YDMOtesoLzp0EOrRy7BQS0Cu/hyDhIhnvy3aIk1e?= =?us-ascii?q?QuCh/J0xAjH94WrX/ascn6NKAOUeCpwqXD0DLOb+hW2Tf67IjIdg4uofeXUr?= =?us-ascii?q?1ubcXRylIiFx3bgVWKqIzlJDKV1usLs2SB8+VgUuevhnchpgpsrTeh2t0ihZ?= =?us-ascii?q?PVhoIJ1F/E7yN5zZ4xKNO3VUN1bsOpHZ9fuSyHK4d7TMMsTm9ntSomyrALt5?= =?us-ascii?q?y2cDUFxZkpwxPSav6KfpWM7x/nVuucJSt1iW9ndby/gRu57Eauyur5Vsau0V?= =?us-ascii?q?ZKqDJIktjQuX8X0RzT7NKLSvxn/keuwTqAywHT6vpYLkAzj6bUN5khwrs2m5?= =?us-ascii?q?EOskrDBjf7lFjqgKOMa0kp+Oal5/76brjmqJKQLYB5hwXmPqgzhsCzG/k0Pw?= =?us-ascii?q?oSU2SB5Oix277u8VfkTLhJiPA9j7PXv4rAJcsBo660GwpV0oE+5BmhFzqmy9?= =?us-ascii?q?EYnWUfLFJCZRKHk5DlO1HQL/D8Cveym0mhnitzyfzbPrLvGprDIXnfnLv/Z7?= =?us-ascii?q?p99VJTyA0pzdBH/Z5bEKwOLOjtWk/rr9zYCAU1PBCzw+biENl914UeVnyTAq?= =?us-ascii?q?KBLa/erUWE6v8tLuSCfoMZpTbwJvY/6/PhiXI1gVodcrOo3ZsTZnC4BPNmI0?= =?us-ascii?q?CBbHr3gtcBFmMKvg4gQ+zsk1KNTyJcZ3WpUqIi+D47EoOmDZzCRoCihryNxj?= =?us-ascii?q?u0HppTZmxeEFCDDW/od5mYW/cLcC+SJ9VukiYFVbimUYMh0RautAH0y7p9MO?= =?us-ascii?q?Xb5yoYuIni1Nh0++3fjw099TpuD8iH0mGNU3l+nnkUSD8uwKB/vUt9x0+M0a?= =?us-ascii?q?dih/xYC91T5/VSXwgkMZ7czvd6C8z9Ww7bYtiJT1OmSM28AT4tVtIx38MOY0?= =?us-ascii?q?FlFtW4kB/D0DSlArAJl7GQBZw77L7c33brK8Z60XbG2/pps15zCM5GL2yhwK?= =?us-ascii?q?p4+QbJCoLOu0SYi+Chc75a3TKHvDOGxHCPuwdcVwB+S6jJWlgeZ1eQptLjoE?= =?us-ascii?q?LeGfvmQ7suNhVAz+aPLqpRds2vhlJDDr+3N93afWO3s2q0BA2U1vWHa4+8Py?= =?us-ascii?q?1XxijSBVgYuwEe4XjAMhIxTG/1uW/RASxyPVPif02q9vNx/iCVVEgxmkuqaE?= =?us-ascii?q?ll2ry/9xUWwbSnQPQPwvhM7DwhrDFwEVC30tnVI8SNvQt6fapaJ9g65QEUhi?= =?us-ascii?q?riqwVhM8n4fOhZjVkEflEvsg=3D=3D?=
X-IPAS-Result: =?us-ascii?q?A2ElBAAHF3tf/zGZrQpggliBI1KBJYE0CoQzgV2PXJopg?= =?us-ascii?q?UA9CwEBAQEBAQEBAQgBIg0EAQEChEgCF4IjJjYHDgIDAQELAQEBBQEBAQEBB?= =?us-ascii?q?gMBAQEChhgIJQyCNyJ7PQk9AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQQCDVRJAR4BAQEBAx0GCkEbAgEIEQQBASsCAgIwHQgCBAESC?= =?us-ascii?q?IMfgX6BDaZgdoEyhDsBAwMLQ4U9BoE4hluGcYFCPoERgxA+glwCAoF0gwCCY?= =?us-ascii?q?ASQSYJwhwImnGwDB4JniH6RWiuDDooClA+SDgx6im6RZ4NBAgQCBAUCFYFbB?= =?us-ascii?q?02BN3BQgmlQFwINgTSMSC8Xg06FFIVCdAIBCioCBgEJAQEDCY03gREBAQ?=
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) 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.1979.3; Mon, 5 Oct 2020 08:53:30 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1979.003; Mon, 5 Oct 2020 08:53:29 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "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-rfc7483bis
Thread-Index: AQHWmPeF0cII/8aMk0+JekoiEWrt5amF4sWAgAMX8eA=
Date: Mon, 5 Oct 2020 12:53:29 +0000
Message-ID: <cb1ebaa5631e4b2f907837c618bb0ddd@verisign.com>
References: <F5EC2287-ADD1-49E9-B5F2-25E73C64DA10@antoin.nl> <064F7704-0619-4CD1-A17C-A59EC82A7596@elistx.com> <a6d6d7fe-9620-e620-a6ba-1b695b6030b9@iit.cnr.it>
In-Reply-To: <a6d6d7fe-9620-e620-a6ba-1b695b6030b9@iit.cnr.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_cb1ebaa5631e4b2f907837c618bb0dddverisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/M2mpa7tXocMOz4CR_xOMRNi0g80>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis
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 12:53:39 -0000


From: regext <regext-bounces@ietf.org> On Behalf Of Mario Loffredo
Sent: Saturday, October 3, 2020 5:38 AM
To: James Galvin <galvin@elistx.com>om>; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis





Il 02/10/2020 22:06, James Galvin ha scritto:

   The WGLC for this document was scheduled to end today.  While there is support to move the document forward there are two minor comments that have been raised during the last call.

   The chairs would like to hear from other working group members as to what to do with these comments.  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:

   I have one item to bring up with draft-ietf-regext-rfc7483bis, which is associated with Section 5.1 “The Entity Object Class”.   The jCard "version" and "fn" members are required according to RFC 6350, which poses an issue if a contact name does not exist or needs to be redacted.  To address this case, I recommend adding a sentence to the end of section 3 "Common Data Types":

   Contact information is defined using jCards as described in [RFC7095].  The “version” and “fn” members are required according to [RFC6350], where an empty “fn” member MAY be used when the contact name does not exist or is redacted.

   Two response have been offered:

   Scott Hollenbeck:

   I'd like to see some discussion of this suggestion. If one understands the normative references, the suggestion is already implicitly addressed. There may be some value in describing this situation explicitly since it came up in the ICANN gTLD implementation context, but so others think this clarification is necessary?

   Jasdip Singh:

   Seems if the RDAP profile for the DNRs (https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en<https://secure-web.cisco.com/1FxE3-8AUQw4AMA04p2iQVRJh0991-gT1gZXLVQSMAGE7tIRQNXEHKTfHbT8hB5Hh6DzlG-girMWkzLkV72lTk4Z8roLcu5bB8T1cfS56XCwqHHHCAZY_boa6q_s3GO3IWufTUBd7di2-x_W-1_pUctunaV9v5bOUtNuRIA_bSa3p1iqsMLydRI3WQg2z4xHhx8OOkodbwNnUW-FQULjEfcgY99Rggri_FHuPl8aeW-B4Bh8cqaMNy-Y2xpTGGu5gvE3kTjgn4VYoHYJtA5JfQQ/https%3A%2F%2Fwww.icann.org%2Fresources%2Fpages%2Frdap-operational-profile-2016-07-26-en>) could clarify this, the spec could be left as-is.



   IMHO RFC7095 omits to state something about the "fn" element while it states clearly that the "version" element must be set to "4.0".  This omission leaves the door open to the interpretation that the empty string is an allowable value. In my opinion this interpretation is correct while the "fn" element must not be null. Besides, in this way,  RDAP implementers are free to differentiate between the case where a value is missing from the case where the value exists but isn't displayed for privacy concerns.

   That being said, I would write the above sentence as in the following:

   Contact information is defined using jCards as described in [RFC7095].  The “fn” member is required and MUST NOT be null according to [RFC6350], where an empty “fn” member MAY be used when the contact name does not exist or is redacted.

   [SAH] I’m OK with this. Any objections?

   Scott