HTTP Usage in the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-using-http-15

[Ballot comment]
Thanks for addressing my DISCUSS.

I am curious if someone went through this doc to make sure everything it says is consistent with the change to MUST use TLS in rdap-sec.

[Ballot comment]

- As I said on the sec draft, I see no reason why RDAP could
not only be defined for use with https URIs.

- 5.5 seems to conflict a bit with one of the notices defined
in the json-response draft where you say to do the same thing
in the payload. I don't think it's a big problem but could be
better to say which to use when.

- I'm also not sure the CORS thing is quite right if cookies
might get sent to the wrong places.

[Ballot comment]
-- Section 1 --

  2.  A client issues an HTTP (or HTTPS) query using GET [RFC7231].  As
      an example, a query for the network registration 192.0.2.0 might
      be

          http://example.com/rdap/ip/192.0.2.0

A small point, but, strictly speaking, that is not a query: it's a query URL.  The query is the full HTTP GET protocol.  So either put in the HTTP query, or make it "As an example, a query URL for...".  (The rdap-query document actually is careful to call them URLs every time.)

Another small point: in bullet 4 you expand the abbreviation "URL".  Good, but you've used "URL" twice, earlier in the document.  You should expand it the first time it's used.

-- Section 2 --
Yet another small point: I see that someone asked you to expand "SSAC".  Cool, but that now screams out for noting that it's a committee of ICANN (which then raises the question of whether ICANN should be expanded).  I'm going to duck and cover now, and just let you do what you think best here.

-- Section 3 --

  First, each query is meant to require only one path of execution to
  obtain an answer.  A response may contain an answer, no answer, or a
  redirect, and clients are not expected to fork multiple paths of
  execution to satisfy a query.

Do clients "satisfy" queries?  I thought that clients make them, and servers satisfy them.

-- Section 5.2 --

  For example, if the client sends

      http://serv1.example.com/weirds/domain/example.com

Again: strictly speaking, the client doesn't "send" that.  You could say, "if the client uses".

-- Section 5.3 --

  Clients
  MAY retry the query based on the respective response code.

What you probably want to say here is

NEW
  A client
  MAY retry the query if that is appropriate for the
  respective response code.
END

-- Section 9.1 --
Thank you!  It's always been my contention that IRIs are not part of wire protocol, and should never be sent around as IRIs.

[Ballot discuss]
= Section 5.6 =
"When responding to queries, it is RECOMMENDED that servers use the
  Access-Control-Allow-Origin header field, as specified by
  [W3C.CR-cors-20130129].  As the use of RDAP is for public resources,
  a value of "*" is suitable for most cases."

What is the use case for cross-site RDAP queries?

Also, I am confused by the claim in the second sentence. The message that I got from draft-ietf-weirds-rdap-sec and draft-ietf-weirds-json-response is that one of the motivations for using HTTP for RDAP was that its authentication features could be leveraged to provide tiered access to data on the server, such that some of the data would not be public but would be restricted to specific users (from draft-ietf-weirds-json-response, Appendix A.1: "In many use cases, it is necessary to hide or obscure the information of a registrant or contact due to policy or other operational matters."). So it seems like if cross-site requests are justified at all, there should be some text here explaining when that might be the case and when not.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-weirds-using-http-13.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

QUESTION: Should we create this registry at a new URL? If so, would "Registration Data Access Protocol (RDAP)" be an appropriate title for the webpage, and for a new category at http://www.iana.org/protocols?

IANA understands that there is a single action that is required to be completed upon approval of this document.

IANA will create a registry called "RDAP Extensions."  The new registry is to be managed via Specification Required, as defined in RFC 5226.

IANA understands that there are no initial registrations in the new registry. The authors have requested that the registry consist of the following information:

Extension Identifier     
Registry Operator             
Reference         
Contact     
Intended Usage

IANA understands that the creation of this new registry is the only action required 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:  (HTTP usage in 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:
- 'HTTP usage in 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.

Note that this is a second Last Call. During its initial IESG Evaluation,
the IESG had several issues to address. This document has addressed
those issues.

Note also 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 is one of a collection that together describe the
  Registration Data Access Protocol (RDAP).  It describes how RDAP is
  transported using the Hypertext Transfer Protocol (HTTP).  RDAP is a
  successor protocol to the very old WHOIS protocol.  The purpose of
  this document is to clarify the use of standard HTTP mechanisms for
  this application.




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

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


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

[This document has been through the IESG once before.  It is being resubmitted
since the IESG asked to review this document once the entire document set was
ready.  Olaf Kolkman was the previous document shepherd, and used the old writeup rather than the new one.  I have made only minor edits.  -MSK]

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

This intended to be Standards Track RFC, it is the normative
specification on how to use a Registration Data Access Protocol on top
of HTTP, hence Standards Track.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes the usage of HTTP for Registration Data
  Directory Services.  The goal of this document is to tie together
  usage patterns of HTTP into a common profile applicable to the
  various types of Directory Services serving Registration Data using
  RESTful practices.  By giving the various Directory Services common
  behavior, a single client is better able to retrieve data from
  Directory Services adhering to this behavior.

Working Group Summary:

During the development of the working group there has been a good
amount of review by multiple WG participants. There are no issues
remaining on the rough side of consensus and the document as a whole is
well carried by consensus.

This document is not contentious, but in the spirit of putting all
cards on the table: there is one point where it touches on an issue
that seems to be potentially create more discussion in the future and
that is the encapsulation format of the reply. The working is clearly
going for JSON although there are some that argue that XML might be
better suited for some deployments. This specification does allow,
just like the charter, a possibility for alternative reply
encapsulations. In other words, I do not see any problems for this
document.


Document Quality:

During the previous IETF there has been a demo of four or more implementations.
There have been explicit statements by others that they believe the
RFC is of sufficient detail to implement against. There is no
indication this document under-specifies any aspects.

There has not been a MIB, Media Type, DNS, or Security expert review
(at least not with those explicit hats).

Personnel:

Chairs: Murray Kucherawy and Olaf Kolkman
Shepherd: Murray Kucherawy
AD: Pete Resnick

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Olaf Kolkman reviewed version 03, 04 and 05 in detail. (The shepherd review
for 04 concluded that a few fixes where needed before submission.)

Murray Kucherawy did a detailed review of -11, resulting in -12.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document has an internationalization section (section 9). I know
that some of the folk in the working group have a background in
Internationalization issues and have reviewed the document. That said
the document identifies the issues only to be addressed in future
document that specify the rules for replies.

I am not an HTTP expert myself but I do not think that the
specification touched areas that are beyond the HTTP knowledge within
the working group.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

There are no specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

I have contacted all authors and they confirmed that there were no
disclosures that needed to be filed.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The WG Consensus is solid and carried by the whole group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

I have not heard discontent about this document.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

ID nits reports a downref. See further below.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The specification registers the "application/rdap+json" media type.
(section 8.2)

Review of the media type has been performed through the
media-types@iana.org list.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

This document refers to other WEIRDS documents.  We expect they will be
processed as a cluster.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

[RFC6839] is a downward reference.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

No, this document will neither obsolete nor update other documents.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

Consistency with Body: Confirm
Consistency extensions/Registries: Confirm (in 8.2)
Detailed spec for new registries: Confirm (in 8.1)
Procedure for future registration: Confirm (in 8.1)
Reasonable name: Confirm

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

There are no such registries. Only 'Specification Required'.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is one trivial ABNF specification in the document. It has been
checked using http://www.anfdata.cz/bnfparser2/

          ---------------RESULT---------------
          name = ALPHA *( ALPHA / DIGIT / "_" )

          [1] passed

[This document has been through the IESG once before.  It is being resubmitted
since the IESG asked to review this document once the entire document set was
ready.  Olaf Kolkman was the previous document shepherd, and used the old writeup rather than the new one.  I have made only minor edits.  -MSK]

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

This intended to be Standards Track RFC, it is the normative
specification on how to use a Registration Data Access Protocol on top
of HTTP, hence Standards Track.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes the usage of HTTP for Registration Data
  Directory Services.  The goal of this document is to tie together
  usage patterns of HTTP into a common profile applicable to the
  various types of Directory Services serving Registration Data using
  RESTful practices.  By giving the various Directory Services common
  behavior, a single client is better able to retrieve data from
  Directory Services adhering to this behavior.

Working Group Summary:

During the development of the working group there has been a good
amount of review by multiple WG participants. There are no issues
remaining on the rough side of consensus and the document as a whole is
well carried by consensus.

This document is not contentious, but in the spirit of putting all
cards on the table: there is one point where it touches on an issue
that seems to be potentially create more discussion in the future and
that is the encapsulation format of the reply. The working is clearly
going for JSON although there are some that argue that XML might be
better suited for some deployments. This specification does allow,
just like the charter, a possibility for alternative reply
encapsulations. In other words, I do not see any problems for this
document.


Document Quality:

During the previous IETF there has been a demo of four or more implementations.
There have been explicit statements by others that they believe the
RFC is of sufficient detail to implement against. There is no
indication this document under-specifies any aspects.

There has not been a MIB, Media Type, DNS, or Security expert review
(at least not with those explicit hats).

Personnel:

Chairs: Murray Kucherawy and Olaf Kolkman
Shepherd: Murray Kucherawy
AD: Pete Resnick

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Olaf Kolkman reviewed version 03, 04 and 05 in detail. (The shepherd review
for 04 concluded that a few fixes where needed before submission.)

Murray Kucherawy did a detailed review of -11, resulting in -12.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document has an internationalization section (section 9). I know
that some of the folk in the working group have a background in
Internationalization issues and have reviewed the document. That said
the document identifies the issues only to be addressed in future
document that specify the rules for replies.

I am not an HTTP expert myself but I do not think that the
specification touched areas that are beyond the HTTP knowledge within
the working group.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

There are no specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

I have contacted all authors and they confirmed that there were no
disclosures that needed to be filed.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The WG Consensus is solid and carried by the whole group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

I have not heard discontent about this document.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

ID nits reports a downref. See further below.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The specification registers the "application/rdap+json" media type.
(section 8.2)

Review of the media type has been performed through the
media-types@iana.org list.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

This document refers to other WEIRDS documents.  We expect they will be
processed as a cluster.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

[RFC6839] is a downward reference.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

No, this document will neither obsolete nor update other documents.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

Consistency with Body: Confirm
Consistency extensions/Registries: Confirm (in 8.2)
Detailed spec for new registries: Confirm (in 8.1)
Procedure for future registration: Confirm (in 8.1)
Reasonable name: Confirm

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

There are no such registries. Only 'Specification Required'.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is one trivial ABNF specification in the document. It has been
checked using http://www.anfdata.cz/bnfparser2/

          ---------------RESULT---------------
          name = ALPHA *( ALPHA / DIGIT / "_" )

          [1] passed

[This document has been through the IESG once before.  It is being resubmitted
since the IESG asked to review this document once the entire document set was
ready.  Olaf Kolkman was the previous document shepherd, and used the old writeup rather than the new one.  I have made only minor edits.  -MSK]

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

This intended to be Standards Track RFC, it is the normative
specification on how to use a Registration Data Access Protocol on top
of HTTP, hence Standards Track.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes the usage of HTTP for Registration Data
  Directory Services.  The goal of this document is to tie together
  usage patterns of HTTP into a common profile applicable to the
  various types of Directory Services serving Registration Data using
  RESTful practices.  By giving the various Directory Services common
  behavior, a single client is better able to retrieve data from
  Directory Services adhering to this behavior.

Working Group Summary:

During the development of the working group there has been a good
amount of review by multiple WG participants. There are no issues
remaining on the rough side of consensus and the document as a whole is
well carried by consensus.

This document is not contentious, but in the spirit of putting all
cards on the table: there is one point where it touches on an issue
that seems to be potentially create more discussion in the future and
that is the encapsulation format of the reply. The working is clearly
going for JSON although there are some that argue that XML might be
better suited for some deployments. This specification does allow,
just like the charter, a possibility for alternative reply
encapsulations. In other words, I do not see any problems for this
document.


Document Quality:

During the previous IETF there has been a demo of four or more implementations.
There have been explicit statements by others that they believe the
RFC is of sufficient detail to implement against. There is no
indication this document under-specifies any aspects.

There has not been a MIB, Media Type, DNS, or Security expert review
(at least not with those explicit hats).

Personnel:

Chairs: Murray Kucherawy and Olaf Kolkman
Shepherd: Murray Kucherawy
AD: Pete Resnick

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Olaf Kolkman reviewed version 03, 04 and 05 in detail. (The shepherd review
for 04 concluded that a few fixes where needed before submission.)

Murray Kucherawy did a detailed review of -11, resulting in -12.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document has an internationalization section (section 9). I know
that some of the folk in the working group have a background in
Internationalization issues and have reviewed the document. That said
the document identifies the issues only to be addressed in future
document that specify the rules for replies.

I am not an HTTP expert myself but I do not think that the
specification touched areas that are beyond the HTTP knowledge within
the working group.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

There are no specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

I have contacted all authors and they confirmed that there were no
disclosures that needed to be filed.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The WG Consensus is solid and carried by the whole group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

I have not heard discontent about this document.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

ID nits reports a downref. See further below.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The specification registers the "application/rdap+json" media type.
(section 8.2)

Review of the media type has been performed through the
media-types@iana.org list.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

This document refers to other WEIRDS documents.  We expect they will be
processed as a cluster.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

[RFC6839] is a downward reference.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

No, this document will neither obsolete nor update other documents.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

Consitency with Body: Confirm
Consistency extentions/Registries: Confirm (in 8.2)
Detailed spec for new registries: Confirm (in 8.1)
Procedure for future registration: Confirm (in 8.1)
Reasonable name: Confifm

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

There are no such registries. Only 'Specification Required'.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is one trivial ABNF specification in the document. It has been
checked using http://www.anfdata.cz/bnfparser2/

          ---------------RESULT---------------
          name = ALPHA *( ALPHA / DIGIT / "_" )

          [1] passed

IESG comments on this indicated that it would be better to wait until other WEIRDS documents before making the final call on this. Will put it back on the telechat at a later date.

[Ballot discuss]
I am satisfied with the response about the 404 status code, so I'm removing that from my DISCUSS position.

1. This point still has no response:

The registration of the application/rdap+json media type was removed in version -07, presumably to move it to the json-response document (which makes sense).  But there are examples here in Appendix A that still use that media type, with no definition in sight.  I'm not happy with that.

I would be happy with an informative reference to the document where that media type is defined, and, of course, and update to that draft, including it (the latest posted version, json-response-04, predates this change).  (An informative reference is OK, I think, because this is in an example.)

2. And discussion has highlighted that there's a serious issue with *not* having a normative reference from this document to the rdap-query document.  I can't see how it's possible for this document to make any sense at all and to have any use at all without rdap-query, and I don't see how we can reasonably evaluate this piece of the solution without understanding that piece along with it.

[Ballot discuss]
This document doesn't talk about security, which sort of makes sense considering the other weirds document we're reviewing in the same telechat.  However, I am concerned that there is a gap between the two documents that leaves open the possibility of password leakage.

Suppose I go to an RDAP server wanting some information that is confidential, and requires authentication.  Further suppose my request is to an http URL, not an https URL.

Presumably the RDAP server would tell me I need to authenticate, by sending an HTTP 401 response.  Suppose basic authentication is being used.  The server must first redirect me to an https server, which _then_ would send the 401 response.  If the response to the http query is 401, the client may send the password over the network in the clear, since this is allowed by the HTTP protocol.

In practice, I would expect that anything that needs to be authenticated is going to have to go over TLS anyway, so this should be straightforward to specify.

Possible responses to clear this DISCUSS would be (a) to point out that I am an idiot and this isn't a problem because I don't understand HTTP authentication properly (I know only enough to be dangerous, so this is a real possibility); (b) to argue that this needs to be fixed but should be addressed in the weirds-rdap-sec document and not in this document, or (c) to add some text to this document specifying how this should be done.  Currently neither document explicitly discusses the 401 response code.

[Ballot discuss]
This document doesn't talk about security, which sort of makes sense considering the other weirds document we're reviewing in the same telechat.  However, I am concerned that there is a gap between the two documents that leaves open the possibility of key leakage.

Suppose I go to an RDAP server wanting some information that is confidential, and requires authentication.  Further suppose my request is to an http URL, not an https URL.

Presumably the RDAP server would tell me I need to authenticate, by sending an HTTP 401 response.  Suppose basic authentication is being used.  The server must first redirect me to an https server, which _then_ would send the 401 response.  If the response to the http query is 401, the client may send the password over the network in the clear, since this is allowed by the HTTP protocol.

In practice, I would expect that anything that needs to be authenticated is going to have to go over TLS anyway, so this should be straightforward to specify.

Possible responses to clear this DISCUSS would be (a) to point out that I am an idiot and this isn't a problem because I don't understand HTTP authentication properly (I know only enough to be dangerous, so this is a real possibility); (b) to argue that this needs to be fixed but should be addressed in the weirds-rdap-sec document and not in this document, or (c) to add some text to this document specifying how this should be done.  Currently neither document explicitly discusses the 401 response code.

[Ballot comment]
(1) It seems like Section 4.1 could be made bit tighter.  There's not really a reason for clients not to send the specific RDAP JSON type in their Accept header.  So you could say that clients must send the RDAP-specific type (when requesting RDAP JSON); servers MAY accept others (e.g., application/json).

(2) In Section 5.2, do you want to recommend that the targets of redirects conform to the query syntax?  If not, it might be helpful to warn implementations that redirect targets might not have the standard query format.

(3) In Section 5.6, it would be helpful to provide some guidance on how the Access-Control-Allow-Origin header should be set.  It seems like most RDAP servers are going to be public resources, so the value "*" would be appropriate, at least as an example.

(4) The Security Considerations should point to draft-ietf-weirds-rdap-sec, since that provides the security mechanism for RDAP

[Ballot discuss]
updated ...

On .well-known point raised by Stephen ....  when EST came through the authors were told  by the appsdir reviewer that:

IETF standards should not define URIs or patterns of URIs, because servers may wish to provide other services (implying the possibility of collision), or deploy resources in an alternate way, for implementation or operational reasons.

This is a fundamental concept in the Web architecture; see .

Possible remedies include:

1) Specifying a "home document" format that links (in the RFC5988 sense) to the various resources as appropriate.
2) Specifying a well-known URI to root the interaction. Note that this is suboptimal; while it avoids collisions, it does not allow alternate deployments, or multiple deployments on the same host.

Why doesn't the same recommendation apply here?

[Ballot discuss]
I am not an international character set expert ...

This draft references RFC 3986 and RFC 3987 which in turn point to RFC 3490 (IDNA 2003) - what if anything needs to be said about RFC 5981 (IDNA 2008) (obsoletes RFC 3490)?

[Ballot comment]
Just checking but does a policy reason include unauthorized access?  draft-ietf-weirds-rdap-sec talks about anonymous access as well as authenticated access so I just want to make sure that's covered in all the Ifs in s1.

please expand: SSAC

[Ballot comment]
- The abstract and 1st two sentences (particularly the
2nd which I just don't get) of the intro are pretty
thoroughly confusing. I was so puzzled that I read the
abstracts of all 6 wg drafts and they are uniformly
uninformative. That doesn't seem like a useful feature
for abstracts. Sorry to be negative but its quite easy to
slip into "we all know what this is about" mode, and
forget that most readers will not have been active wg
participants, which may be the case here. I think
putting a bit of effort into improving the abstracts of the
weirds drafts would be a fine thing to do generally.
(The 2nd para of the intro however is just fine and does
tell me weirds is about.)

- intro: I wondered why you're not using ".well-known/ip"
in the first example but yet you don't say that a client
has to known the base URL from which to start.  How is a
client supposed to know to use a path of "/ip/192.0.2.0"
or "/weirds/ip/192.0.2.0"?

- Section 2: "Described in other documents" seems to
scream for references.

- 5.6: I don't get why CORS is needed here? Can you
explain? (Not sure if that needs to be in the doc, but
its not obvious to me.)

- section 7: Are there any security properties that ought
be checked in the event of a 3xx response? For example,
if https is used for the initial query, should it also be
used for the subsequent one? 

- overall: I was left wondering if this would not have
been better as a part of some other document with more
normative text, but I guess as long as the full set of
RFCs do the job that's ok.

[Ballot discuss]
Two small points, which shouldn't hold things up much:

1. Larry Masinter's AppsDir review notes an issue with using the HTTP 404 status code.  404 is meant to say that the URL you're asking for doesn't exist (or the server isn't willing to disclose that it exists).  The question is whether there's a useful distinction in RDAP between "you're querying about something that doesn't exist" and "you're querying about something that exists, but there's no information available about it."  If not, then 404 might be OK (it's altering the sense of 404 a little, though).  If so, though, there should be different status codes, and 404 belongs to the former.  Please discuss.

2. The registration of the application/rdap+json media type was removed in version -07, presumably to move it to the json-response document (which makes sense).  But there are examples here in Appendix A that still use that media type, with no definition in sight.  I'm not happy with that.

I would be happy with an informative reference to the document where that media type is defined, and, of course, and update to that draft, including it (the latest posted version, json-response-04, predates this change).  (An informative reference is OK, I think, because this is in an example.)

[Ballot comment]
It appears that Olaf is having a conversation about the rest of Larry's review, and I have every confidence that Good Stuff (tm) will come from that.

[Ballot comment]
I'm not completely comfortable about the use of 404 flagged in Larry Masinter's Applications Area Directorate review, but whatever you do to resolve Larry's comment will work for me, too.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-weirds-using-http-07.  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 the IANA action requested by the authors in this document.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

IANA understands that it is requested to create a new registry, the "RDAP Extensions Registry" and that the maintenance rule for this new registry will be Specification Required as defined in RFC 5226. However, IANA has some questions about the new registry.

Is the new registry a stand-alone registry on the IANA Matrix, or should it be a sub-registry of an existing registry?

The current document proposes a template for RDAP extension registration. Will the newly created registry capture all of the fields on the template, a subset, or different fields?

Are there initial registrations in the new RDAP Extensions Registry?

IANA understands that creation of the new RDAP Extensions Registry is the only action required of IANA 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:  (HTTP usage in 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:
- 'HTTP usage in 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 2013-07-29. 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 is one of a collection that together describe the
  Registration Data Access Protocol (RDAP).  It describes how RDAP is
  transported using the Hypertext Transfer Protocol (HTTP).




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

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


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

Shepherd writeup for draft-ietf-weirds-using-http-05.txt
Shepherd: Olaf Kolkman
$Id: draft-ietf-weirds-using-http-shepherd.txt,v 1.3 2013/05/20 13:01:38 olaf Exp $
--------------------------------------------------------------------------------


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

This intended to be Standards Track RFC, it is the normative
specification on how to use a Registration Data Access Protocol on top
of HTTP, hence Standards Track.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

[From the Introduction, the Abstract is a bit denser, but OK IMHO]

  This document describes the usage of HTTP for Registration Data
  Directory Services.  The goal of this document is to tie together
  usage patterns of HTTP into a common profile applicable to the
  various types of Directory Services serving Registration Data using
  RESTful practices.  By giving the various Directory Services common
  behavior, a single client is better able to retrieve data from
  Directory Services adhering to this behavior.


Working Group Summary:

During the development of the working group there has been a good
amount of review by multiple wg participants. There are no issues
arrived on the rough side of consensus and the document as a whole is
well carried by consensus.

This document is not contentious, but in the spirit of putting all
cards on the table: there is one point where it touches on an issue
that seems to be potentially create more discussion in the future and
that is the encapsulation format of the reply. The working is clearly
going for JSON although there are some that argue that XML might be
better suited for some deployments. This specification does allow,
just like the charter, a possiblilty for alternative reply
encapsulations. In other words, I do not see any problems for this
document.


Document Quality:

During the previous IETF there has been a demo of 4 implementations.
There have been explicit statements by others that they believe the
RFC is of sufficient detail to implement against. There is no
indication this document underspecifies aspects.

There has not been a MIB, Media Type, DNS, or Sucurity expert review
(at least not with those explicit hats)



Personnel:

Chairs: Murray Kuchewary and Olaf Kolkman
Shepherd: Olaf Kolkman
AD: Pete Resnick


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed version 03, 04 and 05 in detail. (The shepherd review
for 04 concluded that a few fixes where needed before submission)


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document has an internationalisation section (section 9). I know
that some of the folk in the working group have a background in
Internationalisation issues and have reviewed the document. That said
the document identifies the issues only to be addressed in future
document that specify the rules for replies.

I am not an HTTP expert myself but I do not think that the
specification touched areas that are beyond the HTTP knowledge within
the working group.


(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

There are no specific concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?


I have contacted all authors and they confirmed that there were no
disclosures that needed to be filed.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.


No IPR disclosures (reviewed Mon May 20 12:42:12 UTC 2013)


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The WG Consensus is solid and carried by the whole group.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)


I have not heard discontent about this document.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

ID nits reports a downref. See further below.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.


The specification registers the "application/rdap+json" media type.
(section 8.2)

Review of the media type has been performec through the
media-types@iana.org list.


(13) Have all references within this document been identified as
either normative or informative?

Yes.


(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?




(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

[RFC6839] is a downward reference.




(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

No, this document will obsolete nor update other documents.



(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

Consitency with Body: Confirm
Consistency extentions/Registries: Confirm (in 8.2)
Detailed spec for new registries: Confirm (in 8.1)
Procedure for future registration: Confirm (in 8.1)
Reasonable name: Confifm



(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

There are no such registries. Only 'Specification Required'


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is one trivial ABNF specification in the document. It has been
checked using http://www.anfdata.cz/bnfparser2/

          ---------------RESULT---------------
          name = ALPHA *( ALPHA / DIGIT / "_" )

          [1] passed