Subject: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 29 Oct 2014 14:43:42 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-weirds-json-response-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-weirds-json-response/

----------------------------------------------------------------------
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.

----------------------------------------------------------------------
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.

---

From: Andy Newton <[email-masked]>
Date: Thu, 30 Oct 2014 11:24:19 +0000

This sounds like a good idea to me. Thanks for the text.

I thought I included them. But I’ll circle back to that review for the nits. Thanks.

-andy

---

From: Edward Lewis <[email-masked]>
Date: Thu, 30 Oct 2014 15:16:16 +0000

I’m concerned that this discuss is trying to place policy into the protocol.
I’m not convinced it is, but I want to say something now rather than wait.

At a recent ICANN meeting there was a presentation of the coming RDAP
protocol and how it is a candidate to replace WhoIs.  One of the “selling
points” is that RDAP can support different policy settings, as opposed to
WhoIs which, though it’s simplicity supports just the one default policy.

The current text suggests status codes, which is fine.  Going beyond that to
“RECOMMEND” actions in response to the codes is too far for me because it is
not clear to me how this would enhance interoperability of implementations
while at the same time, “cementing” the status codes as having meaning.
Perhaps the document can mention that codes and their meanings need to be
defined, but I think being so detailed as this list is too far down the path
of pressing an assumed policy into the protocol.

From:  Kathleen Moriarty <[email-masked]>
Date:  Wednesday, October 29, 2014 at 17:43
To:  The IESG <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject:  [weirds] Kathleen Moriarty's Discuss on
draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT)

> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>

---

From: Edward Lewis <[email-masked]>
Date: Thu, 30 Oct 2014 17:23:15 +0000

From:  Kathleen Moriarty <[email-masked]>
Date:  Thursday, October 30, 2014 at 12:33
To:  Edward Lewis <[email-masked]>
Cc:  The IESG <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject:  Re: [weirds] Kathleen Moriarty's Discuss on
draft-ietf-weirds-json-response-11: (with DISCUSS and COMMENT)

>Could you recommend alternate text?  My objective wasn't to set
>policy, but rather to raise awareness on risks and privacy options as
>well as the ways in which the options could be used.   It could be
>very helpful to know what marking something one way or another means
>and what might be possible.  The policies actually implemented could
>differ between administrators.
>
>If the risks are made known, then decisions could be made.

I feel the current text is sufficient.

At most, guidance would be to define what the receiver of a particular
privacy status code should do (in reaction).  But I’m not even sure of
that.  This is needed in DNS, but the DNS protocol is entirely different
from RDAP so I can’t draw a useful analogy.

I’ll leave it to the imagination (to avoid a specific statement) that the
topic of what is to be released about a registration is a very wide-open
question even if you ignore the transport (RDAP or WhoIs or IRIS or RWhoIS
or …).  The expertise needed to hammer this out is likely external to the
IETF.

I guess the question is whether one RDAP “process” can support data for a
registry under one privacy model and a registry under a different privacy
model.  The implementation needs to know how to respond within each model,
but I don’t see that impacting the RDAP protocol exchange.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 30 Oct 2014 07:27:04 -0400

Thanks, Andy.  I'm glad the text was helpful.

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 30 Oct 2014 12:33:33 -0400

Hi Ed,

Thanks for raising your concern.

Thanks,
Kathleen

-- 

Best regards,
Kathleen