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

Of course, you still have a very good point in that the anycast update
method relies on UDP, so sending the key multiple times isn't desirable.
 But I also don't see a way around this.   We could have the server
replicate the key, I guess.

On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri <pusateri@bangj.com> wrote:

> Just saw this in Section 2: "By requiring the use of TCP, the possibility
> of off-network spoofing is eliminated”. So requiring TCP is already handled.
>
> Searching for _dns-update._udp.<domain> still seems odd but that’s been
> going on for a while a presume.
>
> Tom
>
>
> On Jul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>
> Looking in the IANA registry, dns-update isn’t assigned for TCP. So either
> you search for _dns-update._udp.<domain> and use TCP or you register _tcp.
>
> And while you could use an EDNS(0) OPT RR to set the maximum UDP packet
> size larger than 512, you probably wouldn’t want to set it larger than the
> MTU and 1480 isn’t big enough for 3 KEYs plus other records.
>
> Tom
>
> On Jul 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>
> 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...5c85181881b84ed1132d544e157df8
> da85874597
>
> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <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> 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> 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>
>>> 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> 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/Stuart
>>>> Cheshire/draft-sctl-service-registration
>>>>
>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <mellon@fugue.com> wrote:
>>>>
>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke Høiland-Jørgensen <toke@toke.dk>
>>>>> wrote:
>>>>>
>>>>>> Ted Lemon <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
>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>
>>>>
>>> _______________________________________________
>>> dnssd mailing list
>>> dnssd@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>
>>>
>>>
>>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>
>
>