Subject: [dnssd] Review of draft-ietf-dnssd-srp-12

From: Esko Dijk <[email-masked]>
Date: Thu, 11 Nov 2021 09:56:22 +0000

Thanks Ted for addressing the items of my previous review! Agree with all the changes so far.

Below a few remaining items in the -12 version that still need to be addressed, I think.

*** Abstract
The abstract text mentions the motivation for DNS-SRP, including details about 802.11 and 802.15.4 networks. Now I don’t see this argumentation (including the details about 802.11/802.15.4 networks) coming back anywhere in the draft. Normally (at least according to best practices in paper & report writing) an abstract does not introduce new, additional information. It only recaps or summarizes information from the overall document.  So if particular details are like the motivation for DNS-SRP, or particular suitable network types (802.11/802.15.4) are mentioned in an abstract they must also be mentioned somewhere else in the document e.g. in an introduction section.  However I don’t see these items coming back in the main document: the motivation/rationale for SRP is very minimal there.

*** 2.3.1.1
(See also my separate emails of August 18/19)  I find the text of this section very hard to read. But it does not have to be so complex! My idea was to define Service Discovery Instruction in a less detailed way and let the existing validation requirements of section 2.3.2 do their work to “eliminate” any bad cases of Service Discovery Instruction.  This avoid the intricate definition of interrelations between the Instruction types.

Here is an alternative proposed text:

An instruction within an SRP Update is a Service Discovery Instruction if

   *  it contains exactly one "Add to an RRSet" ([RFC2136], Section 2.5.1<https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) or exactly one "Delete an RR from an RRSet" ([RFC2136], Section 2.5.4<https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) RR update,
       o  which updates a PTR type RR,
       o  the target of which is a Service Instance Name,

       o  where the Service Instance Name is being used in at least one other Instruction in this same SRP Update,

   * and it contains no other RR UPDATEs.

This should work because due to the Section 2.3.2 validation requirements, first paragraphs, already puts in the needed constraints in a much clearer & simpler way.
We could discuss the above proposed text to see if people agree whether it is 1) clearer , 2) easier to implement, 3) correct,  or not.

Note also the sentence “it contains exactly one "Add to an RRSet" ([RFC2136], Section 2.5.1<https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) or exactly one "Delete an RR from an RRSet" ([RFC2136], Section 2.5.4<https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) RR update,”
which is in general also improving the existing text by pointing to the correct section numbers.

Also note the first sentence “An instruction within an SRP Update is a Service Discovery Instruction if” which would be an improvement on existing text I think, even if the present text is mostly kept.
(though I hope that won’t be the outcome …)

The existing text in -12 has “Delete RR” pointing to section 2.5.1 which is incorrect.

*** 5 Security Considerations
Given that TLS usage is specified, but that TLS can’t be used for authentication as we discussed, should we mention this fact briefly in Section 5?
E.g. “although TLS is RECOMMENDED to be used by an SRP client for privacy, it does not provide mutual authentication of client and server.”
The current section 5 only has considerations on the security of the KEY RR / SIG(0) mechanism but not related to TLS.

*** 8.2
*** 8.3
In your prior email you wrote:
> That is confusing. The reason for the trailing dot there is that it's a fully-qualified domain name, and such names end in a '.' to indicate the root label. But I think it's probably clearer to leave out the dot here.

I’m fine with having the dot in there, if it is needed in there (I wouldn’t know). Sorry for perhaps being not clear in my review email. The point was this:
In the sentence in 8.2 and in 8.3 (former 9.2/9.3) there’s a grammar issue ; two sentences are joined together.

   Availability of DNS Service Discovery Service Registration Protocol
   Service for a given domain is advertised using the
   "_dnssd-srp._tcp.<domain>" SRV record gives the target host and port
   where DNSSD Service Registration Service is provided for the named
   domain.

The sentence is similar to “Availability of taxi service for a given neighborhood is advertised using a billboard gives the address where taxi service is provided for the neighborhood.”  Doesn’t read too well ;)

What about

   Availability of DNS Service Discovery Service Registration Protocol
   Service for a given domain is advertised using the
   "_dnssd-srp._tcp.<domain>" SRV record. This record gives the target host and port
   where DNSSD Service Registration Service is provided for the named
   domain <domain>.

And the same fix for Section 8.3.

Best regards
Esko

IoTconsultancy.nl  |  Email/Teams: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Nov 2021 17:04:49 -0500

On Thu, Nov 11, 2021 at 4:56 AM Esko Dijk <[email-masked]>
wrote:

> *** Abstract
>
> The abstract text mentions the motivation for DNS-SRP, including details
> about 802.11 and 802.15.4 networks. Now I don’t see this argumentation
> (including the details about 802.11/802.15.4 networks) coming back anywhere
> in the draft. Normally (at least according to best practices in paper &
> report writing) an abstract does not introduce new, additional information.
> It only recaps or summarizes information from the overall document.  So if
> particular details are like the motivation for DNS-SRP, or particular
> suitable network types (802.11/802.15.4) are mentioned in an abstract they
> must also be mentioned somewhere else in the document e.g. in an
> introduction section.  However I don’t see these items coming back in the
> main document: the motivation/rationale for SRP is very minimal there.
>

Okay, this makes sense. I didn't manage to understand that from your
previous comment, even though I'm pretty sure that's what you already said.
:)

> *** 2.3.1.1
>
> (See also my separate emails of August 18/19)  I find the text of this
> section very hard to read. But it does not have to be so complex! My idea
> was to define Service Discovery Instruction in a less detailed way and let
> the existing validation requirements of section 2.3.2 do their work to
> “eliminate” any bad cases of Service Discovery Instruction.  This avoid the
> intricate definition of interrelations between the Instruction types.
>
>
>
>    *  it contains exactly one "Add to an RRSet" ([RFC2136], Section 2.5.1
> <https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) or exactly
> one "Delete an RR from an RRSet" ([RFC2136], Section 2.5.4
> <https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) RR update,
>        o  where the Service Instance Name is being used in at least one
> other Instruction in this same SRP Update,
>
> This should work because due to the Section 2.3.2 validation requirements,
> first paragraphs, already puts in the needed constraints in a much clearer
> & simpler way.
>
> We could discuss the above proposed text to see if people agree whether it
> is 1) clearer , 2) easier to implement, 3) correct,  or not.
>

No, this wouldn't be correct. The additional constraints you want to remove
are to ensure that if the Service Instruction is an Add, the Service
Description Instruction is also an Add, and if the Service Instruction is a
Delete, the Service Description instruction is also a delete. We could
explain that in 2.3.2, but currently we do not.

> Note also the sentence “it contains exactly one "Add to an RRSet" ([RFC2136],
> Section 2.5.1
> <https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) or exactly
> one "Delete an RR from an RRSet" ([RFC2136], Section 2.5.4
> <https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) RR update,”
>
> Also note the first sentence “An instruction within an SRP Update is a
> Service Discovery Instruction if” which would be an improvement on existing
> text I think, even if the present text is mostly kept.
>
> Given that TLS usage is specified, but that TLS can’t be used for
> authentication as we discussed, should we mention this fact briefly in
> Section 5?
>
> E.g. “although TLS is RECOMMENDED to be used by an SRP client for privacy,
> it does not provide mutual authentication of client and server.”
>
> The current section 5 only has considerations on the security of the KEY
> RR / SIG(0) mechanism but not related to TLS.
>

That seems like a good idea.

> > That is confusing. The reason for the trailing dot there is that it's a
> fully-qualified domain name, and such names end in a '.' to indicate the
> root label. But I think it's probably clearer to leave out the dot here.
>
>
>
> I’m fine with having the dot in there, if it is needed in there (I
> wouldn’t know). Sorry for perhaps being not clear in my review email. The
> point was this:
>
>    Service for a given domain is advertised *using the*
>
> *   "_dnssd-srp._tcp.<domain>" SRV record gives the target* host and port
>
> The sentence is similar to “Availability of taxi service for a given
> neighborhood is advertised using a billboard gives the address where taxi
> service is provided for the neighborhood.”  Doesn’t read too well ;)
>

Right. I again completely failed to understand that from your previous
comment—thanks for clarifying (or re-iterating).

>    "_dnssd-srp._tcp.<domain>" SRV record*. This record* gives the target
> host and port
>
>    domain *<domain>*.
> And the same fix for Section 8.3
>

That sounds good.

---

From: Esko Dijk <[email-masked]>
Date: Fri, 12 Nov 2021 12:23:46 +0000

> No, this wouldn't be correct. The additional constraints you want to remove are to ensure that if the Service Instruction is an Add, the Service Description Instruction is also an Add, and if the Service Instruction is a Delete, the Service Description instruction is also a delete. We could explain that in 2.3.2, but currently we do not.

That sounds more straightforward than the current text in the I-D! What about this text, then:

An instruction is a Service Discovery Instruction if it contains

   *  exactly one "Add to an RRSet" ([RFC2136], Section 2.5.1) or exactly one "Delete an RR from an
      RRSet" ([RFC2136], Section 2.5.4) RR update,
   *  which updates a PTR RR,
   *  the target of which is a Service Instance Name,
   *  for which name a Service Description Instruction is present in the
      SRP Update, and
   *  if the RR update is an "Add to an RRSet"
      instruction, that Service Description Instruction
      contains an "Add to an RRset" RR update for the SRV RR
      describing that service; and
   *  if the RR update is a "Delete an RR from an
      RRSet" update, the Service Description Instruction
      contains an "Delete an RR from an RRset" RR update;
   *  and no other add or delete RR updates.

This does modify the logic slightly (in second-last bullet) compared to the original but that’s now based on your explanation.
So one change is to define Service Discovery Instruction without recursively referring to Service Discovery Instruction itself, which I found confusing. Instead it refers to the “exactly one RR update” of the first bullet using the term “RR update”. That works because there’s exactly one. And also it removes the double negation that was present and the unclarity of the negative “does not match” in the definition (does not match against … ?) .

I’d like to reiterate one comment on 2.3.1.1 independent of the above. Not sure if you agree with that :
* Update sentence to: “it contains exactly one "Add to an RRSet" ([RFC2136], Section 2.5.1<https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) or exactly one "Delete an RR from an RRSet" ([RFC2136], Section 2.5.4<https://datatracker.ietf.org/doc/html/rfc2136#section-2.5.1>) RR update,” to point to the correct section numbers.

Best regards
Esko