> -----Original Message-----
> From: regext <regext-boun...@ietf.org> On Behalf Of James Galvin
> Sent: Friday, October 2, 2020 4:15 PM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>
> The WGLC for this document was scheduled to end today. While there is
> support to move the document forward there is one minor comment that
> has been raised during the last call.
>
> The chairs would like to hear from other working group members as to what
> to do with this comment. 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:
>
> Yes, lumping the registrar object with the contact object under a single
> RDAP entity object interface is the rub. We solved the problem in the
> RDAP Profile, by supporting entity lookup by IANA ID (number) and
> registrar name (string) for the registrar objects, and by ROID
> (“((\w|_){1,80}-\w{1,8}") for the contact objects. Where there is
> overlap, which is registrar name (string) and ROID
> ((“((\w|_){1,80}-\w{1,8}") the contact takes precedence. My
> recommendation is to provide guidance in the section 3.1.5 "Entity Path
> Segment Specification" for this real world case:
>
> The <handle> parameter represents an entity (such as a contact,
> registrant, or registrar) identifier whose syntax is specific to the
> registration provider. For example, for some DNRs, contact
> identifiers are specified in [RFC5730] and [RFC5733], and
> registrar identifiers are specified using the IANA Registrar ID
> assigned by ICANN. The server SHOULD define a scheme
> for the <handle> parameter to differentiate between the
> supported entity object types (e.g., contact and registrar),
> such as using different <handle> formats, using a <handle>
> precedence order, or a combination of formats and precedence
> order.
>
> The SHOULD could be a MUST, but the point is to provide guidance to
> implementers of the protocol.
>
> Two responses have been offered:
>
> Jasdip Singh response:
>
> One thought is if it could be in the RDAP profile doc for the DNRs
> (https://secure-web.cisco.com/1k4lL-
> ZaH_4UTeAlExqEDmWoj2i2M2JCucgN0US-
> ZRaw3P13LwsVyTwARJxQoKgUo1ceNGMGoZaum_o86c9qFXMK28e6HYprdo
> vBXG6JQKzs1SqqT5mQ_VEnMihHl3qiwMkTQ8qPKkPpbqOJbRIDs_UDppLFz2
> yhs97pm3Ssnh2DxotUzdWsgbWlESVZbLzMg5Z-
> ZTHevue2cVlwSwhdDlzQiyDBU4e0y9cLgcwXSXX7tJE5mUh04ocHwUI2Kcpqccf
> u_lM-
> d8029rv314sSAKQ/https%3A%2F%2Fwww.icann.org%2Fresources%2Fpages
> %2Frdap-operational-profile-2016-07-26-en).
> That way no need to update the spec.
>
> James Gould response:
>
> The RDAP Profile is dependent on the RFC, so I wouldn't create a
> circular dependency. My recommendation is to take the lessons learned
> in implementing the RFC and provide guidance on how to handle it in the
> RFC directly.
[SAH] I don't think we reached consensus to change anything in the draft, so I
left this one alone.
Scott
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
