vCard KIND:device
draft-salgueiro-vcarddav-kind-device-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-01-16
|
07 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-01-16
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-01-15
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-01-15
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-01-15
|
07 | (System) | IANA Action state changed to In Progress |
2013-01-15
|
07 | Cindy Morgan | State changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2013-01-15
|
07 | Cindy Morgan | IESG has approved the document |
2013-01-15
|
07 | Cindy Morgan | Closed "Approve" ballot |
2013-01-15
|
07 | Cindy Morgan | Ballot approval text was generated |
2013-01-15
|
07 | Pete Resnick | Ballot writeup was changed |
2013-01-15
|
07 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2013-01-15
|
07 | Gonzalo Salgueiro | New version available: draft-salgueiro-vcarddav-kind-device-07.txt |
2013-01-10
|
06 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2013-01-10
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Sam Weiler. |
2013-01-10
|
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-01-09
|
06 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2013-01-09
|
06 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2013-01-08
|
06 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-01-07
|
06 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2013-01-07
|
06 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-01-07
|
06 | Stephen Farrell | [Ballot discuss] Given that many devices today do not have a good s/w update regime and that there are many e.g. SCADA devices that are … [Ballot discuss] Given that many devices today do not have a good s/w update regime and that there are many e.g. SCADA devices that are found to be insecure when they are connected to the Internet, I'm not at all sure that this specification introduces no new security issues. I think you can fix this easily though, for example with text like that below. Or, we can argue about it:-) "At the time of writing many devices that might be described using this specification have no good way to update their software or firmware, and there are also many that are generally insecure but are being connected to the Internet in any case, e.g. in industrial control systems or home networks. Publication of information about such devices (e.g. firmware revisions and hostnames or addresses) can thus represent a significant threat by making it more likely that an existing vulnerability can be exploited more easily. While one would expect that software update schemes for such devices will be deployed in future and that the security of the devices themselves will also improve, implementers and deployers using this specification need to consider that vCards with device information are very likely to be more sensitive than other vCards for some time to come." You might well argue that such text is unlikely to have any good effect, and you'd have a case, but I do think we need to say something here in any case. It'd be even better if there were some relevant optional security mechanism that we could require be supported or used when these vCards are being transmitted or stored, but I'm not sure that that'd be appropriate. (If it were appropriate, I'd be all for it.) |
2013-01-07
|
06 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-01-06
|
06 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-01-05
|
06 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-01-04
|
06 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-01-04
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2013-01-03
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Vijay Gurbani |
2013-01-03
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Vijay Gurbani |
2013-01-03
|
06 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2013-01-02
|
06 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-12-27
|
06 | Barry Leiba | [Ballot comment] I saw that IANA misunderstood how to register the new property value, and that the authors have responded to that. This highlights the … [Ballot comment] I saw that IANA misunderstood how to register the new property value, and that the authors have responded to that. This highlights the need for IANA Considerations to be careful and exact; I suggest changing Section 4 as follows, to make sure it's clear to IANA (and anyone else who reads it) later: OLD The IANA is requested to add "device" to the registry of property values for vCard4. In conformance with Section 10.2.6 of [RFC6350], the registration is as follows, where the reference is to RFCXXXX. Value: device Purpose: The entity represented by the vCard is a computing device such as an appliance, computer, or network element. Conformance: This value can be used with the "KIND" property. Example: See Section 3 of RFCXXXX. NEW IANA is asked to add the following entry to the "vCard Property Values" registry table (http://www.iana.org/assignments/vcard-elements#property-values): +----------+----------+-----------------+ | Property | Value | Reference | +----------+----------+-----------------+ | KIND | device | [RFCXXXX] | +----------+----------+-----------------+ In conformance with Section 10.2.6 of [RFC6350], the registration template is as follows: Value: device Purpose: The entity represented by the vCard is a computing device such as an appliance, computer, or network element. Conformance: This value can be used with the "KIND" property. Example: See Section 3 of RFCXXXX. END |
2012-12-27
|
06 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2012-12-27
|
06 | Pete Resnick | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-12-27
|
06 | Pete Resnick | Ballot has been issued |
2012-12-27
|
06 | Pete Resnick | [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick |
2012-12-27
|
06 | Pete Resnick | Created "Approve" ballot |
2012-12-26
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-12-20
|
06 | Pearl Liang | IANA has reviewed draft-salgueiro-vcarddav-kind-device-06 and has the following comments: IANA has a question for this one. IANA understands that, upon approval of this document, there … IANA has reviewed draft-salgueiro-vcarddav-kind-device-06 and has the following comments: IANA has a question for this one. IANA understands that, upon approval of this document, there is a single IANA action which needs to be completed. In the vCard Properties subregistry of the vCard Elements registry located at: http://www.iana.org/assignments/vcard-elements/vcard-elements.xml a new vCard Property is to be registered as follows: Namespace: [ none specified ] Propoerty: DEVICE Reference: [ RFC-to-be ] Section 3 Currently the vCard Properties registry is maintained through expert review as defined in RFC 5226. IANA Question -> has the document been reviewed by the vCard Properties registry expert? IANA understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. |
2012-12-05
|
06 | Pete Resnick | Placed on agenda for telechat - 2013-01-10 |
2012-11-30
|
06 | Vijay Gurbani | Request for Last Call review by GENART Completed: Ready. Reviewer: Vijay Gurbani. |
2012-11-30
|
06 | Pete Resnick | Ballot writeup was changed |
2012-11-29
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2012-11-29
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2012-11-29
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sam Weiler |
2012-11-29
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sam Weiler |
2012-11-28
|
06 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (vCard KIND:device) to Proposed Standard The IESG … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (vCard KIND:device) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'vCard KIND:device' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-12-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). The file can be obtained via http://datatracker.ietf.org/doc/draft-salgueiro-vcarddav-kind-device/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-salgueiro-vcarddav-kind-device/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-11-28
|
06 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-11-28
|
06 | Amy Vezza | Last call announcement was changed |
2012-11-27
|
06 | Pete Resnick | Last call was requested |
2012-11-27
|
06 | Pete Resnick | Ballot approval text was generated |
2012-11-27
|
06 | Pete Resnick | State changed to Last Call Requested from AD Evaluation::AD Followup |
2012-11-27
|
06 | Pete Resnick | Last call announcement was generated |
2012-11-27
|
06 | Gonzalo Salgueiro | New version available: draft-salgueiro-vcarddav-kind-device-06.txt |
2012-11-27
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-11-27
|
05 | Gonzalo Salgueiro | New version available: draft-salgueiro-vcarddav-kind-device-05.txt |
2012-11-27
|
04 | Pete Resnick | State changed to AD Evaluation::Revised ID Needed from AD Evaluation::Point Raised - writeup needed |
2012-11-27
|
04 | Pete Resnick | State changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation |
2012-11-27
|
04 | Pete Resnick | Ballot writeup was changed |
2012-11-27
|
04 | Pete Resnick | Ballot writeup was generated |
2012-11-27
|
04 | Pete Resnick | Last call announcement was generated |
2012-11-26
|
04 | Joe Clarke | New version available: draft-salgueiro-vcarddav-kind-device-04.txt |
2012-11-17
|
03 | Pete Resnick | State changed to AD Evaluation from Publication Requested |
2012-11-08
|
03 | Pete Resnick | Write-up for draft-salgueiro-vcarddav-kind-device-03 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper … Write-up for draft-salgueiro-vcarddav-kind-device-03 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). Working Group Summary Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document? This document is an individual submission, however it has been discussed and reviewed on the VCARDDAV Working Group mailing list. There was detailed discussion of the "device" KIND along with the "application" KIND (already published as RFC 6473). Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? An informal last call was issued on the VCARDDAV Working Group mailing list. Some comments were received and the draft updated accordingly. The required expert review was requested and approval received via the mailing list. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Cyrus Daboo AD: Pete Resnick (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed this document and have found no nits or issues. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No additional reviews required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Authors have confirmed compliance with BCP's 78 & 79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures filed for this document. (9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? Comments from several participants in the VCARDDAV Working Group have been received and acted on promptly. Also, the concept of the new "device" KIND was discussed during the work on the "application" KIND (already published as RFC 6473), since it is similar in nature. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) There has not been any discontent voiced by anyone. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No ID nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. As per RFC 6350, vCard property values require approval of a designated expert. Such approval has been received fromt he designated expert. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary. No impact on other RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA section is correct. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No registry being setup. (19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language is used. I did verify the XML example as correct. |
2012-11-08
|
03 | Pete Resnick | Assigned to Applications Area |
2012-11-08
|
03 | Pete Resnick | State Change Notice email list changed to cyrus@daboo.name, gsalguei@cisco.com, jclarke@cisco.com, psaintan@cisco.com, draft-salgueiro-vcarddav-kind-device@tools.ietf.org |
2012-11-08
|
03 | Pete Resnick | Intended Status changed to Proposed Standard |
2012-11-08
|
03 | Pete Resnick | IESG process started in state Publication Requested |
2012-11-08
|
03 | Pete Resnick | Stream changed to IETF from None |
2012-09-28
|
03 | Joe Clarke | New version available: draft-salgueiro-vcarddav-kind-device-03.txt |
2012-04-17
|
02 | Gonzalo Salgueiro | New version available: draft-salgueiro-vcarddav-kind-device-02.txt |
2012-01-06
|
01 | (System) | New version available: draft-salgueiro-vcarddav-kind-device-01.txt |
2012-01-06
|
00 | (System) | New version available: draft-salgueiro-vcarddav-kind-device-00.txt |