<div dir="ltr">1.10.3 might be referring to domain name lookups (which can also use the name server name or IP address) rather than explicit nameserver lookups. And as you point out, it's only for exact match searches. So I still think the profile is constructed so as to avoid requiring registries to support nameserver partial string match queries.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 26, 2015 at 6:06 PM, Rubens Kuhl <span dir="ltr"><<a href="mailto:rubensk@nic.br" target="_blank">rubensk@nic.br</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> Em 26 de out de 2015, à(s) 19:50:000, Brian Mountford <<a href="mailto:mountford@google.com">mountford@google.com</a>> escreveu:<br>
><br>
> Interesting. So those are intended to be independent requirements. But I still don't see a requirement for nameserver search with pattern strings.<br>
><br>
> 2.1 refers specifically to search requests with pattern strings, but does not mention nameservers.<br>
><br>
> 2.2 refers to searching for name servers by IP address, which as I read the RFC need not support wildcards (or am I wrong? can wildcards be used with IP addresses? if so, what are the matching rules?).<br>
><br>
> 2.3 refers to the case of multiple hosts with the same name; it doesn't actually call out particular search capabilities, does it?<br>
><br>
> 2.9 deals with entities.<br>
><br>
> 2.10.1 calls out section 3.1.4 of RFC 7482, which deals with nameserver lookup by fully-qualified hostname, not using a search pattern (that's section 3.2.2). The rest of 2.10 appears to deal with format of the returned data.<br>
><br>
> So it still looks to me like actual nameserver search, as discussed in RFC 7482, section 3.2.2, is not required by the ICANN profile. Is that correct?<br>
<br>
<br>
</span>Registry Agreement Specification 4, clause 1.10:<br>
<br>
1.10. Searchability. Offering searchability capabilities on the Directory Services is optional but if offered by the Registry Operator it shall comply with the specification described in this section.<br>
1.10.1 Registry Operator will offer searchability on the web-based Directory Service.<br>
1.10.2 Registry Operator will offer partial match capabilities, at least, on the following fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state or province, etc.).<br>
1.10.3 Registry Operator will offer exact-match capabilities, at least, on the following fields: registrar id, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records).<br>
1.10.4 Registry Operator will offer Boolean search capabilities supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT.<br>
1.10.5 Search results will include domain names matching the search criteria.<br>
1.10.6 Registry Operator will: 1) implement appropriate measures to avoid abuse of this feature (e.g., permitting access only to legitimate authorized users); and 2) ensure the feature is in compliance with any applicable privacy laws or policies.<br>
<br>
<br>
1.10.3 seem to also specify name servers, but only on exact match searches. RDAP Profile 2.1 seems to reflect RA 1.10.2, which does not specify name servers.<br>
<br>
Although a wildcard is not required in IP address, I could imagine it being done using CIDR blocks instead of character regex. And on name server matches, not being required does not prevent implementation if a registry is willing to do so, in my reading of the agreement.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Rubens<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div>