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

Ted Lemon <> Mon, 16 July 2018 18:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26C02130E74 for <>; Mon, 16 Jul 2018 11:51:39 -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 LPKE6Y4oy05s for <>; Mon, 16 Jul 2018 11:51:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92022130E62 for <>; Mon, 16 Jul 2018 11:51:35 -0700 (PDT)
Received: by with SMTP id z20-v6so38812617iol.0 for <>; Mon, 16 Jul 2018 11:51:35 -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=Zivh59WBvx+TE4iNfNPo+Mb4SBGIcJv7Y8budIp/L/Q=; b=qeykWcZIemfLMJf5YvraLxxpkVZEVAby9nrY0gnA64CZ5R/kQPMPcmJifultVX7HzT que7/CT0JtGhzqLhh6dw0Ya/NEyO1JPZMxopMYaLUBcyzCaf76PiX1HccK3nBWZMWrme OHUIsWenQyx4ykOFBYfVgv5ZC6iRP/iHPYBm0r0NfWs08GrGwe+EVXxvSui2Bdb9gPqN 0YLHon1VByP0cJdjQbMW+KSCV+pmxVIxYKUwig7NIXexYLwUyb0/4mE6whTCNhUjZTkN YDq5hLhJqCQa5502AKe69IIeu2hjbKRfE0S64hAsBAbj93Z04ZLqn9bifW6bAuT9vTiF cw+A==
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=Zivh59WBvx+TE4iNfNPo+Mb4SBGIcJv7Y8budIp/L/Q=; b=kShY8AlC9blQl/wCSkblEgLKPQJKTUPU4/PFYHfbZXf7IribNEvYlafEMO2rsLt5y5 co0mhNWfIDCdZAz9n/B6rIIcrdh6CcB0Fz7Y1V3F1yduSlM346tmaNtFDFkYz4Voej50 ypLfkPU7njAAB4oohpH7sjZJMeeWEaLlq/psqWmTGBsGmraE0MVcemXT1tqIoYxi/oBB RyZA0d4+ls85jyqnF+SvTQClVTjyaHnSw9KhpnAGFvVJtt+AJdc8CmgfggfOLCKBEY7a Ex5lMuvTxgjgEjEhF6UQKtVLyCSIP5nSM3HIvU9e1qKfYKU254ZOKFD5o7a5ix6ZI4NR O09w==
X-Gm-Message-State: AOUpUlH8km93c9tRdnNi+WgTkrffU1knAa374xDa1xhO7LvbYhFhW7Eq JT+OFqxODSuq3ya8qQNTT6qBZOSgZ9GBc7mUe0lvbQ==
X-Google-Smtp-Source: AAOMgpfnDmi16MkQaqfWuqg5ZZ+ujEchu8zlmLHtMChqqfzWaKHCqKxYrjRAVkACKEmLXVWcH/Mdi0yUeKjsZqG+f8I=
X-Received: by 2002:a6b:4c5:: with SMTP id 188-v6mr987302ioe.32.1531767094632; Mon, 16 Jul 2018 11:51:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 11:50:54 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Ted Lemon <>
Date: Mon, 16 Jul 2018 14:50:54 -0400
Message-ID: <>
To: Tom Pusateri <>
Cc: dnssd <>
Content-Type: multipart/alternative; boundary="0000000000008e099405712251ef"
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 18:51:39 -0000

I don't know, I kind of like rejectration.   It has a certain classy ring
to it that you don't get with a more pedestrian word like "registration."

My intention with "Registration" was for it to be referring to any message
from the service to the DNS-SD Registration server.  So the capitalization
was intentional.   But I agree that the term is a bit too generic; it might
be better if we could come up with a term that didn't need to be
capitalized to make it stand out.   Maybe "rejectration?"   (Just
Kidding... :)

On Mon, Jul 16, 2018 at 2:47 PM, Tom Pusateri <> wrote:

> > On Jul 16, 2018, at 8:59 AM, Tom Pusateri <> wrote:
> >
> > The TTL addition still leaves ambiguity for the server implementation:
> >
> > "Service Registration servers SHOULD ensure that TTLs are reasonable:
> neither too long nor too short.  The TTL should never be longer than the
> lease time.”
> >
> > Can you give guidance for “too short”? “too long” seems to be > lease
> time. If this isn’t what you mean by “too long”, guidance on that would be
> appreciated too.
> >
> > And finally, if the TTL is “too long” or “too short”, how does the
> server respond? Does the server accept the registration and modify the TTL?
> Does the server reject the registration and return an error? What error
> code?
> May I suggest that the server adjusts the TTL to a reasonable value
> (guidance) and returns the new value in the response.
> Then the client can know for the future what is a more acceptable value
> and adjust future registrations 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?
> 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…”
> Thanks,
> Tom