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

[Ted Lemon <[e-mail]>]

Hm, you're right, that's never stated explicitly.

On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri <[e-mail]> wrote:

> I don’t see anywhere in the document where the anycast update method
> relies on UDP.
>
> Tom
>
>
> On Jul 18, 2018, at 12:27 PM, Ted Lemon <[e-mail]> wrote:
>
> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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/ae53618d8231733701ccdda4d336692a529c9f6
>> b...5c85181881b84ed1132d544e157df8da85874597
>>
>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <[e-mail]> 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 <[e-mail]>
>>> 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 <[e-mail]> 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 <[e-mail]>
>>>> 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 <[e-mail]> 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 <[e-mail]> wrote:
>>>>>
>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke Høiland-Jørgensen <[e-mail]
>>>>>> > wrote:
>>>>>>
>>>>>>> Ted Lemon <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>
>>>>>
>>>> _______________________________________________
>>>> dnssd mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> dnssd mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnssd
>>
>>
>> _______________________________________________
>> dnssd mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnssd
>>
>>
>> _______________________________________________
>> dnssd mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnssd
>> <https://www.ietf..org/mailman/listinfo/dnssd>
>>
>>
>>
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd
>
>
>