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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop