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
