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

[Ted Lemon <[e-mail]>]

You actually talked in your presentation on the charter about an SRP
relay.   I think that is a good approach for Toke's use case.   I don't
think there is any way to do service registration across administrative
boundaries without some kind of trust mechanism of this sort.

On Thu, Jul 19, 2018 at 2:27 PM, Tom Pusateri <[e-mail]> wrote:

>
>
> On Jul 19, 2018, at 12:23 PM, Toke Høiland-Jørgensen <[e-mail]> wrote:
>
> Ted Lemon <[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.
> 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.
> 3. You don’t need the features this draft is good at.
> 4. This draft could do more than constrained devices but then DNS Update
> already does it.
>
> Tom
>
>
>
>