Re: [apps-discuss] APPSDIR review of draft-salgueiro-vcarddav-kind-device-03

[Gonzalo Salgueiro <[e-mail]>]

Larry - 

Thanks for the detailed review. We have posted a new version of the document addressing these nits and the diffs can be found here:

http://www.ietf.org/rfcdiff?url2=draft-salgueiro-vcarddav-kind-device-04

Some comments inline...

On Nov 24, 2012, at 10:12 AM, Larry Masinter wrote:

> (resend)
> I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
> 
> Please resolve these comments along with any other comments you  may receive.  Please wait for direction from your document shepherd or AD before posting a new version of the draft.
> 
> Document: draft-salgueiro-vcarddav-kind-device-03
> Title: vCard KIND:device
> Reviewer: Larry Masinter 
> Review Date: 24 Nov 2012 
> Summary: The document is almost ready for publication as a Proposed Standard. Some clarification and design rationale would be quite helpful.
> 
> Major Issues: none
> Minor Issues/Nits:  
> 
> I had trouble between "Minor issues" or "Nits" for many of these, so I put them together. I don't feel strongly about any of them, if the authors are confident that anyone steeped in vCard and LDAP wouldn't have the same issues.
> 
> =================================
> 1. use cases (definitely NIT)
>> use cases for device   vCards have emerged
> Are these documented somewhere else?  A few more examples would be helpful. 
> ================================

While this is more of a high-level registration draft and others will follow detailing specific use cases, we did add some clarifying text related to the motivating use-cases for this registration.
> 
> 2. LDAP / X.521 alignment, nature of devices  (NIT)
> 
>> In this context, the concept of a device is constrained to computing
>>  devices and thus is distinct from purely mechanical devices such as
>>  elevators, electric generators, etc. that cannot communicate in any
>>  way over a network.
> 
> Why not allow mechanical devices such as elevators, electric generators, or gas and electric meters?

This was a line in the sand that came out of discussions on the mailing list around intended scope. We have tried to be clear here about what is in and what is out-of-scope.  We did add a bit of text refining the scope based on your comment.

> Wouldn't compatibility with LDAP be useful?

We're using the LDAP definition of 'device' as a base and refining that based on mailing list conversations. For example, we're including virtual devices but omitting mechanical devices that are not naturally networked. 
> 
> Is there a need to distinguish between network elements (routers) and appliances and light switches? 

No, not in this context. We want to keep KIND:device generic such that we don't distinguish between a router vCard and a network sensor or a light switch. 

> Between physical objects and virtual objects that do not have a distinct physical location?

Again, both are valid and we don't want to distinguish between the two. 
> 
>>  Although it might be desirable to define a more fine-grained taxonomy
>>  of devices (e.g., a KIND of "device" with a subtype of "router" or 
>>  "computer"), such a taxonomy is out of scope for this document
> 
> "out of scope" is a convenient but frustrating label for "we decided not to do it".  As a spec author/editor it's great; for a reader it isn't so great. Some more elaboration "There were no compelling use cases for such a distinction, and advantages to not making distinctions where some use cases straddled the categories." (if that's a reason) might be more satisfactory.

I absolutely get your point but the intent here was simply to properly position this document as purely a simple registration document (paralleling RFC 6473) and not one that dives into detail on specific use-cases.  As I mentioned, other documents expounding on specific use cases and their related taxonomy are sure to follow (though I obviously don't want to make reference to such potential outcomes).
> 
> ========================================
> 3. Devices "containing" vCards, normative language around it (MINOR)
> 
> " A device MAY contain..."
> The "contain" relationship is unspecified. How are these vCards discovered and accessed in a "device"?  I can see saying that a device "has" one or more vCards and being explicit that discovery and access are unspecified? If a 2D barcode is affixed to the device and used to retrieve the vCards associated with it, is that in scope?  
> My concern is over the normative language "MAY" for a relationship that is unspecified.
> 
> 
>> When a device contains vCards other than its KIND:device vCard, those
>> vCards MUST be linked together with RELATED (see the definition of
>>  the RELATED organizational property in Section 6.6.6 of [RFC6350]).
> 
> Since 'contain' is unspecified, the scope of this advice (and thus the MUST requirement) is unclear. Even if you define "contain", isn't this a SHOULD?

I see your point. Text was amended to reflect address this feedback.
> 
> ===================================================
> 4. Use of RELATED for devices (NIT)
> 
> The values for RELATED in RFC 6350 
> 
>                     "contact" / "acquaintance" / "friend" / "met"
>                        / "co-worker" / "colleague" / "co-resident"
>                        / "neighbor" / "child" / "parent"
>                        / "sibling" / "spouse" / "kin" / "muse"
>                        / "crush" / "date" / "sweetheart" / "me"
>                        / "agent" / "emergency"
> 
> don't seem to match device relationships (robot love?). Perhaps some more examples of RELATED use or advice here would help?

The example included in this draft uses a value of "contact" and other values such as parent, child, etc. could be used as well. My preference is to not go down the rat hole of providing guidance on the usage of RELATED within this registration draft.
> 
> =========================
> 5. Example unexplained (MINOR)
> 
> Section 4, the Example is not explained! Lots of the example is mysterious to me. Please annotate the example with a description of what it means and why.

Text was updated to address this.

Cheers,

Gonzalo

> 
>