Skip to main content

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