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

Tom Pusateri <pusateri@bangj.com> Wed, 18 July 2018 16:05 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 BDB53130DFE for <dnssd@ietfa.amsl.com>; Wed, 18 Jul 2018 09:05:30 -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, 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 Plt3QzIG96qt for <dnssd@ietfa.amsl.com>; Wed, 18 Jul 2018 09:05:28 -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 D92BA124C04 for <dnssd@ietf.org>; Wed, 18 Jul 2018 09:05:27 -0700 (PDT)
Received: from dhcp-8cf2.meeting.ietf.org (dhcp-8cf2.meeting.ietf.org [31.133.140.242]) (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 3F5E9BA0; Wed, 18 Jul 2018 12:03:37 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BF17C094-357A-417E-B0D0-621EDDB75C1E"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 18 Jul 2018 12:05:25 -0400
In-Reply-To: <CAPt1N1nFj5DpkRepLQ=Jmk=Spx87tNcfUMGyJRuAT=26givYKw@mail.gmail.com>
Cc: dnssd <dnssd@ietf.org>
To: Ted Lemon <mellon@fugue.com>
References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <CAPt1N1mYtPRxP6F-JwKbWey3r_vSaNP5srbkf314gdjfdNe8mw@mail.gmail.com> <87d0vn7b5t.fsf@toke.dk> <CALX6+rAjz2FtsQkhNyp=xYjXovUJUMN5Bg5iRHSWzMTJaZtCjg@mail.gmail.com> <CAPt1N1kODz72aHwF0z-uhYo4tojwsLEQJwLyzP8zeUYXduFkyQ@mail.gmail.com> <87a7qq6fdk.fsf@toke.dk> <CAPt1N1k59CM8WG4HoqXkG-crUEJbk+KNppX_pgkVFdwbSxNDpw@mail.gmail.com> <CAPt1N1khnMaRE2oe5WEQmonB8AJcLeBm=OB=i1trbEuc=XiL5Q@mail.gmail.com> <B88554CD-2117-44CC-ACA0-F5ACB3F48F88@bangj.com> <CAPt1N1=42Wum5x0s4dJZUB1t2i7g-UUJwcmWKQV5HMM5mAYyQQ@mail.gmail.com> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <CAPt1N1mrr=od-HBEDoS+Bs7fHuHj1Kc0HU-+6+NvhCyWDywYLg@mail.gmail.com> <CAPt1N1nFj5DpkRepLQ=Jmk=Spx87tNcfUMGyJRuAT=26givYKw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/zdax5acomwWJqTE6G5gW9aFYz1s>
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: Wed, 18 Jul 2018 16:05:31 -0000

If you are adding more KEY records, you will certainly exceed the UDP update size of 512 bytes. The draft doesn’t mention transport but maybe this should be restricted to TCP.
The draft does mention searching for the update server using _dns-update._udp.<domain>. But then it won’t be able to use UDP for updates.

Thanks,
Tom

> On Jul 17, 2018, at 4:12 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
> Tim pointed out that we need to protect the Service Instance Name as well as the Host Description with a KEY record, because FCFS naming has to protect both the service description and the host description.   Here are the changes:
> 
> https://github.com/StuartCheshire/draft-sctl-service-registration/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da85874597 <https://github.com/StuartCheshire/draft-sctl-service-registration/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da85874597>
> 
> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> wrote:
> The question of whether we update RFC6763 is basically "is there text that is in RFC6763 that is no longer correct because of this document."  I think the answer is no.
> 
> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri <pusateri@bangj.com <mailto:pusateri@bangj.com>> wrote:
> Ok, just checking. So given that 6763 semi-defines service registration protocol as DNS Dynamic Update, should this document claim it updates 6763?
> 
> Thanks,
> Tom
> 
>> On Jul 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> wrote:
>> 
>> The title of RFC 6763 is DNS-Based Service Discovery.   So I tried to harmonize the document toward that—did I miss something?
>> 
>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusateri@bangj.com <mailto:pusateri@bangj.com>> wrote:
>> How is DNS-Based Service Discovery different from DNS Service Discovery?
>> 
>> Is this meant to distinguish from RFC 6763?
>>  
>> Thanks,
>> Tom
>> 
>> On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> wrote:
>> 
>>> BTW, the current version of the document on github now includes fixes for all the points that have been raised other than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration <https://github.com/StuartCheshire/draft-sctl-service-registration>
>>> 
>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> wrote:
>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke Høiland-Jørgensen <toke@toke.dk <mailto:toke@toke.dk>> wrote:
>>> Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> writes:
>>> 
>>> Why can't it be just a Host Description? Might be useful for a device
>>> that just wants to register its name but doesn't (currently, or ever)
>>> advertise any services...
>>> 
>>> Good question.   What does the working group think?   :) 
>>> 
>>> 
>>> _______________________________________________
>>> dnssd mailing list
>>> dnssd@ietf.org <mailto:dnssd@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
>> 
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org <mailto:dnssd@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
> 
> 
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd