GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements
RFC 5687
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
10 | (System) | Notify list changed from geopriv-chairs@ietf.org, draft-ietf-geopriv-l7-lcp-ps@ietf.org to (None) |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
|
2010-03-10
|
10 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
|
2010-03-10
|
10 | Cindy Morgan | [Note]: 'RFC 5687' added by Cindy Morgan |
|
2010-03-10
|
10 | (System) | RFC published |
|
2009-09-17
|
10 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
|
2009-09-17
|
10 | (System) | IANA Action state changed to No IC from In Progress |
|
2009-09-17
|
10 | (System) | IANA Action state changed to In Progress |
|
2009-09-17
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2009-09-17
|
10 | Amy Vezza | IESG has approved the document |
|
2009-09-17
|
10 | Amy Vezza | Closed "Approve" ballot |
|
2009-09-17
|
10 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
|
2009-08-23
|
10 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
|
2009-07-13
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2009-07-13
|
10 | (System) | New version available: draft-ietf-geopriv-l7-lcp-ps-10.txt |
|
2009-07-03
|
10 | (System) | Removed from agenda for telechat - 2009-07-02 |
|
2009-07-02
|
10 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
|
2009-07-01
|
10 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
|
2009-07-01
|
10 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss by Ralph Droms |
|
2009-07-01
|
10 | Robert Sparks | [Ballot comment] There are some typo/grammar issues with the Note blocks added to the start of Sections 4 and 5 that need to be corrected … [Ballot comment] There are some typo/grammar issues with the Note blocks added to the start of Sections 4 and 5 that need to be corrected before publication. |
|
2009-07-01
|
10 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
|
2009-07-01
|
10 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded by Ralph Droms |
|
2009-07-01
|
10 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2009-07-01
|
10 | Dan Romascanu | [Ballot comment] There are plenty of acronyms not expanded at the first occurence: USB, DSL, PPoE, etc. |
|
2009-07-01
|
10 | Dan Romascanu | [Ballot discuss] 1. Since this document was written IEEE 802.1AB was approved and deployed. I suggest the following change in Section 5: OLD: Switch/Port Number: … [Ballot discuss] 1. Since this document was written IEEE 802.1AB was approved and deployed. I suggest the following change in Section 5: OLD: Switch/Port Number: This identifier is available only in certain networks, such as enterprise networks, typically available via proprietary protocols like CDP or, in the future, 802.1ab. NEW: Ethernet Switch (Bridge)/Port Number: This identifier is available only in certain networks, such as enterprise networks, typically available via the IEEE 802.1AB protocol [xx] or proprietary protocols like the Cisco Discovery Protocol (CDP) [yy] Adding informative references would also be nice for IEEE 802.1AB and CDP would also be useful. [xx] IEEE 802.1AB-2005 IEEE Standard for Local and Metropolitan Area Networks Station and Media Access Control Connectivity Discovery - http://standards.ieee.org/getieee802/download/802.1AB-2005.pdf Somebody should be able to provide a reference to CDP. 2. The four requirements in the Security Considerations section deserve to be written with 2119 capitalized MUST. |
|
2009-07-01
|
10 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
|
2009-06-30
|
10 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2009-06-29
|
10 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
|
2009-06-25
|
10 | Alexey Melnikov | [Ballot comment] In Section 6: The following requirements and assumptions have been identified: Requirement L7-1: Identifier Choice The L7 LCP … [Ballot comment] In Section 6: The following requirements and assumptions have been identified: Requirement L7-1: Identifier Choice The L7 LCP MUST be able to carry different identifiers or MUST define an identifier that is mandatory to implement. Did you mean "identifier type" here? Regarding the latter aspect, such an identifier is only appropriate if it is from the same realm as the one for which the location information service maintains identifier to location mapping. |
|
2009-06-25
|
10 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
|
2009-06-24
|
10 | Cullen Jennings | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Cullen Jennings |
|
2009-06-24
|
10 | Cullen Jennings | Placed on agenda for telechat - 2009-07-02 by Cullen Jennings |
|
2009-06-24
|
10 | Cullen Jennings | [Ballot Position Update] New position, Yes, has been recorded for Cullen Jennings |
|
2009-06-24
|
10 | Cullen Jennings | Ballot has been issued by Cullen Jennings |
|
2009-06-24
|
10 | Cullen Jennings | Created "Approve" ballot |
|
2009-06-09
|
10 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
|
2009-06-05
|
10 | Amanda Baber | IANA comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2009-05-26
|
10 | Amy Vezza | Last call sent |
|
2009-05-26
|
10 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2009-05-24
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Kent |
|
2009-05-24
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Kent |
|
2009-05-22
|
10 | Cullen Jennings | Note field has been cleared by Cullen Jennings |
|
2009-05-22
|
10 | Cullen Jennings | Last Call was requested by Cullen Jennings |
|
2009-05-22
|
10 | (System) | Ballot writeup text was added |
|
2009-05-22
|
10 | (System) | Last call text was added |
|
2009-05-22
|
10 | (System) | Ballot approval text was added |
|
2009-05-22
|
10 | Cullen Jennings | State Changes to Last Call Requested from AD Evaluation::AD Followup by Cullen Jennings |
|
2009-02-21
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2009-02-21
|
09 | (System) | New version available: draft-ietf-geopriv-l7-lcp-ps-09.txt |
|
2009-01-24
|
10 | Cullen Jennings | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::External Party by Cullen Jennings |
|
2009-01-24
|
10 | Cullen Jennings | [Note]: 'Waiting for reply for email sent Nov 14,2008' added by Cullen Jennings |
|
2009-01-24
|
10 | Cullen Jennings | [Note]: 'Waiting for reply for email sent Nov 14,2008<br><br>' added by Cullen Jennings |
|
2008-11-14
|
10 | Cullen Jennings | State Changes to AD Evaluation::External Party from AD Evaluation by Cullen Jennings |
|
2008-11-13
|
10 | Cullen Jennings | State Changes to AD Evaluation from Publication Requested by Cullen Jennings |
|
2008-09-26
|
10 | Cindy Morgan | Technical Summary This document describes the problems posed by a need for a "layer- seven" location configuration protocol (L7LCP) in IP networks, and states requirements … Technical Summary This document describes the problems posed by a need for a "layer- seven" location configuration protocol (L7LCP) in IP networks, and states requirements for such a protocol. Location configuration, in this document, is the process by which IP endpoints acquire their own location from a network to which they are connected. A configuration protocol that operates at layer 7 (i.e., the application layer) is needed in order to be deployable in many different types of access networks without major modification to lower-layer devices in the network. The distribution of location information is a privacy- sensitive task. This document describes the privacy risks introduced by design choices in an L7LCP and how these risks can be mitigated. WG Summary The WG reached consensus to advance this document. It was produced by an L7LCP design team and went through several revisions in response to WG comments. Initial versions of the document were much broader in scope, and the WG agreed that many sections (e.g., sections on location URIs and on VPN considerations) could be removed from the document without affecting the main content that relates specifically to the development of an L7LCP. There is broad consensus that the current, more tightly-focused document is ready to advance. Document Quality The document was reviewed in depth by the GEOPRIV Working Group. The document is the product of an in-depth discussion of location configuration issues by the L7LCP design team, which led to an initial draft that addressed a wide variety of location-relevant concerns. Several of these concerns sparked significant controversy and were not directly relevant to an L7LCP. As a result, these issues have been spun off into separate documents, and the remaining core L7LCP document now constitutes a focused description of L7LCP requirements. Personnel The WG Chair is Robert Sparks, the Proto Shepherd is Richard Barnes and the Responsible Area Director is Cullen Jennings. ------- The proto writeup follows. -------- (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 shepherd is Richard Barnes. I have personally reviewed it and believe it is ready for forwarding. (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? It has been reviewed carefully by key WG members, as well as by key members of the ECRIT working group, who are to be one of the primary consumers of the protocol to be developed. I do not have concerns. (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? This document might benefit from further review with respect to security concerns. In the final revision to this document, detailed security concerns that were deemed to be not specific to the L7LCP problem were moved to a separate document that has not yet been adopted by the WG. I believe that the document addresses LCP-specific security and privacy issues adequately in the main body of the text, but an additional SECDIR review might be useful to ensure that security concerns are thoroughly addressed. (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 those issues have been discussed in the WG and the WG has indicated that it still wishes to advance the document, detail those concerns here. I do not have any specific concerns. (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 solid WG consensus. There is broad agreement that a strong need exists for an L7LCP, and that this document adequately captures that problem and relevant requirements. (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 will be entered into the ID Tracker.) Nothing. (1.g) Has the Document Shepherd 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. The document has passed this checklist with minor exceptions around the 2616 boilerplate and some stale references. (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]. The references are split. While the document does contain references to documents that are not ready for advancement, all such references are informative, not normative. (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 [RFC2434]. 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? This document does not require actions by IANA. (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? There is no such formal language used in this document. (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. See first of message |
|
2008-09-26
|
10 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
|
2008-06-29
|
08 | (System) | New version available: draft-ietf-geopriv-l7-lcp-ps-08.txt |
|
2008-03-29
|
07 | (System) | New version available: draft-ietf-geopriv-l7-lcp-ps-07.txt |
|
2007-11-19
|
06 | (System) | New version available: draft-ietf-geopriv-l7-lcp-ps-06.txt |
|
2007-09-12
|
05 | (System) | New version available: draft-ietf-geopriv-l7-lcp-ps-05.txt |
|
2007-08-29
|
04 | (System) | New version available: draft-ietf-geopriv-l7-lcp-ps-04.txt |
|
2007-07-12
|
03 | (System) | New version available: draft-ietf-geopriv-l7-lcp-ps-03.txt |
|
2007-04-30
|
02 | (System) | New version available: draft-ietf-geopriv-l7-lcp-ps-02.txt |
|
2007-04-09
|
01 | (System) | New version available: draft-ietf-geopriv-l7-lcp-ps-01.txt |
|
2007-01-08
|
00 | (System) | New version available: draft-ietf-geopriv-l7-lcp-ps-00.txt |