This appears to be a form to fill out https://www.iana.org/form/ports-services
But for some reason it's not listed on the IANA Registry page. tim On Mon, Oct 3, 2022 at 11:17 AM Ted Lemon <mel...@fugue.com> wrote: > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
