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

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Sep 2013 10:44:38 -0700

Thanks Murray,

Inline responses, with added proof of the relevant changes in case you
get some crazy urge to review changes prior to the next revision
coming out.

On 19 August 2013 00:03, Murray S. Kucherawy <[email-masked]> wrote:
> 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.

Excellent point, and a good suggestion that I have ripped off:
https://github.com/martinthomson/drafts/commit/d739f1a085d93b9700777b7ea7ed1339e37bd782

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

It's capitalized in that way intentionally, because that's how RFC
6280 (and it's predecessor) operate, but it's probably worth pointing
out specially.  (I caught one lowercase mistake, thanks.)
https://github.com/martinthomson/drafts/commit/4a1eccec14f435f9139172f2911c43a39c414dcb

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

I think that the latter part regarding software update is still relevant.
https://github.com/martinthomson/drafts/commit/f429e52094f77e9062d1e1805982873dc958cf96

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

That's a fair cop, I think that world needs fewer uppercase words and
this is a good place to start.
https://github.com/martinthomson/drafts/commit/12d69045e6f28bb673bfea2f2b68928982c24e2e

> Section 4.2 would really benefit from at least one example.

OK
https://github.com/martinthomson/drafts/commit/29a4c98deaa1c9f9be66633e7bdfc7fd971318e9

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

OK
https://github.com/martinthomson/drafts/commit/8863446d6f58b315d9ea5696a31f1e6d55f15df6

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

Operational requirements that are necessary to ensure protocol interoperability.

Since we're describing a protocol, the record provisioning is one end
of that protocol.

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

I had thought that this was obvious.  And yes, I expect that this
stuff is going to be highly cacheable.

> Shouldn't RFC3424 be Informative?

Yep. Fixed.

> NITS:

https://github.com/martinthomson/drafts/commit/1fc55d3acb3cef23fea892dcd367c51e5916152f

> The acronym "UNSAF" has to make at least some security people giggle.

I'm sure that JDR is at least a little bit proud of that.