Re: [dnssd] Review of draft-ietf-dnssd-srp-02

[Ted Lemon <[e-mail]>]

Jonathan, thanks for the thorough review. Sorry for taking so long to respond.  I have updated the draft with changes to address your comments. Diffs can be found here: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-dnssd-srp-05.txt <https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-dnssd-srp-05.txt>

I have additional work to do on this based on Esko’s review, but I’ll do that in a separate update so the diffs don’t get confused. Comments below:


> On Oct 8, 2020, at 3:19 PM, Jonathan Hui <jonhui=[e-mail]> wrote:
> 
> I have reviewed this document.
> 
> I believe this document addresses a real pain point in constrained networks - namely how constrained devices can publish services with minimal round trips (i.e. one per update) and avoids the need for expensive multicast. This is of great interest to the Thread Group and Project CHIP efforts, both of which are based on IPv6.
> 
> Overall, I found the document well-written and easy to understand.
> 
> Detailed comments/questions below:
> 
> Intended status: Informational
> 
> Why not standards track?

Because I accidentally put “info” in the XML instead of “std”. :)

> 
> [RFC6763] that allows services to automatically register their
> 
> It's not clear to me at this point what "automatic" really means. It becomes clear later in the doc (e.g. Section 2.6.1), but I think it would help to be clear in the Introduction.

Thanks, this is a really good catch. I’ve substantially updated the introduction to explain this in more detail.

> 
> Manual configuration of the registraton domain can be done either by
> 
> Typo: "registraton" -> "registration"

:)

> using UDP unless TCP is required due to the size of the update.  It
> is the responsibility of a Constrained-Node Network supporting SRP to
> provide appropriate anycast routing to deliver the DNS updates to the
> appropriate server.  It is the responsibility of the SRP server
> 
> Is "appropriate" well-understood here? I could use some clarification on what requirements are placed on the Constrained-Node Network to support SRP anycast. For example, can there be more than one SRP server on the network? If so, does the anycast address always need to map to the same SRP server for a given host?

Interesting, this was actually fixed in a newer version. So the whole discussion of how to configure SRP on “constrained-node networks” is now left up to the specification for that network type.

> 
> o  The Host Description records for a service are a KEY RR, used to
>    claim exclusive ownership of the service registration, and one or
>    more RRs of type A or AAAA, giving the IPv4 or IPv6 address(es) of
>    the host where the service resides.
> 
> Are there recommendations/thoughts on how an SRP server should handle SRP updates containing multiple IPv6 addresses of varying scopes? Is this a topic within scope of this document?

I’ve added a paragraph to the validation section saying that link-scope and IPv4 autoconf addresses are invalid, and registrations that include them should be treated as invalid registrations.  I’ve also mentioned that addresses must be in scope for all potential clients of the SRP server, but haven’t explained this in more detail. I may add a section about this later.

> 
> updates do not include update prerequisites. The specified in
> 
> Typo: "The specified in..."

Oops!

> o  An SRP server is not required to implement general DNS Update
>    prerequsite processing.
> 
> Typo: "prerequsite" -> "prerequisite" 
> 

:)

> The service generates a public/private key pair.  This key pair MUST
> be stored in stable storage; if there is no writable stable storage
> on the client, the client MUST be pre-configured with a public/
> private key pair in read-only storage that can be used.  This key
> pair MUST be unique to the device.
> 
> Strictly speaking, we require the service to retain the key pair for as long as it would like to make updates to its existing service information. For example, should we recommend that a device generate a new key pair after factory reset (if it has the ability to do that)? I'm thinking that the public key can serve as a static identifier.

Yes, that’s intended.  I’ve added some text.

> 
> update is constructed by the client, it MUST include include an
> 
> Typo: "include include"

:)

> 
> updates, and MUST reject updates that would otherwise be SRP updates
> updates if they do not include leases.
> 
> Typo: "SRP updates updates"

Wow. :)

> 
> lease time Section 2.6.1.  Shorter TTLs will result in more frequent
> data refreshes; this increases latency on the client side, and
> increases load on any caching resolvers and on the authoritative
> server.  Longer TTLs will increase the likelihood that data in caches
> 
> Worth mentioning effect on network utilization? Or is that already implied?

OK.  I added text.

> 
> addresses in the records in question.  In addition, proxy should
> 
> Typo: "In addition, the proxy should..."

:)

> 
> specified in [I-D.ietf-dnsop-algorithm-update] section 3.1, in the
> 
> "section 3.1" link not pointing to the appropriate doc.

I’ve updated to point to the RFC.

> 
> 4. Privacy Considerations
> 
> Should we mention UDP here?

Dunno what you mean about this.

> 
> Should we mention the public key here?

I’ve added some text. I think we may also want to allow the client to say “don’t show my key.”

> 
> specification in [RFC8375]Section 7.
> 
> "Section 7" link not pointing to the appropriate doc.
> 

I’m not following this.

> Thanks.
> 
> --
> Jonathan Hui
> 
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd