Hi Paul,
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?
The main question then is to get implementations updated. I'm thus copying a
few implementers so they can comment w.r.t. making this change in their
implementation. I suppose that barring their objections, it's fine to go ahead?
Thanks,
Nils and Peter
On 4/20/24 01:18, Paul Wouters wrote:
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
--
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
https://www.ietf.org/mailman/listinfo/dnsop
