[DNSOP][IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

[David Dong via RT <[e-mail]>]

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, [e-mail] wrote:
> [another (last) attempt of reposting this as it did not get delivered
> to [e-mail] 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, [e-mail] 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
> >> [e-mail]
> >> ph: 301-975-8439
> >> GoogleVoice: 571-249-3671
> >> =====================================
> >