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

[Peter Thomassen <[e-mail]>]

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, [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
>>>> =====================================
>>>
> 
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
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