Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS
draft-ietf-geopriv-res-gw-lis-discovery-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-04-22
|
08 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-04-11
|
08 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-03-20
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2014-01-28
|
08 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2014-01-28
|
08 | (System) | RFC Editor state changed to EDIT |
2014-01-28
|
08 | (System) | Announcement was received by RFC Editor |
2014-01-27
|
08 | (System) | IANA Action state changed to No IC from In Progress |
2014-01-27
|
08 | (System) | IANA Action state changed to In Progress |
2014-01-27
|
08 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2014-01-27
|
08 | Amy Vezza | IESG has approved the document |
2014-01-27
|
08 | Amy Vezza | Closed "Approve" ballot |
2014-01-27
|
08 | Amy Vezza | Ballot approval text was generated |
2014-01-27
|
08 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation |
2014-01-27
|
08 | Richard Barnes | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2014-01-27
|
08 | Richard Barnes | Ballot writeup was changed |
2014-01-24
|
08 | Stephen Farrell | [Ballot comment] Discussion of my discuss I think resolved down to the point that a client doing this will send out a DNS query that … [Ballot comment] Discussion of my discuss I think resolved down to the point that a client doing this will send out a DNS query that e.g. includes 10.99.67.33. If the n/w owner (say a tin-foil hat person) wanted that their choice within 10/8 not be well known, they might consider that doing that would be a (very very) slightly higher risk. Not sure what you'd do about it, but might be worth a mention. |
2014-01-24
|
08 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2014-01-23
|
08 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss |
2014-01-05
|
08 | Ted Lemon | [Ballot comment] The document authors have updated the document to clarify the main point I was concerned about, and have further explained why they think … [Ballot comment] The document authors have updated the document to clarify the main point I was concerned about, and have further explained why they think STUN works here. I am not in a position to argue the latter point, and am satisfied with the response on the former, so I'm clearing. I've left both my DISCUSS and comment points below for the record, but expect no further action from the authors. Former DISCUSS points: (1) This specification relies on home gateways not following RFC 6303. Some of the advice given in the spec will simply fail if RFC 6303 is implemented by the HG. It would be better to assume RFC6303 is being followed by the DNS proxy/resolver in the HG, and write the spec so that it prefers a solution that doesn't rely on successful resolution of names in in-addr.arpa or ip6.arpa for RFC1918 address spaces. I've suggested a way to do this in the comments, and would be happy to work with the authors to fully flesh out this solution if it seems plausible to them. My understanding of how a LIS operates is not very good, though, so I may be assuming capabilities that a typical LIS doesn't actually have. (2) The document assumes that a device that is implementing this discovery mechanism will be able to distinguish between a VPN and a non-VPN connection. How this is done is not discussed. I am skeptical that this is possible. I would like to see the document go into this in more detail if the authors actually know how to make this happen. A similar problem exists for non-VPN tunnels, as I have mentioned in the comments. Unfortunately, I don't see any obvious way to distinguish between location-bound IP addresses and tunneled IP addresses. I think the way to address point 2 is simply to recommend best practices for setting up LIS configurations in these situations. Generally speaking providers will have control of the reverse tree for these tunnels. It would be helpful if there were a way for the DNS response to include a record in addition to the NAPTR (or as part of the NAPTR if possible) that indicates that if an alternate LIS is available, it should be preferred. Is it possible that this is documented elsewhere? Or is there a way for the LIS itself to provide this advice based on the source address of the query? (3) for the responsible AD: What's the IETF consensus status of this document? It's set to Unknown. Former comments: In 4.1, paragraph three mentions UPnP and NAT-PMP, but doesn't mention Port Control Protocol (PCP), RFC 6887. Given that PCP is the only protocol in this genre that has an IETF standard written to describe it, it should be mentioned for completeness, even though UPnP and NAT-PMP are more widely deployed. It's also worth noting that at least in principle PCP supports the ability to get edge information from the PCP server that's actually at the final transition from NATted addresses to global addresses, so this doesn't have the limitations that you are ascribing to UPnP and NAT-PMP. This is worth mentioning not only because it might be helpful, but also because if the operator has populated the reverse tree for their private address space, the outer global address isn't going to refer to the customer. Another point about global addresses versus NATted addresses at the CPE-PE edge is that protocols such as Dual-stack Light, Lightweight 4over6 and MAP will produce weird results for location determination and are only available on networks with native IPv6 capability, so LIS results obtained over IPv4 when these tunneling mechanisms are in use should be treated in a similar manner to LIS results obtained over a VPN connection. It is _possible_ with lw4over6 and MAP (and maybe DS-Lite) to use the address+port range to specifically identify the customer endpoint, but given that it's much easier to do with IPv6, this seems pointless. A similar issue exists for 6RD and other tunneled delivery of IPv6. In 4.3, given that LIS discovery is a fairly infrequent operation, is there really any point in restricting the set of prefix masks at which LIS records can be placed? It seems to me that the number of queries you'd get by starting at /64 and going one nybble at a time up the tree would be perfectly reasonable for an operation that happens infrequently. It would add latency if you are trying to locate a LIS as a prelude to making an emergency call, however. Also, why bother looking up the IPv6 address? It seems to me that there is no chance that a LIS server is going to be configured on a per-IP-address basis, particularly since IPv6 addresses will not be allocated to end users. Are you attempting to account for the possibility that the provider might NAT the customer down to a single IPv6 address? If the purpose of this is to locate handsets on a mobile network, where the handset might well have been given a /128 by the provider, it might be worth mentioning that. In 4.5, this whole mechanism is likely to fail for resolvers that implement RFC 6303. In the last paragraph of 4.5, the outcome described seems bad enough to beg for mitigation. Presumably in the scenario shown in figure 2, it's a bad outcome for the host to use STUN to get the public IP address corresponding to the outer edge of the NAT, and similarly a bad outcome for the CPE to query DNS A rather than DNS B. The right way to solve this problem, presuming for the moment that the ISP cares about providing accurate LIS service, would be to publish a global IP address belonging to the ISP in the global DNS for the LIS corresponding to the ISP's external address pool. This global IP address would however be configured on a host _inside the NAT_, and of course routing inside the NAT would have to reach that host without crossing the NAT, so that packets reach the LIS with the CPE's NATted IP address as the source address. This can then be used to provide accurate location information, because the CPE's IP address can be directly associated with the customer. This protocol relies heavily on STUN, but STUN server address discovery is problematic, and is not discussed. In reading up on this, I've encountered several assertions that STUN works well with existing home gateways, but no document explaining how it works. If your belief that STUN will address this problem is based on such documentation, a reference to it would be helpful. |
2014-01-05
|
08 | Ted Lemon | [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from Discuss |
2014-01-05
|
08 | Stephen Farrell | [Ballot discuss] Just noting that -08 doesn't address this. Sent some mail. Where'd my DISCUSS go? :-) I'm not sure if this still applies or … [Ballot discuss] Just noting that -08 doesn't address this. Sent some mail. Where'd my DISCUSS go? :-) I'm not sure if this still applies or not, but I'll whack it back in at least temporarily. (1) I don't get how its hard to configure a LIS name/addr but easy to configure a STUN server - can you explain? (2) Doesn't this require an ISP/access network to likely be able to answer DNS queries for all sorts of 1918 derived names? That seems undesirable - why is is justified here? |
2014-01-05
|
08 | Stephen Farrell | [Ballot comment] I agree with Adrian's discuss. I would further note that pretty much every geopriv dfaft seems to get a "this is pretending to … [Ballot comment] I agree with Adrian's discuss. I would further note that pretty much every geopriv dfaft seems to get a "this is pretending to handle privacy" discuss, but that the discuss-criteria are preventing the IESG from doing more than tinkering here. I'm not sure if that's really worthy of discussion within the IESG, but perhaps we might consider an addition to the discuss criteria that privacy also needs to be addressed and is discuss-worthy? But I'm a bit reluctant to go there in the absence of some privacy BCPs which we don't have (should we?) |
2014-01-05
|
08 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2013-12-18
|
08 | Martin Thomson | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2013-12-18
|
08 | Martin Thomson | New version available: draft-ietf-geopriv-res-gw-lis-discovery-08.txt |
2013-12-12
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call (ends 2013-12-12) |
2013-12-10
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Nevil Brownlee. |
2013-12-10
|
07 | Peter Yee | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. |
2013-12-09
|
07 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-geopriv-res-gw-lis-discovery-07, which is currently in Last Call, and has the following comments: We understand that this document doesn't require … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-geopriv-res-gw-lis-discovery-07, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. IANA requests that the IANA Considerations section of the document remain in place upon publication. If this assessment is not accurate, please respond as soon as possible. |
2013-12-05
|
07 | Gunter Van de Velde | Assignment of request for Telechat review by OPSDIR to Scott Bradner was rejected |
2013-12-05
|
07 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Location Information Server (LIS) Discovery … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Location Information Server (LIS) Discovery using IP address and Reverse DNS) to Proposed Standard The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'Location Information Server (LIS) Discovery using IP address and Reverse DNS' 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 2013-12-12. 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 The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway. This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-geopriv-res-gw-lis-discovery/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-geopriv-res-gw-lis-discovery/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-12-05
|
07 | Amy Vezza | State changed to In Last Call (ends 2013-11-18) from Last Call Requested |
2013-12-05
|
07 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-12-05
|
07 | Richard Barnes | Last call was requested |
2013-12-05
|
07 | Richard Barnes | State changed to Last Call Requested from IESG Evaluation |
2013-12-05
|
07 | Richard Barnes | Last call announcement was changed |
2013-12-05
|
07 | Richard Barnes | Last call announcement was generated |
2013-12-05
|
07 | Stephen Farrell | [Ballot discuss] Where'd my DISCUSS go? :-) I'm not sure if this still applies or not, but I'll whack it back in at least temporarily. … [Ballot discuss] Where'd my DISCUSS go? :-) I'm not sure if this still applies or not, but I'll whack it back in at least temporarily. (1) I don't get how its hard to configure a LIS name/addr but easy to configure a STUN server - can you explain? (2) Doesn't this require an ISP/access network to likely be able to answer DNS queries for all sorts of 1918 derived names? That seems undesirable - why is is justified here? |
2013-12-05
|
07 | Stephen Farrell | [Ballot comment] I agree with Adrian's discuss. I would further note that pretty much every geopriv dfaft seems to get a "this is pretending to … [Ballot comment] I agree with Adrian's discuss. I would further note that pretty much every geopriv dfaft seems to get a "this is pretending to handle privacy" discuss, but that the discuss-criteria are preventing the IESG from doing more than tinkering here. I'm not sure if that's really worthy of discussion within the IESG, but perhaps we might consider an addition to the discuss criteria that privacy also needs to be addressed and is discuss-worthy? But I'm a bit reluctant to go there in the absence of some privacy BCPs which we don't have (should we?) |
2013-12-05
|
07 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-12-04
|
07 | Richard Barnes | Changed consensus to Yes from Unknown |
2013-12-04
|
07 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2013-12-04
|
07 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-12-04
|
07 | Adrian Farrel | [Ballot comment] Thanks for Section 6. I find it addresses the Discuss I would have entered. |
2013-12-04
|
07 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2013-12-04
|
07 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-12-03
|
07 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-12-03
|
07 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-12-03
|
07 | Martin Stiemerling | [Ballot comment] Jari is holding the discuss about the change of the status after the IETF LC. The doc is saying standards track but the … [Ballot comment] Jari is holding the discuss about the change of the status after the IETF LC. The doc is saying standards track but the LC announcement was is saying it is Informational. Do we need to re-run the IETF LC? |
2013-12-03
|
07 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-12-02
|
07 | Jari Arkko | [Ballot discuss] I'm probably missing something obvious, but as far as I can tell, the document was last called (twice) with intended status set to … [Ballot discuss] I'm probably missing something obvious, but as far as I can tell, the document was last called (twice) with intended status set to Informational. I see no ietf-list level discussion about the status, but I have not reviewed the WG discussion. Why was status set to Proposed Standard a couple of days ago? Is this backed up by some community discussion that I'm not seeing, an error, or what? |
2013-12-02
|
07 | Jari Arkko | [Ballot comment] Peter Yee's Gen-ART review comments were addressed. Thanks! |
2013-12-02
|
07 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko |
2013-12-02
|
07 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Scott Bradner |
2013-12-02
|
07 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Scott Bradner |
2013-12-02
|
07 | Joel Jaeggli | [Ballot comment] cleared my previous dicuss on 5 so I think I can llive with it as written |
2013-12-02
|
07 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
2013-12-02
|
07 | Brian Haberman | [Ballot comment] I am balloting No-Obj based on the premise that the -07 version resolves the DISCUSS points I raised against the -05 version. |
2013-12-02
|
07 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-12-01
|
07 | Richard Barnes | Intended Status changed to Proposed Standard from Informational |
2013-12-01
|
07 | Ted Lemon | [Ballot comment] In 4.1, paragraph three mentions UPnP and NAT-PMP, but doesn't mention Port Control Protocol (PCP), RFC 6887. Given that PCP is the … [Ballot comment] In 4.1, paragraph three mentions UPnP and NAT-PMP, but doesn't mention Port Control Protocol (PCP), RFC 6887. Given that PCP is the only protocol in this genre that has an IETF standard written to describe it, it should be mentioned for completeness, even though UPnP and NAT-PMP are more widely deployed. It's also worth noting that at least in principle PCP supports the ability to get edge information from the PCP server that's actually at the final transition from NATted addresses to global addresses, so this doesn't have the limitations that you are ascribing to UPnP and NAT-PMP. This is worth mentioning not only because it might be helpful, but also because if the operator has populated the reverse tree for their private address space, the outer global address isn't going to refer to the customer. Another point about global addresses versus NATted addresses at the CPE-PE edge is that protocols such as Dual-stack Light, Lightweight 4over6 and MAP will produce weird results for location determination and are only available on networks with native IPv6 capability, so LIS results obtained over IPv4 when these tunneling mechanisms are in use should be treated in a similar manner to LIS results obtained over a VPN connection. It is _possible_ with lw4over6 and MAP (and maybe DS-Lite) to use the address+port range to specifically identify the customer endpoint, but given that it's much easier to do with IPv6, this seems pointless. A similar issue exists for 6RD and other tunneled delivery of IPv6. In 4.3, given that LIS discovery is a fairly infrequent operation, is there really any point in restricting the set of prefix masks at which LIS records can be placed? It seems to me that the number of queries you'd get by starting at /64 and going one nybble at a time up the tree would be perfectly reasonable for an operation that happens infrequently. It would add latency if you are trying to locate a LIS as a prelude to making an emergency call, however. Also, why bother looking up the IPv6 address? It seems to me that there is no chance that a LIS server is going to be configured on a per-IP-address basis, particularly since IPv6 addresses will not be allocated to end users. Are you attempting to account for the possibility that the provider might NAT the customer down to a single IPv6 address? If the purpose of this is to locate handsets on a mobile network, where the handset might well have been given a /128 by the provider, it might be worth mentioning that. In 4.5, this whole mechanism is likely to fail for resolvers that implement RFC 6303. In the last paragraph of 4.5, the outcome described seems bad enough to beg for mitigation. Presumably in the scenario shown in figure 2, it's a bad outcome for the host to use STUN to get the public IP address corresponding to the outer edge of the NAT, and similarly a bad outcome for the CPE to query DNS A rather than DNS B. The right way to solve this problem, presuming for the moment that the ISP cares about providing accurate LIS service, would be to publish a global IP address belonging to the ISP in the global DNS for the LIS corresponding to the ISP's external address pool. This global IP address would however be configured on a host _inside the NAT_, and of course routing inside the NAT would have to reach that host without crossing the NAT, so that packets reach the LIS with the CPE's NATted IP address as the source address. This can then be used to provide accurate location information, because the CPE's IP address can be directly associated with the customer. This protocol relies heavily on STUN, but STUN server address discovery is problematic, and is not discussed. In reading up on this, I've encountered several assertions that STUN works well with existing home gateways, but no document explaining how it works. If your belief that STUN will address this problem is based on such documentation, a reference to it would be helpful. |
2013-12-01
|
07 | Ted Lemon | Ballot comment text updated for Ted Lemon |
2013-12-01
|
07 | Ted Lemon | [Ballot comment] In 4.1, paragraph three mentions UPnP and NAT-PMP, but doesn't mention Port Control Protocol (PCP), RFC 6887. Given that PCP is the … [Ballot comment] In 4.1, paragraph three mentions UPnP and NAT-PMP, but doesn't mention Port Control Protocol (PCP), RFC 6887. Given that PCP is the only protocol in this genre that has an IETF standard written to describe it, it should be mentioned for completeness, even though UPnP and NAT-PMP are more widely deployed. It's also worth noting that at least in principle PCP supports the ability to get edge information from the PCP server that's actually at the final transition from NATted addresses to global addresses, so this doesn't have the limitations that you are ascribing to UPnP and NAT-PMP. This is worth mentioning not only because it might be helpful, but also because if the operator has populated the reverse tree for their private address space, the outer global address isn't going to refer to the customer. Another point about global addresses versus NATted addresses at the CPE-PE edge is that protocols such as Dual-stack Light, Lightweight 4over6 and MAP will produce weird results for location determination and are only available on networks with native IPv6 capability, so LIS results obtained over IPv4 when these tunneling mechanisms are in use should be treated in a similar manner to LIS results obtained over a VPN connection. It is _possible_ with lw4over6 and MAP (and maybe DS-Lite) to use the address+port range to specifically identify the customer endpoint, but given that it's much easier to do with IPv6, this seems pointless. A similar issue exists for 6RD and other tunneled delivery of IPv6. In 4.3, given that LIS discovery is a fairly infrequent operation, is there really any point in restricting the set of prefix masks at which LIS records can be placed? It seems to me that the number of queries you'd get by starting at /64 and going one nybble at a time up the tree would be perfectly reasonable for an operation that happens infrequently. It would add latency if you are trying to locate a LIS as a prelude to making an emergency call, however. Also, why bother looking up the IPv6 address? It seems to me that there is no chance that a LIS server is going to be configured on a per-IP-address basis, particularly since IPv6 addresses will not be allocated to end users. Are you attempting to account for the possibility that the provider might NAT the customer down to a single IPv6 address? If the purpose of this is to locate handsets on a mobile network, where the handset might well have been given a /128 by the provider, it might be worth mentioning that. In 4.5, this whole mechanism is likely to fail for resolvers that implement RFC 6303. In the last paragraph of 4.5, the outcome described seems bad enough to beg for mitigation. Presumably in the scenario shown in figure 2, it's a bad outcome for the host to use STUN to get the public IP address corresponding to the outer edge of the NAT, and similarly a bad outcome for the CPE to query DNS A rather than DNS B. The right way to solve this problem, presuming for the moment that the ISP cares about providing accurate LIS service, would be to publish a global IP address belonging to the ISP in the global DNS for the LIS corresponding to the ISP's external address pool. This global IP address would however be configured on a host _inside the NAT_, and of course routing inside the NAT would have to reach that host without crossing the NAT, so that packets reach the LIS with the CPE's NATted IP address as the source address. This can then be used to provide accurate location information, because the CPE's IP address can be directly associated with the customer. This protocol relies heavily on STUN, but STUN server address discovery is problematic, and is not discussed. In reading up on this, I've encountered several assertions that STUN works well with existing home gateways, but no document explaining how it works. If your belief that STUN will address this problem is based on such documentation, a reference to it would be helpful. |
2013-12-01
|
07 | Ted Lemon | Ballot comment text updated for Ted Lemon |
2013-12-01
|
07 | Ted Lemon | [Ballot discuss] (1) This specification relies on home gateways not following RFC 6303. Some of the advice given in the spec will simply fail … [Ballot discuss] (1) This specification relies on home gateways not following RFC 6303. Some of the advice given in the spec will simply fail if RFC 6303 is implemented by the HG. It would be better to assume RFC6303 is being followed by the DNS proxy/resolver in the HG, and write the spec so that it prefers a solution that doesn't rely on successful resolution of names in in-addr.arpa or ip6.arpa for RFC1918 address spaces. I've suggested a way to do this in the comments, and would be happy to work with the authors to fully flesh out this solution if it seems plausible to them. My understanding of how a LIS operates is not very good, though, so I may be assuming capabilities that a typical LIS doesn't actually have. (2) The document assumes that a device that is implementing this discovery mechanism will be able to distinguish between a VPN and a non-VPN connection. How this is done is not discussed. I am skeptical that this is possible. I would like to see the document go into this in more detail if the authors actually know how to make this happen. A similar problem exists for non-VPN tunnels, as I have mentioned in the comments. Unfortunately, I don't see any obvious way to distinguish between location-bound IP addresses and tunneled IP addresses. I think the way to address point 2 is simply to recommend best practices for setting up LIS configurations in these situations. Generally speaking providers will have control of the reverse tree for these tunnels. It would be helpful if there were a way for the DNS response to include a record in addition to the NAPTR (or as part of the NAPTR if possible) that indicates that if an alternate LIS is available, it should be preferred. Is it possible that this is documented elsewhere? Or is there a way for the LIS itself to provide this advice based on the source address of the query? (3) for the responsible AD: What's the IETF consensus status of this document? It's set to Unknown. |
2013-12-01
|
07 | Ted Lemon | [Ballot comment] In 4.1, paragraph three mentions UPnP and NAT-PMP, but doesn't mention Port Control Protocol (PCP), RFC 6887. Given that PCP is the … [Ballot comment] In 4.1, paragraph three mentions UPnP and NAT-PMP, but doesn't mention Port Control Protocol (PCP), RFC 6887. Given that PCP is the only protocol in this genre that has an IETF standard written to describe it, it should be mentioned for completeness, even though UPnP and NAT-PMP are more widely deployed. It's also worth noting that at least in principle PCP supports the ability to get edge information from the PCP server that's actually at the final transition from NATted addresses to global addresses, so this doesn't have the limitations that you are ascribing to UPnP and NAT-PMP. This is worth mentioning not only because it might be helpful, but also because if the operator has populated the reverse tree for their private address space, the outer global address isn't going to refer to the customer. Another point about global addresses versus NATted addresses at the CPE-PE edge is that protocols such as Dual-stack Light, Lightweight 4over6 and MAP will produce weird results for location determination and are only available on networks with native IPv6 capability, so LIS results obtained over IPv4 when these tunneling mechanisms are in use should be treated in a similar manner to LIS results obtained over a VPN connection. It is _possible_ with lw4over6 and MAP (and maybe DS-Lite) to use the address+port range to specifically identify the customer endpoint, but given that it's much easier to do with IPv6, this seems pointless. A similar issue exists for 6RD and other tunneled delivery of IPv6. In 4.3, given that LIS discovery is a fairly infrequent operation, is there really any point in restricting the set of prefix masks at which LIS records can be placed? It seems to me that the number of queries you'd get by starting at /64 and going one nybble at a time up the tree would be perfectly reasonable for an operation that happens infrequently. It would add latency if you are trying to locate a LIS as a prelude to making an emergency call, however. Also, why bother looking up the IPv6 address? It seems to me that there is no chance that a LIS server is going to be configured on a per-IP-address basis, particularly since IPv6 addresses will not be allocated to end users. Are you attempting to account for the possibility that the provider might NAT the customer down to a single IPv6 address? If the purpose of this is to locate handsets on a mobile network, where the handset might well have been given a /128 by the provider, it might be worth mentioning that. In 4.5, this whole mechanism is likely to fail for resolvers that implement RFC 6303. In the last paragraph of 4.5, the outcome described seems bad enough to beg for mitigation. Presumably in the scenario shown in figure 2, it's a bad outcome for the host to use STUN to get the public IP address corresponding to the outer edge of the NAT, and similarly a bad outcome for the CPE to query DNS A rather than DNS B. The right way to solve this problem, presuming for the moment that the ISP cares about providing accurate LIS service, would be to publish a global IP address belonging to the ISP in the global DNS for the LIS corresponding to the ISP's external address pool. This global IP address would however be configured on a host _inside the NAT_, and of course routing inside the NAT would have to reach that host without crossing the NAT, so that packets reach the LIS with the CPE's NATted IP address as the source address. This can then be used to provide accurate location information, because the CPE's IP address can be directly associated with the customer. This protocol relies heavily on STUN, but STUN server address discovery is problematic, and is not discussed. In reading up on this, I've encountered several assertions that STUN works well with existing home gateways, but no document explaining how it works. If your belief that STUN will address this problem is based on such documentation, a reference to it would be helpful. |
2013-12-01
|
07 | Ted Lemon | Ballot comment and discuss text updated for Ted Lemon |
2013-12-01
|
07 | Ted Lemon | [Ballot discuss] (1) This specification relies on home gateways not following RFC 6303. Some of the advice given in the spec will simply fail … [Ballot discuss] (1) This specification relies on home gateways not following RFC 6303. Some of the advice given in the spec will simply fail if RFC 6303 is implemented by the HG. It would be better to assume RFC6303 is being followed by the DNS proxy/resolver in the HG, and write the spec so that it prefers a solution that doesn't rely on successful resolution of names in in-addr.arpa or ip6.arpa for RFC1918 address spaces. I've suggested a way to do this in the comments, and would be happy to work with the authors to fully flesh out this solution if it seems plausible to them. My understanding of how a LIS operates is not very good, though, so I may be assuming capabilities that a typical LIS doesn't actually have. (2) The document assumes that a device that is implementing this discovery mechanism will be able to distinguish between a VPN and a non-VPN connection. How this is done is not discussed. I am skeptical that this is possible. I would like to see the document go into this in more detail if the authors actually know how to make this happen. A similar problem exists for non-VPN tunnels, as I have mentioned in the comments. Unfortunately, I don't see any obvious way to distinguish between location-bound IP addresses and tunneled IP addresses. I think the way to address point 2 is simply to recommend best practices for setting up LIS configurations in these situations. Generally speaking providers will have control of the reverse tree for these tunnels. It would be helpful if there were a way for the DNS response to include a record in addition to the NAPTR (or as part of the NAPTR if possible) that indicates that if an alternate LIS is available, it should be preferred. Is it possible that this is documented elsewhere? Or is there a way for the LIS itself to provide this advice based on the source address of the query? |
2013-12-01
|
07 | Ted Lemon | [Ballot comment] What's the IETF consensus status of this document? It's set to Unknown. In 4.1, paragraph three mentions UPnP and NAT-PMP, but doesn't mention … [Ballot comment] What's the IETF consensus status of this document? It's set to Unknown. In 4.1, paragraph three mentions UPnP and NAT-PMP, but doesn't mention Port Control Protocol (PCP), RFC 6887. Given that PCP is the only protocol in this genre that has an IETF standard written to describe it, it should be mentioned for completeness, even though UPnP and NAT-PMP are more widely deployed. It's also worth noting that at least in principle PCP supports the ability to get edge information from the PCP server that's actually at the final transition from NATted addresses to global addresses, so this doesn't have the limitations that you are ascribing to UPnP and NAT-PMP. This is worth mentioning not only because it might be helpful, but also because if the operator has populated the reverse tree for their private address space, the outer global address isn't going to refer to the customer. Another point about global addresses versus NATted addresses at the CPE-PE edge is that protocols such as Dual-stack Light, Lightweight 4over6 and MAP will produce weird results for location determination and are only available on networks with native IPv6 capability, so LIS results obtained over IPv4 when these tunneling mechanisms are in use should be treated in a similar manner to LIS results obtained over a VPN connection. It is _possible_ with lw4over6 and MAP (and maybe DS-Lite) to use the address+port range to specifically identify the customer endpoint, but given that it's much easier to do with IPv6, this seems pointless. A similar issue exists for 6RD and other tunneled delivery of IPv6. In 4.3, given that LIS discovery is a fairly infrequent operation, is there really any point in restricting the set of prefix masks at which LIS records can be placed? It seems to me that the number of queries you'd get by starting at /64 and going one nybble at a time up the tree would be perfectly reasonable for an operation that happens infrequently. It would add latency if you are trying to locate a LIS as a prelude to making an emergency call, however. Also, why bother looking up the IPv6 address? It seems to me that there is no chance that a LIS server is going to be configured on a per-IP-address basis, particularly since IPv6 addresses will not be allocated to end users. Are you attempting to account for the possibility that the provider might NAT the customer down to a single IPv6 address? If the purpose of this is to locate handsets on a mobile network, where the handset might well have been given a /128 by the provider, it might be worth mentioning that. In 4.5, this whole mechanism is likely to fail for resolvers that implement RFC 6303. In the last paragraph of 4.5, the outcome described seems bad enough to beg for mitigation. Presumably in the scenario shown in figure 2, it's a bad outcome for the host to use STUN to get the public IP address corresponding to the outer edge of the NAT, and similarly a bad outcome for the CPE to query DNS A rather than DNS B. The right way to solve this problem, presuming for the moment that the ISP cares about providing accurate LIS service, would be to publish a global IP address belonging to the ISP in the global DNS for the LIS corresponding to the ISP's external address pool. This global IP address would however be configured on a host _inside the NAT_, and of course routing inside the NAT would have to reach that host without crossing the NAT, so that packets reach the LIS with the CPE's NATted IP address as the source address. This can then be used to provide accurate location information, because the CPE's IP address can be directly associated with the customer. This protocol relies heavily on STUN, but STUN server address discovery is problematic, and is not discussed. In reading up on this, I've encountered several assertions that STUN works well with existing home gateways, but no document explaining how it works. If your belief that STUN will address this problem is based on such documentation, a reference to it would be helpful. |
2013-12-01
|
07 | Ted Lemon | [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon |
2013-11-30
|
07 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-11-29
|
07 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-11-25
|
07 | Cindy Morgan | Created "Approve" ballot |
2013-11-25
|
07 | Cindy Morgan | Closed "Approve" ballot |
2013-11-22
|
07 | Richard Barnes | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-11-22
|
07 | Richard Barnes | Telechat date has been changed to 2013-12-05 from 2013-08-29 |
2013-11-22
|
07 | Richard Barnes | Ballot has been issued |
2013-11-18
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call (ends 2013-11-18) |
2013-11-13
|
07 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2013-11-13
|
07 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-geopriv-res-gw-lis-discovery-07, which is currently in Last Call, and has the following comments: We understand that this document doesn't require … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-geopriv-res-gw-lis-discovery-07, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. IANA requests that the IANA Considerations section of the document remain in place upon publication. If this assessment is not accurate, please respond as soon as possible. |
2013-11-11
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Nevil Brownlee |
2013-11-11
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Nevil Brownlee |
2013-11-08
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2013-11-08
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2013-11-04
|
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: (Location Information Server (LIS) Discovery … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Location Information Server (LIS) Discovery using IP address and Reverse DNS) to Informational RFC The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'Location Information Server (LIS) Discovery using IP address and Reverse DNS' as Informational RFC 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 2013-11-18. 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 The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway. This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-geopriv-res-gw-lis-discovery/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-geopriv-res-gw-lis-discovery/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-11-04
|
07 | Cindy Morgan | State changed to In Last Call (ends 2013-07-31) from Last Call Requested |
2013-11-04
|
07 | Cindy Morgan | Last call announcement was generated |
2013-11-04
|
07 | Richard Barnes | Last call was requested |
2013-11-04
|
07 | Richard Barnes | State changed to Last Call Requested from AD Evaluation |
2013-11-04
|
07 | Martin Thomson | New version available: draft-ietf-geopriv-res-gw-lis-discovery-07.txt |
2013-09-09
|
06 | Richard Barnes | Moving to AD Eval pending changes, WG review, and re-LC |
2013-09-09
|
06 | Richard Barnes | State changed to AD Evaluation from IESG Evaluation::AD Followup |
2013-09-07
|
06 | Adrian Farrel | [Ballot comment] The authors have added some very good privacy text to this document, and I thank them for that. However, their work is predicated … [Ballot comment] The authors have added some very good privacy text to this document, and I thank them for that. However, their work is predicated on geopriv being a sound idea - i.e. an LIS being something that an application trusts to know where its hosting device is, and that a user will have the clue/knobs to disable the feature if they want to. The current climate suggests both that users lack this clue and that applications may do stuff without telling the user. Furthermore, we can be relatively certain that an LIS operator cannot be trusted if for no other reason than they be served with an instrument of local law. It does not seem reasonable (within the scope of criteria for Discusses) for me to continue to push this point as one requiring resolution in this document even though I continue to believe that the mechanism introduced here will expose users who were previously (unknown to them) protected by home gateways. There has been some discussion that the geopriv working group might start to actively work on a location discovery process that can be used and still preserve the user's privacy, But absent that, I cannot in all conscience support the publication of this work. I will therefore Abstain. |
2013-09-07
|
06 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to Abstain from Discuss |
2013-09-06
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-09-06
|
06 | Martin Thomson | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2013-09-06
|
06 | Martin Thomson | New version available: draft-ietf-geopriv-res-gw-lis-discovery-06.txt |
2013-08-29
|
05 | Cindy Morgan | State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2013-08-29
|
05 | Sean Turner | [Ballot discuss] aside: I wonder what the average number of discusses for a geopriv draft is. From the secdir review: The authors mention that RFC … [Ballot discuss] aside: I wonder what the average number of discusses for a geopriv draft is. From the secdir review: The authors mention that RFC 5986 is the preferred method whenever it is supported. I believe that this is because it is more accurate. First question: am I correct in believing this? Secondly, is there any way an attacker could a) cause a device to identify the wrong domain name and b) if a device identifies an incorrect domain name (whether or not the attacker can cause this to happen) is there anyway an attacker can exploit that? Question 2a) may be difficult to answer because the draft does not mandate any particular solution. Indeed it cannot, because the solution used will depend on what is supported locally. But if the answers to questions 1 and 2b) are "yes" it might be worthwhile to point this out in the security considerations section as an additional reason to use the solution given in RFC5389 whenever it is available. |
2013-08-29
|
05 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2013-08-29
|
05 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-08-29
|
05 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-08-28
|
05 | Pete Resnick | [Ballot discuss] I disagree with the WG's assessment that this is an Informational document. Section 4.2 is protocol. This document specifies a series of queries … [Ballot discuss] I disagree with the WG's assessment that this is an Informational document. Section 4.2 is protocol. This document specifies a series of queries to determine a LIS based on an IP address of the client. It proposes how to form the query, the types of responses to expect, an algorithm for additional queries based on portions of the IP address, etc. I simply can't see how this is not a Proposed Standard. |
2013-08-28
|
05 | Pete Resnick | Ballot discuss text updated for Pete Resnick |
2013-08-28
|
05 | Pete Resnick | [Ballot discuss] I disagree with the WG's assessment that this is an Information document. Section 4.2 is protocol. This document specifies a series of queries … [Ballot discuss] I disagree with the WG's assessment that this is an Information document. Section 4.2 is protocol. This document specifies a series of queries to determine a LIS based on an IP address of the client. It proposes how to form the query, the types of responses to expect, an algorithm for additional queries based on portions of the IP address, etc. I simply can't see how this is not a Proposed Standard. |
2013-08-28
|
05 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick |
2013-08-28
|
05 | Joel Jaeggli | [Ballot discuss] first support adrian's dicuss and I do belive that it is discuss0-worthy by our current criterion... Second I deeply concerned (though perhaps I … [Ballot discuss] first support adrian's dicuss and I do belive that it is discuss0-worthy by our current criterion... Second I deeply concerned (though perhaps I shouldn't be): that what amounts to classful addressing is being proposed for embedding in DNS names. how is that not a harmful precident? I have visions of that being reused in totally inaprropiate fashion, driving address/prefix assingment procedures and so on. |
2013-08-28
|
05 | Joel Jaeggli | Ballot discuss text updated for Joel Jaeggli |
2013-08-28
|
05 | Joel Jaeggli | [Ballot discuss] first support stephen's dicuss and I do belive that it is discuss0-worthy by our current criterion... Second I deeply concerned (though perhaps I … [Ballot discuss] first support stephen's dicuss and I do belive that it is discuss0-worthy by our current criterion... Second I deeply concerned (though perhaps I shouldn't be): that what amounts to classful addressing is being proposed for embedding in DNS names. how is that not a harmful precident? I have visions of that being reused in totally inaprropiate fashion, driving address/prefix assingment procedures and so on. |
2013-08-28
|
05 | Joel Jaeggli | [Ballot Position Update] New position, Discuss, has been recorded for Joel Jaeggli |
2013-08-27
|
05 | Stephen Farrell | [Ballot discuss] (1) I don't get how its hard to configure a LIS name/addr but easy to configure a STUN server - can you explain? … [Ballot discuss] (1) I don't get how its hard to configure a LIS name/addr but easy to configure a STUN server - can you explain? (2) Doesn't this require an ISP/access network to likely be able to answer DNS queries for all sorts of 1918 derived names? That seems undesirable - why is is justified here? |
2013-08-27
|
05 | Stephen Farrell | [Ballot comment] I agree with Adrian's discuss. I would further note that pretty much every geopriv dfaft seems to get a "this is pretending to … [Ballot comment] I agree with Adrian's discuss. I would further note that pretty much every geopriv dfaft seems to get a "this is pretending to handle privacy" discuss, but that the discuss-criteria are preventing the IESG from doing more than tinkering here. I'm not sure if that's really worthy of discussion within the IESG, but perhaps we might consider an addition to the discuss criteria that privacy also needs to be addressed and is discuss-worthy? But I'm a bit reluctant to go there in the absence of some privacy BCPs which we don't have (should we?) |
2013-08-27
|
05 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-08-27
|
05 | Stewart Bryant | [Ballot discuss] I agree with Adrian's discuss as I had the same concerns when reading the text. |
2013-08-27
|
05 | Stewart Bryant | [Ballot Position Update] New position, Discuss, has been recorded for Stewart Bryant |
2013-08-26
|
05 | Amy Vezza | Document shepherd changed to Alissa Cooper |
2013-08-26
|
05 | Brian Haberman | [Ballot discuss] 1) This document rightly states that the approach documented is brittle and could possibly do more harm than good. The right thing to … [Ballot discuss] 1) This document rightly states that the approach documented is brittle and could possibly do more harm than good. The right thing to do is use the approach described in RFC 5986. What I want to discuss is why does section 4.3 say: "The DHCP method described in [RFC5986] SHOULD be attempted on all local network interfaces before attempting this method." Why is this not a MUST? In what situation(s), would a device not perform the RFC 5986 approach first? 2) I think it should be noted that this approach will most likely not work if a device is configured to use a public DNS (e.g., 8.8.8.8). The question that arises though, is how would the LIS discovery process *know* that the device is configured to use an alternative DNS server? |
2013-08-26
|
05 | Brian Haberman | [Ballot comment] I strongly support Adrian's point on this work. |
2013-08-26
|
05 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2013-08-26
|
05 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-08-25
|
05 | Adrian Farrel | [Ballot discuss] I am raising this as a Discuss because I believe the issue needs more debate amongst the IESG. I acknowledge that I do … [Ballot discuss] I am raising this as a Discuss because I believe the issue needs more debate amongst the IESG. I acknowledge that I do not appear to have a Discuss that meets the normal Discuss criteria, and so I expect that I will clear or move to an Abstain after we have talked about this. I would be a lot happier with this document if it included a strong warning that the use of location services within a home environment may release information about the user that many would consider a significant violation of privacy. Unlike mobile environments, the home cannot disguise its location or identity by moving to a new location. The difficulty of finding an LIS across a home gateway has, until now, provided significant protection for home users who were unaware of the privacy issues related to geopriv location announcement. This work will expose home users to behavior by applications they may be running that will announce their location-sensitive data without their explicit permission. No statements of good conduct by application providers or LIS operators can protect a non-savvy user in situation. Until and unless the geopriv working group actively works on a location discovery process that can be used and still preserve the user's privacy, I cannot in all conscience support the publication of this work. Since such work is in scope for the working group, I assume that there is some reason why the working group has elected only to work on mechanisms that disclose location. I believe that, at the least, this issue needs to be properly discussed before the IETF goes further down the path of this single approach. --- Just as a by-the-by, the Security section seems to say "It you use this mechanism you're likely to end up with an LIS that could be an imposter and there is currently no way to detect this." Is that wise? |
2013-08-25
|
05 | Adrian Farrel | Ballot discuss text updated for Adrian Farrel |
2013-08-25
|
05 | Adrian Farrel | [Ballot discuss] I am raising this as a Discuss because I believe the issue needs more debate amongst the IESG. I acknowledge that I do … [Ballot discuss] I am raising this as a Discuss because I believe the issue needs more debate amongst the IESG. I acknowledge that I do not appear to have a Discuss that meets the normal Discuss criteria, and so I expect that I will clear or move to an Abstain after we have talked about this. I would be a lot happier with this document if it included a strong warning that the use of location services within a home environment may release information about the user that many would consider a significant violation of privacy. Unlike mobile environments, the home cannot disguise its location or identity by moving to a new location. The difficulty of finding an LIS across a home gateway has, until now, provided significant protection for home users who were unaware of the privacy issues related to geopriv location announcement. This work will expose home users to behavior by applications they may be running that will announce their location-sensitive data without their explicit permission. No statements of good conduct by application providers or LIS operators can protect a non-savvy user in situation. Until and unless the geopriv working group actively works on a location discovery process that can be used and still preserve the user's privacy, I cannot in all conscience support the publication of this work. Since such work is in scope for the working group, I assume that there is some reason why the working group has elected only to work on mechanisms that disclose location. I believe that, at the least, this issue needs to be properly discussed before the IETF goes further down the path of this single approach. --- Just as a by-the-by, the Security section seems to say "It you use this mechanism you're likely to end up with an LIS that could be an imposter and there is currently no way to detect this. Is that wise? |
2013-08-25
|
05 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel |
2013-08-25
|
05 | Richard Barnes | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-08-25
|
05 | Richard Barnes | Ballot has been issued |
2013-08-25
|
05 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2013-08-25
|
05 | Richard Barnes | Created "Approve" ballot |
2013-08-22
|
05 | Richard Barnes | Placed on agenda for telechat - 2013-08-29 |
2013-08-02
|
05 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Catherine Meadows. |
2013-07-31
|
05 | Peter Yee | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. |
2013-07-31
|
05 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-07-23
|
05 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2013-07-23
|
05 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-geopriv-res-gw-lis-discovery-05, which is currently in Last Call, and has the following comments: We understand that this document doesn't require … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-geopriv-res-gw-lis-discovery-05, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. If this assessment is not accurate, please respond as soon as possible. |
2013-07-18
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2013-07-18
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2013-07-18
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2013-07-18
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2013-07-17
|
05 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2013-07-17
|
05 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Location Information Server (LIS) Discovery … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Location Information Server (LIS) Discovery using IP address and Reverse DNS) to Informational RFC The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'Location Information Server (LIS) Discovery using IP address and Reverse DNS' as Informational RFC 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 2013-07-31. 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 The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway. This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-geopriv-res-gw-lis-discovery/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-geopriv-res-gw-lis-discovery/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-07-17
|
05 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-07-17
|
05 | Richard Barnes | Last call was requested |
2013-07-17
|
05 | Richard Barnes | State changed to Last Call Requested from Last Call Requested |
2013-07-17
|
05 | Richard Barnes | Last call was requested |
2013-07-17
|
05 | Richard Barnes | State changed to Last Call Requested from Last Call Requested |
2013-07-17
|
05 | Richard Barnes | Last call was requested |
2013-07-17
|
05 | Richard Barnes | Ballot approval text was generated |
2013-07-17
|
05 | Richard Barnes | State changed to Last Call Requested from AD Evaluation |
2013-07-17
|
05 | Richard Barnes | Ballot writeup was changed |
2013-07-17
|
05 | Richard Barnes | Ballot writeup was generated |
2013-07-17
|
05 | Richard Barnes | Changed document writeup |
2013-07-17
|
05 | Richard Barnes | Last call announcement was generated |
2013-06-21
|
05 | Richard Barnes | State changed to AD Evaluation from Publication Requested |
2013-04-05
|
05 | 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? The type of RFC being requested is Informational. Informational is appropriate because this document specifies only recommendations for provisioning of discovery records in the DNS; it defines no new protocol. The title page header indicates that the document is to be Informational. (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: The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway. This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device. Working Group Summary: There is strong consensus around this document in the working group. It is required for the HELD protocol's discovery mechanism to work through NATs and other residential gateways. Document Quality: There are a few existing implementations of the protocol. It has been incorporated into several emerging standards, especially for emergency calling. The document received thorough review from the DNS community on its use of the reverse DNS. Personnel: The Document Shepherd is Alissa Cooper. The responsible Area Director is Richard Barnes. (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 find it clear and ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I do not have concerns about the depth or breadth of review that has been performed. (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. The document defines a new way to use the reverse DNS tree (i.e., new records besides PTR), and an algorithm for searching the reverse DNS tree to find provisioned records. The document has been reviewed several times by members of the DNS community, on the GEOPRIV and DNSEXT mailing lists, and the comments raised have been resolved. (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. I do not have any specific 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? All authors have confirmed that all relevent IPR disclosures have been filed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed with regard to this document. (9) 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 strong consensus for this document. Several WG participants have expressed the opinion that it addresses a necessary use case. (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 are no threatened appeals. (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. I have checked the document and did not find any ID nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. This document does not require any formal reviews. (13) Have all references within this document been identified as either normative or informative? Yes. References are divided into normative and informative. (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? There are no such references. (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. There are no such references. (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 WG considers it unnecessary. This document does not change the status of any existing 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). This document does not make any request of IANA. (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. The document does not create any new IANA registries. (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. There is no formal language in this document. |
2013-04-05
|
05 | Cindy Morgan | Note added 'Alissa Cooper (acooper@cdt.org) is the document shepherd.' |
2013-04-05
|
05 | Cindy Morgan | Intended Status changed to Informational |
2013-04-05
|
05 | Cindy Morgan | IESG process started in state Publication Requested |
2013-04-05
|
05 | (System) | Earlier history may be found in the Comment Log for draft-thomson-geopriv-res-gw-lis-discovery |
2013-04-05
|
05 | Ray Bellis | New version available: draft-ietf-geopriv-res-gw-lis-discovery-05.txt |
2012-09-25
|
04 | Ray Bellis | New version available: draft-ietf-geopriv-res-gw-lis-discovery-04.txt |
2012-03-29
|
03 | Ray Bellis | New version available: draft-ietf-geopriv-res-gw-lis-discovery-03.txt |
2011-09-12
|
02 | (System) | New version available: draft-ietf-geopriv-res-gw-lis-discovery-02.txt |
2011-03-14
|
01 | (System) | New version available: draft-ietf-geopriv-res-gw-lis-discovery-01.txt |
2011-01-31
|
00 | (System) | New version available: draft-ietf-geopriv-res-gw-lis-discovery-00.txt |