ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-weirds-rdap-query-15.txt> (Registration Data Access Protocol Query Format) to Proposed Standard

2014-10-20 10:39:07
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.

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

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.

The word ''match'' is used referring to a FQDN.  Does this mean to imply
''match'' as defined in RFC 1034 (where '*' matches anything)?

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.


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.


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?

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


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)?


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?

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

<Prev in Thread] Current Thread [Next in Thread>