> -----Original Message----- > From: Edward Lewis [mailto:edward.lewis@xxxxxxxxx] > Sent: Friday, October 17, 2014 12:02 PM > To: ietf@xxxxxxxx; iesg@xxxxxxxx > Cc: weirds@xxxxxxxx; 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? > 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. > 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*. > 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"? > 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? > 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. > 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." Scott
<<attachment: smime.p7s>>