Hi all,
I've read the thread multiple times, and can definitely see both sides of the conversation. As Paul W is wearing both an AD hat and the DE hat, he has asked me to make the decision and instruct him. While I really don't love it, I believe that it makes sense to stick with _signal. Reasons against: 1: It is very generic. It's not at all clear that foo.bar.baz._signal.example.com has anything to do with DNSSEC (although _dsboot.foo.bar.baz._signal.example.com is clearer) Reason for: 1: It is very generic - it another scheme happens to be able to fit well under _signal, they can use it; _cheese.foo.bar.baz._signal.com **might** be good if a parent wants to inform someone about their children's cheese preferences) 2: Strings are cheap - if another scheme happens to not fit will under _signal, they can choose another one (hopefully less generic next time!) — _flavor.foo.bar._cheese.example.com. 3: It happens to already be some what deployed - and we cannot (easily) tell who all has done so. Yes, CloudFlare presumably has this baked into a variable somewhere and it would be trivial to s/_signal/_dnssec-boot/, but someone might also have already done this manually. Yes, I fully agree that people shouldn't kvetch if they implemented from a draft and have to change — which is why I only used this as a tie-breaker. This was one of those "there is no perfect answer" situations, and at least some set of people will be unhappy (sorry!), but I think that sticking with the draft is the lesser of the two evils… W On Wed, May 15, 2024 at 4:49 PM, Peter Thomassen <pe...@desec.io> wrote: > Hi David, > > The DNSOP chairs have told me that the document is no longer a WG document > as it's with the IESG, so a consensus call here is not applicable. > > Given the discussion here, we'll leave it to the IESG to decide. If I hear > any news, I'll post them here. > > Thanks, > Peter > > On 5/15/24 00:03, David Dong via RT wrote: > > 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 > > -- > Like our community service? 💛 > Please consider donating at > > https://desec.io/ > > deSEC e.V. > Kyffhäuserstr. 5 > 10781 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
