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

Tom Pusateri <pusateri@bangj.com> Mon, 16 July 2018 18:47 UTC

Return-Path: <pusateri@bangj.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 74C05130E62 for <dnssd@ietfa.amsl.com>; Mon, 16 Jul 2018 11:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 w6y8qxW-WySR for <dnssd@ietfa.amsl.com>; Mon, 16 Jul 2018 11:47:12 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B58A130E55 for <dnssd@ietf.org>; Mon, 16 Jul 2018 11:47:12 -0700 (PDT)
Received: from [10.244.195.212] (unknown [206.108.167.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id A0A3D80B; Mon, 16 Jul 2018 14:45:27 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <9DA32538-BFDE-4C84-B1E1-4393D62FBF5A@bangj.com>
Date: Mon, 16 Jul 2018 14:47:08 -0400
Cc: dnssd <dnssd@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/UKLNLU-W44K3nrLcDihMIuUyUkI>
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:47:15 -0000


> 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