Protocol Action: 'Location Information Server (LIS) Discovery using IP address and Reverse DNS' to Proposed Standard (draft-ietf-geopriv-res-gw-lis-discovery-08.txt)

The IESG <iesg-secretary@ietf.org> Mon, 27 January 2014 19:17 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0C11A0264; Mon, 27 Jan 2014 11:17:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjQk3KaPiwxa; Mon, 27 Jan 2014 11:17:13 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9920C1A0379; Mon, 27 Jan 2014 11:17:10 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'Location Information Server (LIS) Discovery using IP address and Reverse DNS' to Proposed Standard (draft-ietf-geopriv-res-gw-lis-discovery-08.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140127191710.7699.80155.idtracker@ietfa.amsl.com>
Date: Mon, 27 Jan 2014 11:17:10 -0800
Cc: geopriv mailing list <geopriv@ietf.org>, geopriv chair <geopriv-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jan 2014 19:17:14 -0000

The IESG has approved the following document:
- 'Location Information Server (LIS) Discovery using IP address and
   Reverse DNS'
  (draft-ietf-geopriv-res-gw-lis-discovery-08.txt) as Proposed Standard

This document is the product of the Geographic Location/Privacy Working
Group.

The IESG contact persons are Richard Barnes and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-geopriv-res-gw-lis-discovery/




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.


RFC Editor Note:

At the end of Section 7:
NEW:
"""
DNS queries that are not blocked as <xref target="RFC6303"/>
demands, or directed to servers outside the network, can cause the
addresses that are in use within the network to be exposed outside of
the network.  For resolvers within the network, implementing <xref
target="RFC6303"/> avoids this issue; otherwise, the problem cannot be
avoided without blocking DNS queries to external servers.
"""