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

From: Richard Barnes <[email-masked]>
Date: Fri, 21 Jun 2013 11:50:53 -0400

I have reviewed this document, and have two major questions I would like to
discuss before sending it to LC.

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.

Question 2:
Section 4.1 requires addresses be ordered by "proximity".  It's not clear
to me what you mean by this (proximity to what?), or how an implementor is
supposed to detect proximity.  Could this sentence be safely deleted?

Couple of other minor comments:

-- Should the reference to RFC 3693 be changed to RFC 6280?
-- The document indirectly addresses considerations around CGN/LSN, without
using those terms directly.  It could be helpful to just say that, to help
make sure people realize what you're talking about.
-- In Section 4.1, a reference to PCP might be helpful.  I'm pretty sure it
can do similar things.
-- Section 4.5 comments on the required accuracy of the discovery process.
 ("It is not necessary...").  It seems like the real goal here is just to
get to the right LIS, not the host.  Why not just say that directly?  "It
is not necessary that the IP addressed used to discover a LIS be the an
actual IP address assigned to the target device, only that the IP address
map to the correct LIS for the device (e.g., an address in the same access
network as the device)."
-- Section 6, for clarity: "identity of a LIS" -> "identity of a LIS
serving a given network"

Thanks,
--Richard

---

From: Ray Bellis <[email-masked]>
Date: Tue, 25 Jun 2013 07:22:29 +0000

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

> I have reviewed this document, and have two major questions I would like to discuss before sending it to LC.
> 
> 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.

I'll look into that.  The caveats around using zone cuts detailed in RFC 5507 probably don't apply here.

> Question 2: 
> Section 4.1 requires addresses be ordered by "proximity".  It's not clear to me what you mean by this (proximity to what?), or how an implementor is supposed to detect proximity.  Could this sentence be safely deleted?

Martin?

> -- Should the reference to RFC 3693 be changed to RFC 6280?

Probably, yes :)

> -- The document indirectly addresses considerations around CGN/LSN, without using those terms directly.  It could be helpful to just say that, to help make sure people realize what you're talking about.

ack

> -- In Section 4.1, a reference to PCP might be helpful.  I'm pretty sure it can do similar things.

OK, we'll check.

> -- Section 4.5 comments on the required accuracy of the discovery process.  ("It is not necessary...").  It seems like the real goal here is just to get to the right LIS, not the host.  Why not just say that directly?  "It is not necessary that the IP addressed used to discover a LIS be the an actual IP address assigned to the target device, only that the IP address map to the correct LIS for the device (e.g., an address in the same access network as the device)."

Good call, I think.

> -- Section 6, for clarity: "identity of a LIS" -> "identity of a LIS serving a given network"

OK.

thanks,

Ray

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Jun 2013 16:33:49 -0700

>> Section 4.1 requires addresses be ordered by "proximity".  It's not clear to me what you mean by this (proximity to what?), or how an implementor is supposed to detect proximity.  Could this sente…

The actual text:

   [...]  These are ordered by
   proximity, with those addresses that are used in adjacent network
   segments being favoured over those used in public or remote networks.

The intent is to define proximity using the remainder of the sentence.
 Clearly that isn't precise enough.

I have no good recommendation, other than stipulating an ordering
based on discovery method, except that we don't explicitly mandate
any.  If we actually said: use PCP and STUN, then we could say: use
the PCP address before the STUN address (if that was the right thing
to do, which is probably true, if they are different at all).

---

From: tsg <[email-masked]>
Date: Tue, 25 Jun 2013 18:42:41 -0700

> On 25 June 2013 00:22, Ray Bellis <[email-masked]> wrote:

You could state proximity as a distance range factor or an uncertainty 
factor.  The way it reads it seems to assign PRIORITY to the differing 
proximity models (i.e proximity relative to internal or external 
networking).

Todd
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

-- 
// Standard "perasonal email" disclaimers apply