Subject: [Gen-art] Gen-ART review of draft-salgueiro-vcarddav-kind-device-06

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 30 Nov 2012 08:50:37 -0600

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-salgueiro-vcarddav-kind-device-06
Reviewer: Vijay K. Gurbani
Review Date: Nov-30-2012
IETF LC End Date: Dec-26-2012
IESG Telechat date: Unknown

This document is ready as a Proposed Standard.

Major: 0
Minor: 0
Nits: 2

Nits:

1/ S1: The value "thing" sort of creeps up on you in the second
  paragraph.  Upon further reading, it becomes more apparent that
  during the WG discussions "thing" was a meta-value (or super-
  class) and that "application" and "device" appear to be sub-
  classes (or specific values) of "thing"s.

  Furthermore, rf6473 already defined "application" and that this
  particular draft is now defining "device".

  To better impart this information, I would suggest the following
  simple modification

  OLD:
  ...Working Group defined values of "individual", "org", "group", and
  "location" for the KIND property.  Additionally, [RFC6473] has
  defined a value of "application" for the KIND property to represent
  software applications.

  During working group discussion of the document that became
  [RFC6473], consideration was given to defining a more general value
  of "thing", but it was decided to split "thing" into software
  applications and hardware devices and to define only the
  "application" value at that time....

  NEW:
  ...Working Group defined values of "individual", "org", "group", and
  "location" for the KIND property.

  During working group discussion of the document that became
  [RFC6473], consideration was given to defining a more general value
  of "thing", but it was decided to split "thing" into software
  applications and hardware devices and to define only the
  "application" value at that time....

2/ S2, top of page 4: "FN" probably expands to "Full Name".  If it is
  an accepted practice to use "FN" in your domain, then you can leave
  it unexpanded.  If not, then an expansion may help the general reader
  (like me) who may think what "FN" is.  (The rest of the properties
  listed on page 4 and 5 appear to be self-explanatory).

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Fri, 30 Nov 2012 11:27:12 -0500

Vijay - 

Good to hear from you, my friend. Hope you are well.

Thanks for the detailed review. As for your two nits:

1. I'm fine with the suggested edit and will update the next version (after IETF LC) with the suggested changes.

2. FN is a well-known identification property for vCards and does expand to "Full Name". Even in RFC 6350 it doesn't appear to be expanded, so I'll likely continue that trend and simply add a reference section 6.2.1 of RFC 6350 after the usage of FN to help the uninitiated in vCards.  Is that OK with you?

Cheers,

Gonzalo

---

From: Joe Marcus Clarke <[email-masked]>
Date: Fri, 30 Nov 2012 11:30:40 -0500

> 1. I'm fine with the suggested edit and will update the next version (after IETF LC) with the suggested changes.

++

> 2. FN is a well-known identification property for vCards and does expand to "Full Name". Even in RFC 6350 it doesn't appear to be expanded, so I'll likely continue that trend and simply add a refer…

FN is a property name, so I think we should leave it as-is.  Since we
already reference 6350, and we don't annotate each property, do we need
another ref?  I think those in the vCard domain will recognize FN.
Thoughts?

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Fri, 30 Nov 2012 11:37:37 -0500

> another ref?  I think those in the vCard domain will recognize FN.

I'm certainly OK without the specific reference to FN (as that is what is there now). It was suggested as an aid for casual readers since Vijay mentioned that FN was the only property that wasn't immediately understood.  I'm good either way.

Cheers,

Gonzalo

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 30 Nov 2012 10:40:13 -0600

Gonzalo: Please see inline.

On 11/30/2012 10:27 AM, Gonzalo Salgueiro wrote:
> 1. I'm fine with the suggested edit and will update the next version
> (after IETF LC) with the suggested changes.
>
> 2. FN is a well-known identification property for vCards and does
> expand to "Full Name". Even in RFC 6350 it doesn't appear to be
> expanded, so I'll likely continue that trend and simply add a
> reference section 6.2.1 of RFC 6350 after the usage of FN to help the
> uninitiated in vCards.  Is that OK with you?

That sounds good.  Thanks for attending to my comments.

Cheers,

- vijay

---

From: Joe Marcus Clarke <[email-masked]>
Date: Fri, 30 Nov 2012 11:41:24 -0500

On 11/30/12 11:37 AM, Peter Saint-Andre wrote:
> Hi Vijay and Gonzalo,
> 
> Agreed, that change in the introduction makes sense.
> 
> As to FN, how about this?
> 
> OLD
>    o  The device itself (e.g., the FN property might represent the 
>       hostname of a computing device, the URL property might represent a
>       website that contains details on where to find documentation or
>       get further information about the device, the KEY property might
>       represent a digital certificate that was provisioned into the 
>       device at the time of manufacture [IEEE.802.1AR], or a public key 
>       certificate previously provisioned into the device, and the ADR,
>       GEO, and TZ properties might represent the physical address,
>       geographical location, and timezone where the device is deployed).
> 
> NEW
>    o  The device itself. For example, the FN ("full name") property
>        ([RFC6250, section 2.1) might represent the hostname of a computing
>        device, the URL property might represent a website that contains
>        details on where to find documentation or get further information
>        about the device, the KEY property might represent a digital
>        certificate that was provisioned into the device at the time of
>         manufacture [IEEE.802.1AR], or a public key certificate previously
>        provisioned into the device, and the ADR, GEO, and TZ properties
>        might represent the physical address, geographical location, and
>        timezone where the device is deployed.

While I think you mean 6350 :-) I wonder do we need this reference?  We
don't do the same for ADR, GEO, and TZ below.  I don't mind the
parenthetical expansion.  Would that not be sufficient?

Joe

> 
> Peter
> 
> On Nov 30, 2012, at 9:27 AM, Gonzalo Salgueiro wrote:
> 
>> Vijay - 
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 30 Nov 2012 09:37:03 -0700

Hi Vijay and Gonzalo,

OLD

NEW

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 30 Nov 2012 09:49:07 -0700

I think only the expansion is fine. And yes, 6350. Typing too fast. :)

---

From: Joe Marcus Clarke <[email-masked]>
Date: Fri, 30 Nov 2012 11:54:57 -0500

> I think only the expansion is fine. And yes, 6350. Typing too fast. :)

Cool.  So:

OLD

NEW
       might represent the hostname of a computing
        manufacture [IEEE.802.1AR], or a public key certificate
previously

Joe

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 30 Nov 2012 11:17:20 -0600

On 11/30/2012 11:12 AM, Pete Resnick wrote:
[...]
> Do I understand correctly that you simply want to delete the sentence,
> "Additionally, [RFC6473] has defined a value of "application" for the
> KIND property to represent software applications."?

Pete: Yes.

> I can put the two changes (this one, and the one suggest by PSA as
> edited by Joe) in the RFC Editor notes of the tracker for the moment.
> Who know, maybe a miracle will occur and these will be the only changes
> between Last Call and IESG Evaluation. :-)

Thanks,

- vijay

---

From: Pete Resnick <[email-masked]>
Date: Fri, 30 Nov 2012 11:12:53 -0600

pr

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