Subject: [weirds] Last Call: <draft-ietf-weirds-using-http-13.txt> (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 10 Oct 2014 15:22:07 -0700

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)'
  <draft-ietf-weirds-using-http-13.txt> 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
[email-masked] mailing lists by 2014-10-24. Exceptionally, comments may be
sent to [email-masked] 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.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 17 Oct 2014 14:15:56 +0000

A few comments, mostly nits:

Comment 1
---------

Section 1.

##    The registration data expected to be presented by this service is
##    Internet resource registration data - registration of domain names
##    and Internet number resources.  These data is typically provided by

Nit: ''These data is'':
Perhaps - remove the ‘’The'' to start the paragraph and then ''Such data
are''
for the Nit. (Treat ‘’data'' consistently as singular or plural.)

Comment 2
---------

Section 3.

Nit: ''meant to return only one path of execution'' - perhaps ''follow one
path''?

Comment 3
---------

Section 5.6.

Nit: ''As the use of RDAP is for public resources'' is a judgement call.
Suggest
rewording as ''When RDAP is for public resources, a value of ‘*’. . .''

Comment 4
---------

Section 6.

Slight discomfort: I suppose this is not internationalizable given the
nature
of the programming tools being ASCII-based.  So no formal objection, but a
desire to allow identifiers to be able to break out of a ASCII-only set
''is
a pony I'd like to have.''

No suggested change, but curious ... if ...

Comment 5
---------

Section 7.

Nit: ''It does require the RDAP clients MUST support HTTPS.''
Nit: ''This document made'' should be ''This document makes''

Comment 6
---------

Section 8.1

Addition to third paragraph:

Suggestion: ''For documentation in other than the RFC series, IANA is
requested
to hold in escrow copies of the documentation.'' (This was needed for a DNS
RR type defined in an ATM Forum document.)

Comment 7

---------

Appendix B

Nit: ''this is unlikely to have any known side effects'' - suggest ''this
will be[/ought to be] compatible with the RDAP definition.''

---

From: Pete Resnick <[email-masked]>
Date: Fri, 17 Oct 2014 09:48:45 -0500

I'll leave the authors to respond on the nits; at first glance they all 
seem reasonable to address. On the two more substantive items:

> No suggested change, but curious ... if ...

Do note that the restriction described says SHOULD. To quote 2119, 
"there may exist valid reasons in particular circumstances to ignore a 
particular item, but the full implications must be understood and 
carefully weighed before choosing a different course." You *could* go 
look at http://www.unicode.org/reports/tr31/ about using Unicode in 
identifiers, or you could go look at the Identifier Class in the 
soon-to-be-released 
https://datatracker.ietf.org/doc/draft-ietf-precis-framework/, and then 
try to use one of these for your prefixes, but you had better fully 
understand what you are embarking on. :-)

> RR type defined in an ATM Forum document.)

This sounds like something that is not unique to this particular 
document (that is, any registry that uses "Specification Required" would 
have this issue), and might have weird copyright issues. I'm inclined 
*not* to put this in the IANA Considerations of this document, but 
rather mention this issue to IANA and/or IAB folks and let them work out 
a policy to deal with this on all registries that use "Specification 
Required", if that is needed.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Byron Ellacott <[email-masked]>
Date: Wed, 22 Oct 2014 00:33:59 +0000

Responses inline...

On 18/10/2014 12:15 am, "Edward Lewis" <[email-masked]> wrote:

>Perhaps - remove the Œ¹The'' to start the paragraph and then ''Such data
>are''
>for the Nit. (Treat Œ¹data'' consistently as singular or plural.)

Good catch.  I suspect "These data is" was meant to be "This data is",
using "data" as a collective noun.  I agree with removing 'The', but
personally prefer "This data is".

>Nit: ''meant to return only one path of execution'' - perhaps ''follow one

How would s/return/require/ work for you?  The notion is that a protocol
matching this design intent would not lead to clients having branching or
tree searching operations, so for me "follow one path" describes a client
behaviour more than a protocol expectation.

>rewording as ''When RDAP is for public resources, a value of Œ*¹. . .''

I agree with the premise of this nit.  The entire sentence then reads:

When RDAP is for public resources, a value of "*" is suitable for most
cases.

How about something a little less tortuous:

A value of "*" is suitable when RDAP is used for public resources.

>Nit: ''This document made'' should be ''This document makes''

=> "It does require that RDAP clients MUST support HTTPS."

And agree on made => makes.

>will be[/ought to be] compatible with the RDAP definition.''

How about we be more assertive:

"... this is compatible with the RDAP definition."

Thanks for looking over the doc closely!

-- 
bje

---

From: Edward Lewis <[email-masked]>
Date: Wed, 22 Oct 2014 11:12:20 +0000

As I’m a proven HTTP-in-email idiot and I think I can get away with this,
I’ll top post my answers.

Comment 1 - I’m as happy with data begin singular as well as plural, so long
as it’s consistent.  So, using the singular form is fine here.
Comment 2 - Yes, ‘require’ works.

For the rest - I agree with all of the offered fixes.

From:  Byron Ellacott <[email-masked]>
Date:  Tuesday, October 21, 2014 at 20:33
To:  Edward Lewis <[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, Andy Newton <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject:  Re: [weirds] Last Call: <draft-ietf-weirds-using-http-13.txt>
(HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed
Standard

>> Perhaps - remove the ¹The'' to start the paragraph and then ''Such data
>> are''
>> for the Nit. (Treat ¹data'' consistently as singular or plural.)
> 
>> rewording as ''When RDAP is for public resources, a value of *¹. . .''
>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 Oct 2014 23:41:05 -0700

>[email-masked] mailing lists by 2014-10-24. Exceptionally, comments may be

 From Section 1:

   "This document describes the usage of the Hypertext Transfer Protocol
    (HTTP) [RFC7230] for registration data directory services."

The title of the draft is "HTTP usage in the Registration Data Access 
Protocol (RDAP)".  I suggest aligning the title of the draft with 
what the document describes.

In Section 4.1:

   "Clients MUST support HTTPS as well as HTTP."

Why is this an absolute requirement?

Regards,
S. Moonesamy

---

From: Andy Newton <[email-masked]>
Date: Fri, 24 Oct 2014 13:19:06 +0000

>Why is this an absolute requirement?

Security mafia, IETF religion, NSA. Take your pick. But the scope of why
the IETF desires to have its protocols include security features is much
larger than this draft or working group. From a practical standpoint, most
client HTTP libraries support it so this does not seem burdensome to me.
And it is a client requirement, not a service operator requirement.

-andy

---

From: Andy Newton <[email-masked]>
Date: Fri, 24 Oct 2014 15:58:23 +0000

On 10/24/14, 9:28 AM, "S Moonesamy" <[email-masked]> wrote:

>I don't have a strong opinion about this.  I suggest having a short
>explanation (it could be a few words) for the "MUST".

What about a reference to the rdap-sec draft instead of a short
explanation?

-andy

---

From: S Moonesamy <[email-masked]>
Date: Fri, 24 Oct 2014 06:28:58 -0700

Hi Andy,

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Fri, 24 Oct 2014 15:08:34 -0700

Hi Andy,
>What about a reference to the rdap-sec draft instead of a short

There is the following in draft-ietf-weirds-rdap-sec-09:

   "HTTP Over TLS [RFC2818] can be used as needed to
    provide protection against man-in-the-middle attacks.

and in Section 7 of this draft:

   "However, it does not restrict against the use of security
    mechanisms offered by the HTTP protocol.  It does require the RDAP
    clients MUST support HTTPS."

There is an inconsistency when I compare the two.  I prefer not to 
argue about that as it is Friday. :-)

I'll suggest the following:

    "Clients MUST implement HTTPS as well as HTTP to support security 
services."

Please ask someone to review the suggestion as it is not that good.

Regards,
S. Moonesamy