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

From: "James Galvin" <[email-masked]>
Date: Fri, 02 Oct 2020 16:15:19 -0400

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://www.icann.org/resources/pages/rdap-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.

Thanks!

Antoin and Jim

On 18 Sep 2020, at 9:52, Antoin Verschuren wrote:

> The following working group document is believed to be ready for 
> submission to the IESG for publication as a standards track document:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis/
>
> This WG last call will end at close of business, Friday, 2 October 
> 2020.
>
> Please review this document and indicate your support (a simple 
> “+1” is sufficient) or concerns with the publication of this 
> document by replying to this message on the list.
>
> The document shepherd for this document is Mario Loffredo.
>
> Regards,
>
> Jim and Antoin
>
>
>
>
>
>
>
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Mario Loffredo <[email-masked]>
Date: Sat, 3 Oct 2020 09:17:53 +0200

Il 02/10/2020 22:15, James Galvin ha scritto:
> support to move the document forward there is one minor comment that 
> has been raised during the last call.
>
> 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 
> recommendation is to provide guidance in the section 3.1.5 "Entity 
> Path Segment Specification" for this real world case:
>
> in implementing the RFC and provide guidance on how to handle it in 
> the RFC directly.
>
>
The proposed update seems reasonable to me. However, we don't have to 
make assumptions regarding how handle is generated by RDAP servers. In 
my opinion, the document should simply give guidance to RDAP 
implementers about how to disambiguate cases where overlap may occur. 
Therefore, I would change the sentence as in the following:

OLD

The server SHOULD define a scheme
for the <handle> parameter to differentiate

NEW

Where overlap may occur, the server SHOULD define a scheme
for the <handle> parameter to differentiate

Best,

Mario

>> This WG last call will end at close of business, Friday, 2 October 2020.
>>
>> Please review this document and indicate your support (a simple “+1” 
>> is sufficient) or concerns with the publication of this document by 
>> replying to this message on the list.
>>

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 5 Oct 2020 13:00:24 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Mario Loffredo
> Sent: Saturday, October 3, 2020 3:18 AM
> To: James Galvin <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>
>
> > 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.
> >
> > (https://secure-
> web.cisco.com/1_AKsyXhtRLN9h4LEAG65owtJMhHrfLUp94HAp7iv6U5KRK_-
> 2Mtzd56Rf4smGoyDJ4eiIqM3a4E73iWsnhGOX4YnFCyWF_xzCaslHxhJOxiqbH
> hiSRwAiyk8mMkECJoYKSlQ1kmb4u3-
> _sD2Be3SyrMHZApsS3iBtbY3MemXbSWSv4c6DFlq8sfMzGMjqy4PQekUbt9Lt
> HcNRfwPHXhN9IFFpecud-xKW8luC4RDIz7jmjeFU9N11h-
> lUPrhogswglEugCXCl95vnmjQ5lqytQ/https%3A%2F%2Fwww.icann.org%2Fre
> sources%2Fpages%2Frdap-operational-profile-2016-07-26-en).
> Where overlap may occur, the server SHOULD define a scheme for the
> <handle> parameter to differentiate

I'm still not comfortable with this. If we suggest that the server MUST or SHOULD do something to define a scheme, we leave open the issue of how a client discovers that scheme - and if we add a processing step to discover the scheme, we've changed the protocol from the client's perspective. I still believe that this is an issue best addressed in an implementation profile document and not the protocol specification.

Scott

---

From: "Gould, James" <[email-masked]>
Date: Mon, 5 Oct 2020 13:15:34 +0000

Scott,

>> I'm still not comfortable with this. If we suggest that the server MUST or SHOULD do something to define a scheme, we leave open the issue of how a client discovers that scheme - and if we add a processing step to discover the scheme, we've changed the protocol from the client's 
>> perspective. I still believe that this is an issue best addressed in an implementation profile document and not the protocol specification.

I believe that providing guidance in the protocol to the real-world overlapping of entity handles (contact and registrar) as necessary.  The protocol would have explicit language on how to handle the case of overlapping entity handles.  A discovery mechanism is not needed, since we didn't have a need to create one based on the approach taken.  

-- 
 
JG

James Gould
Fellow Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 10/5/20, 9:00 AM, "regext on behalf of Hollenbeck, Scott" <[email-masked] on behalf of shollenbeck=[email-masked]> wrote:

    > lUPrhogswglEugCXCl95vnmjQ5lqytQ/https%3A%2F%2Fhttp://secure-web.cisco.com/1KzaMJBYCbHehlcyM7qgPzBHHaQvr1dOBGVjKZpsDWq867Y5KK33Xpj7gO1ijGMStZiT2-3TBK7ej3U5yYTxNbvIluknka0M48pQzXdUZwKvNgHeKhpieimICcERv8ytTgpOTh6oH_p_deFEo_xT15mJU5eJufBCSCEnu_AQMtR3VgaaURwLueY0Bw-Am4T5mb12dNiJHS_Uy6RpnXYUflqWBeQ0NCXczhOd7XkXyO62Kk1SHZ5UHdFFWrOFdBbuRuOkpX8FDJHhiWXx2xy2thQ/http%3A%2F%2Fwww.icann.org%2Fre

    Scott
    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/14qQ5GBAbqizg1W93npsiyV-qaIPAEr0IPtYJq1e7X-_7EoaNxVfB1TEiGzncUFjJiWvcnx6HykFwrZ-ABrD6xiCsFOMEGvVa2nDcW_IEtcp3Kp7hIrt7QPfU1p8toWJrW6Cam0kzs62ESNznCXJSwbu2i9LvV_B2lJ_5iFZL_W3yetKjwXg0uiEC8RQ26Ce90KoEXMuk-nZ5uY-UUHWe1MXXF9N0PIwrFts920hzq-qzWa1SHCEGSw3o0Odax04AFTW15t-zXQUXQWTY0UPnWd5ve9mRKR1zu3ao84TP6yA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: Jasdip Singh <[email-masked]>
Date: Mon, 5 Oct 2020 15:21:10 +0000

Hi.

Section 5.1 of 7483bis ( https://tools.ietf.org/html/draft-ietf-regext-rfc7483bis-01#section-5.1 ) defines handle as:

  handle -- a string representing a registry-unique identifier of the entity

The phrase 'registry-unique identifier' connotes a unique lookup key for entities, irrespective of their type. It puts the onus on a registry to ensure so. Does that not suffice?

Jasdip

On 10/5/20, 9:15 AM, "regext on behalf of Gould, James" <[email-masked] on behalf of jgould=[email-masked]> wrote:

    Scott,

    
    -- 
     
    JG

    James Gould
    Fellow Engineer
    
    703-948-3271
    12061 Bluemont Way
    Reston, VA 20190

    

        Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 12 Oct 2020 15:09:39 +0000

> From: regext <[email-masked]> On Behalf Of James Galvin
> Sent: Friday, October 2, 2020 4:15 PM
> To: [email-masked]
> 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.
>
> (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).

[SAH] I don't think we reached consensus to change anything in the draft, so I left this one alone.

Scott

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 26 Oct 2020 16:10:43 +0100

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=[email-masked]> het volgende geschreven:
> 
>> From: regext <[email-masked] <mailto:[email-masked]>> On Behalf Of James Galvin
>> To: [email-masked] <mailto:[email-masked]>
>> (https://secure-web.cisco.com/1k4lL- <https://secure-web.cisco.com/1k4lL->
>> d8029rv314sSAKQ/https%3A%2F%2Fwww.icann.org <http://2fwww.icann.org/>%2Fresources%2Fpages
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 26 Oct 2020 16:40:54 +0100

Hi Chairs,

Il 26/10/2020 16:10, Antoin Verschuren ha scritto:
> The chairs agree with the Authors that there was no consensus reached 
> during the extended WGLC to make changes to the document.
> We had 3 explicit statements of support for this document, and one 
> concern whose required changes were not supported by 3 others.

I'll publish the shepherd writeup by tomorrow.

Best,

Mario

>
> Regards,
>
> Jim and Antoin
>
>
>
>> Op 12 okt. 2020, om 17:09 heeft Hollenbeck, Scott 
>> <shollenbeck=[email-masked] 
>> <mailto:shollenbeck=[email-masked]>> het volgende 
>> geschreven:
>>
>>> From: regext <[email-masked] 
>>> <mailto:[email-masked]>> On Behalf Of James Galvin
>>> To:[email-masked] <mailto:[email-masked]>
>>> what
>>> d8029rv314sSAKQ/https%3A%2F%2Fwww.icann.org 
>>> <http://2fwww.icann.org/>%2Fresources%2Fpages