> -----Original Message----- > From: regext <regext-boun...@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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
