If the authors insist, then as DE of this registry, this entry is okay. My point below still holds, but I will leave that up to the authors and IESG.
Paul Sent using a virtual keyboard on a phone > On Apr 19, 2024, at 18:47, David Dong via RT > <drafts-expert-review-comm...@iana.org> wrote: > > Hi Paul, > > Just a ping on this; thank you. > > Best regards, > > David Dong > IANA Services Sr. Specialist > >> On Sat Apr 13 01:24:13 2024, pe...@desec.io wrote: >> Hi Paul, >> >>> On 4/12/24 22:36, Paul Wouters wrote: >>> However, I would urge the authors/WG to pick a less generic and more >>> specific name than "_signal", such as "_dnssec-bootstrap". Especially >>> because there is also the well known "Signal" message client. Also, >>> in case of future different signaling, the current name might become >>> confusing. >> >> The signaling record names actually have two underscore labels, and >> look like (taking nohats.ca as an example) >> >> _dsboot.nohats.ca._signal.ns2.foobar.fi. >> >> The specific type of signal is already indicated by the first label. >> Other signaling use cases would use a different first label. (draft- >> thomassen-dnsop-mske has an example.) >> >> The _signal label generically indicates that ns2.foobar.fi likes to >> signal something about nohats.ca. Its presence is needed to allow >> separating the object from the source without ambiguity. >> >> We could change _signal to something else, but not to _dnssec- >> bootstrap as that's not generic. Suggestions are welcome. >> >> >> I'd like to add some considerations: >> >> - The spec has quite a few production implementations (see Section 8), >> and changing them would come with significant costs. >> >> - I don't think the _signal label is in use for the Signal messenger. >> Even in case it's used in the future, a collision (in terms of prefix >> labels + rdtype) seems unlikely. >> >> As there would be significant costs, but no tangible benefit, perhaps >> we should not do this. >> >> >> Further context: The structure of the signaling name is the result of >> the DNSOP Interim [1]. Details on rejected alternatives can be found >> in [2]. >> >> [1]: "Open Issue 3" in https://datatracker.ietf.org/meeting/interim- >> 2022-dnsop-01/materials/slides-interim-2022-dnsop-01-sessa- >> authenticated-dnssec-bootstrapping-00.pdf >> [2]: >> https://mailarchive.ietf.org/arch/msg/dnsop/FE5Sm5vzZtq9VgKxgkfmv4VuVI8/ >> >> Thanks, >> Peter > > _______________________________________________ > DNSOP mailin _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
