Subject: [regext] AD Review: draft-ietf-regext-rdap-object-tag

From: Adam Roach <[email-masked]>
Date: Mon, 4 Jun 2018 18:32:11 -0500

I've reviewed the document draft-ietf-regext-rdap-object-tag in 
preparation for
placing it into IETF last call. The mechanism and document generally 
look good
and useful; however, I have some concerns about its URL synthesis.

The mechanical synthesis of URLs as described in this document 
contravenes the
requirements of BCP 190, section 2.3. Ordinarily, I would consider this a
showstopper and ask the working group to adjust handling to match BCP 190
requirements (e.g., using RFC 6570 URI Templates). Because this 
specification
simply builds upon RFC 7484 techniques for performing URI synthesis, 
however,
forcing such a change would result in an incongruity that I understand might
cause deployment issues.

Nonetheless, I request that the working group consider whether the use of
something like RFC 6570 would be appropriate for the mechanism described 
this
document. Please also understand that other area directors may note and 
object
to this type of URL synthesis during IESG processing. Chairs: please let me
know when you believe working group consideration of this issue is complete.

---------------------------------------------------------------------------

I also have one question about an example in section 2:

 >  For example, if the base RDAP URL
 >  "https://example.com/rdap/" is associated with service provider
 >  "YYYY" in an IANA registry, an RDAP client will parse a tagged entity
 >  identifier "XXXX-YYYY" into distinct handle ("XXXX") and service
 >  provider ("YYYY") identifiers.  The service provider identifier
 >  "YYYY" is used to query an IANA registry to retrieve the base RDAP
 >  URL "https://example.com/rdap/".  The base RDAP URL is concatenated
 >  to the entity handle to create a complete RDAP query path segment of
 >  "https://example.com/rdap/entity/XXXX-YYYY".

I read the text as calling for implementors to concatenate "XXXX-YYYY" 
to the
end of the IANA-registered base URL ("https://example.com/rdap/"), 
resulting in
"https://example.com/rdap/XXXX-YYYY". The example instead shows
"https://example.com/rdap/entity/XXXX-YYY". Is the inclusion of "entity/" in
this example an error?

Thanks for the work everyone has done on this document.

/a

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 5 Jun 2018 13:39:25 +0000

> -----Original Message-----
> From: Adam Roach <[email-masked]>
> Sent: Monday, June 04, 2018 7:32 PM
> To: [email-masked]; [email-masked]
> Subject: [EXTERNAL] AD Review: draft-ietf-regext-rdap-object-tag
>
> preparation for placing it into IETF last call. The mechanism and document
> generally look good and useful; however, I have some concerns about its
> URL synthesis.
>
> The mechanical synthesis of URLs as described in this document contravenes
> the requirements of BCP 190, section 2.3. Ordinarily, I would consider
> this a showstopper and ask the working group to adjust handling to match
> BCP 190 requirements (e.g., using RFC 6570 URI Templates). Because this
> specification simply builds upon RFC 7484 techniques for performing URI
> synthesis, however, forcing such a change would result in an incongruity
> that I understand might cause deployment issues.

Thanks for the review, Adam. I'm a little confused, though. RFC 7484 doesn't talk about URI synthesis - it describes registries and registration practices for data that can be used by RDAP clients to find servers. RFC 7482 describes how the URLs for RDAP queries are structured. My document includes the URLs and path segments from 7482 only as examples.

> this document. Please also understand that other area directors may note
> and object to this type of URL synthesis during IESG processing. Chairs:
> please let me know when you believe working group consideration of this
> issue is complete.

Maybe I'm missing something, but since this document isn't focused on URI synthesis I don't see how 6570 is applicable *unless* we're revisiting 7482. What this document describes is a practice for RDAP entity identifier construction so that clients can use information contained in that structure to bootstrap entity queries. That is, "when you create entity identifiers you should stick this thing on the end to make it easier for clients to find the associated server".

> resulting in "https://example.com/rdap/XXXX-YYYY". The example instead
> shows "https://example.com/rdap/entity/XXXX-YYY". Is the inclusion of
> "entity/" in this example an error?

No, it's not an error. That’s the path segment that 7482 describes for entity queries. I can see how my text above might be confusing, though, so how about this wording instead?

OLD:
"The base RDAP URL is concatenated to the entity handle to create a complete RDAP query path segment of "https://example.com/rdap/entity/XXXX-YYYY""

NEW:
"The RDAP query URL is formed using the base RDAP URL and entity path segment described in Section 3.1.5 of RFC 7482, using "XXXX-YYY" as the value of the handle identifier. The complete RDAP query URL becomes "https://example.com/rdap/entity/XXXX-YYYY"."

Scott

---

From: Adam Roach <[email-masked]>
Date: Tue, 5 Jun 2018 17:36:57 -0500

> Thanks for the review, Adam. I'm a little confused, though. RFC 7484 doesn't talk about URI synthesis - it describes registries and registration practices for data that can be used by RDAP clients…

Apologies -- I meant RFC 7482 rather than 7484.

> Maybe I'm missing something, but since this document isn't focused on URI synthesis I don't see how 6570 is applicable *unless* we're revisiting 7482. What this document describes is a practice for…

Okay, that makes sense. I had read this document as specifying the 
concatenation, but your explanation that it is simply specifying 
identifiers for use with 7482 makes sense.

> "The RDAP query URL is formed using the base RDAP URL and entity path segment described in Section 3.1.5 of RFC 7482, using "XXXX-YYY" as the value of the handle identifier. The complete RDAP query…

That seems good.

Thanks for the explanations. Based on what you've said, I think this is 
ready for IETF last call -- you can treat my comment for clarification 
of the example as an IETF last call comment, and address it along with 
any other feedback you receive during last call.

/a

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 6 Jun 2018 10:56:49 +0000

> Sent: Tuesday, June 05, 2018 6:37 PM
> To: Hollenbeck, Scott <shollenbeck=[email-masked]>;
> [email-masked]' <[email-masked]>; 'draft-ietf-regext-rdap-object-
> [email-masked]' <[email-masked]>
> Subject: [EXTERNAL] Re: [regext] AD Review: draft-ietf-regext-rdap-object-
> tag
>
> >> preparation for placing it into IETF last call. The mechanism and
> >> document generally look good and useful; however, I have some
> >> concerns about its URL synthesis.
> >>
> >> contravenes the requirements of BCP 190, section 2.3. Ordinarily, I
> >> would consider this a showstopper and ask the working group to adjust
> >> handling to match BCP 190 requirements (e.g., using RFC 6570 URI
> >> Templates). Because this specification simply builds upon RFC 7484
> >> techniques for performing URI synthesis, however, forcing such a
> >> change would result in an incongruity that I understand might cause
> deployment issues.
> > Thanks for the review, Adam. I'm a little confused, though. RFC 7484
> doesn't talk about URI synthesis - it describes registries and
> registration practices for data that can be used by RDAP clients to find
> servers. RFC 7482 describes how the URLs for RDAP queries are structured.
> My document includes the URLs and path segments from 7482 only as
> examples.
>
> >> Nonetheless, I request that the working group consider whether the
> >> use of something like RFC 6570 would be appropriate for the mechanism
> >> described this document. Please also understand that other area
> >> directors may note and object to this type of URL synthesis during IESG
> processing. Chairs:
> >> please let me know when you believe working group consideration of
> >> this issue is complete.
> > Maybe I'm missing something, but since this document isn't focused on
> URI synthesis I don't see how 6570 is applicable *unless* we're revisiting
> 7482. What this document describes is a practice for RDAP entity
> identifier construction so that clients can use information contained in
> that structure to bootstrap entity queries. That is, "when you create
> entity identifiers you should stick this thing on the end to make it
> easier for clients to find the associated server".
>
> >> -----------------------------------------------------------------------
> ---
> >> -
> >>
> > No, it's not an error. That’s the path segment that 7482 describes for
> entity queries. I can see how my text above might be confusing, though, so
> how about this wording instead?
> >
> > OLD:
> > "The base RDAP URL is concatenated to the entity handle to create a
> complete RDAP query path segment of "https://example.com/rdap/entity/XXXX-
> YYYY""
> >
> > NEW:
> > "The RDAP query URL is formed using the base RDAP URL and entity path
> segment described in Section 3.1.5 of RFC 7482, using "XXXX-YYY" as the
> value of the handle identifier. The complete RDAP query URL becomes
> "https://example.com/rdap/entity/XXXX-YYYY"."
>
> That seems good.
>

Will do - thanks!

Scott