[DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

2024-07-05 Thread Philip Homburg
> That is, first see if there is a discovered mtu (such as by PLPMTUD > or some future method), Can we go back to reality? There is no PMTU discovery for DNS replies over UDP that works at scale. It doesn't work, it never worked. If, through some major breakthrough, someone can actually make it

[DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

2024-07-05 Thread Nick Hilliard
Philip Homburg wrote on 05/07/2024 11:01: Can we go back to reality? There is no PMTU discovery for DNS replies over UDP that works at scale. It doesn't work, it never worked. specifically, short of implementing end-to-end circuits, it can't work reliably. There is no way for an endpoint to de

[DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

2024-07-05 Thread Petr Špaček
On 05. 07. 24 12:50, Nick Hilliard wrote: Philip Homburg wrote on 05/07/2024 11:01: Can we go back to reality? There is no PMTU discovery for DNS replies over UDP that works at scale. It doesn't work, it never worked. specifically, short of implementing end-to-end circuits, it can't work reli

[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE

2024-07-05 Thread Petr Špaček
On 01. 07. 24 21:20, Paul Hoffman wrote: Thanks again for the input on the new RRTYPE. I submitted it to the RRTYPE expert reviewers, and the new definition is posted at . It has "2024-06-24" as its submission da

[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE

2024-07-05 Thread Shumon Huque
On Fri, Jul 5, 2024 at 8:19 AM Petr Špaček wrote: > On 01. 07. 24 21:20, Paul Hoffman wrote: > > Thanks again for the input on the new RRTYPE. I submitted it to the > RRTYPE expert reviewers, and the new definition is posted at < > https://www.iana.org/assignments/dns-parameters/WALLET/wallet-com

[DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

2024-07-05 Thread Paul Wouters
On Jul 5, 2024, at 08:14, Petr Špaček wrote: > > I understand why Paul Vixie does not like 1400 set in stone. > > Having said that I think it's in fact _not_ set in stone because the text > says RECOMMENDED. > > My interpretation is that it means "if you don't know any better use 1400", > bu

[DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

2024-07-05 Thread Petr Špaček
On 05. 07. 24 15:24, Paul Wouters wrote: On Jul 5, 2024, at 08:14, Petr Špaček wrote: I understand why Paul Vixie does not like 1400 set in stone. Having said that I think it's in fact _not_ set in stone because the text says RECOMMENDED. My interpretation is that it means "if you don't kn

[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE

2024-07-05 Thread Dick Franks
On Fri, 5 Jul 2024 at 14:03, Shumon Huque wrote: > On Fri, Jul 5, 2024 at 8:19 AM Petr Špaček wrote: > >> >> >8 >> >> I wonder if it needs some words how to handle wallet addresses longer >> than 255 characters? >> >> > I was wondering the same thing earlier, but forgot to chime in about it. > >

[DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

2024-07-05 Thread Paul Wouters
On Fri, 5 Jul 2024, Petr Špaček wrote: My interpretation is that it means "if you don't know any better use 1400", but RECOMMENDED is more concise. I read RECOMMENDED as “don’t think you are smarter than the collective IETF”. Or maybe that’s just how I hope people will read it. I think y

[DNSOP] Fwd: Re: [Ext] Revised the application for the WALLET RRTYPE

2024-07-05 Thread Dick Franks
Resent Shown a red card by DKIM -- Forwarded message - From: Dick Franks Date: Fri, 5 Jul 2024 at 15:04 Subject: Re: [DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE To: Shumon Huque , Cc: Petr Špaček On Fri, 5 Jul 2024 at 14:03, Shumon Huque wrote: > On Fri

[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE

2024-07-05 Thread Paul Hoffman
On Jul 5, 2024, at 05:19, Petr Špaček wrote: > > I wonder if it needs some words how to handle wallet addresses longer than > 255 characters? To date, every known blockchain uses 256-bit signature keys. Most use truncated hashes of the public key, and all use either hexadecimal or some other A

[DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

2024-07-05 Thread Jared Mauch
On Fri, Jul 05, 2024 at 02:14:19PM +0200, Petr Špaček wrote: > On 05. 07. 24 12:50, Nick Hilliard wrote: > > Philip Homburg wrote on 05/07/2024 11:01: > > > Can we go back to reality? There is no PMTU discovery for DNS replies > > > over UDP that works at scale. It doesn't work, it never worked. >

[DNSOP] Re: draft-ietf-dnsop-zoneversion-09

2024-07-05 Thread John Levine
It appears that Mark Andrews said: > >What is the reasoning behind the following? Why not just FORMERR the request >when the option length is not zero? How hard do we think writing a client is >that they will get sending a zero length option wrong? What is wrong with >sending back an immediate

[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE

2024-07-05 Thread Erik Kline
"expect to find two strings" I didn't see this specified so thought I'd ask: what is the separator of the two strings? ASCII whitespace, or ...? On Mon, Jul 1, 2024 at 12:22 PM Paul Hoffman wrote: > Thanks again for the input on the new RRTYPE. I submitted it to the RRTYPE > expert reviewers,

[DNSOP] Re: Murray Kucherawy's No Objection on draft-ietf-dnsop-zoneversion-08: (with COMMENT)

2024-07-05 Thread Wessels, Duane
Hi Murray, I don’t believe your comments have been addressed yet. My apologies for the delay. > On Jun 19, 2024, at 10:13 PM, Murray Kucherawy via Datatracker > wrote: > > > -- > COMMENT: >

[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE

2024-07-05 Thread Paul Hoffman
On Jul 5, 2024, at 14:33, Erik Kline wrote: > > "expect to find two strings" > > I didn't see this specified so thought I'd ask: what is the separator of the > two strings? ASCII whitespace, or ...? Welcome to RFC 1035 and and TXT records. There is no separator: the TXT record (and thus now

[DNSOP] Re: Last Call: (The DNS Zone Version (ZONEVERSION) Option) to Informational RFC

2024-07-05 Thread Wessels, Duane
> On Jul 4, 2024, at 1:55 AM, Petr Špaček wrote: > > > Unrelated thoughts: > > ### OPCODE > Currently the document sorta implicitly talks about DNS queries - mainly > implied by the structure of section 3.2 and listed possible answer types and > RCODEs. > > Should the document be explicitl

[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE

2024-07-05 Thread Erik Kline
On Fri, Jul 5, 2024 at 2:42 PM Paul Hoffman wrote: > On Jul 5, 2024, at 14:33, Erik Kline wrote: > > > > "expect to find two strings" > > > > I didn't see this specified so thought I'd ask: what is the separator of > the two strings? ASCII whitespace, or ...? > > Welcome to RFC 1035 and and TX

[DNSOP] Re: I-D Action: draft-ietf-dnsop-compact-denial-of-existence-04.txt

2024-07-05 Thread Shumon Huque
This update addresses requested items from discussion at the last IETF meeting, specifically: * Mention impacts on RFC 8020/8198 style NXDOMAIN synthesis * Specify the optional use of a new EDE code (Invalid Query Type) in responses to explicit queries for the NXNAME meta-type. I am not aware of