RE: Last Call: <draft-ietf-weirds-rdap-query-15.txt> (Registration Data

I apologize in advance for anyone who has issues with HTML-formatted messages. 
Don’t do that, Ed ;)

 

Scott

 

From: Edward Lewis [mailto:edward(_dot_)lewis(_at_)icann(_dot_)org] 
Sent: Tuesday, October 21, 2014 9:35 AM
To: Hollenbeck, Scott; ietf(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org
Cc: weirds(_at_)ietf(_dot_)org; Andy Newton
Subject: Re: Last Call: <draft-ietf-weirds-rdap-query-15.txt> (Registration 
Data Access Protocol Query Format) to Proposed Standard

 

A few “comebacks” in-line.

 

From: "Hollenbeck, Scott" <shollenbeck(_at_)verisign(_dot_)com>
Date: Tuesday, October 21, 2014 at 8:51
To: Edward Lewis <edward(_dot_)lewis(_at_)icann(_dot_)org>, 
"ietf(_at_)ietf(_dot_)org" <ietf(_at_)ietf(_dot_)org>, 
"iesg(_at_)ietf(_dot_)org" <iesg(_at_)ietf(_dot_)org>
Cc: "weirds(_at_)ietf(_dot_)org" <weirds(_at_)ietf(_dot_)org>, Andy Newton 
<andy(_at_)arin(_dot_)net>
Subject: RE: Last Call: <draft-ietf-weirds-rdap-query-15.txt> (Registration 
Data Access Protocol Query Format) to Proposed Standard

 

-----Original Message-----

From: Edward Lewis [mailto:edward(_dot_)lewis(_at_)icann(_dot_)org]

Sent: Friday, October 17, 2014 12:02 PM

To: ietf(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org

Cc: weirds(_at_)ietf(_dot_)org; Hollenbeck, Scott; Andy Newton

Subject: Re: Last Call: <draft-ietf-weirds-rdap-query-15.txt>

(Registration Data Access Protocol Query Format) to Proposed Standard

 

Thanks for the feedback, Ed.

 

A couple of comments

Comment 1

Section 1.1

Nit: the detail on REST and RESTful seems out of place in a list of

acronyms and abbreviations.

 

The "detail" is no more than a sentence or two. I'm inclined to leave that nit 
alone.

 

Comment 2

Section 2

##   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.

Nit: should be "it is unlikely that a uniform approach ... is needed

for

interoperability."

 

Agreed.

 

Comment 3

Section 3.2

Confusion: domain/domains and entity/entities plural forms are defined

externally to the list, but nameserver/nameservers plural form is

not.  I think that is just an inconstency.

 

I don't understand this comment. The text I'm looking at in Section 3.2 
includes search path segment definitions for "domains", "nameservers", and 
"entities". The singular forms used for lookups are defined in Section 3.1. 
What am I missing?

 

That in the bullets you have:

   o  'domains': ...
   o  'nameservers': ...
   o  'entities': …
And in prose you have:
For the domain and entity objects described in this document the plural object 
forms are "domains" and "entities”.
Merely the mismatch in the “number of parameters” (- the prose doesn’t mention 
nameservers)
 
[SAH] OK, now I see that. Will fix.
 

The word ''match'' is used referring to a FQDN.  Does this mean to

imply

''match'' as defined in RFC 1034 (where '*' matches anything)?

 

Matching is described in Section 4.1.

 

The you have a “forward reference here - using “match” in 3.2 (and in the 
context of a “fully-qualified domain name), then later in the document defining 
it in 4.1.

 

I’ve seen this problem when implementers read the RFCs.  They might read 3.2 
and assume match as defined in the DNS.  Match is such an overloaded term it 
deserves qualification (or an adjective).

 

[SAH] I’ll add a sentence for the forward reference to 4.1

 

And what is throwing me is that this begins talking about testing to

see

if something exists and then seems to start talking about finding

inexact

matches (the plurals).

It reads as if the first paragraph doesn't relate to the rest of the

section.

 

Hmm, OK. That first paragraph (which describes using the HTTP HEAD method to 
check for object existence) could be moved to Section 3.1.

 

Comment 4

Section 3.2.1 and 3.2.2

Confusion: Both 3.2.1 and 3.2.2 cover searching for name servers.  Why

are

two approaches presented?

    http://example.com/rdap/nameservers?name=ns1.example*.com

and

    http://example.com/rdap/domains?nsLdhName=ns1.example*.com

I suppose this isn't a major issue, but seems awkward.

 

3.2.1 describes searching for *domains*. 3.2.2 describes searching for *name 
servers*.

 

Then maybe the example “ns1.example*.com” ought to be just "example*.com.”?

 

[SAH] No. I assume you’re looking at the example in Section 3.2.1. It describes 
a method of searching for domain information by name server name, and in this 
case the name server name can be represented with a pattern. As it says in the 
text, “The following URL would be used to search for domains delegated to name 
servers matching the "ns1.example*.com" pattern”.

 

 

Comment 5

Section 4.2

Needed work: What is a "name-record" ?  I can imagine a few different

meanings, which is the problem.  Is this a "registration" , i.e., the

mapping of the network object to an entity (set)?  Are associated

"name-records" like variants of IDNs?  Are they related in a IP

hierarchy,

or somehow jointly registered objects?

 

I believe this text came from John Klensin. My understanding of the meaning is 
that the term refers to a row in a relational database. Would it be clearer to 
just say "record" or "entry" instead of "name record"?

 

I’ll go with what was meant.  As a reader, my note is that the term may be a 
little too abstract.

 

Perhaps:

 

Conceptually, a search-query-matching record in a database may be linked to an
   associated record, which may also be linked to another such
   record, and so on.
 

That is, if “linked to” is the right term.  Perhaps “associated with” (knowing 
that term is in the title).  Of perhaps this

 

Conceptually, a search-query-matching record in a database may be a member
of a set of one or more records associated with a registration event [if that’s
the appropriate grouping].
 
(Sorry about the formatting - I’ve lost control of how this mail reader does 
formatting.)

 

I have a new comment coming from re-reading this section:

If an implementation is to return more than one
   name-record in response to a query, information from the records
   thereby identified is returned.

> From that I would assume the draft is saying all associated records would be 
> too - and later we talk about issues with authorization to release 
> information.  I’d change the “is returned” to “is subject to be included in a 
> response (pending other considerations [and maybe cite the Security 
> Considerations]).”
 

Oh, wait, that’s in the next paragraph.

 

Perhaps using the word “set” might make 4.2 work better.

 

Uh, see below...

 

Comment 6

Section 4.2 - later on

Confusion: It sounds here that a client cannot set up an expectation

that

it's query will return something specific or return a list, which is

bad

(meaning the client can’t set expectation).  A client ought to be able

to

know what it will get back, even if it is an error.  What I mean is

'returning information that was not explicitly selected by an exact-

match

lookup' is ... is bothering me.

Maybe these terms need to be ironed out better: search vs. lookup and

what

does match mean.  I do see match defined - after it is used a few

times.

And in section 3.2, I first ran into the confusion of search v. lookup.

(In the DNS world, we distunguish this by saying DNS does not search,

it

does a lookup.)

 

Can you suggest appropriate text?

 

4.2.  Associated Records
 
Conceptually, any query-matching record in the registry's database might be a 
member of a set of related records, related in some fashion as defined by the 
registry. (E.g., variants of an IDN.)  When constructing the response, the 
entire set ought to be considered as candidates for inclusion.  However, the 
construction of the final response needs to be mindful of privacy and other 
data-releasing policies when assembling the RDAP response set.
Note too that due to the nature of searching, there may be a list of 
query-matching records.  Each one of those is subject to being a member of a 
set as described in the previous paragraph.  What is ultimately returned in a 
response will be the union of all the sets and be filtered by whatever policies 
are in place.
 
[SAH] I’m OK with this.
 

 

Comment 7

Section 5

Suggestion: this seems to be begging for a "standard" definition of an

non-standard extension prefix - or everyone will use "custom_" because

that is the example here.  (Name collisions.)  And if a custom one

becomes

a standard, can the transition be eased?  (TXT to SPF issue.)  And how

do

we encourage more standard and fewer uniques (the EPP[EXT] issue)?

 

Note the reference to Section 6 of the using-http document. It describes an 
IANA registry for these prefixes.

 

Then I’d change this:

 

Custom path segments can be created by prefixing the segment with a
   unique identifier followed by an underscore character (0x5F).
To:
Custom path segments SHOULD be created by prefixing the segment with a
   unique identifier followed by an underscore character (0x5F).

(A one word change, “can” to “SHOULD”.)

 

[SAH] That would open up a different can of worms with respect to “what if they 
don’t?” questions. With no one else pushing back on this point (at least not 
yet) I’d prefer to not introduce a 2119 term here.

 

 

Comment 8

Section 6

Suggestion: Shouldn't RDAP applications be considered to be IDNA2008

aware? The argument for this is in RFC 6912.  Or is that pressing a

policy

into the protocol needlessly?

 

One of the authors of RFC 6912 (Andrew Sullivan) was very helpful in developing 
the text for this section. I would defer to his guidance.

 

Comment 9

Section 8

##   Search functionality also increases the privacy risk of disclosing

##   object relationships that might not otherwise be obvious.  For

##   example, a search that returns IDN variants [RFC6927] that do not

##   explicitly match a client-provided search pattern can disclose

##   information about registered domain names that might not be

otherwise

##   available.  Implementers need to consider the policy and privacy

##   implications of returning information that was not explicitly

##   requested.

I think this can improved by mentioning that implementers need to

“consider policy and privacy implications, e.g., by checking for

authorization to release information to the requestor, in all cases and

especially here, when returning information that was not explicitly

requested.”

In general, I’ve always been a little suspect on RDAP’s search ability

and

now carefully reading the last call documents am still a little shaky

on

it.  Perhaps the word “search” to me has a wider definition than is

being

applied here, where RDAP just looks for a common pre-amble (prefix,

starting string, whatever you want to call it).  I am aware of the

perils

of unicode, sigh, but I wish there was a chance to have a search

definition that was free of ASCII assumptions and was always mindful of

the authorization to “release” information.

I am aware I’m saying this very late in the game.  I’m willing to

accept

the definition going forward as is.  But I wanted to drop the comment

somewhere.  But please add in, where implementers “consider”, mention

of

the authorization model.  This is because I can see operators pulling

open

source tools for this from the shelf, they won’t be handcrafting the

code,

and need some place to “configure this”.

 

How about this?

 

OLD:

"Implementers need to consider the policy and privacy implications of returning 
information that was not explicitly requested."

 

NEW:

"Implementers need to consider the policy and privacy implications of returning 
information that was not explicitly requested. Clients should only receive 
information that they are explicitly authorized to receive."

 

Almost…”Servers should only send information that clients are explicitly 
authorized to receive.”

 

The way it is worded is impossible to "enforce."

 

[SAH] OK!

 

Scott

smime.p7s
Description: S/MIME cryptographic signature