Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
draft-ietf-geopriv-held-identity-extensions-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2010-12-13
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2010-12-13
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2010-12-13
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2010-12-13
|
06 | (System) | IANA Action state changed to Waiting on Authors from On Hold |
2010-12-10
|
06 | (System) | IANA Action state changed to On Hold from In Progress |
2010-12-10
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2010-12-09
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2010-12-09
|
06 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2010-12-08
|
06 | (System) | IANA Action state changed to In Progress |
2010-12-08
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-12-08
|
06 | Amy Vezza | IESG has approved the document |
2010-12-08
|
06 | Amy Vezza | Closed "Approve" ballot |
2010-12-08
|
06 | Amy Vezza | Approval announcement text regenerated |
2010-12-08
|
06 | Robert Sparks | Ballot writeup text changed |
2010-12-07
|
06 | Dan Romascanu | [Ballot comment] Section 3.2 includes the following statement: The media access control (MAC) address used by the IEEE 802 family of access technologies … [Ballot comment] Section 3.2 includes the following statement: The media access control (MAC) address used by the IEEE 802 family of access technologies is an identifier that is assigned to a particular network Device. A MAC address is a unique sequence that is either assigned at the time of manufacture of a Device, or assigned by a local administrator. A MAC address rarely changes; therefore, a MAC address is an appropriate identifier for a Device. Actually MAC addresses are assigned to network interfaces that connect devices to the IEEE LAN - these are typically fixed on devices but not always. I recommend to make the text more accurate and clear on this aspect. |
2010-12-07
|
06 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss |
2010-12-02
|
06 | Cindy Morgan | State changed to IESG Evaluation - Defer::AD Followup from IESG Evaluation - Defer. |
2010-12-02
|
06 | Sean Turner | [Ballot comment] I support Tim's discuss. The FQDN section specifically mentions that if the FQDN doesn't correspond to a singular IP address or host then … [Ballot comment] I support Tim's discuss. The FQDN section specifically mentions that if the FQDN doesn't correspond to a singular IP address or host then it's not suitable. Should this be repeated in the other sections? e.g., if the URI doesn't specifically refer to a particular device, then a URI is not a suitable identifier. I see the general guidance in Section 2- just curious why only FQDN got this special treatment. In Section 3.7, I says: Each identifier contains a string of decimal digits with a length as specified. But, the imsi and min identifier descriptions don't include length constraints. Seems like they all should (they're in the schema I guess just copy the values forward to the descriptions). Please remove "Note that" from the last paragraph of the Security considerations. Normative language should not be in a note. |
2010-12-02
|
06 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss |
2010-12-02
|
06 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
2010-12-02
|
06 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2010-12-02
|
06 | Adrian Farrel | [Ballot comment] I support Dan's Discuss. draft-ietf-georiv-arch is (somewhat) careful in its definition of "device" and I do not think it means "network interface". Although … [Ballot comment] I support Dan's Discuss. draft-ietf-georiv-arch is (somewhat) careful in its definition of "device" and I do not think it means "network interface". Although it is true that network interfaces do not currently wander independent of devices (and if they did, they might need to be independently trackable) some care is needed in the wording to make the association clear. |
2010-12-01
|
06 | Sean Turner | [Ballot comment] I support Tim's discuss. The FQDN section specifically mentions that if the FQDN doesn't correspond to a singular IP address or host then … [Ballot comment] I support Tim's discuss. The FQDN section specifically mentions that if the FQDN doesn't correspond to a singular IP address or host then it's not suitable. Should this be repeated in the other sections? e.g., if the URI doesn't specifically refer to a particular device, then a URI is not a suitable identifier. I see the general guidance in Section 2- just curious why only FQDN got this special treatment. In Section 3.7, I says: Each identifier contains a string of decimal digits with a length as specified. But, the imsi and min identifier descriptions don't include length constraints. Seems like they all should (they're in the schema I guess just copy the values forward to the descriptions). |
2010-12-01
|
06 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2010-12-01
|
06 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2010-11-30
|
06 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss |
2010-11-28
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2010-11-15
|
06 | Alexey Melnikov | [Ballot comment] 2.2. Identifier Format and Protocol Details If the LIS requires an identifier that is not provided in the request, the desired … [Ballot comment] 2.2. Identifier Format and Protocol Details If the LIS requires an identifier that is not provided in the request, the desired identifiers MAY be identified in the HELD error response, using the "requiredIdentifiers" element. This element contains a list of XML qualified names [W3C.REC-xml-names11-20060816] that identify the identifier elements required by the LIS. Namespace prefix bindings for the qualified names are taken from document context. Figure 2 shows an example error indicating that the requester needs to include a MAC address (Section 3.2) if the request is to succeed. Is there an IANA registry for these? 5. Security Considerations All HELD requests containing identity MUST be authenticated by the LIS. How authentication is accomplished and what assurances are desired is a matter for policy. Is this description sufficient for providing interoperability? |
2010-11-15
|
06 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2010-11-14
|
06 | (System) | New version available: draft-ietf-geopriv-held-identity-extensions-06.txt |
2010-11-10
|
06 | Robert Sparks | Telechat date has been changed to 2010-12-02 from 2010-11-18 |
2010-10-27
|
06 | Tim Polk | [Ballot discuss] This discuss expands upon one of the comments in Alexey's ballot position. In section 5. Security Considerations, paragraphs 2 and 3 state: … [Ballot discuss] This discuss expands upon one of the comments in Alexey's ballot position. In section 5. Security Considerations, paragraphs 2 and 3 state: All HELD requests containing identity MUST be authenticated by the LIS. How authentication is accomplished and what assurances are desired is a matter for policy. The base HELD protocol uses return reachability of an IP address implied by the requester being able to successfully complete a TCP handshake. It is RECOMMENDED that any means of authentication provide at least this degree of assurance. For requests that include Device identity, the LIS MUST support HTTP digest authentication [RFC2617]. Unauthenticated location requests containing Device identity can be challenged with an HTTP 401 (Unauthorized) response or rejected with an HTTP 403 (Forbidden) response. However, RFC 5985 states: A Device that conforms to this specification MAY choose not to support HTTP authentication [RFC2617] or cookies [RFC2965]. Where IP reachability is not an appropriate means of authentication, the only authentication mechanism that MUST be required by the LIS is optional for the Device. Should digest authentication be a MUST for the Device? The combination of digest authentication and TLS seems a straightforward solution. Alternatively, TLS client authentication is a more complex solution but might be more scalable. |
2010-10-27
|
06 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2010-10-27
|
06 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2010-10-27
|
06 | Russ Housley | State changed to IESG Evaluation - Defer from IESG Evaluation by Russ Housley |
2010-10-27
|
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo |
2010-10-27
|
06 | Stewart Bryant | [Ballot comment] I agree with the discusses already posted, but no additional issues. |
2010-10-27
|
06 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant |
2010-10-27
|
06 | Robert Sparks | State changed to IESG Evaluation from Waiting for AD Go-Ahead::External Party by Robert Sparks |
2010-10-26
|
06 | Dan Romascanu | [Ballot comment] I support the issues raised by Alexey in his DISCUSS. |
2010-10-26
|
06 | Dan Romascanu | [Ballot discuss] In Section 3.2: The media access control (MAC) address used by the IEEE 802 family of access technologies is an identifier … [Ballot discuss] In Section 3.2: The media access control (MAC) address used by the IEEE 802 family of access technologies is an identifier that is assigned to a particular network Device. A MAC address is a unique sequence that is either assigned at the time of manufacture of a Device, or assigned by a local administrator. A MAC address rarely changes; therefore, a MAC address is an appropriate identifier for a Device. Actually MAC addresses are not assigned to devices but to network interfaces that connect devices to a physical segment. There may be more than one MAC address per device in the case of devices with multiple network interfaces, and even more MAC addresses per one physical interface in some cases (for example one MAC address per VLAN). The scheme works but only for the globally unique addresses which are guaranteed to be unique and any of the MAC addresses on the device interfaces can be used to identify the device. |
2010-10-26
|
06 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
2010-10-26
|
06 | Lars Eggert | [Ballot comment] Section 3.6., paragraph 4: > A domain name does not always correspond to a single IP address or > host. If … [Ballot comment] Section 3.6., paragraph 4: > A domain name does not always correspond to a single IP address or > host. If this is the case, a domain name is not a suitable > identifier. Right. Domain names are also clearly context specific (split-horizon DNS, etc.) |
2010-10-26
|
06 | Lars Eggert | [Ballot discuss] Section 3.3., paragraph 0: > 3.3. TCP or UDP Port Number DISCUSS: There are transport protocols other than TCP and UCP, i.e., … [Ballot discuss] Section 3.3., paragraph 0: > 3.3. TCP or UDP Port Number DISCUSS: There are transport protocols other than TCP and UCP, i.e., SCTP and DCCP. But let's take a step back - is there *really* a use case for identifying devices based on what is basically a socket ID? If yes, then you need to extend this to support SCTP and DCCP (note that DCCP has service codes in addition to port numbers.) This will be ugly and complex, hence the question whether anybody actually really needs this urgently. |
2010-10-26
|
06 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2010-10-23
|
06 | Alexey Melnikov | [Ballot comment] I am still thinking about the following issues, so for now this is a Comment (but I can upgrade it to DISCUSS): 2.2. … [Ballot comment] I am still thinking about the following issues, so for now this is a Comment (but I can upgrade it to DISCUSS): 2.2. Identifier Format and Protocol Details If the LIS requires an identifier that is not provided in the request, the desired identifiers MAY be identified in the HELD error response, using the "requiredIdentifiers" element. This element contains a list of XML qualified names [W3C.REC-xml-names11-20060816] that identify the identifier elements required by the LIS. Namespace prefix bindings for the qualified names are taken from document context. Figure 2 shows an example error indicating that the requester needs to include a MAC address (Section 3.2) if the request is to succeed. Is there an IANA registry for these? 5. Security Considerations All HELD requests containing identity MUST be authenticated by the LIS. How authentication is accomplished and what assurances are desired is a matter for policy. Is this description sufficient for providing interoperability? |
2010-10-23
|
06 | Alexey Melnikov | [Ballot discuss] Thank you for addressing most of my comments from my early AD review. There are a couple of minor things that I would … [Ballot discuss] Thank you for addressing most of my comments from my early AD review. There are a couple of minor things that I would still like to discuss before recommending approval of this document. 3.1. IP Address The "ip" element can express a Device identity as an IP address. The "v" attribute identifies the IP version with a single hexadecimal digit. The element uses the textual format specific to the indicated IP version ([RFC0791] for IPv6, Should be IPv4. I would actually suggest referencing IPv4/IPv6 address ABNF from RFC 3986. [RFC4291] for IPv6). 3.7. Cellular Telephony Identifiers Each identifier in this section needs a Normative reference to the document which defines its format. Alternatively, the format needs to be defined in full in this document. |
2010-10-23
|
06 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov |
2010-10-22
|
06 | Robert Sparks | Placed on agenda for telechat - 2010-10-28 by Robert Sparks |
2010-10-22
|
06 | Robert Sparks | [Ballot Position Update] New position, Yes, has been recorded for Robert Sparks |
2010-10-22
|
06 | Robert Sparks | Ballot has been issued by Robert Sparks |
2010-10-22
|
06 | Robert Sparks | Created "Approve" ballot |
2010-10-20
|
05 | (System) | New version available: draft-ietf-geopriv-held-identity-extensions-05.txt |
2010-10-13
|
06 | Robert Sparks | State changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead by Robert Sparks |
2010-10-13
|
06 | Amy Vezza | State changed to Waiting for AD Go-Ahead from In Last Call by Amy Vezza |
2010-10-07
|
06 | Amanda Baber | IANA understands that, upon approval of this document, three IANA Actions must be completed. First, in the namespace registry of the IETF XML document repository … IANA understands that, upon approval of this document, three IANA Actions must be completed. First, in the namespace registry of the IETF XML document repository located at http://www.iana.org/assignments/xml-registry/ns.html a new registration is to be made: ID: geopriv:held:id URN: urn:ietf:params:xml:ns:geopriv:held:id Registration template: URI: urn:ietf:params:xml:ns:geopriv:held:id Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com). XML: BEGIN Namespace for HELD Device Identity Parametersurn:ietf:params:xml:ns:geopriv:held:idSee RFC-to-be. END Reference: RFC-to-be Second, in the schema registry of the IETF XML document repository located at: http://www.iana.org/assignments/xml-registry/schema.html a new registration is to be made. ID: geopriv:held:id URI: urn:ietf:params:xml:schema:geopriv:held:id Filename: As documented in Section 6 of the approved document Reference: RFC-to-be Third, in the HELD Error Codes subregistry of the Geopriv HTTP Enabled Location Delivery (HELD) Parameters registry located at: http://www.iana.org/assignments/held-parameters/held-parameters.xhtml a new registration is to be made: code: badIdentifier description: This error code indicates that a Device identifier used in the HELD request was either: not supported by the LIS, badly formatted, or not one for which the requester was authorized to make a request. reference: RFC-to-be IANA understands that these three actions are all that need to be completed upon approval of the document. |
2010-09-28
|
06 | Amy Vezza | Last call sent |
2010-09-28
|
06 | Amy Vezza | State changed to In Last Call from Last Call Requested by Amy Vezza |
2010-09-28
|
06 | Robert Sparks | Last Call was requested by Robert Sparks |
2010-09-28
|
06 | (System) | Ballot writeup text was added |
2010-09-28
|
06 | (System) | Last call text was added |
2010-09-28
|
06 | (System) | Ballot approval text was added |
2010-09-28
|
06 | Robert Sparks | State changed to Last Call Requested from Publication Requested by Robert Sparks |
2010-06-22
|
06 | Amy Vezza | The GEOPRIV working group requests publication of draft-ietf-geopriv- held-identity-extensions-04 as Proposed Standard. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd … The GEOPRIV working group requests publication of draft-ietf-geopriv- held-identity-extensions-04 as Proposed Standard. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The Document Shepherd for this document is Alissa Cooper. The Shepherd has personally reviewed this version of the document, and believes it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been thoroughly reviewed by a range of WG members, and has also received substantial attention from the emergency calling community. It received an early SECDIR review (http://www.ietf.org/mail-archive/web/geopriv/current/msg08064.html ). As it was reviewed a number of times prior to working group adoption, I do not have concerns about the depth or breadth of reviews performed. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document would likely benefit from further security review, as security concerns have been the focal point of most of the discussion about the document. I am confident with the security model as is, but it may be helpful to confirm within the security community since the SECDIR review was several draft versions ago. (1.d) Does the Document Shepherd have any specific concerns or issues 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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I have no special concerns about this document. It is a very necessary piece of the HELD architecture, and the working group has refined it at length so as to comply with appropriate security and privacy standards. Several interoperable implementations of this specification (or parts of it) exist and have been tested within the emergency calling community. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is general consensus within the working group behind this document. Those within the group who had raised strong concerns over the years about various security aspects have agreed that those concerns have been resolved. (1.f) 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 entered into the ID Tracker.) I am not aware of any extreme discontent or potential appeals related to this document. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? I have personally verified that the document satisfies all nits. (1.h) Has the document split its references into normative and informative? 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 strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split into normative and informative. There are no downward references or references to documents with unclear status. There are two I-Ds in the normative references section, draft-ietf- geopriv-http-location-delivery and draft-ietf-idnabis-defs, both of which are in the RFC Editor's Queue. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists, and provides instructions for IANA to register a sub-namespace in the HELD namespace and a registry of device identity types. The name for the new registry is reasonable and the initial contents are defined. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? All of the XML in the document validates correctly. (1.k) 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 When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device. Working Group Summary This document has been discussed at length within the working group, with a particular focus on security and privacy. There is WG consensus that this document describes an important piece of the HELD architecture and that it has addressed concerns raised previously. Document Quality The HELD extensions described in this document are simple to read and understand. Multiple revisions of this document have made for a straightforward but comprehensive discussion of relevant security and privacy issues. |
2010-06-22
|
06 | Amy Vezza | Draft Added by Amy Vezza in state Publication Requested |
2010-06-22
|
06 | Amy Vezza | [Note]: 'The Document Shepherd for this document is Alissa Cooper (acooper@cdt.org).' added by Amy Vezza |
2010-06-21
|
04 | (System) | New version available: draft-ietf-geopriv-held-identity-extensions-04.txt |
2010-02-24
|
03 | (System) | New version available: draft-ietf-geopriv-held-identity-extensions-03.txt |
2009-12-09
|
02 | (System) | New version available: draft-ietf-geopriv-held-identity-extensions-02.txt |
2009-10-22
|
06 | Samuel Weiler | Request for Early review by SECDIR Completed. Reviewer: Donald Eastlake. |
2009-10-19
|
01 | (System) | New version available: draft-ietf-geopriv-held-identity-extensions-01.txt |
2009-09-18
|
06 | Samuel Weiler | Request for Early review by SECDIR is assigned to Donald Eastlake |
2009-09-18
|
06 | Samuel Weiler | Request for Early review by SECDIR is assigned to Donald Eastlake |
2009-09-07
|
00 | (System) | New version available: draft-ietf-geopriv-held-identity-extensions-00.txt |