Hi all, Following up on this. Please let us know how we should proceed for this. Thank you.
Best regards, David Dong IANA Services Sr. Specialist On Thu May 09 09:39:29 2024, pe...@desec.io wrote: > [another (last) attempt of reposting this as it did not get delivered > to dnsop@ietf.org on May 7, as evidenced by the list archive] > > > Hi, > > On 5/2/24 19:59, David Dong via RT wrote: > > Following up on this; does the group agree that "_dnssec" is OK? > > Looking at what's been said in this thread: > - Two people have proposed to change the label, current proposal: > _dnssec > - Two implementers have said they'd make the change but don't seem > convinced > - The authors (hats off, but also implementers and authors of current > drafts using the mechanism) are not convinced > > The authors don't feel comfortable declaring consensus in either > direction (neither do we know whether that's our role), and we're not > sure how to proceed. Perhaps the DNSOP chairs could weigh in, as the > discussion is happening on the WG list although the document is > technically out of the door ... > > > I've been reluctant adding the following argument as to not seem > insisting; OTOH it may have its own technical merit, so here is. > > The "_dnssec" label implies that the mechanism is not suitable for > signaling unrelated to DNSSEC. That's an artificial limitation, and > it's unclear why to impose the restriction. An operator could very > well want to publish other things, like > > - TXT at _abuse.example.com._signal.ns1.provider.net for an abuse > address, > - PTR at _catalog.example.com._signal ... for catalog zone membership, > - ... > > If the signaling method is generic, I believe it should have a short > generic label. Any specificity to determine the kind of signal can go > into the first label. > > I have no specific preference for "_signal" other than I don't know > what a good alternative would be. Narrowing the scope with "_dnssec" > doesn't seem to improve the situation. > > Thanks, > Peter > + Nils (for the "we"/author statements) > > > > Thank you. > > > > Best regards, > > > > David Dong > > IANA Services Sr. Specialist > > > > On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: > >> On 20 Apr 2024, at 19:38, Paul Wouters wrote: > >> > >>> On Sat, 20 Apr 2024, Peter Thomassen wrote: > >>> > >>>> The authors certainly don't insist, but we'd need to pick a > >>>> suitable > >>>> replacement for the "_signal" label. > >>>> > >>>> John proposed "_dnssec-signal" elsewhere in this thread. > >>>> > >>>> The authors would like to note that adding "_dnssec-" eats up 8 > >>>> more > >>>> bytes, increasing chances that bootstrapping will fail due to the > >>>> _dsboot.<domain-name>._dnssec-signal.<nsname> length limitation. > >>>> Other than this (unnecessary?) use case narrowing, this choice > >>>> seems > >>>> fine. > >>>> > >>>> That said, does this choice address your concerns? > >>> > >>> It would, but I would also be okay if it is just _dnssec. > >>> > >> > >> If the concern is that the label is too generic, “_dnssec” might be > >> too generic as well. If it is to be more precise, go with _ds-boot > >> or > >> something more specific to the use case. I don’t have an > >> implementation in the mix, so it this isn’t a strong opinion. If > >> the > >> group agrees _dnssec is fine, then I am fine with it too. > >> > >> Scott > >> > >> ===================================== > >> Scott Rose > >> NIST/CTL/WND > >> scott.r...@nist.gov > >> ph: 301-975-8439 > >> GoogleVoice: 571-249-3671 > >> ===================================== > > _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
