[apps-discuss] AppsDir reivew of draft-ietf-geopriv-res-gw-lis-discovery

["Murray S. Kucherawy" <[e-mail]>]

I have been selected as the Applications Area Directorate (appsdir) reviewer
for this draft.  (For background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments you may
receive.  Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-geopriv-res-gw-lis-discovery
Title: Location Information Server (LIS) Discovery using IP address and
	Reverse DNS
Reviewer: Murray S. Kucherawy
Review Date: August 18, 2013
IETF Last Call Date: Completed July 31, 2013
IESG Telechat Date: N/A

SUMMARY: This document is mostly ready to go as an Informational document,
but a few things in terms of document flow need to be reviewed, plus some
other minor points need consideration.

MAJOR ISSUES: 

I found an issue with the flow of the document going from 4.1 to 4.2.  I had
to re-read 4.2 several times to understand what's going on here.  Maybe
a quick set of ordered bullets that show the general steps the algorithm
will follow, probably up in Section 4, would help.  Something like:

"The goal here is to produce a small set of NAPTR queries to find the LIS
based on a set of derived IP addresses.  The steps of the algorithm are:

1. collect some IP addresses that refer to the Device
2. convert them into in-addr.arpa or ip6.arpa style names
3. issue NAPTR queries on those names
4. progressively shorten the names and repeat the queries until a hit is found"

..using wording to your liking.  Then Section 4.1 maps to step 1 and Section
4.2 maps to steps 2-4 quite nicely.  You could break Section 4.2 up such that
each step has its own (small) section as well, and turn what you have now
as 4.3 into 5, and so on downward.  The main point is that I didn't really
understand how you were trying to accomplish your goal until I was most
of the way through 4.2.

MINOR ISSUES: 

The use of "Device" as (apparently) a proper noun without a definition is
curious.  There are some uses of "device" as well, and I don't know how
they're different.

In Section 3.1, the sixth paragraph ("Existing residential gateways...") seems
unnecessary given the content of the one right before it.

In Section 4.2, the SHOULD NOT doesn't seem to be right to me as it doesn't
affect this protocol at all should that advice be ignored.  I agree a bunch
of extra unnecessary DNS traffic is avoided if an operator complies, which
is hardly a bad thing, but this specific protocol is unaffected.

Section 4.2 would really benefit from at least one example.

The second paragraph of Section 4.6 seems redundant to the discussion in
Section 4.1.

Are the SHOULDs in Section 4.7 meant to describe protocol interoperability
requirements, or capability requirements (a la an Applicability Statement)?

Sections 4.2 and 4.7 talk about the "upward" walk to find the NAPTR record.
If, say, a v4 operator only puts a record at a /16 node, then it's
guaranteed to get three queries for every Device connecting.  It's guaranteed
four in the case of a v6 operator who only puts a record at a /32 node.
I wonder if this is worth mentioning as a tradeoff versus a smaller zone file,
or if it's just plain obvious, or if caching is expected to handle most of
this.

Shouldn't RFC3424 be Informative?

NITS: 

Section 1: s/when it is considered/when one considers/

Section 4:
OLD: "...each IP address that it is potentially reachable from."
NEW: "...each IP address from which it is potentially reachable."

Section 4.1:
OLD: "...by any access network these methods are not mandated."
NEW: "...by any access network, these methods are not mandated."

Section 4.6:
OLD: "Configuration of STUN server ..."
NEW: "Configuration of a STUN server ..."
The acronym "UNSAF" has to make at least some security people giggle.