Subject: [Gen-art] Gen-ART review of draft-ietf-vcarddav-vcardrev

From: <[email-masked]>
Date: Fri, 8 Apr 2011 23:21:17 -0400

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-vcarddav-vcardrev
Reviewer:  Kathleen Moriarty
Review Date:  8 April 2011
IETF LC End Date:  11 April 2011
IESG Telechat date: (if known)

Summary:  The document is ready with nits.

Major issues:

Minor issues:

Nits/editorial comments:

Section 3.2, paragraph 2:
It reads as a 4 element list instead of 2, here is one option:
Change from: (space, ASCII decimal 32, or horizontal tab, ASCII decimal 9).
To:  (space (ASCII decimal 32) or horizontal tab (ASCII decimal 9)).

Section 5.2:
Consider changing from: The VALUE parameter is optional, and is used to identify the value
   type (data type) and format of the value.
To: The VALUE parameter is optional, used to identify the value
   type (data type) and format of the value.

Section 5.2:
Although it is a preference to have a comma before the last value in a list, the IETF prefers it according to the Gent-ART guidance.  The usage would also be consistent with the other comma separated lists in the document.
Change from: value lists except within the N, NICKNAME, ADR and CATEGORIES properties.
To: value lists except within the N, NICKNAME, ADR, and CATEGORIES properties.

Section 5.3:
Remove the comma in the first sentence, it is not necessary.

Section 5.5:
Comma is not necessary in the following sentence (only when the list has 3 or more values):
Its value is either a single small positive integer, or a pair of small positive integers separated by a dot.

Section 6.1.4:
Second paragraph of 'location' section
Change from:  All properties in an location
To:  All properties in a location

Iana-token section:
Change from:  A new value's specification document MUST
         specify which properties make sense for that new kind of vCard, and which do not.
To:  A new value's specification document MUST
         specify which properties make sense for that new kind of vCard and which do not.

Section 9:
Birthday, address, and phone information could be sensitive.  In the third bullet, you may want to protect certain information if required by regulations (country, state specific, and industry - FERPA for universities)
The cryptographic keys would just be the public key for the user in the card if it was shared.

---

From: Simon Perreault <[email-masked]>
Date: Sat, 09 Apr 2011 06:50:38 -0400

> To:  (space (ASCII decimal 32) or horizontal tab (ASCII decimal 9)).

Changed.

>     type (data type) and format of the value.

Changed.

> To: value lists except within the N, NICKNAME, ADR, and CATEGORIES properties.

Changed.

> Remove the comma in the first sentence, it is not necessary.

Removed.

> Its value is either a single small positive integer, or a pair of small positive integers separated by a dot.

Removed.

> To:  All properties in a location

Changed.

>           specify which properties make sense for that new kind of vCard and which do not.

Changed.

> The cryptographic keys would just be the public key for the user in the card if it was shared.

I'm sorry, I disagree with that. IETF protocols should not be concerned 
with local regulations [RFC2804].

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Sat, 9 Apr 2011 08:03:55 -0400

Simon,

I am fine with the changes.  The last is not a Gen-ART, but was put there for adding considerations to the security section.  I just meant that it should state that there may be privacy concerns with some of the information.  I listed the regulations to give examples, but not to have them entered into the document.  You mention the use of encryption for protection against spoofing, it would also be used for confidentiality in protecting privacy of the information.

Best regards,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Saturday, April 09, 2011 6:51 AM
To: Moriarty, Kathleen
Cc: [email-masked]; [email-masked]
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-vcarddav-vcardrev

Changed.

Changed.

Changed.

Removed.

Removed.

Changed.

Changed.

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Simon Perreault <[email-masked]>
Date: Mon, 11 Apr 2011 09:17:22 -0400

On 2011-04-09 08:03, [email-masked] wrote:
> The last is not a Gen-ART, but was put
> there for adding considerations to the security section.  I just
> meant that it should state that there may be privacy concerns with
> some of the information.  I listed the regulations to give examples,
> but not to have them entered into the document.  You mention the use
> of encryption for protection against spoofing, it would also be used
> for confidentiality in protecting privacy of the information.

I misunderstood your previous comment. I understand now. Sorry about
that. How about the following:

   o  vCards often carry information that can be sensitive (e.g.
      birthday, address, and phone information).  Although they have no
      inherent authentication or privacy, they can easily be carried by
      any security mechanism that transfers MIME objects with
      authentication or privacy (e.g.  S/MIME [RFC5751], OpenPGP
      [RFC4880]).  In cases where the privacy or authenticity of
      information contained in vCard is a concern, the vCard SHOULD be
      transported using one of these secure mechanisms.  The KEY
      property (Section 6.8.1) can be used to transport the public key
      used by these mechanisms.

Thanks,
Simon

---

From: <[email-masked]>
Date: Mon, 11 Apr 2011 09:42:19 -0400

Hi Simon,

Thank you for the update.  How about the following which slightly changes your proposed text:

   o  vCards often carry information that can be sensitive (e.g.
      birthday, address, and phone information).  Although vCards have no
      inherent authentication or privacy provisions, they can easily be carried by
      any security mechanism that transfers MIME objects to address
      authentication or privacy (e.g.  S/MIME [RFC5751], OpenPGP
      [RFC4880]).  In cases where the privacy or authenticity of
      information contained in vCard is a concern, the vCard SHOULD be
      transported using one of these secure mechanisms.  The KEY
      property (Section 6.8.1) can be used to transport the public key
      used by these mechanisms.

Thank you,
Kathleen

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: Monday, April 11, 2011 9:17 AM
To: Moriarty, Kathleen
Cc: [email-masked]; [email-masked]
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-vcarddav-vcardrev

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 11 Apr 2011 09:53:27 -0400

>       used by these mechanisms.

Perfect, thanks.

Simon