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

[Martin Duke <[e-mail]>]

Thanks for following up, Ted. It looks good to me.

On Mon, Jan 29, 2024 at 2:27 PM Ted Lemon <[e-mail]> wrote:

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