Subject: [weirds] Comments on draft-ietf-weirds-rdap-query-00

From: SM <[email-masked]>
Date: Fri, 28 Sep 2012 08:00:06 -0700

Hello,

Here are some quick comment on 
draft-ietf-weirds-rdap-query-00.  Please note that this is not a review.

The RFC 2119 boilerplate is missing.  There is a long list of 
normative references.  Could the list be pruned to what is really needed?

 From the Introduction Section:

   "The protocol described in this specification is intended to address
    deficiencies with the WHOIS protocol [RFC3912] that have been
    identified over time, including:

    o  Lack of standardized command structures,
    o  lack of standardized output and error structures,
    o  lack of support for internationalization and localization, and
    o  lack of support for user identification, authentication, and
       access control."

I don't see any mention of user identification, authentication and 
access control in the draft.  If that is being addressed in another 
draft, I suggest having a pointer to the draft for now.  I suggest 
deferring the question of where the material should be until the work 
is in better shape.

   'While HTTP contains mechanisms for servers to authenticate clients
    and for clients to authenticate servers (from which authorization
    schemes may be built), both authentication of clients and servers and
    authorization for access to data are out-of-scope of this document.
    In general, these matters require "policy" and are not the domain of
    technical standards bodies.'

The draft mentions that the intention is to address deficiencies, 
e.g. authentication.  It then argues that authentication and 
authorization are out of scope for the document.  Is that a good idea?

As a general comment, if a matter is a policy decision, it might be 
easier to say so instead of explaining that it is not in the domain 
of technical standard bodies.

   "The patterns described in this document purposefully do not encompass
    all of the methods employed in the WHOIS and RESTful web services of
    all of the RIRs and DNRs."

I suggest expanding RIR and DNR on first use.

   "The intent of the patterns described here are to enable lookups of
    networks by IP address, autonomous system numbers by number,
    reverse DNS meta-data by domain, domains by name, name servers by
    name, registrars by name, and entities (such as contacts) by
    identifier.  It is envisioned that each registry will continue to
    maintain NICNAME/WHOIS and/or RESTful web services specific to their
    needs and those of their constituencies, and the information retrieved
    through the patterns described here may reference such services."

I suggest forgetting about ICANN, RIRs, gTLDs and ccTLDs.  It may be 
easier to explain which type of queries are being defined in the 
specification and leave it at that.

   "WHOIS services, in general, are read-only services.  Therefore URL
    [RFC3986] patterns presented here are only applicable to the HTTP
    [RFC2616] GET and HEAD methods."

Why?  It's easier to say that this is about an information retrieval 
mechanism and which methods should be used.

   "Additionally, resource management, provisioning and update functions
    are out of scope for this document.  Registries have various and
    divergent methods covering these functions, and it is unlikely a
    uniform approach for these functions will ever be possible."

As the above was not part of the problem description, it's easier to 
ignore all of that instead of providing an explanation.

In Section 2.1:

   "Semantically, the simpler form using the address can be thought of as
    a CIDR block with a length of 32 for IPv4 and a length of 128 for
    IPv6."

This sounds like tutorial material.

In Section 4:

   "Clients with graphical user interfaces may prefer a U-label since this
    is more visually recognizable and familiar than A-label strings, but
    clients of programmatic interfaces may wish to submit and display
    A-labels or may not be able to input U-labels with their keyboard
    configuration."

I suggest avoiding user interface details.

Regards,
-sm

---

From: Andy Newton <[email-masked]>
Date: Fri, 28 Sep 2012 16:09:56 +0000

Thanks SM. By my count your tab for Atlanta is now pre-populated with
three beers.

>normative references.  Could the list be pruned to what is really needed?

We can take a look at the reference list.

As for 2119 language, there is only one "MUST" in the document (outside of
boilerplate). We can take that out or convert to 2119 language.

>draft, I suggest having a pointer to the draft for now.

Yes, that would be the rdap-sec draft.

>authorization are out of scope for the document.  Is that a good idea?

Unfortunately, stating repeatedly that the IETF is a standards body and
doesn't do policy seems necessary in the Whois space. At least that is my
experience. Now, we should probably make that text normative in the
rdap-sec draft so we don't have to repeat it everywhere.

>specification and leave it at that.

This may be the wrong place to do it, but identifying the target audience
is important I think.

>ignore all of that instead of providing an explanation.

I beg to differ. ARIN has multiple RESTful services and we have had people
confuse their purpose. It is best to identify the target audience for
clarity. Now, we can perhaps argue if this is the right place to do it.

>This sounds like tutorial material.

Yup, it is. But so are examples in RFCs and we do that all the time. Text
to add clarity is a good thing, I think.

>I suggest avoiding user interface details.

Conversion between A-label and U-label is important, and noting where in
the system that conversion occurs is very important. IMHO.

Actually, I think this nit check deserves two beers.

-andy

---

From: SM <[email-masked]>
Date: Fri, 28 Sep 2012 12:36:43 -0700

Hi Andy,
>Thanks SM. By my count your tab for Atlanta is now pre-populated with

Thanks. :-)

>rdap-sec draft so we don't have to repeat it everywhere.

I understand your intent and I am not disagreeing with it.  You may 
have noticed that my reading of the text is different from the 
intent.  The document will be reflecting IETF Consensus.  The 
paragraph, taken by itself, is incorrect as it can be read as a 
general statement.  It is appropriate to specify a mechanism to 
ensure interoperability.

>clarity. Now, we can perhaps argue if this is the right place to do it.

With all due respect I think that we are talking about two different 
things here.  My point was about a specification defining the Unified 
Registration Data Access Protocol Query Format.  It's not about WHOIS 
and RESTful web services provided by ARIN.

I agree that it is best to identify the target audience for 
clarity.  I'll write this as general comments as it may be relevant 
for the other drafts.

   (i)  What is the purpose of the draft?

   (ii) What is the target audience?

>to add clarity is a good thing, I think.

Some of these RFCs end up causing headaches.

>Actually, I think this nit check deserves two beers.

It's my lucky day; two beers for a nit. :-)

In Section 2.4:

   "Internationalized names represented in A-label format [RFC5890] are
    also valid name server names."

As you settled for A-label format, you could use the "wire format" 
argument for the protocol.  You can then leave it to 
draft-ietf-weirds-json-response-00 to address other 
internationalization-related issues.

Regards,
-sm