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

[Richard Barnes <[e-mail]>]

Hi Ray,

Thanks for your reply.  That makes sense to me.  I'll go ahead and send
this to LC.

--Richard


On Tue, Jul 16, 2013 at 6:11 AM, Ray Bellis <[e-mail]>wrote:

>
> 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
>
>
>