Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option
draft-ietf-netext-ani-location-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-06-10
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-05-28
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-05-13
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-03-25
|
09 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-03-24
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-03-24
|
09 | (System) | RFC Editor state changed to EDIT |
2015-03-24
|
09 | (System) | Announcement was received by RFC Editor |
2015-03-24
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2015-03-24
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2015-03-24
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-03-23
|
09 | (System) | IANA Action state changed to In Progress |
2015-03-23
|
09 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-03-23
|
09 | Amy Vezza | IESG has approved the document |
2015-03-23
|
09 | Amy Vezza | Closed "Approve" ballot |
2015-03-23
|
09 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2015-03-23
|
09 | Brian Haberman | Ballot writeup was changed |
2015-03-23
|
09 | Brian Haberman | Ballot approval text was generated |
2015-03-23
|
09 | Rajesh Pazhyannur | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-03-23
|
09 | Rajesh Pazhyannur | New version available: draft-ietf-netext-ani-location-09.txt |
2015-03-21
|
08 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2015-03-19
|
08 | Richard Barnes | [Ballot comment] Thanks for a good discussion of confidentiality protections in the Security Considerations. It would be helpful if you could also note that another … [Ballot comment] Thanks for a good discussion of confidentiality protections in the Security Considerations. It would be helpful if you could also note that another way to address the concerns here is to provision location information at the least granular level possible. Suggested: "The other way to protect the sensitive location information of network users is of course to not send it in the first places. Users of the civic location sub option should provision location values with the highest possible level of granularity, e.g., to the province or city level, rather than provisioning specific addresses. In addition to helping protect private information, reducing granularity will also reduce the size of the civic location sub option." I cleared because it looks like we are agreed on point (4) of my DISCUSS, i.e., that the XML/URI-based option will be removed in favor of just using the DHCP option. I trust Brian and the authors will make sure the change is made. |
2015-03-19
|
08 | Richard Barnes | [Ballot Position Update] Position for Richard Barnes has been changed to No Objection from Discuss |
2015-03-12
|
08 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2015-03-05
|
08 | Cindy Morgan | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2015-03-05
|
08 | Cindy Morgan | Changed consensus to Yes from Unknown |
2015-03-05
|
08 | Stephen Farrell | [Ballot comment] - What if the network being identified here was a tethering n/w or any other kind of n/w that's carried about by a … [Ballot comment] - What if the network being identified here was a tethering n/w or any other kind of n/w that's carried about by a person? In that case ANI, and these new options, would be privacy invasive. Does that statement exist in one of the RFCs referred to in section 6? If not, would it be worth adding here, even though it might better belong elsewhere? - intro: What if a WLAN operator has no realm? - intro: DPI? What's that got to do with it? I'd suggest removing that. |
2015-03-05
|
08 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-03-05
|
08 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2015-03-05
|
08 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-03-05
|
08 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-03-05
|
08 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-03-04
|
08 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2015-03-04
|
08 | Richard Barnes | [Ballot discuss] (1) In Section 3.1, the "civic location" description here mentions the use of a location URI, but there's no corresponding Format for it. … [Ballot discuss] (1) In Section 3.1, the "civic location" description here mentions the use of a location URI, but there's no corresponding Format for it. Is that what you actually mean to have for XML Encoding (1)? You're not going to fit much XML in 253 octets anyway. I would suggest having format 0 be the RFC 4776 format, and format 1 be a URI pointing to an XML document. (2) It would help interoperability if you could constrain the classes of location URI that are supported. For example, if the mechanism in RFC 6753 is sufficient for your purposes, you could require that geolocation values in format 1 use an HTTPS URI to be dereferenced using that mechanism. Likewise, unless there's a known, compelling need to support HTTP URIs, you should require HTTPS. The fact that you have 253 format codes remaining means that if there are future needs for other URI types, you can liberalize. (3) To ensure that the location information referenced by location URIs is protected, please comment on the assumed access control model for these URIs. Can anyone with the URI dereference it? Or are they required to be access-controlled? Section 4 of RFC 6753 should provide a helpful framework. (4) Alternatively to (2) and (3), you could just remove the option for a XML/URI-based location altogether. Is there a compelling use cases here for very precise location? Even with the 253-octet limit, the RFC 4776 format would allow you to specify down to roughly the neighborhood level in most cases. For example, encoding "Washington, DC 20001, US" takes only 26 octets. Even looking at some Japanese addresses, which are more verbose, the examples I'm finding are still on the order of 70-100 octets. (5) Did the WG consider constraining the set of civic address elements that can be used? It's not clear to me that the use cases for this document require very granular information, e.g., to the individual building, floor, or room. The RFC 4776 format makes it fairly easy to express these constraints, by saying something like "The civic addresses carried in the civic location sub option MUST NOT contain elements other than A1, ..., A6 and PC." |
2015-03-04
|
08 | Richard Barnes | [Ballot comment] Thanks for a good discussion of confidentiality protections in the Security Considerations. It would be helpful if you could also note that another … [Ballot comment] Thanks for a good discussion of confidentiality protections in the Security Considerations. It would be helpful if you could also note that another way to address the concerns here is to provision location information at the least granular level possible. Suggested: "The other way to protect the sensitive location information of network users is of course to not send it in the first places. Users of the civic location sub option should provision location values with the highest possible level of granularity, e.g., to the province or city level, rather than provisioning specific addresses. In addition to helping protect private information, reducing granularity will also reduce the size of the civic location sub option." |
2015-03-04
|
08 | Richard Barnes | Ballot comment and discuss text updated for Richard Barnes |
2015-03-04
|
08 | Richard Barnes | [Ballot discuss] (1) In Section 3.1, the "civic location" description here mentions the use of a location URI, but there's no corresponding Format for it. … [Ballot discuss] (1) In Section 3.1, the "civic location" description here mentions the use of a location URI, but there's no corresponding Format for it. Is that what you actually mean to have for XML Encoding (1)? You're not going to fit much XML in 253 octets anyway. I would suggest having format 0 be the RFC 4776 format, and format 1 be a URI pointing to an XML document. (2) It would help interoperability if you could constrain the classes of location URI that are supported. For example, if the mechanism in RFC 6753 is sufficient for your purposes, you could require that geolocation values in format 1 use an HTTPS URI to be dereferenced using that mechanism. Likewise, unless there's a known, compelling need to support HTTP URIs, you should require HTTPS. The fact that you have 253 format codes remaining means that if there are future needs for other URI types, you can liberalize. (3) To ensure that the location information referenced by location URIs is protected, please comment on the assumed access control model for these URIs. Can anyone with the URI dereference it? Or are they required to be access-controlled? Section 4 of RFC 6753 should provide a helpful framework. (4) Alternatively to (2) and (3), you could just remove the option for a XML/URI-based location altogether. Is there a compelling use cases here for very precise location? Even with the 253-octet limit, the RFC 4776 format would allow you to specify down to roughly the neighborhood level in most cases. For example, encoding "Washington, DC 20001, US" takes only 26 octets. Even looking at some Japanese addresses, which are more verbose, the examples I'm finding are still on the order of 70-100 octets. |
2015-03-04
|
08 | Richard Barnes | [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes |
2015-03-04
|
08 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-03-04
|
08 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-03-04
|
08 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-03-03
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2015-03-03
|
08 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-02-28
|
08 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2015-02-25
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2015-02-25
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2015-02-11
|
08 | Brian Haberman | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-02-11
|
08 | Brian Haberman | Placed on agenda for telechat - 2015-03-05 |
2015-02-11
|
08 | Brian Haberman | Ballot has been issued |
2015-02-11
|
08 | Brian Haberman | [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman |
2015-02-11
|
08 | Brian Haberman | Created "Approve" ballot |
2015-02-11
|
08 | Brian Haberman | Ballot writeup was changed |
2015-02-11
|
08 | Brian Haberman | IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup |
2015-02-11
|
08 | Rajesh Pazhyannur | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2015-02-11
|
08 | Rajesh Pazhyannur | New version available: draft-ietf-netext-ani-location-08.txt |
2015-02-11
|
07 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-02-10
|
07 | Pearl Liang | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2015-02-10
|
07 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-netext-ani-location-07. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-netext-ani-location-07. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there is a single action which needs to be completed. In the Access Network Information (ANI) Sub-Option Type Values subregistry of the Mobile IPv6 parameters located at: http://www.iana.org/assignments/mobility-parameters/ three new option type values will be registered as follows: Value: [ TBD-at-Registration ] Description: Civic location Sub-option Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: MAG group identifier Sub-option Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: ANI Update-Timer Sub-option Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. 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. This message is only to confirm what actions will be performed. |
2015-02-10
|
07 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2015-01-31
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Stefan Winter |
2015-01-31
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Stefan Winter |
2015-01-29
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2015-01-29
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2015-01-28
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2015-01-28
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2015-01-27
|
07 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2015-01-27
|
07 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Extensions to the PMIPv6 Access … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Extensions to the PMIPv6 Access Network Identifier Option) to Proposed Standard The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'Extensions to the PMIPv6 Access Network Identifier Option' 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 2015-02-10. 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 Access Network Identifier (ANI) Mobility option was introduced in Access Network Identifier Option for Proxy Mobile IPv6 (RFC 6757). This enables a Mobility Access Gateway (MAG) to convey identifiers like network identifier, geolocation, and operator identifier. This specification extends the Access Network Identifier mobility option with sub options to carry civic location and MAG group Identifier. This specification also defines an ANI Update-Timer sub option that determines when and how often the ANI option will be updated. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-01-27
|
07 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2015-01-27
|
07 | Brian Haberman | Last call was requested |
2015-01-27
|
07 | Brian Haberman | Last call announcement was generated |
2015-01-27
|
07 | Brian Haberman | Ballot approval text was generated |
2015-01-27
|
07 | Brian Haberman | Ballot writeup was generated |
2015-01-27
|
07 | Brian Haberman | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2015-01-27
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-01-27
|
07 | Rajesh Pazhyannur | New version available: draft-ietf-netext-ani-location-07.txt |
2015-01-23
|
06 | Brian Haberman | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2015-01-21
|
06 | Brian Haberman | IESG state changed to AD Evaluation from Publication Requested |
2015-01-20
|
06 | Cindy Morgan | Intended Status changed to Proposed Standard |
2015-01-20
|
06 | Cindy Morgan | IESG process started in state Publication Requested |
2015-01-20
|
06 | Cindy Morgan | Working group state set to Submitted to IESG for Publication |
2015-01-20
|
06 | Cindy Morgan | (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? … (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? This I-D is being progressed for publication as a Proposed Standard. The I-D proposes new extensions which will need IANA action and hence the standards track is appropriate. The type of RFC is indicated in the title header of the I-D. (2) The IESG approval announcement includes a Document Announcement Write-Up. Technical Summary: Access Network Identifier (ANI) Mobility option was introduced in Access Network Identifier Option for Proxy Mobile IPv6 (RFC 6757). This enables a Mobility Access Gateway (MAG) to convey identifiers like network identifier, geolocation, and operator identifier. This specification extends the Access Network Identifier mobility option with sub options to carry civic location and MAG group Identifier. This specification also defines an ANI Update-Timer sub option that determines when and how often the ANI option will be updated. Working Group Summary: The WG initially considered updating RFC 6757 (Access Network Identifier (ANI) Option for Proxy Mobile IPv6). However after considering the scope and the extensions being proposed, it was decided that a separate I-D extending RFC 6757 was a better approach. Consensus was strong to create a new WG I-D and extend RFC6757. Document Quality: Are there existing implementations of the protocol? Not at the present time. Have a significant number of vendors indicated their plan to implement the specification? At least one vendor has expressed plans to implement this 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? All reviewers have been acknowledged in the I-D. 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? The document does not specific a MIB or media type. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Doc Shepherd: Basavaraj Patil AD: Brian Haberman (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 the document multiple times and provided feedback to the authors. It is now ready for publication and hence being forwarded to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns about the depth or breadth of the reviews performed to date. (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. Do not see a reason for additonal reviews from any specific area. (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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no concerns or issues with this I-D. The working group supports this I-D and its publication. (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? Yes. All authors have confirmed conformance with the provisions of BCP 78, 79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No known IPR disclosures have been filed that reference this document. (9) How solid is the WG consensus behind this document? WG consensus is strong. 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? The WG as a whole understands the document and the extension to RFC 6757 being proposed therein. There is general agreement in the WG about the need for this extension. (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 is no disagreement or discontent in the working group regarding this document. (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 major ID nits. Output from checking is : Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No MIB, media type of URI types are specified in the document. (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? All normative references are published RFCs. If such normative references exist, what is the plan for their completion? N/A (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? Yes. Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? Yes. Listed in the abstract. 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 WG considers it unnecessary. N/A (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 clear in terms of the instructions. There is no requirement to create a new registry for this I-D. The registry where the IANA assignments will be maintained is clearly indicated. (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 new registry is being requested. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No XML code, BNF rules, MIBs etc. are specified in the document. |
2015-01-20
|
06 | Cindy Morgan | Changed document writeup |
2015-01-20
|
06 | Cindy Morgan | Notification list changed to "Basavaraj Patil" <bpatil1+ietf@gmail.com> |
2015-01-20
|
06 | Cindy Morgan | Document shepherd changed to Basavaraj Patil |
2015-01-16
|
06 | Rajesh Pazhyannur | New version available: draft-ietf-netext-ani-location-06.txt |
2014-12-12
|
05 | Rajesh Pazhyannur | New version available: draft-ietf-netext-ani-location-05.txt |
2014-11-10
|
04 | Rajesh Pazhyannur | New version available: draft-ietf-netext-ani-location-04.txt |
2014-09-08
|
03 | Rajesh Pazhyannur | New version available: draft-ietf-netext-ani-location-03.txt |
2014-08-27
|
02 | Rajesh Pazhyannur | New version available: draft-ietf-netext-ani-location-02.txt |
2014-07-22
|
01 | Rajesh Pazhyannur | New version available: draft-ietf-netext-ani-location-01.txt |
2014-07-21
|
00 | Rajesh Pazhyannur | New version available: draft-ietf-netext-ani-location-00.txt |