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

From: Edward Lewis <[email-masked]>
Date: Fri, 17 Oct 2014 16:01:37 +0000

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 21 Oct 2014 12:51:39 +0000

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Friday, October 17, 2014 12:02 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; 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.

> acronyms and abbreviations.

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

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

Agreed.

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

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

Matching is described in Section 4.1.

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

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

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

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

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

Can you suggest appropriate text?

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

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

> 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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Oct 2014 13:35:11 +0000

A few “comebacks” in-line.

From:  "Hollenbeck, Scott" <[email-masked]>
Date:  Tuesday, October 21, 2014 at 8:51
To:  Edward Lewis <[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, Andy Newton <[email-masked]>
Subject:  RE: Last Call: <draft-ietf-weirds-rdap-query-15.txt> (Registration
Data Access Protocol Query Format) to Proposed Standard

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

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

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

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

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 21 Oct 2014 18:38:43 +0000

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

Scott

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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tuesday, October 21, 2014 at 8:51
To: Edward Lewis <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Andy Newton <[email-masked]>
Subject: RE: Last Call: <draft-ietf-weirds-rdap-query-15.txt> (Registration Data Access Protocol Query Format) to Proposed Standard

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

A couple of comments

Comment 1

Section 1.1

Comment 2

Section 2

##   Additionally, resource management, provisioning and update

functions

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

for

interoperability."

Agreed.

Comment 3

Section 3.2

   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

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

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

and

[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

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

hierarchy,

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

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

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

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

match

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.

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

it

does a lookup.)

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

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

Then I’d change this:

[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

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

policy

Comment 9

Section 8

##   information about registered domain names that might not be

otherwise

##   requested.

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

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

perils

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

accept

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,

How about this?

OLD:

NEW:

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

[SAH] OK!

Scott

---

From: Andrew Newton <[email-masked]>
Date: Tue, 21 Oct 2014 19:28:51 -0400

> IANA registry for these prefixes.
...
>
>
> [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.

I agree with Scott, especially given the reference to Section 6 of
draft-ietf-weirds-using-http.

-andy

---

From: Andy Newton <[email-masked]>
Date: Fri, 24 Oct 2014 18:00:22 +0000

I missed this due to all the HTML in the email...

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

How does this work with anonymous access to public information, which is
how this information is served today? How do I ³explicitly" authorize an
anonymous user? I think the old text above is good enough and find the
next text (both versions) to be confusing.

-andy

---

From: Edward Lewis <[email-masked]>
Date: Fri, 24 Oct 2014 23:03:31 +0000

As far as HTML in email, I just don’t care anymore. ;)

If by “public information” you mean information that anyone can access,
then an anonymous user is explicitly permitted to be sent it.  If by
“anonymous” you mean a user without a proven identity, then any
information deemed consumable by the general public is explicitly
permitted to be sent.

Just being pedantic.

Perhaps the second sentence is redundant, but I do see a difference (which
may be moot) in placing restrictions on what is sent vs. what can be
received.

From:  Andy Newton <[email-masked]>
Date:  Friday, October 24, 2014 at 14:00
To:  Edward Lewis <[email-masked]>, "Hollenbeck, Scott"
<[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: Last Call: <draft-ietf-weirds-rdap-query-15.txt>
(Registration Data Access Protocol Query Format) to Proposed Standard

---

From: Andy Newton <[email-masked]>
Date: Tue, 28 Oct 2014 13:31:16 +0000

> information deemed consumable by the general public is explicitly

It’s the word “explicitly” which is confusing me. How is it “explicit” that they are permitted access to the information? Are you assuming a specific authorization scheme or security service? Are you assuming/imposing some sort of public notification?

> may be moot) in placing restrictions on what is sent vs. what can be

I agree. There is a difference and that the sentence is redundant. As it stands I find it adds more confusion and does not really add a useful benefit.

-andy

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Oct 2014 13:46:45 +0000

(I hope HTML is off…)

Here’s my concern.

Most RFCs assume the target audience is the implementer and this sentence
makes it explicit.  (Not being said pejorative sense, and, um, no pun
intended.) For a large part of the deployment, the code will be pulled off
the git-shelf by operators and put into service.  The operators will be at
the mercy of the developer’s inclusion or exclusion of knobs and meters to
configure the code to do the right thing.  The idea stuck in the back of
my head is ensuring that implementers knowingly include a way for a
authorization-to-send policy to be specified (made explicit), even if the
policy is “all can see anything.”

How about this then:

Implementers need to consider the policy and privacy implications of
returning information that was not explicitly requested.  Servers ought
to support means to ensure that any information sent is done in accordance
with local policy, including what is found in a search.

This is meant to be a reminder within the scope of “other things found
while searching.”
Local policy is the catch-all used in DNSSEC RFCs to cover anything an
operator may elect to do.

From:  Andy Newton <[email-masked]>
Date:  Tuesday, October 28, 2014 at 9:31
To:  Edward Lewis <[email-masked]>
Cc:  Scott Hollenbeck <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  Re: Last Call: <draft-ietf-weirds-rdap-query-15.txt>
(Registration Data Access Protocol Query Format) to Proposed Standard

>It’s the word “explicitly” which is confusing me. How is it “explicit”
>that they are permitted access to the information? Are you assuming a
>specific authorization scheme or security service? Are you
>assuming/imposing some sort of public notification?
>
>> Just being pedantic.
>> 
>I agree. There is a difference and that the sentence is redundant. As it
>stands I find it adds more confusion and does not really add a useful
>benefit.
>
>-andy
>
>

---

From: Andy Newton <[email-masked]>
Date: Tue, 28 Oct 2014 14:02:14 +0000

> with local policy, including what is found in a search.

I find this much easier to understand, and it works for me.

-andy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 28 Oct 2014 14:18:01 +0000

> From: Andy Newton [mailto:[email-masked]]
> Sent: Tuesday, October 28, 2014 10:02 AM
> To: Edward Lewis
> Cc: Hollenbeck, Scott; [email-masked]; [email-masked]; [email-masked]

Same here. I'll see if I can add it after the IESG does their thing.

Scott

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Oct 2014 10:22:49 -0700

[trimming]

Pete, could you do this as an RFC Editor note, make it a YES comment, or do
a "Point raised" so we have a chance to fix it before it goes to the RFC
Editor?

-MSK

On Tue, Oct 28, 2014 at 7:18 AM, Hollenbeck, Scott <[email-masked]
> wrote:

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 28 Oct 2014 17:34:05 +0000

After re-reading the suggested text I’d actually like to change it. Please don’t do anything to commit it as-is.

OLD:
Implementers need to consider the policy and privacy implications of returning information that was not explicitly requested.  Servers ought to support means to ensure that any information sent is done in accordance with local policy, including what is found in a search.

NEW:
Implementers need to consider the policy and privacy implications of returning information that was not explicitly requested.  Servers need to ensure that any information sent, including search results, is returned in accordance with local policy.

Scott

From: Murray S. Kucherawy [mailto:[email-masked]]
Sent: Tuesday, October 28, 2014 1:23 PM
To: Hollenbeck, Scott
Cc: Andy Newton; Edward Lewis; [email-masked]
Subject: Re: Last Call: <draft-ietf-weirds-rdap-query-15.txt> (Registration Data Access Protocol Query Format) to Proposed Standard

[trimming]

Pete, could you do this as an RFC Editor note, make it a YES comment, or do a "Point raised" so we have a chance to fix it before it goes to the RFC Editor?
-MSK

On Tue, Oct 28, 2014 at 7:18 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:
> From: Andy Newton [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Hollenbeck, Scott; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> On Oct 28, 2014, at 9:46 AM, Edward Lewis <[email-masked]<mailto:[email-masked]>>
> wrote:
>
> > How about this then:
> >

Scott

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Oct 2014 19:36:07 +0000

FWIW, I’m fine with the change.

From:  <Hollenbeck>, Scott <[email-masked]>
Date:  Tuesday, October 28, 2014 at 13:34
To:  "Murray S. Kucherawy" <[email-masked]>
Cc:  Andy Newton <[email-masked]>, Edward Lewis <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject:  RE: Last Call: <draft-ietf-weirds-rdap-query-15.txt> (Registration
Data Access Protocol Query Format) to Proposed Standard

> Implementers need to consider the policy and privacy implications of returning
> information that was not explicitly requested.  Servers ought to support means
> to ensure that any information sent is done in accordance with local policy,
> including what is found in a search.
>  
> NEW: 
> Implementers need to consider the policy and privacy implications of returning
> information that was not explicitly requested.  Servers need to ensure that
> any information sent, including search results, is returned in accordance with
> local policy.
>  
> Scott
>  
> 
> Subject: Re: Last Call: <draft-ietf-weirds-rdap-query-15.txt> (Registration
> Pete, could you do this as an RFC Editor note, make it a YES comment, or do a
> "Point raised" so we have a chance to fix it before it goes to the RFC Editor?
> -MSK
> 
>  
> 
> On Tue, Oct 28, 2014 at 7:18 AM, Hollenbeck, Scott <[email-masked]>
> wrote: