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

[Paul Wouters <[e-mail]>]

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 <[e-mail]> 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, [e-mail] 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