Re: [DNSOP] Proposal for Namespaced Service Names

[Ben Schwartz <[e-mail]>]

I think the right approach here would be for us (especially relevant chairs
and ADs) to reach out to the squatters and try to get them to join the
process.  We can also try to make this process easier.  (Why isn't there a
"request entry" button next to each IANA registry?)  We should emphasize
the "early allocation" process for work in progress.

For SVCB, the prefixes are generally expected to be URI schemes, so the
first step would be to register your scheme [1].  This registry is
First-Come-First-Serve so the barrier to entry is very low.  Once you have
a scheme, the next step would be to place it in the Attrleaf registry [2].
This requires a stable "reference" (i.e. a SVCB "mapping document") owned
by an organization, but that document does not have to be an IETF
specification.  Indeed, it is possible to do all of this without
interacting with the IETF at all!

I don't think we should try to encode the owner of each service type into
the name of the service type.  If an experimental protocol becomes widely
used, we don't want to be stuck with the owner-encoding name.  This could
also create significant security, performance, and reliability concerns,
e.g. if the original owning entity ceases operation.

--Ben Schwartz

[1] https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
[2]
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

On Mon, Oct 3, 2022 at 9:05 AM Jeremy Saklad <jeremy=
[e-mail]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> My thinking is that people are reluctant to engage with the process for
> experimental or extremely niche applications, for better or for worse. Or
> simply because it is meant for personal or internal use: if a company
> initially wants to use it on their own machines alone, they may not want to
> reserve a public name for it. On the other hand, there’s another reason to
> provide a separate namespace for this: self-documentation.
>
> My idea is that a new .well-known directory could be set aside for this,
> which would provide a place to (optionally) self-publish specifications for
> how to use the namespaced service with standards like SBVC. There’d be a
> few constraints on doing this unilaterally, of course: you wouldn’t be able
> to define new service parameters, unless a method of avoiding overlap with
> the registry were devised. But it would be a considerable improvement on
> the current state of affairs.
>
> Take the following record:
>
> > _newservice.example.com._service._tcp.server.example. 86400 IN
> SRV 0 0 1021 target.example.
>
> This tells a client that <target.example> offers the service “_
> newservice.example.com” (“newservice” as defined by the owner of <
> example.com>) at port tcp/1021 of <server.example>. It also tells a human
> that relevant documentation may be found at <
> https://example.com/.well-known/service/newservice>.
> -----BEGIN PGP SIGNATURE-----
>
> iMwEARYKAHQWIQST9JhYTT2FVNyHHwCUsC6j0LZIGwUCYzrdo1YYJ2h0dHBzOi8v
> b3BlbnBncGtleS5zYWtsYWQ1LmNvbS9maW5nZXJwcmludC9GRERGQzRBNEE2N0Qw
> NEVGRkVCOEU0MjQ5Q0EyMTQ5NTgzRURCRjg0JwAKCRCUsC6j0LZIGyHfAP9rY/0e
> Kqw1OcVrla+B4wODAM8xKcSngj0uGlZAmRlMOQD+OCRmILO/tRwgYASjX2074lKW
> DD6r+WPMatv7KYwWhwo=
> =NJWR
> -----END PGP SIGNATURE-----
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>