Re: [Geopriv] AD review of draft-ietf-geopriv-res-gw-lis-discovery-05

[Ray Bellis <[e-mail]>]

On 21 Jun 2013, at 16:50, Richard Barnes <[e-mail]> wrote:

> Question 1:
> I compared the discovery process in this document to the one in draft-google-self-published-geofeeds, which led me to wonder whether this document could make use of SOA records to guide the search.  A few of possible revisions to the algorithm come to mind: 
> 1. Instead of climbing, just skip to the SOA (The approach from the other document)
> 2. Query at SOA and less specific (regarding the SOA as a logical network boundary)
> 3. Query at SOA and more specific (if the nearest network hasn't provisioned, don't allow less-specifics to override)
> 
> Have the authors considered these possibilities?  Are any of these worth considering?  It seems like using the SOA record would help make it more predictable to network operators where they should provision the LIS discovery records.  My initial impression is that (2) seems to strike the balance between reducing queries, while still allowing fall-back.  Even if the answer is that there's no good use for SOA, it could be helpful to have a couple of sentences saying why.

The approach in draft-google-self-published-geofeeds is to query for a NAPTR record at the same owner name in .arpa as a device's PTR record should be, and if not found, use the SOA that would be returned in the negative response to determine the zone cut, and then issue a second NAPTR query at that owner name.

There are two flaws that I can see in this approach:

1.  The SOA record will not be returned if there are _other_ NAPTR records present for the same owner name.

2.  It doesn't permit jumping out of a delegated .arpa zone into the parent zone.

I think the first issue is kind of a show stopper, at least if one is using existing RRTYPES.  It might work if an application had a dedicated RRTYPE instead of re-using NAPTR.  I've just flagged this with the authors of that document.

I see the second issue as problematic for our particular application.  IMHO, delegation of your .arpa space should not prevent the discovery mechanism from finding your ISP LIS, nor require you to insert your own NAPTR records and keep those in sync with your ISP's.

To jump out above the zone cut to find the next less specific SOA would require the issuing of a "nonsense" query with at least one label removed, at which point you're kind of back to tree climbing.

kind regards,

Ray