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

Ted Lemon <mellon@fugue.com> Mon, 16 July 2018 18:51 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C02130E74 for <dnssd@ietfa.amsl.com>; Mon, 16 Jul 2018 11:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPKE6Y4oy05s for <dnssd@ietfa.amsl.com>; Mon, 16 Jul 2018 11:51:35 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92022130E62 for <dnssd@ietf.org>; Mon, 16 Jul 2018 11:51:35 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id z20-v6so38812617iol.0 for <dnssd@ietf.org>; Mon, 16 Jul 2018 11:51:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; 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; d=1e100.net; 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: <CD2C55AF-252B-43D8-A963-3DF2FB992594@bangj.com>
References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <CAPt1N1mYtPRxP6F-JwKbWey3r_vSaNP5srbkf314gdjfdNe8mw@mail.gmail.com> <EAA984C0-05A7-450C-812A-B9D43890F627@bangj.com> <CAPt1N1=8stpf_A7i-rcpxvn3SMjJL1E74fvLVuSZM=moHpWu2g@mail.gmail.com> <DF354A0C-0689-4715-ADF9-B9B35A4E23DC@bangj.com> <CAPt1N1mrbmKQtET0Jw3ex0LP6ti3P+X0LODqTutkxsu+ucoZ0w@mail.gmail.com> <9DA32538-BFDE-4C84-B1E1-4393D62FBF5A@bangj.com> <CD2C55AF-252B-43D8-A963-3DF2FB992594@bangj.com>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 16 Jul 2018 14:50:54 -0400
Message-ID: <CAPt1N1kHG8AW-Jdh9_XJogV+LoweLAi+9n=9vd_a8CTpYGxACQ@mail.gmail.com>
To: Tom Pusateri <pusateri@bangj.com>
Cc: dnssd <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008e099405712251ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/emZUz4ef3ieDh299z6N2Zg2IYy0>
Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=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 <pusateri@bangj.com> wrote:

>
>
> > On Jul 16, 2018, at 8:59 AM, Tom Pusateri <pusateri@bangj.com> 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
> "services.arpa" 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
>
>
>