Subject: Re: [weirds] Last Call: <draft-ietf-weirds-using-http-07.txt> (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard

From: Olaf Kolkman <[email-masked]>
Date: Sun, 11 Aug 2013 13:34:00 +0200

Hello Subramanian,

[ Adding the WG, for transparency purposes. ]
[ I've dropped the IETF list at this point, as we seem to delve into details, feel free to add the IETF list if you think that is wise]
[ Adding Pete to the CC, for information, nothing actionable]

On Jul 17, 2013, at 6:15 AM, SM <[email-masked]> wrote:

> At 16:05 15-07-2013, The IESG wrote:
>> The IESG has received a request from the Web Extensible Internet
>> Registration Data Service WG (weirds) to consider the following document:
>> - 'HTTP usage in the Registration Data Access Protocol (RDAP)'
>>  <draft-ietf-weirds-using-http-07.txt> as Proposed Standard
> 
> The Abstract mentions that:
> 
>  "This document is one of a collection that together describe the
>   Registration Data Access Protocol (RDAP).  It describes how RDAP is
>   transported using the Hypertext Transfer Protocol (HTTP)."
> 
> In Section 2 it is mentioned that:
> 
> "RDAP query and response formats are described in other documents
>  in the collection of RDAP specifications, while this document
>  describes how RDAP clients and servers use HTTP to exchange
>  queries and responses."
> 
> I read the document and I did not find any other information about collection of RDAP specifications.
> 
> According to Section 1:
> 
>  "This document describes the usage of HTTP for Registration Data
>   Directory Services."
> 
> From Section 2:
> 
>  "In accordance with [SAC-051], this document describes the base
>   behavior for a Registration Data Access Protocol (RDAP).
>   [SAC-051] describes a protocol profile of RDAP for Domain Name
>   Registries (DNRs), the Domain Name Registration Data
>   Access Protocol (DNRD-AP)."
> 
> The recommendation in SAC051 is to adopt the following terminology:
> 
>  "Domain Name Registration Data Access Protocol (DNRD-AP).
>   The components of a (standard) communications exchangequeries
>   and responsesthat specify the access to DNRD"
> 
> I did not find any other information about the Registration Data Access Protocol.  It is weird that the IETF is standardizing a collection of documents which is undocumented.  It is also weird that the IETF is standardizing the Registration Data Access Protocol when there isn't any information about the said protocol except for the terminology mentioned above.
> 
> From Section 1:
> 
>  "A replacement protocol is expected to retain the simple transactional
>   nature of WHOIS, while providing a specification for queries and
>   responses, redirection to authoritative sources, support for
>   Internationalized Domain Names (IDNs, [RFC5890]), and support for
>   localized registration data such as addresses and organisation or
>   person names."
> 
> I read the draft again and I still did not know what the replacement protocol is.  I suggest clarifying where the Registration Data Access Protocol actually exists and where is it specified.
> 

All of these points above seem to me to suggest that the context in which this document is used is not clear to the innocent reader (Are there any in this space?).  

The review by Larry Manister (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10141.html) also touches on this point. He makes concrete suggestions in order to fix the document:

>> Please define what "Registration Data" is on first use.
>> Please define what "Registration Data Directory Services" are.
>> Please supply a reference for "RESTful"
>> 
>> Please explain what you mean by "better" in:
>>   "By giving the various Directory Services common
>>    behavior, a single client is better able to retrieve data from
>>    Directory Services adhering to this behavior."
>> Better how?
>> 
>> Please explain or give an example about what is insufficient in:
>>    "the WHOIS protocol is insufficient to
>>    modern registration data service requirements."
>> 
>> 
>> The sentence
>> ” Where complexity may reside, it is the goal of this document..."
>> is awkward, suggest just striking "Where complexity may
>> reside".
>> 
>> 
>> Please explain who "SSAC" is and why their opinion about WHOIS is relevant.
>> in " As is noted in SSAC Report ..."
>> 
>> Please give a reference for RDAP

The request  that I read in your and Larry's review is to clarify what RDAP is and in what context it is used. I think Larry's suggestions help achieving that, correct?

> In Section 1:
> 
>  "This is the basic usage pattern for this protocol:
> 
>   1.  A client issues an HTTP query using GET.  As an example, a query
>       for the network registration 192.0.2.0 might be http://
>       example.com/ip/192.0.2.0.
> 
>   2.  If the receiving server has the information for the query, it
>       examines the Accept header field of the query and returns a 200
>       response with a response entity appropriate for the requested
>       format.
> 
>   3.  If the receiving server does not have the information for the
>       query but does have knowledge of where the information can be
>       found, it will return a redirection response (3xx) with the
>       Location: header field containing an HTTP(S) URL (Uniform
>       Resource Locator) pointing to the information or another server
>       known to have knowledge of the location of the information.  The
>       client is expected to re-query using that HTTP URL.
> 
>   4.  If the receiving server does not have the information being
>       requested and does not have knowledge of where the information
>       can be found, it returns a 404 response.
> 
>   5.  If the receiving server will not answer a request for policy
>       reasons, it will return an error response (4xx) indicating the
>       reason for giving no answer."
> 
> The above is basically HTTP being given another name.  Section 3 of the draft says that:
> 
>  "HTTP also benefits from widespread investment in scalability,
>   reliability, and performance, and widespread programmer understanding
>   of client behaviours for RESTful web services, reducing the cost to
>   deploy Registration Data Directory Services and clients."
> 
> It seems that someone decided to choose port 80 and then went to find the reasons for that choice.  Can I ask for some references for the above?  I am okay if I am told that I have to believe that it is true because it is written in a RFC.

Would all this be solved with a reference to RESTful? 

> 
> From Section 4.2:
> 
>  "Servers MUST ignore unknown query parameters.  Use of unknown query
>   parameters for cache-busting is described in Appendix B."
> 
> If I understood the requirement it is that the servers must ignore unknown query parameters while the draft documents usage of unknown query parameters in Appendix B.  This doesn't make sense to me.

Appendix B describes how _clients_ make use of those parameters to circumvent middle boxes, like caching proxies.  In other words given that Servers MUST ignore the query parameters appendix B describes a cool hack to circumvent unwanted middle box behavior.

I don't think any action is required, unless you have suggestions for specific language?

> 
> From Section 5:
> 
>  "While no standard HTTP response code is forbidden in usage, at a
>   minimum clients SHOULD understand the response codes described in
>   this section as they will be in common use by servers."
> 
> I don't understand the "SHOULD understand".

Would this work:
SHOULD implement the specified behavior for the response codes described in….

> 
> From the Security Considerations section:
> 
>  "This document does not pose strong security requirements to the RDAP
>   protocol."
> 
> I read the about as meaning that the unspecified RDAP protocol does not need strong security requirements.
> 
>  "Additional security considerations to the RDAP protocol will be
>   covered in future RFCs documenting specific security mechanisms and
>   schemes."
> 
> I assumed that security considerations was about considering security concerns and discussing about them.  The above leaves that to future RFCs.

Larry has similar remarks. 

> 
> In Section 9.1:
> 
>  "Clients can use IRIs [RFC3987] for internal use as they see fit, but
>   MUST transform them to URIs [RFC3986] for interaction with RDAP
>   servers."
> 
> That means that servers do not support internationalization.

Yes the parts of servers that deal with the queries is defined to deal with URIs.  The i18n aspect here is that the client is instructed to normalize the query behavior, not the server.

The part of servers that deals with responses and internal lookup magic do need to have understanding of i18n, that is in 9.2.

I am not sure how this comment is actionable? Suggestions?

> 
> From Section 9.2:
> 
>  "On the other hand, when servers return data and have knowledge
>   that the data is in a language or script, the data SHOULD be
>   annotated with language identifiers whenever they are available,
>   thus allowing clients to process and display the data accordingly.
> 
>   The mechanism for including a language identifier in a response will
>   be defined in subsequent documents describing specific response
>   formats."
> 
> The approach adopted in this future Proposed Standard is that everything will be defined in some future document.  This future Proposed Standard is under-specified to the such an extent that it would be extremely difficult to implement without insider information.

Yep, it is clear that that is the overall theme in your review. Acting on this would involve adding a number of references to other documents in he WEIRD suite. 

> By the way, the RFC 4627 and RFC 5234 references should be normative.
> 

Thanks for your thorough review, 
Best,

--Olaf

---

From: SM <[email-masked]>
Date: Tue, 13 Aug 2013 10:59:55 -0700

Hi Olaf,
At 04:34 11-08-2013, Olaf Kolkman wrote:
>[ I've dropped the IETF list at this point, as 
>we seem to delve into details, feel free to add 
>the IETF list if you think that is wise]

Adding ietf@ is never wise. :-)

>All of these points above seem to me to suggest 
>that the context in which this document is used 
>is not clear to the innocent reader (Are there any in this space?).

The first sentence (see above) is a good summary 
of my comments.  There are innocent readers in 
this space.  I'll restrain myself from commenting about this. :-)

>The review by Larry Manister 
>(http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10141.html) 
>also touches on this point. He makes concrete 
>suggestions in order to fix the document:

I agree with the points raised by Larry Masinter.

>The request  that I read in your and Larry's 
>review is to clarify what RDAP is and in what 
>context it is used. I think Larry's suggestions help achieving that, correct?

That is correct.

>Would all this be solved with a reference to RESTful?

I don't think so.  As Larry pointed out, there is 
a significant number of editorial issues which 
can be considered as a major issue.  The protocol 
is okay.  It's how it is specified which is the 
problem, e.g. layering.  Adding a reference to 
RESTful is unfortunately not a fix.

>Appendix B describes how _clients_ make use of 
>those parameters to circumvent middle boxes, 
>like caching proxies.  In other words given that 
>Servers MUST ignore the query parameters 
>appendix B describes a cool hack to circumvent unwanted middle box behavior.
>

Could you provide some examples of known query 
parameters as it may make the discussion easier?

>SHOULD implement the specified behavior for the response codes described in….

That may work.  It would be helpful if there is 
some explanatory text for the "SHOULD".

>Yes the parts of servers that deal with the 
>queries is defined to deal with URIs.  The i18n 
>aspect here is that the client is instructed to 
>normalize the query behavior, not the server.

Ok.

>The part of servers that deals with responses 
>and internal lookup magic do need to have 
>understanding of i18n, that is in 9.2.

Section 9.2. has a "SHOULD" and basically says nothing. :-)

>I am not sure how this comment is actionable? Suggestions?

The entire document needs an editorial pass.  I 
don't know what text to suggest as anything I can 
think of would not make sense as I look at the entire document.

I would suggest looking at Larry's review and 
edit the draft from that perspective.  Once the 
major issues (I am using the word "issue" 
lightly) are resolved it is simply a matter of 
doing another pass of the draft for consistency.

Regards,
-sm