Registration Data Access Protocol (RDAP) Query Format
draft-ietf-weirds-rdap-query-18

[Ballot comment]
Former DISCUSS Points, left as comments as a reminder to Pete.

Quoting Pete:

Point 1 - add explanatory text as discussed
Point 2 - unpleasant, but can live with it
Point 3 - Stop talking about Posix and make it clear that asterisk is the only choice.

Point 1:

In section 3.1.1, it's not clear which of three alternative things you may have been specifying: (1) the ASCII representation of the IP address is intended to be converted to binary before use, (2) the ASCII representation is intended to be used directly, or (3) whether the IP address is converted to binary prior to use is an implementation choice.  If (1) is what's intended, you should say so explicitly.  If either (2) or (3) is intended, then the representation that's used needs to be in some canonical form, and the text as written does not ensure that it will be.

So to address this discuss, you should either update the text to say that (1) is what's intended, and it won't work otherwise, or you need to require, not suggest, a canonical representation.  If you go with the second option, your reference to RFC 5952 isn't adequate: you need to specifically reference section 4, and specifically exclude section 5.  I have no preference as to how you resolve this.

Point 2:

In 3.1.3, the instructions as given don't really guide implementations toward interoperability.  Why not just say that servers SHOULD either convert a-labels to u-labels, or u-labels to a-labels, and be done with it?  It's not like it's a difficult conversion, and they have to do the conversion to do the comparison, unless for some reason they store both A- and U-labels as keys in their database, which seems really unlikely.  The recommendations are written are so vague that I would expect interoperability to only be likely in the case of queries that contain no IDN labels.  I wouldn't mind this in an Informational document, but it's pretty sketchy in a standards-track document.

It's particularly weird that in one place you say "An RDAP server that receives a query string with a mixture of A-labels and U-labels MAY convert all the U-labels to A-labels, perform IDNA processing, and proceed with exact-match lookup" and then in the next paragraph you say "The server MAY perform the match using either the A-label or U-label form.  Using one consistent form for matching every label is likely to be more reliable."

I'm not sure how to resolve this.  I think there's some underlying decision the working group has made that led to this language, but the lack of consistency I mention above leads me to wonder if either that decision wasn't very clear, or the document failed to reflect it.  Interestingly, 3.1.4 is written as if 3.1.3 gives clear guidance as to how IDNs are represented.

[point 2', which I forgot to label as a separate point, has been moved moved to a comment]


Point 3:

In 4.1, you don't actually specify the syntax for partial string matches.  I think I can intuit what you mean, but you should be explicit, and you shouldn't suggest using POSIX regex searches unless that's what you really mean; if that's what you really mean, then you need to do a lot more work than you've done.  I _think_ what you intend is to simply say that if one or more asterisks appear in a label, then when the search is done, any label that contains the non-asterisk characters in sequence plus zero or more characters in sequence in place of each asterisk would match.  But you don't actually say that, so I'm not sure what you actually intended.  The text could be read to mean that any arbitrary search mechanism is allowed, but if that's the case then you need to go into a lot more detail about the caveats, such as the '.' character in posix regexps and the start and end markers.

The text on partial matches for unicode also seems unnecessarily complicated, and likely not implementable without massive knowledge of all the various unicode character sets, which I would not expect an implementation to bother with.  It seems relatively harmless to allow searches on combining characters, particularly since it would be a lot of work to prevent it.  For example, a search for *ཀ་ would not find all instances of a syllable that starts with the sound "ka" because ka can be either a head letter or subjoined, but a user might search first using the head letter and then the subjoined letter if (as is not unlikely) he or she were unsure of the correct spelling.  It would be a shame if such a search were rendered impossible by an overly-thorough implementation of the current text.

As I say, I don't really know what was intended here, so I can't make a definite suggestion as to what the right thing to do is to fix this; I think we just need to discuss it, hence the discuss point.


Point A:

In 3.1.2:

  For example, the following URL would be used to find information
  describing autonomous system number 12 (a number within a range of
  registered blocks):

  http://example.com/rdap/autnum/12

  The following URL would be used to find information describing 4-byte
  autonomous system number 65538:

  http://example.com/rdap/autnum/65538

The examples don't really seem to illustrate what is said in the text.  The syntax for both examples is the same, and we don't see any return results.  So to say that one example is an example of a number within a range of registered blocks, while the other is a 4-byte number, doesn't make sense because the query formats are identical.  The preceding text is clear, if I understand it correctly: a number in the path element following 'autnum' is an autonomous system number, which references a block of one or more numbers.  If there are additional semantics, e.g., byte size boundaries for AS numbers, that are also encoded in the query, those should be described explicitly.  But IMHO that doesn't make sense: in _this_ context, these are just decimal numbers of arbitrary precision, and how many bytes they are, or whether any particular number references a block or just a single number, is not something that should be mentioned in the examples.

Point B:

Section 6 appears to be confusing presentation and representation.  A client might well present a UI that shows U-labels, but use A-labels on the back end.  The text as written here really doesn't make sense.  What are you trying to say?  I think that you shouldn't confuse what's presented to the user with what's sent on the wire.  Possibly this is related to the confusion over A-labels and U-labels that I called out in Point 2 of the discuss.

Former discuss points:

Point 2' from my initial discuss has been moved here because although I don't know of a mitigation strategy for the privacy concern I raised, I do see the valid use case, and so I don't feel like I have any action item to propose.  It would be great if the authors could address this in the security considerations section, but I won't hold them to it.

Point 2':

In 3.2.1 and 3.2.2, the main use cases I can see for nameserver searches are for spammers to identify related domains, and for eavesdroppers to do the same.  What's the motivation for including these capabilities?  At a minimum, the privacy considerations for this search ought to be discussed in a privacy considerations section or in the security considerations section.

[Ballot comment]

- Using https schemed URIs in the examples would be better.
Mind you, https://example.com does get you a fairly odd
certificate, so I can see why you might push back on that;-)

- I think the privacy considerations from the json response
draft might be better here.

[Ballot comment]
"Servers MUST return an HTTP 501 (Not Implemented) [RFC7231] response to inform clients of unsupported queries."

Shouldn't this go in -using-http?

Also, the wording here could use tightening.  It seems like you want to use 501 for query *types* that you don't support, vs. 404 for things where you just don't have an answer.  So sending a query for "bbc.co.uk" to the ".youtube" server would result in 404, but sending it to the ARIN server might result in 501.

[Ballot discuss]
Point 1:

In section 3.1.1, it's not clear which of three alternative things you may have been specifying: (1) the ASCII representation of the IP address is intended to be converted to binary before use, (2) the ASCII representation is intended to be used directly, or (3) whether the IP address is converted to binary prior to use is an implementation choice.  If (1) is what's intended, you should say so explicitly.  If either (2) or (3) is intended, then the representation that's used needs to be in some canonical form, and the text as written does not ensure that it will be.

So to address this discuss, you should either update the text to say that (1) is what's intended, and it won't work otherwise, or you need to require, not suggest, a canonical representation.  If you go with the second option, your reference to RFC 5952 isn't adequate: you need to specifically reference section 4, and specifically exclude section 5.  I have no preference as to how you resolve this.

Point 2:

In 3.1.3, the instructions as given don't really guide implementations toward interoperability.  Why not just say that servers SHOULD either convert a-labels to u-labels, or u-labels to a-labels, and be done with it?  It's not like it's a difficult conversion, and they have to do the conversion to do the comparison, unless for some reason they store both A- and U-labels as keys in their database, which seems really unlikely.  The recommendations are written are so vague that I would expect interoperability to only be likely in the case of queries that contain no IDN labels.  I wouldn't mind this in an Informational document, but it's pretty sketchy in a standards-track document.

It's particularly weird that in one place you say "An RDAP server that receives a query string with a mixture of A-labels and U-labels MAY convert all the U-labels to A-labels, perform IDNA processing, and proceed with exact-match lookup" and then in the next paragraph you say "The server MAY perform the match using either the A-label or U-label form.  Using one consistent form for matching every label is likely to be more reliable."

I'm not sure how to resolve this.  I think there's some underlying decision the working group has made that led to this language, but the lack of consistency I mention above leads me to wonder if either that decision wasn't very clear, or the document failed to reflect it.  Interestingly, 3.1.4 is written as if 3.1.3 gives clear guidance as to how IDNs are represented.

[point 2', which I forgot to label as a separate point, has been moved moved to a comment]


Point 3:

In 4.1, you don't actually specify the syntax for partial string matches.  I think I can intuit what you mean, but you should be explicit, and you shouldn't suggest using POSIX regex searches unless that's what you really mean; if that's what you really mean, then you need to do a lot more work than you've done.  I _think_ what you intend is to simply say that if one or more asterisks appear in a label, then when the search is done, any label that contains the non-asterisk characters in sequence plus zero or more characters in sequence in place of each asterisk would match.  But you don't actually say that, so I'm not sure what you actually intended.  The text could be read to mean that any arbitrary search mechanism is allowed, but if that's the case then you need to go into a lot more detail about the caveats, such as the '.' character in posix regexps and the start and end markers.

The text on partial matches for unicode also seems unnecessarily complicated, and likely not implementable without massive knowledge of all the various unicode character sets, which I would not expect an implementation to bother with.  It seems relatively harmless to allow searches on combining characters, particularly since it would be a lot of work to prevent it.  For example, a search for *ཀ་ would not find all instances of a syllable that starts with the sound "ka" because ka can be either a head letter or subjoined, but a user might search first using the head letter and then the subjoined letter if (as is not unlikely) he or she were unsure of the correct spelling.  It would be a shame if such a search were rendered impossible by an overly-thorough implementation of the current text.

As I say, I don't really know what was intended here, so I can't make a definite suggestion as to what the right thing to do is to fix this; I think we just need to discuss it, hence the discuss point.

[Ballot comment]
Point A:

In 3.1.2:

  For example, the following URL would be used to find information
  describing autonomous system number 12 (a number within a range of
  registered blocks):

  http://example.com/rdap/autnum/12

  The following URL would be used to find information describing 4-byte
  autonomous system number 65538:

  http://example.com/rdap/autnum/65538

The examples don't really seem to illustrate what is said in the text.  The syntax for both examples is the same, and we don't see any return results.  So to say that one example is an example of a number within a range of registered blocks, while the other is a 4-byte number, doesn't make sense because the query formats are identical.  The preceding text is clear, if I understand it correctly: a number in the path element following 'autnum' is an autonomous system number, which references a block of one or more numbers.  If there are additional semantics, e.g., byte size boundaries for AS numbers, that are also encoded in the query, those should be described explicitly.  But IMHO that doesn't make sense: in _this_ context, these are just decimal numbers of arbitrary precision, and how many bytes they are, or whether any particular number references a block or just a single number, is not something that should be mentioned in the examples.

Point B:

Section 6 appears to be confusing presentation and representation.  A client might well present a UI that shows U-labels, but use A-labels on the back end.  The text as written here really doesn't make sense.  What are you trying to say?  I think that you shouldn't confuse what's presented to the user with what's sent on the wire.  Possibly this is related to the confusion over A-labels and U-labels that I called out in Point 2 of the discuss.

Former discuss points:

Point 2' from my initial discuss has been moved here because although I don't know of a mitigation strategy for the privacy concern I raised, I do see the valid use case, and so I don't feel like I have any action item to propose.  It would be great if the authors could address this in the security considerations section, but I won't hold them to it.

Point 2':

In 3.2.1 and 3.2.2, the main use cases I can see for nameserver searches are for spammers to identify related domains, and for eavesdroppers to do the same.  What's the motivation for including these capabilities?  At a minimum, the privacy considerations for this search ought to be discussed in a privacy considerations section or in the security considerations section.

[Ballot discuss]
Point 1:

In section 3.1.1, it's not clear which of three alternative things you may have been specifying: (1) the ASCII representation of the IP address is intended to be converted to binary before use, (2) the ASCII representation is intended to be used directly, or (3) whether the IP address is converted to binary prior to use is an implementation choice.  If (1) is what's intended, you should say so explicitly.  If either (2) or (3) is intended, then the representation that's used needs to be in some canonical form, and the text as written does not ensure that it will be.

So to address this discuss, you should either update the text to say that (1) is what's intended, and it won't work otherwise, or you need to require, not suggest, a canonical representation.  If you go with the second option, your reference to RFC 5952 isn't adequate: you need to specifically reference section 4, and specifically exclude section 5.  I have no preference as to how you resolve this.

[point 2 moved to comment]

Point 3:

In 4.1, you don't actually specify the syntax for partial string matches.  I think I can intuit what you mean, but you should be explicit, and you shouldn't suggest using POSIX regex searches unless that's what you really mean; if that's what you really mean, then you need to do a lot more work than you've done.  I _think_ what you intend is to simply say that if one or more asterisks appear in a label, then when the search is done, any label that contains the non-asterisk characters in sequence plus zero or more characters in sequence in place of each asterisk would match.  But you don't actually say that, so I'm not sure what you actually intended.  The text could be read to mean that any arbitrary search mechanism is allowed, but if that's the case then you need to go into a lot more detail about the caveats, such as the '.' character in posix regexps and the start and end markers.

The text on partial matches for unicode also seems unnecessarily complicated, and likely not implementable without massive knowledge of all the various unicode character sets, which I would not expect an implementation to bother with.  It seems relatively harmless to allow searches on combining characters, particularly since it would be a lot of work to prevent it.  For example, a search for *ཀ་ would not find all instances of a syllable that starts with the sound "ka" because ka can be either a head letter or subjoined, but a user might search first using the head letter and then the subjoined letter if (as is not unlikely) he or she were unsure of the correct spelling.  It would be a shame if such a search were rendered impossible by an overly-thorough implementation of the current text.

As I say, I don't really know what was intended here, so I can't make a definite suggestion as to what the right thing to do is to fix this; I think we just need to discuss it, hence the discuss point.

[Ballot comment]
Point A:

In 3.1.2:

  For example, the following URL would be used to find information
  describing autonomous system number 12 (a number within a range of
  registered blocks):

  http://example.com/rdap/autnum/12

  The following URL would be used to find information describing 4-byte
  autonomous system number 65538:

  http://example.com/rdap/autnum/65538

The examples don't really seem to illustrate what is said in the text.  The syntax for both examples is the same, and we don't see any return results.  So to say that one example is an example of a number within a range of registered blocks, while the other is a 4-byte number, doesn't make sense because the query formats are identical.  The preceding text is clear, if I understand it correctly: a number in the path element following 'autnum' is an autonomous system number, which references a block of one or more numbers.  If there are additional semantics, e.g., byte size boundaries for AS numbers, that are also encoded in the query, those should be described explicitly.  But IMHO that doesn't make sense: in _this_ context, these are just decimal numbers of arbitrary precision, and how many bytes they are, or whether any particular number references a block or just a single number, is not something that should be mentioned in the examples.

Point B:

Section 6 appears to be confusing presentation and representation.  A client might well present a UI that shows U-labels, but use A-labels on the back end.  The text as written here really doesn't make sense.  What are you trying to say?  I think that you shouldn't confuse what's presented to the user with what's sent on the wire.  Possibly this is related to the confusion over A-labels and U-labels that I called out in Point 2 of the discuss.

Former discuss points:

Point 2 from my initial discuss has been moved here because although I don't know of a mitigation strategy for the privacy concern I raised, I do see the valid use case, and so I don't feel like I have any action item to propose.  It would be great if the authors could address this in the security considerations section, but I won't hold them to it.

Point 2:

In 3.1.3, the instructions as given don't really guide implementations toward interoperability.  Why not just say that servers SHOULD either convert a-labels to u-labels, or u-labels to a-labels, and be done with it?  It's not like it's a difficult conversion, and they have to do the conversion to do the comparison, unless for some reason they store both A- and U-labels as keys in their database, which seems really unlikely.  The recommendations are written are so vague that I would expect interoperability to only be likely in the case of queries that contain no IDN labels.  I wouldn't mind this in an Informational document, but it's pretty sketchy in a standards-track document.

It's particularly weird that in one place you say "An RDAP server that receives a query string with a mixture of A-labels and U-labels MAY convert all the U-labels to A-labels, perform IDNA processing, and proceed with exact-match lookup" and then in the next paragraph you say "The server MAY perform the match using either the A-label or U-label form.  Using one consistent form for matching every label is likely to be more reliable."

I'm not sure how to resolve this.  I think there's some underlying decision the working group has made that led to this language, but the lack of consistency I mention above leads me to wonder if either that decision wasn't very clear, or the document failed to reflect it.  Interestingly, 3.1.4 is written as if 3.1.3 gives clear guidance as to how IDNs are represented.

In 3.2.1 and 3.2.2, the main use cases I can see for nameserver searches are for spammers to identify related domains, and for eavesdroppers to do the same.  What's the motivation for including these capabilities?  At a minimum, the privacy considerations for this search ought to be discussed in a privacy considerations section or in the security considerations section.

[Ballot discuss]
Point 1:

In section 3.1.1, it's not clear which of three alternative things you may have been specifying: (1) the ASCII representation of the IP address is intended to be converted to binary before use, (2) the ASCII representation is intended to be used directly, or (3) whether the IP address is converted to binary prior to use is an implementation choice.  If (1) is what's intended, you should say so explicitly.  If either (2) or (3) is intended, then the representation that's used needs to be in some canonical form, and the text as written does not ensure that it will be.

So to address this discuss, you should either update the text to say that (1) is what's intended, and it won't work otherwise, or you need to require, not suggest, a canonical representation.  If you go with the second option, your reference to RFC 5952 isn't adequate: you need to specifically reference section 4, and specifically exclude section 5.  I have no preference as to how you resolve this.

Point 2:

In 3.1.3, the instructions as given don't really guide implementations toward interoperability.  Why not just say that servers SHOULD either convert a-labels to u-labels, or u-labels to a-labels, and be done with it?  It's not like it's a difficult conversion, and they have to do the conversion to do the comparison, unless for some reason they store both A- and U-labels as keys in their database, which seems really unlikely.  The recommendations are written are so vague that I would expect interoperability to only be likely in the case of queries that contain no IDN labels.  I wouldn't mind this in an Informational document, but it's pretty sketchy in a standards-track document.

It's particularly weird that in one place you say "An RDAP server that receives a query string with a mixture of A-labels and U-labels MAY convert all the U-labels to A-labels, perform IDNA processing, and proceed with exact-match lookup" and then in the next paragraph you say "The server MAY perform the match using either the A-label or U-label form.  Using one consistent form for matching every label is likely to be more reliable."

I'm not sure how to resolve this.  I think there's some underlying decision the working group has made that led to this language, but the lack of consistency I mention above leads me to wonder if either that decision wasn't very clear, or the document failed to reflect it.  Interestingly, 3.1.4 is written as if 3.1.3 gives clear guidance as to how IDNs are represented.

In 3.2.1 and 3.2.2, the main use cases I can see for nameserver searches are for spammers to identify related domains, and for eavesdroppers to do the same.  What's the motivation for including these capabilities?  At a minimum, the privacy considerations for this search ought to be discussed in a privacy considerations section or in the security considerations section.

Point 3:

In 4.1, you don't actually specify the syntax for partial string matches.  I think I can intuit what you mean, but you should be explicit, and you shouldn't suggest using POSIX regex searches unless that's what you really mean; if that's what you really mean, then you need to do a lot more work than you've done.  I _think_ what you intend is to simply say that if one or more asterisks appear in a label, then when the search is done, any label that contains the non-asterisk characters in sequence plus zero or more characters in sequence in place of each asterisk would match.  But you don't actually say that, so I'm not sure what you actually intended.  The text could be read to mean that any arbitrary search mechanism is allowed, but if that's the case then you need to go into a lot more detail about the caveats, such as the '.' character in posix regexps and the start and end markers.

The text on partial matches for unicode also seems unnecessarily complicated, and likely not implementable without massive knowledge of all the various unicode character sets, which I would not expect an implementation to bother with.  It seems relatively harmless to allow searches on combining characters, particularly since it would be a lot of work to prevent it.  For example, a search for *ཀ་ would not find all instances of a syllable that starts with the sound "ka" because ka can be either a head letter or subjoined, but a user might search first using the head letter and then the subjoined letter if (as is not unlikely) he or she were unsure of the correct spelling.  It would be a shame if such a search were rendered impossible by an overly-thorough implementation of the current text.

As I say, I don't really know what was intended here, so I can't make a definite suggestion as to what the right thing to do is to fix this; I think we just need to discuss it, hence the discuss point.

[Ballot comment]
Point A:

In 3.1.2:

  For example, the following URL would be used to find information
  describing autonomous system number 12 (a number within a range of
  registered blocks):

  http://example.com/rdap/autnum/12

  The following URL would be used to find information describing 4-byte
  autonomous system number 65538:

  http://example.com/rdap/autnum/65538

The examples don't really seem to illustrate what is said in the text.  The syntax for both examples is the same, and we don't see any return results.  So to say that one example is an example of a number within a range of registered blocks, while the other is a 4-byte number, doesn't make sense because the query formats are identical.  The preceding text is clear, if I understand it correctly: a number in the path element following 'autnum' is an autonomous system number, which references a block of one or more numbers.  If there are additional semantics, e.g., byte size boundaries for AS numbers, that are also encoded in the query, those should be described explicitly.  But IMHO that doesn't make sense: in _this_ context, these are just decimal numbers of arbitrary precision, and how many bytes they are, or whether any particular number references a block or just a single number, is not something that should be mentioned in the examples.

Point B:

Section 6 appears to be confusing presentation and representation.  A client might well present a UI that shows U-labels, but use A-labels on the back end.  The text as written here really doesn't make sense.  What are you trying to say?  I think that you shouldn't confuse what's presented to the user with what's sent on the wire.  Possibly this is related to the confusion over A-labels and U-labels that I called out in Point 2 of the discuss.

[Ballot discuss]
-- Section 3.2.1 --
None of the syntaxes begin with "/", and then you have a examples that do.  Probably should take the "/" off the examples, no?  But I see that the json-response document also uses the leading slash.  But but, the bootstrapping document says that the URLs MUST end with slashes, because query specifications are appended to them (therefore the query specifications don't begin with slashes).  This all seems somewhat inconsistent.

[Ballot comment]
-- Section 1.1 --
You have some repetition repetition in the definition of REST.

I suggest adding a little to the definition of IDNA, to make it clear that it's not just a handy abbreviation, but a pointer to something specific: "Internationalized Domain Names in Applications, a protocol for the handling of IDNs."

Also, some of these terms (such as NFC and NFKC) have references where they're used down below.  It wouldn't be a bad idea to cite those references up here as well.

-- Section 3 --

  Queries are
  formed by retrieving the appropriate base URL from the registry

This may seem picayune, but I think it should be "an appropriate base URL", not "the".  There may be more than one, and the bootstrap doc says that if one doesn't work, try another.  It also doesn't give any guidance on selecting from among multiple https URLs, or multiple http ones.

-- Section 3.1.3 --

  IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels;
  that is, all internationalized labels in an IDN SHOULD be either
  A-labels or U-labels.

You think the bit after the "that is" clarifies, but I don't.  I suggest that this does:
NEW
  IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels;
  that is, internationalized labels in an IDN SHOULD be either all
  A-labels or all U-labels.
END

-- Section 4.1 --

  Partial matching is not feasible across combinations of Unicode
  characters because Unicode characters can be combined with another
  Unicode character or characters.  Servers SHOULD NOT partially match
  combinations of Unicode characters where a Unicode character may be
  legally combined with another Unicode character or characters.  It
  should be noted, though, that it may not always be possible to detect
  possible cases where a character could have been combined with
  another character, but was not, because of the way combining
  characters can be combined with many other characters.

I'm not going to try to re-write that myself (don't try this at home!), and I did understand it... but I have to say that it's a truly convoluted paragraph.  Please see if you can say this and the subsequent paragraph in a different way without the "combined combining character characters with combined character combinations" feel to it.

[Ballot discuss]
= Section 3.2.3 =
If I'm reading the document correctly, when searching for an entity, the search pattern is expected to represent an entity using the syntax specified in Section 6.1 of draft-ietf-weirds-json-response. But when the path segment is provided, rather than a search, Section 3.1.5 says this:

  The  parameter represents an entity (such as a contact,
  registrant, or registrar) identifier whose syntax is specific to the
  registration provider.  For example, for some DNRs contact
  identifiers are specified in RFC 5730 [RFC5730] and RFC 5733
  [RFC5733].

This makes it seem as if an entity in a path segment uses different syntax (actually, non-standard syntax that is up to the registration provider) than an entity that someone might search for. Is there some specific field in the entity definition in draft-ietf-weirds-json-response that  is supposed to correspond to? Aren't HTTP GETs for both path segments and searches meant to provide responses based on the same underlying data? If so, I don't understand why there is a specified syntax for entities in one but not the other. This also seems inconsistent with the following text in Section 6.1 of draft-ietf-weirds-json-response:

  The entity object class appears throughout this document and is an
  appropriate response for the /entity/XXXX query defined in
  Registration Data Access Protocol Lookup Format
  [I-D.ietf-weirds-rdap-query]

[Ballot comment]
= Section 3 =
"The query URL is
  constructed by concatenating the base URL to the help path segment
  specified in either Section 3.1.6."

The "either" is extraneous, or there is some other section missing at the end of this sentence.

= Section 4.2 and Section 8:
I think it would be helpful here to point out that the identity/authorization of the searcher may be a relevant factor in determining how broad the response set should be for any particular query (and not just a single static policy that applies to all searchers equally).

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-weirds-rdap-query-15, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Registration Data Access Protocol Query Format) to Proposed Standard


The IESG has received a request from the Web Extensible Internet
Registration Data Service WG (weirds) to consider the following document:
- 'Registration Data Access Protocol Query Format'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-10-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Note that this document refers to draft-ietf-weirds-bootstrap. Last Call
for that document is coming soon, but review on this document can
be done at this time.

Abstract


  This document describes uniform patterns to construct HTTP URLs that
  may be used to retrieve registration information from registries
  (including both Regional Internet Registries (RIRs) and Domain Name
  Registries (DNRs)) using "RESTful" web access patterns.  These
  uniform patterns define the query syntax for the Registration Data
  Access Protocol (RDAP).




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Murray Kucherawy is the document shepherd.
Pete Resnick is the responsible Area Director.

2. Review and Consensus

This document received a good amount of the working group's attention throughout the life of the working group, and has also received some commentary from outside the working group.

It, along with the bootstrap document and the JSON response document, form the core of the RDAP protocol.  Notably, some of the external reviews included people heavily involved in the HTTP community (Mark Nottingham, Julian Reschke, discussing URI design) and lengthy discussion of such things as internationalized domain names (Andrew Sullivan, John Klensin).  There has been no formal review requested on those topics, but given the attention it got already, I am not concerned about a need to do so.

Security review is pending, though that will happen through the normal course of IETF Last Call via SECDIR, so it has not been explicitly requested.

There has been nothing unusual process-wise.  No appeals have been threatened.

3. Intellectual Property

The authors have affirmed that there are no known outstanding IPR matters with respect to this document.

4. Other Points

There are normative downward references to RFC1166 and RFC4290, which do not currently appear in the downref registry.

The RFC Editor should be advised that Appendix A is to be removed before publication.