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

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.

On Thu, Jul 19, 2018 at 10:53 AM, Tom Pusateri <pusateri@bangj.com> wrote:

> I’ll put this on the mailing list for the benefit of those not at the
> meeting today.
>
> The document draft-sctl-service-registration is not a general purpose
> Service Registration Protocol. It has made many compromises to allow
> registration in a single Update message for constrained devices but there
> is no encryption or authentication/authorization mechanism that can be used
> outside an administrative domain.
>
> Since RFC 6763 summarizes in Appendix A:
>       Service discovery requires a service registration protocol.
>       DNS already has one: DNS Dynamic Update
>
> DNS Dynamic Update is generic and can handle service registration from
> anywhere under any conditions. But it’s chatty and so there is a need for
> something that is more efficient for constrained devices.
>
> draft-sctl-service-registration does this by instructing you how to use
> DNS Dynamic Update is a particular way. It’s a profile of usage.
>
> Therefore, I don’t think we should call this Service Registration Protocol
> which is a generic name because it isn’t a generic solution.
>
> I propose “DNS Update Profile for Constrained Services”.
>
> Without a name change, I don’t support adoption of this draft.
>
> Thanks,
> Tom
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>