[weirds] Protocol Action: 'HTTP usage in the Registration Data Access Protocol (RDAP)' to Proposed Standard (draft-ietf-weirds-using-http-15.txt)

The IESG <iesg-secretary@ietf.org> Thu, 01 January 2015 23:18 UTC

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150101231810.31665.91285.idtracker@ietfa.amsl.com>
Date: Thu, 01 Jan 2015 15:18:10 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/LIEsviPPl315R3G531IbbQOSglg
Cc: weirds chair <weirds-chairs@tools.ietf.org>, weirds mailing list <weirds@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [weirds] Protocol Action: 'HTTP usage in the Registration Data Access Protocol (RDAP)' to Proposed Standard (draft-ietf-weirds-using-http-15.txt)

The IESG has approved the following document:
- 'HTTP usage in the Registration Data Access Protocol (RDAP)'
  (draft-ietf-weirds-using-http-15.txt) as Proposed Standard

This document is the product of the Web Extensible Internet Registration
Data Service Working Group.

The IESG contact persons are Pete Resnick and Barry Leiba.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/




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
   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. [AD Note: During AD Evaluation, the document was made
   even clearer that it is agnostic as to data format, though the WG
   still intends to concentrate on the JSON format in other docs.]


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

[weirds] Protocol Action: 'HTTP usage in the Regi… The IESG