Re: [dnssd] Martin Duke's No Objection on draft-ietf-dnssd-srp-23: (with COMMENT)

[Ted Lemon <[e-mail]>]

Martin, thanks for the review, sorry the response has taken so long.
Apologies also to Joerg Ott for not responding to the tsv-art review (see
below).

On Tue, Aug 8, 2023 at 10:12 PM Martin Duke via Datatracker <
[e-mail]> wrote:

>
> I see no on-list response to Joerg Ott's TSVART review. If there is not a
> private one, please respond.
>

I don't know what happened here—I think I must have accidentally deleted
this. I've included the comments inline here:

This could raise the issue that not much is said about UDP transmission
> behavior,
> not in this spec, nor actually in most of the referenced ones.  RFC 1035
> discusses
> a retransmission timer to be set in the range of 2-5 seconds, none of the
> other
> cited DNS specs seem to be explicit about this at all, probably because
> common
> sense govern DNS implementations and DNS queries, if resolved iteratively,
> generally
> may not have more than a single transaction outstanding.  But does this
> also hold
> for series of updates, e.g., after synchronized reboots or something
> similar?


I was sure that we'd added text about this, but it's actually in the
update-lease document. I've copied that text into the SRP document since I
think it's relevant in both places.

Here is that text:

    <section>
      <name>Retransmission Strategy</name>
      <t>The DNS protocol, including DNS updates, can operate over UDP or
TCP. When using UDP, reliable
      transmission must be guaranteed by retransmitting if a DNS UDP
message is not acknowledged in a
      reasonable interval. <xref target="RFC1035" section="4.2.1"
sectionFormat="of"/> provides some
      guidance on this topic, as does <xref target="RFC1536" section="1"
sectionFormat="of"/>.
      <xref target="RFC8085" section="3.1.3" sectionFormat="of"/> also
provides useful guidance that
      is particularly relevant to DNS.</t>
    </section>

I am not a DNS expert and there may be specs that define the behavior for
> UDP-based
> operation more precisely or stating that only a single transaction to a
> given server
> may be outstanding at a given point in time, in which case it may be
> worthwhile
> explicitly pointing towards those.  If such don't exist, it may be
> worthwhile adding
> a word of caution for controlling series of transmissions in case such
> happen.


I've added (hopefully this will be non-controversial—it's certainly what
was intended):
   <section>
   <name>Successive Updates</name>
   <t>Service Registration Protocol does not require that every update
contain the same information.
     When an SRP requestor needs to send more than one SRP update to the
SRP registrar, it MUST send
     these sequentially: until an earlier update has been successfully
acknowledged, the requestor
     MUST NOT begin sending a subsequent update.</t>
 </section>

Non-transport nits:
> Sect. 3.2.5.5.1 talks about the KEY-LEASE value and suggests that it be
> the same
> as before (1st para) and then "nonzero" (3rd para).  What is supposed to
> happen if
> it is nonzero but not the same as before? Maybe state this explicitly?


The update-lease document is fully explicit about this. The answer is that
whatever lease is sent in the update is applied at that time.

The text flow in the bulleted lists in section 3.3.1 is sometimes hard to
> parse and,
> especially in 3.3.1.2 does not necessarily yield a complete sentence.


Hm. Fixing this was a significant edit, which would be hard to represent
here, so if you wouldn't mind, please take a look at the -24 document when
it's published and let me know if it makes more sense. I was trying to
reduce the word count, but I agree that with some of the later updates, the
text became a bit unwieldy and, as you say, doesn't even quite work as a
sentence.

Sect. 3.3.4 states: "To delete an individual subtype, an SRP Update must be
> constructed
> that contains the service type and all subtypes for that service".  Does
> this miss
> something like "except for the subtype to be deleted" in the end?


Good point--thanks for noticing this. I've added the exact text you
suggested.

The authors may want to do a careful pass on the normative language (upper
case
but also the of can vs. MAY).

I did a pass and found some shoulds that should be SHOULDs and one can that
should have been a MAY, as well as a few other bits of text that weren't
clearly normative nor non-normative that I was able to clarify—thanks for
suggesting this.