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

From: Antoin Verschuren <[email-masked]>
Date: Fri, 18 Sep 2020 15:52:44 +0200

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

---

From: Tom Harrison <[email-masked]>
Date: Mon, 21 Sep 2020 08:28:34 +1000

On Fri, Sep 18, 2020 at 03:52:44PM +0200, 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
> 
> 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.

+1

-Tom

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 21 Sep 2020 07:49:00 +0200

+1

Mario

Il 18/09/2020 15:52, Antoin Verschuren ha scritto:
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

-- 
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: Roger D Carney <[email-masked]>
Date: Mon, 21 Sep 2020 11:22:20 +0000

+1

________________________________
From: regext <[email-masked]> on behalf of Mario Loffredo <[email-masked]>
Sent: Monday, September 21, 2020 12:49 AM
To: Antoin Verschuren <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis

Notice: This email is from an external sender.

+1

Mario

---

From: "Gould, James" <[email-masked]>
Date: Mon, 21 Sep 2020 15:22:12 +0000

Upon review of draft-ietf-regext-rfc7482bis, I have the following feedback:

Use of entity lookup for registrar objects was added, but there is no guidance related to handling entity lookups for different independent object types, where the object identifier and subsequently the <handle> may overlap.  An example is the ROID format for contacts “((\w|_){1,80}-\w{1,8}” is unique from the use of the IANA Registrar ID “\d+” for registrars but not unique from the registrar name (“fn element” in RFC 7483 with “\w+”).  The registrar name is a superset of the ROID, so a <handle> following the ROID format can take precedence as a contact object lookup instead of a registrar object lookup.  A <handle> is a unique for all RDAP objects except for the entity object that can be mapped to multiple distinct object types (contact and registrar).  Should the RFC cover the case of possible overlapping <handle> values for different types of entity objects, such as contact and registrar objects, where the server must define a unique <handle> scheme or define a <handle> precedence order?

-- 
 
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 9/18/20, 9:53 AM, "regext on behalf of Antoin Verschuren" <[email-masked] on behalf of [email-masked]> wrote:

    https://secure-web.cisco.com/1ac_zElJ5XQmeb9wriRMGDiyT7UDPT8R5g2FcJC2RaWdbjhJcHcMnYwMXRBnrYllgQcTJVcEgIqtPvkcTXRxOQgngF10AWz1u6mbrsU9Obl8HdB5bEVPFRkQ1JKS_qyIlCvLAC98Tcml3B1kfNqMiHyspmwKyJ008MmX9avaDxOYfAqeKp0H1PXsGpYdjCZqjNa7zRWyk1N3_lUE1X2Yi9rXxJJ9Fanu4psdzydQ4_-UkpC-IPlaMBxw1hZIP6ui58hPmQk8mwL8Nf-kwlRrUVQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rfc7482bis%2F

    
    
    Regards,
    
    Jim and Antoin

    

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1337bMS3R-xYDaKpOLmuqHkKg7WPZZbyrQeuCHEOaMTy79XTBPSksvcitVG4qB9Y_ZjJhfUiOugbe1-v-9wXelNfsHhGGvWVcoMOwHlM_U5v6kzj7P5uT0Ng62WkQxlHJgKcnmBWSUqjGxf0Z9qloV1JU7QAzsGjezePhbG7PDDMJR1hrpzqfIqJxj0iUSyTfqPbhAhoUrpSG9N5jUHcAFCtXJKqsYpG8qWLvM9oBiD7M9TmVIaelV91RBcnl3JyEfx4gRw2MzBbYHHUgsY257fKpHu_IWgSP78kNIypzLJU/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 21 Sep 2020 18:01:51 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Gould, James
> Sent: Monday, September 21, 2020 11:22 AM
> To: [email-masked]; [email-masked]
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>
> Use of entity lookup for registrar objects was added, but there is no guidance
> related to handling entity lookups for different independent object types,
> where the object identifier and subsequently the <handle> may overlap.  An
> example is the ROID format for contacts “((\w|_){1,80}-\w{1,8}” is unique
> from the use of the IANA Registrar ID “\d+” for registrars but not unique
> from the registrar name (“fn element” in RFC 7483 with “\w+”).  The registrar
> name is a superset of the ROID, so a <handle> following the ROID format can
> take precedence as a contact object lookup instead of a registrar object
> lookup.  A <handle> is a unique for all RDAP objects except for the entity
> object that can be mapped to multiple distinct object types (contact and
> registrar).  Should the RFC cover the case of possible overlapping <handle>
> values for different types of entity objects, such as contact and registrar
> objects, where the server must define a unique <handle> scheme or define
> a <handle> precedence order?

Jim, RDAP doesn't have any notion of registrar entities that are somehow different from any other type of entity, so I'm not sure what, if anything, makes sense to say in the document. If you have a specific suggestion for text, it would be worth sharing to see what others think.

Scott

---

From: "Gould, James" <[email-masked]>
Date: Mon, 21 Sep 2020 18:27:23 +0000

Scott,

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.

-- 
 
JG

James Gould
Fellow Engineer

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

    
    
    Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 24 Sep 2020 16:32:05 +0000

> From: Gould, James <jgould=[email-masked]>
> Sent: Monday, September 21, 2020 2:27 PM
> To: Hollenbeck, Scott <[email-masked]>; [email-masked];
> [email-masked]
> 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.
>

I'd like to see some discussion of this suggestion, too. What do people think? Is it necessary?

Scott

---

From: Jasdip Singh <[email-masked]>
Date: Thu, 24 Sep 2020 16:35:35 +0000

Hello Scott, James.

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.

Jasdip

    
    
    Scott