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

Antoin Verschuren <> Mon, 26 October 2020 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93C163A0A50 for <>; Mon, 26 Oct 2020 08:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iM04TXIq00r1 for <>; Mon, 26 Oct 2020 08:11:49 -0700 (PDT)
Received: from ( [IPv6:2001:985:b3c0:1:e2cb:4eff:fe5e:3096]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C5253A0C20 for <>; Mon, 26 Oct 2020 08:11:49 -0700 (PDT)
Received: by (Postfix, from userid 5001) id 30FCD280720; Mon, 26 Oct 2020 16:11:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=walhalla; t=1603725107; bh=m1VqbNu7WjZQidVscqsPUwhbvE0sy1It42HTonHQLA0=; h=From:Subject:Date:References:To:In-Reply-To:From; b=WYeyj+/Fy04WF65WwauegS3MLekdcYPusFYS9vxkZv9LpcvYQhfRnE38/HznkBvOS HZMCjs9nRXerMXtWsttLPYTpnrvUqt0NgOS+idMdbDMfBqxldSfw/TXudOv1npDq+J yVE8PRMizkfoWmcnmsfHykcLWWIzNDM7KzZzmfbI=
Received: from [IPv6:2001:985:b3c0:1:941c:299b:7ae5:bc8a] (unknown [IPv6:2001:985:b3c0:1:941c:299b:7ae5:bc8a]) by (Postfix) with ESMTPSA id 933B3280645 for <>; Mon, 26 Oct 2020 16:11:44 +0100 (CET)
From: Antoin Verschuren <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_95A1BAF2-0CF5-486E-BB7A-0BF31BFBD557"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 26 Oct 2020 16:11:44 +0100
References: <> <> <>
To: "" <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Oct 2020 15:11:52 -0000

Thank you Scott and all others that replied during the extended WGLC..
This is to inform you that this WGLC is now officially closed.
We had 3 explicit statements of support for this document, and 2 concerns which led to an extended WGLC. 
1 of the concerns was addressed by the autor in a new version of the document, and 1 concern did not get support.
We will submit the new version of the document to the IESG as is.

The document shepherd for this document is Jasdip Singh.
Jasdip, could you please start your shepherd writeup?


Jim and Antoin

> Op 12 okt. 2020, om 15:26 heeft Hollenbeck, Scott <> het volgende geschreven:
>> -----Original Message-----
>> From: regext < <>> On Behalf Of James Galvin
>> Sent: Friday, October 2, 2020 4:06 PM
>> To: <>
>> 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- <https://secure-/>
>> <>
>> mnI0WBAe7ZaFAHesmDgIEQi6C5xdf4AFgOuCxci5Eg7TKAZOYRCMTpkn4HpQ
>> A0IDR_way6sBg1J7G75Fc6554SdNlt4CZkx6Y4of235gC9pdotYdG-
>> DmTSKFkMu7EbRZFxRQq2wuuUIJrvrbPz8ZGCf81LYvWGTfZrUMt-
>> DtcEm1hz8yHyNC2J1hOc_6YhTLsOG_N5ZHM81dqp6v_HPIIN9ppz69MwuaZA
>> ao62RBYsmFe3OyFzQ/ <>%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
> _______________________________________________
> regext mailing list
> <>
> <>