JSON Responses for the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-json-response-14

[Ballot comment]
Thanks for adding suggested text to expand the privacy considerations section, this is very helpful.

Thanks for addressing the SecDir review and including information on a possible cache poisoning attack.
http://www.ietf.org/mail-archive/web/secdir/current/msg05183.html
Some nits were included as well that might be helpful.

[Ballot comment]

- I support Alissa's discuss point that jCard is too rich a
syntax and the specific jCard members intended to be used here
ought be specified and the spec should say to not use others.
The example on p18, with gender, dob, and other privacy
sensitive fields should be adjusted to not include such.

- I think it would have been a fine thing had the WG decided to
do a more comprehensive privacy analysis of RDAP but I don't
see that in this document set at least. I do like Kathleen's
suggested text better than that currently in the privacy
considerations section though.

- Figure numbers are used inconsisently, some examples have
them and, for no apparent reason, some don't. That needs
fixing. There's also a lack of clarity about the specification
style here - you need to be clearer as to what is just and
example and what is not.

- p21, the list following the example contains items that were
not in the example - this is unclear writing. Are you saying
that the list is normative or not? If so, you need to say so.
If not, why go beyond the example? The same point applies to
the lots of other examples that follow.

- 10.2.X: there's a lot of stuff here that wasn't described. I
wouldn't be surprised if that causes interop problems.

[Ballot discuss]
Thanks for your work on this draft and including options for privacy protections.  I do support Alissa's discuss on the -sec draft and as such, my discuss here is specific to this draft and values set forth in it for privacy.  The general security and privacy considerations would be good to reference from one place.

I think it would help to have the explicit guidance or recommendations for privacy included directly in the privacy section.  While the example in the appendix is good, I'd prefer to see explicit recommendations for each of the relevant status codes from section 10.2.2.  How about something along the lines of the following:

Current Privacy Considerations section:
  This specification suggests status values to denote contact and
  registrant information that has been marked as private and/or has
  been redacted or obscured.  See Section 10.2.2 for the list of status
  values.  See Appendix A.1 on guidance to apply those values to
  contacts and registrants.

Suggested Privacy Considerations section:
  This specification suggests status values to denote contact and
  registrant information that has been marked as private and/or has
  been redacted or obscured.  See Section 10.2.2 for the complete list of status
  values.  A few of the status values indicate that there are privacy
  concerns associated with the object instance.  For the following status
  codes, the RECOMMENDED actions include:
      7. private - The object is not be shared in query responses, unless the
          user is authorized to view this information.
      8. redacted - The data has already been redacted, and may be returned
          in a response in the data redacted form.  This is a safer option to choose
          to prevent unauthorized access to associated object instances than marking
          them as private.
      9. obscured - The data has already been obscured, and may be returned in a
          response in the obscured form.  This option may reveal privacy sensitive
          information and should only be used when data sensitivity does not require
          a more protective option like "private" or "redacted".

  See Appendix A.1 or an example applying those values to
  contacts and registrants.

[Ballot comment]
Thanks for addressing the SecDir review and including information on a possible cache poisoning attack.
http://www.ietf.org/mail-archive/web/secdir/current/msg05183.html
Some nits were included as well that might be helpful.

[Ballot comment]
Point 1:

In 4.3:
  It is the job of the clients to determine line breaks, spacing and
  display issues for sentences within the character strings of the
  "description" array.  Each string in the "description" array contains
  a single complete division of human readable text indicating to
  clients where there are semantic breaks.

What do you mean by "semantic breaks"?  Paragraph breaks?  Sentence breaks?  Dependent clause breaks?  This doesn't make sense.  I'm not going to raise a discuss on it because I don't think it affects interoperability, but I have no idea how to implement a client to display this in a way that will make sense to the user.

Point 2:

A general question that occurred to me in reading 5.5, which also applies to 5.4: should you have some text talking about how the link member of a network or autnum object is generated?  Both networks and autnum objects, as I understand it, can be gotten by querying any number in the range they enclose.  But of course the link member isn't going to enumerate all the possible queries that could return the particular object containing that link member.  So how is the value that's returned chosen?  Is it the lowest number in the range?  The number that was used in the query that returned the object?  Some other number?

I don't think you need to change anything, but it might be worth discussing this in sections 5.4 and 5.5.

[Ballot comment]
In section 9 it might be worth saying a few more words about how responses can be truncated.  Until I saw the example, I was thinking that the JSON itself might be incomplete.  The example made me realise that you're talking about limiting what is returned, not actually truncating what used to be a complete response.  I'm OK with referring to it as "truncated", but I'd like to see just a little explanation of the situations you're talking about, so it's clear you don't just mean snipping it in the middle.

[Ballot discuss]
I think this document is missing a discussion of the fact that while jCard was selected as the format for entity representation because it can flexibly accommodate the spectrum of the kinds of entities that require representation in RDAP, the full jCard specification includes many fields that are unrelated to the uses of the RDAP protocol and therefore not expected to be stored or made available by servers. This is a different point than the point made in Appendix A.1 (which should really be in Section 14 IMO) about the use of status values, which implies that the fields exist in the server-side database but are not shared in certain circumstances.

[Ballot comment]
= Section 3.2 =
I love an idiom as much as the next person, but it would be better to use names in examples that are not culturally specific.

= Section 4 =
The reference to I-D.ietf-jcardcal-jcard should be replaced with RFC 7095, I think.

= Section 6.1 =
Following on from my DISCUSS, I know the example in this section is just an example, but it includes all kinds of information about Joe User that no registry should be asking for and no registrant should willingly provide (gender? anniversary? really?!). It would be nice for the example to reflect what reality might/should actually be like.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-weirds-json-response-10.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about one of the actions requested in the IANA Considerations Section of this document.

IANA understands that, upon approval of this document, there are two actions which must be completed.

First, in the application media types registry located at:

https://www.iana.org/assignments/media-types/

a new media type will be registered as follows:

Name: rdap+json
Template: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the "RDAP JSON Values" registry.
The new registry is to be managed via Expert Review as defined in RFC 5226.
IANA understands that the authors would like to have the following fields for each registration:

Value
Type
Description
Registrant Name
Registrant Contact Information

As per Pete Resnick's reply in a separate message, IANA  will create a brand new
category called "Registration Data Access Protocol (RDAP)" and be added to
http://www.iana.org/protocols. 

QUESTION: Should this new registry "RDAP JSON Values" a stand alone registry with
its own new URL under this new category "Registration Data Access Protocol (RDAP)"? 
Or, is  "RDAP JSON Values" a sub-registry of that new created registry "Registration
Data Access Protocol (RDAP)"?  IANA suggests that this draft should clearly define
the new name space/location and category.

There are 49 (forty-nine) initial registrations in the new sub-registry "RDAP JSON
Values" as follows:

Value: result set truncated due to authorization
Type: notice and remark type
Description: The list of results does not contain all results due to lack of authorization. This may indicate to some clients that proper authorization will yield a longer result set.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: result set truncated due to excessive load
Type: notice and remark type
Description: The list of results does not contain all results due to excessively heavy load on the server. This may indicate to some clients that requerying at a later time will yield a longer result set.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: result set truncated due to unexplainable reasons
Type: notice and remark type
Description: The list of results does not contain all results for an unexplainable reason. This may indicate to some clients that requerying for any reason will not yield a longer result set.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: object truncated due to authorization
Type: notice and remark type
Description: The object does not contain all data due to lack of authorization.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: object truncated due to excessive load
Type: notice and remark type
Description: The object does not contain all data due to excessively heavy load on the server. This may indicate to some clients that requerying at a later time will yield all data of the object.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: object truncated due to unexplainable reasons
Type: notice and remark type
Description: The object does not contain all data for an unexplainable reason.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: validated
Type: status
Description: Signifies that the data of the object instance has been found to be accurate. This type of status is usually found on entity object instances to note the validity of identifying contact information.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: renew prohibited
Type: status
Description: Renewal or reregistration of the object instance is forbidden.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: update prohibited
Type: status
Description: Updates to the object instance are forbidden.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: transfer prohibited
Type: status
Description: Transfers of the registration from one registrar to another are forbidden. This type of status normally applies to DNR domain names.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: delete prohibited
Type: status
Description: Deletion of the registration of the object instance is forbidden. This type of status normally applies to DNR domain names.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: proxy
Type: status
Description: The registration of the object instance has been performed by a third party. This is most commonly applied to entities.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: private
Type: status
Description: The information of the object instance is not designated for public consumption. This is most commonly applied to entities.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: redacted
Type: status
Description: Some of the information of the object instance has not been made available. This is most commonly applied to entities.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: obscured
Type: status
Description: Some of the information of the object instance has been altered for the purposes of not readily revealing the actual information of the object instance. This is most commonly applied to entities.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: associated
Type: status
Description: The object instance is associated with other object instances in the registry. This is most commonly used to signify that a nameserver is associated with a domain or that an entity is associated with a network resource or domain.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: active
Type: status
Description: The object instance is in use. For domain names, it signifies that the domain name is published in DNS. For network and autnum registrations it signifies that they are allocated or assigned for use in operational networks. This maps to the Extensible Provisioning Protocol (EPP) [RFC5730] 'OK' status.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: inactive
Type: status
Description: The object instance is not in use. See 'active'.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: locked
Type: status
Description: Changes to the object instance cannot be made, including the association of other object instances.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: pending create
Type: status
Description: A request has been received for the creation of the object instance but this action is not yet complete.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: pending renew
Type: status
Description: A request has been received for the renewal of the object instance but this action is not yet complete.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: pending transfer
Type: status
Description: A request has been received for the transfer of the object instance but this action is not yet complete.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: pending update
Type: status
Description: A request has been received for the update or modification of the object instance but this action is not yet complete.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: pending delete
Type: status
Description: A request has been received for the deletion or removal of the object instance but this action is not yet complete. For domains, this might mean that the name is no longer published in DNS but has not yet been purged from the registry database.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: registration
Type: event action
Description: The object instance was initially registered.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: reregistration
Type: event action
Description: The object instance was registered subsequently to initial registration.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: last changed
Type: event action
Description: An action noting when the information in the object instance was last changed.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: expiration
Type: event action
Description: The object instance has been removed or will be removed at a pre-determined date and time from the registry.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: deletion
Type: event action
Description: The object instance was removed from the registry at a point in time that was not pre-determined.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: reinstantiation
Type: event action
Description: The object instance was reregistered after having been removed from the registry.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: transfer
Type: event action
Description: The object instance was transferred from one registrant to another.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: locked
Type: event action
Description: The object instance was locked (see the 'locked' status).
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: unlocked
Type: event action
Description: The object instance was unlocked (see the 'locked' status).
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: registrant
Type: role
Description: The entity object instance is the registrant of the registration. In some registries, this is known as a maintainer.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: technical
Type: role
Description: The entity object instance is a technical contact for the registration.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: administrative
Type: role
Description: The entity object instance is an administrative contact for the registration.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: abuse
Type: role
Description: The entity object instance handles network abuse issues on behalf of the registrant of the registration.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: billing
Type: role
Description: The entity object instance handles payment and billing issues on behalf of the registrant of the registration.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: registrar
Type: role
Description: The entity object instance represents the authority responsible for the registration in the registry.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: reseller
Type: role
Description: The entity object instance represents a third party through which the registration was conducted (i.e. not the registry or registrar).
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: sponsor
Type: role
Description: The entity object instance represents a domain policy sponsor, such as an ICANN approved sponsor.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: proxy
Type: role
Description: The entity object instance represents a proxy for another entity object, such as a registrant.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: notifications
Type: role
Description: An entity object instance designated to receive notifications about association object instances.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: noc
Type: role
Description: The entity object instance handles communications related to a network operations center (NOC).
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: registered
Type: domain variant relation
Description: The variant names are registered in the registry.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: unregistered
Type: domain variant relation
Description: The variant names are not found in the registry.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: registration restricted
Type: domain variant relation
Description: Registration of the variant names is restricted to certain parties or within certain rules.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: open registration
Type: domain variant relation
Description: Registration of the variant names is available to generally qualified registrants.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org

Value: conjoined
Type: domain variant relation
Description: Registration of the variant names occurs automatically with the registration of the containing domain registration.
Registrant Name: IESG
Registrant Contact Information: iesg@ietf.org


IANA understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (JSON Responses for the Registration Data Access Protocol (RDAP)) to Proposed Standard


The IESG has received a request from the Web Extensible Internet
Registration Data Service WG (weirds) to consider the following document:
- 'JSON Responses for the Registration Data Access Protocol (RDAP)'
  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.

Abstract


  This document describes JSON data structures representing
  registration information maintained by Regional Internet Registries
  (RIRs) and Domain Name Registries (DNRs).  These data structures are
  used to form Registration Data Access Protocol (RDAP) query
  responses.




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

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/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 fair amount of the working group's attention throughout the life of the working group, and has also received a small amount of commentary from outside the working group.

It, along with the Using HTTP document and the JSON response document, form the core of the RDAP protocol.  Notably, there has been lengthy discussion of such things as internationalized domain names (Andrew Sullivan, John Klensin) and I18N in general.  There has been no formal review requested on that topic, 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 exist a handful of prototype implementations based on this document, so there's running code.

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

3. Intellectual Property

Andy Newton affirmed that there are no known outstanding IPR matters with respect to this document, and understand they have been operating under BCP 78/79 all along.  I expect Scott Hollenbeck to similarly affirm at any time.

4. Other Points

There is a normative downward reference to RFC1166, which does not currently appear in the downref registry.