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

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: regext <[e-mail]> On Behalf Of James Galvin
> Sent: Friday, October 2, 2020 4:06 PM
> To: [e-mail]
> 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