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

Martin Duke <> Wed, 31 January 2024 15:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0E46C14F6F7; Wed, 31 Jan 2024 07:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7hTCnkd0qpqb; Wed, 31 Jan 2024 07:02:42 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 0941AC14F6E4; Wed, 31 Jan 2024 07:02:42 -0800 (PST)
Received: by with SMTP id a1e0cc1a2514c-7d5c890c67fso1740024241.0; Wed, 31 Jan 2024 07:02:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1706713361; x=1707318161;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rZEKgJaMBKDo9eAYQ6f6Yrp5UmWs31vyFe3vOCNeFSU=; b=KypXxRcIh6LJ07dtEct5sxPUYkerShi/bepurlELPTwhMM/tWJNaXun4hnAz/hT2cK EQRrwR47ORczX2L/uMx7gHBMTzqnOKFJhnhM4e8wGEg+hAHiaRkJxCN3k5nh00pEtyHk 7ETotcH+HUBvFOmu2ysuz/tA3DBIriRQG43jGe6WwR5qWyKeGU6U2Y35Scs3tHPc3Vlv 2tNxQQDUpWr27BUO62Tss2TyVrHJZ0coYmwPTS5a4vwRQ4qNBxGN5btIPubzE/KEu4Cc Zq4uN7F/fQvyi+Sh0kXHlHKZ5j7TWQM7AD1o1wiqC4OWGeEGM4/1jhhJ4w3A6NnuMZm1 g46g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1706713361; x=1707318161; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rZEKgJaMBKDo9eAYQ6f6Yrp5UmWs31vyFe3vOCNeFSU=; b=LCB+GEAziyKPdqgHlwS5To2A2of6/3L+K8miLkG0lJnBMFBVpu/dttBCQNuK1QAiHU +zDd5mb/2+KJCDSV2U92uX6J5/iqJs/a2YT1d/7grKqRM1C5rHgQBZO13TKuP5Sjprv/ 6MF7NnF+WfgsuHwz2aLT3qrUW0raLFJ/LgPDL/3XJ4usinGYMvX4QLlOsNGa002E5q+e CsGZXaGPn4Qy+DBv+JIHWrcHI1xruOatDIXpccmSVNibKOD5o5JwpB3klrB8abL04gzo UK8rSIwnjn4Eq6xVep+LdUJmosYPigdkO0wbEZHzQ5Q3mR/kEnuxfiE5tHNWJVucsBYx 72ZQ==
X-Gm-Message-State: AOJu0Yynf/3WgNmbqtgp9KWPmYyfRWsjIJNhevvx+9A8FfY+PdQrTQ1U tWOAHQqxKW2EO5qeGWkAhioECMgAfluAnM1pKV5PpjZU7Df2HmHCGT0qfs8ZSBUkgfS5fzvrdy/ xYjK4C9jDOiFJjDRuNrgDRCrGHoHKYB0g
X-Google-Smtp-Source: AGHT+IEV4/iGgtu7aj0SvIK/yUUn+50FSA+SHUDf0OFhDMENcMfMUsVj4HDjm2zhSm6oB1vPG4Z3lISZZyBNd197Kk0=
X-Received: by 2002:a05:6122:3a06:b0:4bd:483a:5128 with SMTP id fp6-20020a0561223a0600b004bd483a5128mr1712822vkb.9.1706713360599; Wed, 31 Jan 2024 07:02:40 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Wed, 31 Jan 2024 07:02:28 -0800
Message-ID: <>
To: Ted Lemon <>
Cc:, The IESG <>,,,,
Content-Type: multipart/alternative; boundary="00000000000097914406103f2bfb"
Archived-At: <>
Subject: Re: [dnssd] Martin Duke's No Objection on draft-ietf-dnssd-srp-23: (with COMMENT)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Jan 2024 15:02:42 -0000

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

On Mon, Jan 29, 2024 at 2:27 PM Ted Lemon <> 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 <
>> 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. 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 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.