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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 12 October 2020 13:26 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 8B8233A14D0 for <regext@ietfa.amsl.com>; Mon, 12 Oct 2020 06:26:35 -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 G2hXyfaLy7yo for <regext@ietfa.amsl.com>; Mon, 12 Oct 2020 06:26:34 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (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 22AC03A14CE for <regext@ietf.org>; Mon, 12 Oct 2020 06:26:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=4262; q=dns/txt; s=VRSN; t=1602509194; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=swHkLM9Zkc52JOdyB9Dnb43I8ZWO0/sLzww+eMlc0Qg=; b=McX1vTp4QPZwub2NRPnw/3xPtZu9B358isSjGC2z8OoS09EdIbJeDhao NoqaA+ZbEl8eSxJymd87fExzDK8J0Qjzl6rjZUlpK4VURrjnRyUaggKZq eLePxirSBH1FLS6+x7cXve9nMNBekJ3K+m83T9FHAQ8RJO3fpjTAMnlcr A9PPn5QvTBIVgTuuXq+aPdjZNArPJWfOXDkupHXMHS0ulKcb4FCcGuQqD bPyabcElq0fpUpBjbwTXDBlIg2eR8VC1HqVWyXack6nQ4RJO/Ol5DtWRQ V9wbkm4UiOH8TbrE3pPx5e+2PtZpd9q2NwzCvuY6OCgP+okQN81pxgDIg Q==;
IronPort-SDR: zQIy67SRkbIMny53oQ6aaKiHCos3yvRRgbObC3uLMcVB1QiI+FCOJiCtSGg5DIIDHwMxB0x0bW 8/HV3oqy/H3zBXgj0Kk8K08/ahoACJkYNHf+K3hMIUMIyTf/0astVQr7g1FEHnPEo7ea/g6xo4 4XIGp9ItNq52pUKdf7L1QfWJeBI/jbP4u9n1aFyMDceL3y4wmUM2YcEKYA0u1EN4re3NoIUpy1 ugpXbmMvWl3IZmDVs4qR+C3rd2BbgRmaB9G40mt3+iUOj/82Qk5kgpx2CEA33agQfwvi3Q8GUP d0Q=
X-IronPort-AV: E=Sophos;i="5.77,366,1596513600"; d="scan'208";a="3152697"
IronPort-PHdr: =?us-ascii?q?9a23=3AGXnqzhZbbPMuzfledqpxJlP/LSx+4OfEezUN45?= =?us-ascii?q?9isYplN5qZpsy/ZB7h7PlgxGXEQZ/co6odzbaP7Oa9Bideut6oizMrSNR0TR?= =?us-ascii?q?gLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ?= =?us-ascii?q?/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vLhi6twXcu8sZjYZjJKs61w?= =?us-ascii?q?fErGZPd+lK321jOEidnwz75se+/Z5j9zpftvc8/MNeUqv0Yro1Q6VAADspL2?= =?us-ascii?q?466svrtQLeTQSU/XsTTn8WkhtTDAfb6hzxQ4r8vTH7tup53ymaINH2QLUpUj?= =?us-ascii?q?ms86tnVBnlgzoBOjUk8m/Yl9Zwgbpbrhy/uhJ/34DaboKbNPV8f6PSYdwUSm?= =?us-ascii?q?VaU8ZNTCNBAJ+wY5cTA+cDO+tTsonzp0EJrRu7HQSgCuHhyjhMhn/yw6I61f?= =?us-ascii?q?8uHh/a0wwjB94FrWnao8nyNKcOTeC5wrTDwDLYb/NW3jf97IzIfQ4nof6XQ7?= =?us-ascii?q?1/bcnRxFIxFwzblFWQqJflPzKa1uQLqWSU8+1gVee2hmMhtgp+rSShyN02hY?= =?us-ascii?q?nVmoIa1ErE9SNhzYs3OdG1TEB1bcO5HJZQuSyUN4V7TMwmTm10uCg21r8LtY?= =?us-ascii?q?C7cSYFypkqxhDRZv+bf4WW/h/uW/udLCpliH9hdryygQu5/0anyu35TMa00V?= =?us-ascii?q?BKozJZndnNrXACyxvT5tKbRft6+0etwTeP2BzJ5eFCJ0A4j63bK4QuwrM2i5?= =?us-ascii?q?EdslzDEzfrlEnqlqOaa0cp9+ay5+j6YrjrqIWQOoB3hw3mL6gihtazDfk6Pw?= =?us-ascii?q?QSRWSX5Oux2b758UHkQ7hHiOA9nLPDv5DAP8sbo7a0AwpS0ok+9RmyFyym0N?= =?us-ascii?q?EEnXkfK1JFZQ6Hg5DpO17QJPD4Cu+yjkmwnjlz2vzJPqXvDJrMIXTfjbvtZ6?= =?us-ascii?q?h95FJbyAop1dBT/YhbBawbLPLtQE/xr9rYAgUlPAyzxubrENR91oUAVmKTGq?= =?us-ascii?q?KVLb/evUWV6u8tLeSAfpIZtTbzJvQ/6PPjjmc1mVoHcqmo2ZsXZmq4HvNjI0?= =?us-ascii?q?iBenrsgtABEWMOvgUgSuzlk0ONXiJQZ3upQaIz+Cs7CIO9DYfCSYCthqaN0z?= =?us-ascii?q?u8Hp1TfmxGEEyDEW/0d4WYXPcBcC2SLdVlkjwaVLihTZQs2g+qtA/70LpnMu?= =?us-ascii?q?XV9jcEupLk0dh///fTmg0q9TxoE8Sd1HmAT3tqkWMHWTA307x/rFd8ylidza?= =?us-ascii?q?h4jeZUFdtJ5/NGAU8GMsuWwOV+FdH0cg/Ff8yVWBCtRdDsSWU+R9Yvwtkmbk?= =?us-ascii?q?J8AMmyyBvE2nzuS/UPmrOGFIAc86/A0T72Pck3gyLc2aYsn0UOQ8ZTOyuhnK?= =?us-ascii?q?EppCbJAIuc2WWek6Knc64R1y2JvFyIynaS9gkMSw53VaHIW3oSbUj+s9nj51?= =?us-ascii?q?jDQLnoArMiZFgSgfWeI7dHP4W6xW5NQ+3ubYzT?=
X-IPAS-Result: =?us-ascii?q?A2H6BACaWIRf/zCZrQpggQmEaYE0CoQzkRmbaT0LAQEBA?= =?us-ascii?q?QEBAQEBCAEbFAQBAQKESAIXggEmOBMCAwEBCwEBAQUBAQEBAQYDAQEBAoYYC?= =?us-ascii?q?CUMgjciez0JPQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEEAg1USQEeAQEBAQIBHQYROhAHBAIBCBEEAQEDAiYCAgIwFQgIAgQBEgiDH?= =?us-ascii?q?4JcpmN2gTKFVIRogQ4qhmCGcYFCPoERgxA+giM5AoR2gmAEkFaCcIcsnG4DB?= =?us-ascii?q?4JoiQGRXyuDFYoIlB2SGwx7nGODQgIEAgQFAhWBa0SBN3BQgmkJRxcCDYE0k?= =?us-ascii?q?FyKVnQ3AgYBCQEBAwmNN4ERAQE?=
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) 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, 12 Oct 2020 09:26:31 -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, 12 Oct 2020 09:26:31 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "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+JekoiEWrt5amUBAEg
Date: Mon, 12 Oct 2020 13:26:31 +0000
Message-ID: <943f3cee9a89408c9d6425f17ca5cf0e@verisign.com>
References: <F5EC2287-ADD1-49E9-B5F2-25E73C64DA10@antoin.nl> <064F7704-0619-4CD1-A17C-A59EC82A7596@elistx.com>
In-Reply-To: <064F7704-0619-4CD1-A17C-A59EC82A7596@elistx.com>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/-Z4wz6N-UANDUsdot9pTBohHxoE>
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, 12 Oct 2020 13:26:36 -0000

> -----Original Message-----
> From: regext <regext-bounces@ietf.org> On Behalf Of James Galvin
> Sent: Friday, October 2, 2020 4:06 PM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis
>
> 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://secure-
> web.cisco.com/11khs_gD3RqFuWkwSmkqxXidBMgZZIHUGiC-
> mnI0WBAe7ZaFAHesmDgIEQi6C5xdf4AFgOuCxci5Eg7TKAZOYRCMTpkn4HpQ
> A0IDR_way6sBg1J7G75Fc6554SdNlt4CZkx6Y4of235gC9pdotYdG-
> DmTSKFkMu7EbRZFxRQq2wuuUIJrvrbPz8ZGCf81LYvWGTfZrUMt-
> DtcEm1hz8yHyNC2J1hOc_6YhTLsOG_N5ZHM81dqp6v_HPIIN9ppz69MwuaZA
> ao62RBYsmFe3OyFzQ/https%3A%2F%2Fwww.icann.org%2Fresources%2Fpa
> ges%2Frdap-operational-profile-2016-07-26-en)
> could clarify this, the spec could be left as-is.

[SAH] I just updated the document to address this feedback.

> Mario Loffredo:
>
> The document does not contain any requirement or recommendation about
> when returning ldhName and unicodeName values. However, the examples
> seem to convey the idea that ldhName must  always be returned and
> unicodeName must be returned in case of an IDN.

[SAH] There was no additional discussion, so I left this one alone.

Scott