Re: [dnssd] draft-sctl-service-registration call for adoption

[Toke Høiland-Jørgensen <[e-mail]>]

Tom Pusateri <[e-mail]> writes:

>> On Jul 19, 2018, at 12:23 PM, Toke Høiland-Jørgensen <[e-mail]> wrote:
>> 
>> Ted Lemon <[e-mail] <mailto:[e-mail]>> writes:
>> 
>>> Tom, there are a couple of problems with what you've said. First, the
>>> goal of SRP is actually to provide a general solution for registering
>>> services to be discovered using DNSSD. It is not for constrained
>>> devices only, although that is certainly one case where it's valuable.
>>> So we can't call it a registration protocol only for constrained
>>> devices.
>>> 
>>> Secondly, this is DNS Update. It's just that DNS Update without
>>> something like this *doesn't work* as a registration protocol, and
>>> we've seen that because DNS-SD over DNS hasn't taken the world by
>>> storm in the years since it's been published. This specification is
>>> intended to correct this problem, not to provide a second protocol
>>> that can be used in a constrained set of cases.
>>> 
>>> It's true that FCFS doesn't work for all use cases. This specification
>>> acknowledges that and talks about how to address the problem. We've
>>> also had discussions about this at the mic. This protocol is however
>>> the enabling technology required to solve those problems as well.
>>> Those will be subsets of this, rather than this being a subset of
>>> those.
>>> 
>>> So although I understand where you are coming from, I do not agree
>>> with your analysis of the situation.
>> 
>> As someone whose primary interest in this draft is naming devices across
>> (logical) admin boundaries, I can only agree with Ted here. This is by
>> no means just a thing for constrained devices.
>> 
>> Oh, and I do also support adoption of the draft, if that hasn't been
>> clear from my previous messages :)
>> 
>> -Toke
>
> While you want it to be used for this purpose, it’s not really
> designed for crossing administrative boundaries.
>
> 1. You need encryption which it can’t do because of the multiple
> packets required to do key management.

No, I don't.

> 2. DNS Update does solve the administrative boundary problem at the
> expense of more packets back and forth to the update server. That
> isn’t a problem for you.

I don't care about the number of packets going back and forth, no. What
I care about is not having to distribute keys and configuration to
devices.

> 3. You don’t need the features this draft is good at.

Such as FCFS/TOFU authentication, you mean? Where is that in DNS update?

> 4. This draft could do more than constrained devices but then DNS
> Update already does it.

See above.

-Toke