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

From: Alissa Cooper <[email-masked]>
Date: Mon, 1 Dec 2014 16:06:59 -0800

I reviewed the -12 of this document and it mostly looks good, but there are a couple of outstanding points:

* The first paragraph in Section 13 is redundant now, I think.

* I’m a little confused about the normative recommendation made in Section 13. It almost sounds as if you’re recommending a particular interpretation of “private,” “redacted,” and “obscured,” while being open to other interpretations. That doesn’t seem advisable, though — shouldn’t the interpretations of those values apply the same everywhere? It seems more like what you want to RECOMMEND is that if the data elements fit the interpretations of the status values, then those status values SHOULD be used.

* The example given for “obscured” is not quite what I was expecting, and seems like it could be confused for “redacted.” I would have thought “obscured” meant something more like you take an identifier that directly identifies an entity and replace it with a randomized identifier for that entity, or some such.

Thanks,
Alissa

On Oct 30, 2014, at 7:24 AM, Alissa Cooper <[email-masked]> wrote:

> On Oct 30, 2014, at 4:09 AM, Andy Newton <[email-masked]> wrote:
> 
>> 
>> On Oct 28, 2014, at 7:14 PM, Alissa Cooper <[email-masked]> wrote:
>> 
>>> ----------------------------------------------------------------------
>>> 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.
>> 
>> This is a good point.  Does inserting the following paragraph after the first paragraph in Section 5.1 address this?
>> 
>> The entity object class uses jCard [RFC7095] to represent contact information,
>> such as postal addresses, email addresses, phone numbers and names of 
>> organizations and individuals. Many of the types of information that can be
>> represented with jCard are unlikely to be used in RDAP, such as birthdays,
>> anniversaries, and gender.
> 
> s/are unlikely to be used/have no use/
> 
> Otherwise looks good.
> 
>> 
>> 
>>> ----------------------------------------------------------------------
>>> 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.
>> 
>> Agreed (though your section numbers are off).
> 
> Sorry about that, too many document reviews going on at once …
> 
> Thanks,
> Alissa
> 
>> 
>> Thanks.
>> 
>> -andy
> 
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Andy Newton <[email-masked]>
Date: Tue, 2 Dec 2014 10:54:49 +0000

From:  Alissa Cooper <[email-masked]>

>* The first paragraph in Section 13 is redundant now, I think.

Oops. Editing mistake.

>
>* I¹m a little confused about the normative recommendation made in
>Section 13. It almost sounds as if you¹re recommending a particular
>interpretation of ³private,² ³redacted,² and ³obscured,² while being open
>to other interpretations. That doesn¹t seem
> advisable, though ‹ shouldn¹t the interpretations of those values apply
>the same everywhere? It seems more like what you want to RECOMMEND is
>that if the data elements fit the interpretations of the status values,
>then those status values SHOULD be used.

Most of the new text in this section was given to us by Kathleen, which I
viewed as a recommended list of status values to use when appropriate and
a quick comparison of the privacy related status values (in case the
reader gets lost in the sea of status values listed in 10.2.2).

Maybe the last sentence in the first paragraph should be changed.

OLD
  For the following status codes, the RECOMMENDED actions include:

NEW
  The following status codes SHOULD be used to describe data elements
  of a response when appropriate:

>
>* The example given for ³obscured² is not quite what I was expecting, and
>seems like it could be confused for ³redacted.² I would have thought
>³obscured² meant something more like you take an identifier that directly
>identifies an entity and replace it
> with a randomized identifier for that entity, or some such.

The difference between redact and obscured in this context is the former
is removal of certain data. Checking my dictionary, I see that redact can
actually mean removal or obscuring of data. I¹d be willing to change the
status value to ³removed" or some other word for better clarity.

Your suggestion for obscured is different enough that it is probably
worthy of a separate status value to be used with ³private² or ³redacted².
Perhaps ³anonymized²?

-andy

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 2 Dec 2014 09:38:09 -0800

>  of a response when appropriate:

Works for me.

> worthy of a separate status value to be used with ³private² or ³redacted².

I think if you have private, removed, and obscured, you will have covered all the bases. Anonymity is difficult to achieve in practice, so I would stay away from "anonymized.”

Alissa