Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt

Ted Lemon <> Mon, 16 July 2018 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B61801311EA for <>; Mon, 16 Jul 2018 14:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] 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 ensm0Dvbv6eU for <>; Mon, 16 Jul 2018 14:28:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C79FA130E41 for <>; Mon, 16 Jul 2018 14:28:48 -0700 (PDT)
Received: by with SMTP id 188-v6so23619362ita.5 for <>; Mon, 16 Jul 2018 14:28:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v0gIPezkW2vtczbil/fduf/th3Io4ZCdFr1/15DWmJw=; b=SbiwGF0gkfVHIOffuV2oB3qvptXRanWWrsOHzTr9zmfZrPkJNIJ5SEcf+uHRevkD9K uZN2nl6OwF6tXyqpaDPihPVaNqRzaZacRVo7wMH6QjFeaifWEbpS8d9Ss18E+K9xjkHL 5LNxthOSvEH+dyzfkQY0ALtsBX1oBBIMgoY9vFNkwsg/5y4r1BnmzsZvpYgpxRo3F8C6 2vZSl+zI8Yh3ip+iyfLknhiUKZImuyhYTMORBgguVUeugjlOLxIjyea9/yfAku2aReio EOQa21UxyUsl+Iy2q8NHTOxhv5X4cjAvDPKaZCdU1piZE/rbV/aACBhH7AHSIhDs8e2p Inzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v0gIPezkW2vtczbil/fduf/th3Io4ZCdFr1/15DWmJw=; b=RGYGCvhFLfrNSVyMq37J5zDq0uCnlSe9mhiz3vlCDusPR55YlVptovMEcVSfdwIqTm RmsDHYuTr2K/lig5ce49VnjwlCxZ7iL7K/suUPYX2OyalAKx1yBsuKICXJ7ObiRe8AOR x+DfUJMz8kziFQoGc0f6NYv7SKiXW7qgVXZtJ7hj9TW66y6WEIqEFStvttd1vlA3azPW MiUGLR9yHi4sTSaGAUugP6lExikzkJmDOL6ET+5BjCSqWmSRm5jTccdDaBK5hefY34pX 52fKg8G/E/+jeWWBcss10gIEb+ShISHuheVhqcKAZNOej3lOhLLvn2rR8n3Ssta6V1Ys +5ww==
X-Gm-Message-State: AOUpUlEsWzyQgRIwFBnnALGeRMPUwdNTUeuMigX6dFHmRRgKxY/jEE6h lkcGQzgy11+RoagEiM03UpefaeQPKhPe3UKXTc2Klw==
X-Google-Smtp-Source: AAOMgpfBQLrTIYxIbo3ahaPbAkqDyZZFQnJlKWsC6zcxq0mssPgB/sOHX1GpEoAuWP2J/+cxtJTaVGfCKHxEQiTbmZo=
X-Received: by 2002:a24:4dd3:: with SMTP id l202-v6mr14230547itb.144.1531776528102; Mon, 16 Jul 2018 14:28:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 14:28:07 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Ted Lemon <>
Date: Mon, 16 Jul 2018 17:28:07 -0400
Message-ID: <>
To: Tom Pusateri <>
Cc: dnssd <>
Content-Type: multipart/alternative; boundary="000000000000d54dcd0571248342"
Archived-At: <>
Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt
X-Mailman-Version: 2.1.27
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: Mon, 16 Jul 2018 21:28:51 -0000

On Mon, Jul 16, 2018 at 2:47 PM, Tom Pusateri <> wrote:
> May I suggest that the server adjusts the TTL to a reasonable value
> (guidance) and returns the new value in the response.

I don't think this is important.   What behavior on the client would change
on the basis of this guidance?   The client doesn't necessarily know which
server it's talking to, so the advisory TTL value, if retained, might be
considered wrong next time it sends an update. strations with this server.

> New Feedback
> ——————————
> Section 2 says:
> 'In other network environments, updates for names ending in
> "" may be rewritten internally to names with broader
> visibility.’
> And Section 2.2 says:
> ‘...and let the DNS-SD Service Registration server handle rewriting that
> to a different domain if necessary.’
> When the registration server rewrites the domain, does it send the new
> domain back in the response? I couldn’t find that anywhere in the document.
> Does it have to send back all of the records in the request? Can it send
> just a header if the Zone doesn’t change and the TTL doesn’t change? Can it
> only complete the Zone section if the zone name changes but the TTL stays
> the same with nothing changes in the Update section?

We concluded that it does not.   The only case where this happens now is
for constrained devices, and constrained devices shouldn't care.

> Section 2.3.3:
> 'To do so, it must discover default registration zone’   ——> insert ‘the’

> Section 2.4.2 Page 9:
> change “rejectration” to “registration”.

> Throughout the document "DNS-SD Registration Protocol” is used
> synonymously with "DNS-SD Service Registration Protocol”. If the latter is
> too many words, you might substitute ‘this specification’. This becomes
> even more confusing with the discussion of service registration protocols
> in RFC 6763 such as:
>         "Service discovery requires a service registration protocol. DNS
> already has one: DNS Dynamic Update.” and
>         "This also requires some service discovery registration protocol
> to be implemented and deployed for clients to register with the central
> aggregation server.  Virtually every company with an IP network already
> runs a DNS server, and DNS already has a dynamic registration protocol.”
> This provides additional motivation for a new name.
> “Registrations” is capitalized lots of places where it probably shouldn’t
> be: "Ordinarily Registrations will fail…”

Yeah, I went through the document and noticed that there was a huge amount
of inconsistent use of terminology.   I updated the document to use SRP
instead of the various permutations of DNS-SD Service Registration
Protocol, SRP Server for the various permutations of Registration server,
and SRP update instead of Registration.