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

Ted Lemon <mellon@fugue.com> Mon, 27 August 2018 22:34 UTC

Return-Path: <mellon@fugue.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 A656C130F2D for <dnsop@ietfa.amsl.com>; Mon, 27 Aug 2018 15:34:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 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] 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 P5VRWEmxDJjP for <dnsop@ietfa.amsl.com>; Mon, 27 Aug 2018 15:34:10 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 32F6E130ED7 for <dnsop@ietf.org>; Mon, 27 Aug 2018 15:34:10 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id k38-v6so731075qtk.11 for <dnsop@ietf.org>; Mon, 27 Aug 2018 15:34:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+h1l7Xdh0mY2EZ2A+cD+r7lrjuDX8bFeHre4EDtH2RY=; b=xEwsHcZ64t49+Nyfs/v7NOj5O4f2WWjKWkoat0mDlhqf9h/a4On1XC6WC6YTnOYZnQ 1zLdIw4HJfnPoo5cE4ZCj8zW1N2Is+F7IjUgJ5ie+nhz/xqYs9nLOtu0BYAuIFUz7RuM 0Cu807uUqeRCHWESOtmVWTB4cKrWg6WCmnzIwvDeMR+aU/JMeRPngkluXxinY3an2HVP SQzZHE/++KLpTE5Nblm/L5jKiAhjaNemuam5t7/AQlAXVVe6iRkHYN/t+DYyNvUwPHhj 40JtiJgFwTXBpz0sGO+C3lH0zDLKv1Ux08vduAl0LN2FjXYlMP0F0D+7LPYWumhK6uLB zhJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+h1l7Xdh0mY2EZ2A+cD+r7lrjuDX8bFeHre4EDtH2RY=; b=j9ZYNprMhjbg+l6o5+yQoEYX5eryFHvA3QOPoSXaBJURDylYJ7AzzBxRLJpQyH6llB rQhVT45WuD/BXc38wm/jzddelJ36lAbbtperlsHdHdGYbZkUbtybI7Qo6NFHEVgeFBCT vhG5lb3xS4AwOcXoqFMu0QHk77ovSNnHF981WPXy8+DaSrR4ld/WgD4SDpEjWf3A8d/O KA3UinFYKM2lXJ/j9GM73IMIUYmbV18BES2DRRExqEFPkAq4VJFA/uqRWXJZ0/z7GJp2 Gqmi9EXuhZZP2HK0L1EfA1GYX4OswO1ucUc4J9dw4Gjl4uMGimUPLSjx4Z27M8f1RxfV 8UNQ==
X-Gm-Message-State: APzg51AGS2J9GdFcQVeEnngQsenXS4ynf/5VsQMTxjpv6xXqbohNyQvX 8OxbNejjL9THH0YmFcyfuVVuxC3SIk4=
X-Google-Smtp-Source: ANB0Vdan5tDMpBESrrsA0N40Mpke1DGSh2kshWuk5RlxX0SXofFFljR2ZOR4fK/UkIo0E1RFdOs4vw==
X-Received: by 2002:aed:3ec5:: with SMTP id o5-v6mr16396488qtf.270.1535409249188; Mon, 27 Aug 2018 15:34:09 -0700 (PDT)
Received: from [172.20.10.7] (mobile-107-107-59-133.mycingular.net. [107.107.59.133]) by smtp.gmail.com with ESMTPSA id x8-v6sm332700qka.24.2018.08.27.15.34.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 15:34:08 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <5A2EEB89-1247-4848-938F-6A2A145A6542@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_01A830C2-34CA-473E-AF37-52D0B4FE18DD"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Mon, 27 Aug 2018 18:34:05 -0400
In-Reply-To: <53E0A9E9-7E7B-4AD9-8739-BCEA08ED89D0@bangj.com>
Cc: dnsop WG <dnsop@ietf.org>
To: Tom Pusateri <pusateri@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> <6D607922-393D-4549-AAFA-49279C260CA4@bangj.com> <3C6100BD-62D6-41ED-B7BF-679F0D4E4113@fugue.com> <5063A32B-4877-4860-BA73-CCB068AB7FCB@bangj.com> <CAPt1N1=tXZNgT6ygAaLFfOMze7hbGZ6q_eN1C3iEo9ryBNcyLg@mail.gmail.com> <98EF2CAC-7C13-4E68-8D2B-EC0659EA9646@bangj.com> <CAPt1N1kFNY4=CUMsTvXmeRREeLAkY8xpBdw4vPDxujgke6QT8A@mail.gmail.com> <963460AA-14BB-44AA-87CA-7F09A707DB5D@bangj.com> <47AE41F8-9F5F-4CC8-B4F0-7E8191011E99@bangj.com> <F4335D3A-0241-437F-A428-8EA95F0A1C18@fugue.com> <56E8B2A6-7B65-4D25-B102-9EFA7E2CBE7B@bangj.com> <86D465A4-F390-4370-83EC-0E72FBE115BE@isc.org> <CAPt1N1=xy+JAtgvvF_+9LiTiefbpTy_Vd0b8gswozA1K1C57Nw@mail.gmail.com> <99FA0B76-D225-45FC-A33C-B65E2673A45E@isc.org> <CAPt1N1kp8Tg5tWEiDCMuMNTmehRsBSkkC1=u+RcvkG6ZCegE-g@mail.gmail.com> <977DF12E-178B-4500-B045-F27BF1CDF51C@isc.org> <CAPt1N1=cafnVmnNM2eSF67QbgRk8hUEAd2Gwuqx4OUehPZSmyQ@mail.gmail.com> <AC3FE6CF-CC11-44D3-8C50-BC19C295F001@bangj.com> <CAPt1N1ksyp1t_e9Qd4FTtTVsZr9+VDm11MR-jS9Oz8Kpz7J7AQ@mail.gmail.com> <9B4A76C4-3BA6-46EC-90EB-E78065FD8BD3@bangj.com> <CAPt1N1=o3KRa_X2KTuW1=KagOv1R0KM=QvT0QBf5YrOSWTr9mw@mail.gmail.com> <461B2749-E2A4-42B8-9FB3-824D96039423@bangj.com> <DEE0C8C8-5557-4D97-B3C8-6535F3EB3693@bangj.com> <CAPt1N1knPwGFy38c0=xNT_mHwo=vQZmzqNJHc_=Oshcr1OH8sQ@mail.gmail.com> <C273A347-C918-428F-9CB9-FBF9426F913A@bangj.com> <CAPt1N1mTSYcmaw3TpO1UnHA1r4CF2+BQR9UG-kSQaiTxGtk24g@mail.gmail.com> <A3BB12A2-1159-40D6-8F24-96226F98E1F5@bangj.com> <AD5AAC94-077C-47A6-A28C-9FA7D2A78E2D@isc.org> <CAPt1N1mLVo917KWhU9msKsPaJWRquF=S0B796xa36+xwuGQGPw@mail.gmail.com> <7259D997-7915-4664-AE6E-6DE20A08852E@bangj.com> <CAPt1N1k3fK4YsYUJG2zNvspPjdDxZsFsQb9eqMT1pXzoxrWDQQ@mail.gmail.com> <53E0A9E9-7E7B-4AD9-8739-BCEA08ED89D0@bangj.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/AZpVKahakiqQqxZ1t79udSZ_dBQ>
Subject: Re: [DNSOP] 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: Mon, 27 Aug 2018 22:34:26 -0000

Sorry, I realized that I accidentally hit "reply" instead of "reply all."

The issue that I raised with Tom is that for the DNSSD SRP use case, the only names that receive updates from multiple services are service names (IOW, not service instance names).   In the case of SRP, PTR RRs in service names always point to service instance names, which are per-service, and hence can be counted on to expire on a single schedule.   So for the use case of SRP, the easiest way to handle deleting service name PTR RRs is to take advantage of the semantics of DNSSD: when a service instance SRV record expires, also delete the PTR RR on the service name that points to it.

The reason I bring this up is that it's the most complicated use case I know of.   Is there some other use case where we expect more than one DNS Update client to be updating RRs of the same type on the same name?   How would this even work without SRP semantics?   If this is not expected, then any complexity in the timeout RR that's present only to support that use case is unnecessary.

This is what has been motivating my questions about use cases.   I'm sorry I didn't make that clear earlier.

> On Aug 27, 2018, at 3:34 PM, Tom Pusateri <pusateri@bangj.com>; wrote:
> 
> Not true. You have PTR records with the same service name from multiple clients each with different RDATA and unique timeouts as I demonstrated yesterday in the example.
> 
> Tom
> 
> 
>> On Aug 27, 2018, at 3:27 PM, Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> wrote:
>> 
>> For service instance names, there is only one service. So there shouldn’t be a problem. 
>> 
>> On Mon, Aug 27, 2018 at 2:28 PM Tom Pusateri <pusateri@bangj.com <mailto:pusateri@bangj.com>> wrote:
>> Because even if you add TYPE, you have multiple PTR records (instance names) with the same owner name, class, and type that can timeout differently.
>> 
>> Tom
>> 
>>> On Aug 26, 2018, at 11:20 PM, Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> wrote:
>>> 
>>> If we do that, why do we need a hash at all?
>>> 
>>> On Sun, Aug 26, 2018 at 10:51 PM Mark Andrews <marka@isc.org <mailto:marka@isc.org>> wrote:
>>> I would add a covered type field to TIMEOUT (c.f. RRSIG).  I also wouldn’t have more than
>>> a single timeout per record.  I’m tempted to say a single hash as well.  If there is multiple
>>> timeouts per record then the blocks need to be sorted in timeout order.
>>> 
>>> Covered is there to reduce the number of RR’s that need to be hashed to remove a record.
>>> It will also reduce the size of IXFR’s as you don’t need to re-construct a new TIMEOUT
>>> record that covers every timeout at a name on each change.
>>> 
>>> For all records at a name is often more expensive that for all records of type covered.
>>> Name servers are optimised for looking up <name,type,class> tuples rather than <name,class>
>>> tuples.
>>> 
>>> Sorting of timeout blocks is so that you can look at the first timeout when working out
>>> which TIMEOUT needs to be processed first in a zone.
>>> 
>>> -- 
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia <https://maps.google.com/?q=1+Seymour+St.,+Dundas+Valley,+NSW+2117,+Australia&entry=gmail&source=g>
>>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org <mailto:marka@isc.org>
>>> 
>> 
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dnsop
>