On Sun, 19 May 2024, Steve Crocker wrote:
[speaking as individual only]
In my view, an algorithm moves through seven phases during its lifecycle.
1. Experimental – defined and included in the IANA registry
2. Adopted – begin inclusion in validation suite
3. Available – ok to use for signing
4
Actually, we are developing an unrelated scheme that has need of the same
zone structure for signaling but not involving DNSSEC itself, and would see
some advantage in utilizing the same standard top level underscore naming for
signaling use in general.
Would you want to put the signal info in
[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:
- Tw
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 see
[reposting as it did not get delivered to dnsop@ietf.org, 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 lab
On Mon, 6 May 2024, Petr Špaček wrote:
R1. UDP responders SHOULD NOT use IPv6 fragmentation [RFC8200].
Operational impact of this recommendation is unclear.
Why? Because clients belong to several sets:
- One set clients cannot receive fragmented answers,
Good because it has been proven to
