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

Tom Pusateri <pusateri@bangj.com> Fri, 24 August 2018 18:33 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 C1683130DE2 for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 11:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 9nWhyeh95qkg for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 11:33:53 -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 CF431127598 for <dnsop@ietf.org>; Fri, 24 Aug 2018 11:33:52 -0700 (PDT)
Received: from [172.16.10.128] (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 5482F2F94; Fri, 24 Aug 2018 14:29:38 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-00435C55-2E9A-438C-9906-BA0EE16EDBB6"
Mime-Version: 1.0 (1.0)
From: Tom Pusateri <pusateri@bangj.com>
X-Mailer: iPhone Mail (16A5364a)
In-Reply-To: <CAPt1N1kFNY4=CUMsTvXmeRREeLAkY8xpBdw4vPDxujgke6QT8A@mail.gmail.com>
Date: Fri, 24 Aug 2018 14:33:51 -0400
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <963460AA-14BB-44AA-87CA-7F09A707DB5D@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>
To: Ted Lemon <mellon@fugue.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/c5KG900W8pmuNYcb6B4Q2mDUJ1Y>
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: Fri, 24 Aug 2018 18:33:55 -0000

Sorry, I never surveyed the set of inconsiderate DCHP servers.

Thanks,
Tom

> On Aug 24, 2018, at 2:04 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
> Can you give us an example?
> 
>> On Fri, Aug 24, 2018 at 1:56 PM Tom Pusateri <pusateri@bangj.com> wrote:
>> Sure. It’s not the thoughtful, well-behaved implementations that we worry about. It’s the ones that aren’t. This is a protection mechanism. (Belt AND suspenders..)
>> 
>> Thanks,
>> Tom
>> 
>> 
>>> On Aug 24, 2018, at 1:36 PM, Ted Lemon <mellon@fugue.com> wrote:
>>> 
>>> The DHCP case isn't actually a problem today.   DHCP servers automatically remove these records.   The ISC server has been doing this for 20 years, and I'm pretty sure all the other servers that compete with it do too.
>>> 
>>> On Fri, Aug 24, 2018 at 12:50 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>>>> 
>>>> 
>>>>> On Aug 24, 2018, at 9:54 AM, Ted Lemon <mellon@fugue.com> wrote:
>>>>> 
>>>>>> On Aug 24, 2018, at 9:52 AM, Tom Pusateri <pusateri@bangj.com> wrote:
>>>>>> 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.
>>>>> 
>>>>> The reason I'm asking is not that I don't think there are theoretical use cases for what you are proposing.   I'm asking if there are actual use cases.   How would this be used in practice?   What can't someone do right now that they need to do and that this new technology enables?
>>>> 
>>>> Specifically, there are two applications mentioned in the draft.
>>>> 
>>>> 1. When a DNS server receives a dynamic DNS Update from a client registering its name after having received an IP address from an DHCP lease, the length of the DHCP lease can be tied to the length that the DNS address/PTR records stay in the authoritative server.
>>>> 
>>>> 2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, & TXT records), these records can timeout according to the lease lifetime contained in the update lease EDNS(0) option.
>>>> 
>>>> These are not theoretical. They solve practical problems that exist today. I think there are others associated with existing problems for sleeping devices and IoT devices that I need to research to more clearly answer your specific question but I think these two already fulfill that requirement.
>>>> 
>>>> Tom
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop