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

Thank you Scott and all others that replied during the extended WGLC..
The chairs agree with the Authors that there was no consensus reached during the extended WGLC to make changes to the document.
Therefor this WGLC is now officially closed.
We had 3 explicit statements of support for this document, and one concern whose required changes were not supported by 3 others.
We will submit the document to the IESG as is.

The document shepherd for this document is Mario Loffredo.
Mario, could you please start your shepherd writeup?

Regards,

Jim and Antoin

> Op 12 okt. 2020, om 17:09 heeft Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org> het volgende geschreven:
> 
>> -----Original Message-----
>> From: regext <regext-bounces@ietf.org <mailto:regext-bounces@ietf.org>> On Behalf Of James Galvin
>> Sent: Friday, October 2, 2020 4:15 PM
>> To: regext@ietf.org <mailto: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- <https://secure-web.cisco.com/1k4lL->
>> ZaH_4UTeAlExqEDmWoj2i2M2JCucgN0US-
>> ZRaw3P13LwsVyTwARJxQoKgUo1ceNGMGoZaum_o86c9qFXMK28e6HYprdo
>> vBXG6JQKzs1SqqT5mQ_VEnMihHl3qiwMkTQ8qPKkPpbqOJbRIDs_UDppLFz2
>> yhs97pm3Ssnh2DxotUzdWsgbWlESVZbLzMg5Z-
>> ZTHevue2cVlwSwhdDlzQiyDBU4e0y9cLgcwXSXX7tJE5mUh04ocHwUI2Kcpqccf
>> u_lM-
>> d8029rv314sSAKQ/https%3A%2F%2Fwww.icann.org <http://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 <mailto:regext@ietf.org>
> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>