Isn't the process for service names essentially "just ask us for one?" It doesn't seem particularly onerous.
On Mon, Oct 3, 2022 at 10:13 AM Ben Schwartz <bemasc= 40google....@dmarc.ietf.org> wrote: > 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= > 40saklad5....@dmarc.ietf.org> 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 >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
