Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

Tom Pusateri <pusateri@bangj.com> Fri, 24 August 2018 13:52 UTC

Return-Path: <pusateri@bangj.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15DB126BED for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 06:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 HWvbMXp64vq0 for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 06:52:50 -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 154E4124BE5 for <dnsop@ietf.org>; Fri, 24 Aug 2018 06:52:50 -0700 (PDT)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (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 0CEC72EEE; Fri, 24 Aug 2018 09:48:36 -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: <C0EE2719-B662-4231-AF51-D3B98B00AD0D@fugue.com>
Date: Fri, 24 Aug 2018 09:52:48 -0400
Cc: Paul Vixie <paul@redbarn.org>, dnsop WG <dnsop@ietf.org>, Tim Wattenberg <mail@timwattenberg.de>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D607922-393D-4549-AAFA-49279C260CA4@bangj.com>
References: <153507165910.12116.7113196606839876181.idtracker@ietfa.amsl.com> <AFB90F6F-5D99-4403-AAB6-1123727973E6@bangj.com> <5B7F5E07.5080100@redbarn.org> <7F91FFF7-71C3-4F8E-82CD-266B170983E0@bangj.com> <C0EE2719-B662-4231-AF51-D3B98B00AD0D@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ETY0lPW6-A9qCZNgSnc7EjzJ78c>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Aug 2018 13:52:52 -0000


> On Aug 24, 2018, at 9:11 AM, Ted Lemon <mellon@fugue.com>; wrote:
> 
> On Aug 23, 2018, at 11:44 PM, Tom Pusateri <pusateri@bangj.com>; wrote:
>> An RRset isn’t granular enough because the components of the set could come from different clients with different timeout values.
>> Therefore, a unique identifier is needed for each record. The hash provides that unique identifier since it is calculated over the entire record including the unique RDATA.
> 
> The hash stuff seems like a premature optimization.   I can think of two other ways to do this: either just send the contents of the RR, or use an index into the RRset and define a sorting order.   Bearing in mind that there's no reason for any server to store this data internally as anything other than an additional tuple in the RR itself, hashes may be the least efficient way to implement this.   Remember that for zone transfers, either you transfer the whole zone, or you transfer the differences, and in either case the zone contents for any zone serial number should always be the same.

We thought about sorting and indexing but that seemed way more error prone and not as general. The hash is a general solution that works well for these immediate uses and for any future uses that we can’t anticipate. It also provides the basis of a unique identifier that could be used for other non-related DNS extensions that need a unique identifier, so this code could be re-used. With the current libraries available, it’s not particularly complicated or onerous. 

> Another question to ask here is, what is the application for this?   If it's just for DNSSD Registration, then it might be better to implement it in a less general way.  It would be worth scoping this before saying that it has to be done this way.   When Stuart and I talked about this, we had a much simpler model in mind; your model is certainly more general, but who's the customer?   I'm not saying your model is wrong, just that we ought to discuss it explicitly.
> 

Yes, it was intended to be more general than for service registration. It’s directly applicable to name registration for IP addresses. I can add a section on other uses if more motivation is desired. Mark Andrews had some uses as well that hopefully, he can share. If others have uses in mind that this solves I would love to hear about them.

> If a zone is signed, are the TIMEOUT records signed?
> 

No. The draft says they are skipped.

Thanks,
Tom