On Thursday, July 4, 2024 6:03:44 PM PDT Tim Wicinski wrote:
> Geoff,
>
> On Thu, Jul 4, 2024 at 8:58 PM Geoff Huston wrote:
> > I think you appear to be getting "requestor" and "responder" confused in
> > your proposed text. Did you mean to say the following?
>
> Arrgh - Guilty and thank you fo
Geoff,
On Thu, Jul 4, 2024 at 8:58 PM Geoff Huston wrote:
>
> I think you appear to be getting "requestor" and "responder" confused in
> your proposed text. Did you mean to say the following?
>
>
Arrgh - Guilty and thank you for that.
UDP responders should compose response response packets wit
> On 5 Jul 2024, at 10:37 AM, Tim Wicinski wrote:
>
> Paul
>
> On Thu, Jul 4, 2024 at 6:41 PM Paul Vixie
> wrote:
> On Thursday, July 4, 2024 7:05:22 AM PDT Tim Wicinski wrote:
> > On Tue, Jul 2, 2024 at 9:26 PM David Farmer wrote:
> > > 2. Also, maybe R5 should have text similar to R3 with
Paul
On Thu, Jul 4, 2024 at 6:41 PM Paul Vixie
wrote:
> On Thursday, July 4, 2024 7:05:22 AM PDT Tim Wicinski wrote:
>
> > On Tue, Jul 2, 2024 at 9:26 PM David Farmer wrote:
>
> > > 2. Also, maybe R5 should have text similar to R3 with "...the minimum
>
> > > of...the interface MTU, the network
On Thursday, July 4, 2024 7:05:22 AM PDT Tim Wicinski wrote:
> On Tue, Jul 2, 2024 at 9:26 PM David Farmer wrote:
> > 2. Also, maybe R5 should have text similar to R3 with "...the minimum
> > of...the interface MTU, the network MTU...and 1400 bytes..." Instead of
> > "It should use a limit of 1400
All
A reminder Call for Agenda Items for the IETF 120 in Vancouver, Canada.
Draft Submission Deadline is Monday 8 July 2024.
Please email the chairs with your requests.
*Or* drop us a pull request
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf120
look for dnsop-ietf120-agenda
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 error signal? There is a thing of being
It appears that Peter Thomassen said:
>NEW
>[...] A name server MAY also
>include additional ZONEVERSION options with reduced LABELCOUNT if, in
>addition to the zone corresponding to the QNAME, it is also
>authoritative for any of its parents. [...]
We all seem to agree that th
Petr,
On Thu, Jul 4, 2024 at 3:22 AM Petr Špaček wrote:
> I've reviewed version 18 and it seems okay.
>
> I have only nit:
> Section C.1. BIND 9 is using somewhat confusing references to
> recommendations. Sometimes it says "recommendation 3" but it means
> something else than R3 in the precedin
David
Thanks for the comments.
On Tue, Jul 2, 2024 at 9:26 PM David Farmer wrote:
> A couple of issues I noticed;
>
> 1. The text added to R2 in section 3.1 refers to Appendix C, but it
> includes an Editor's Note that it will be removed, leaving this as a
> dangling reference. The Editor's Not
> On 4 Jul 2024, at 07:45, Nicolai Leymann via Datatracker via dnsdir
> wrote:
>
> Overall I think the document is ready for publication.
Thanks Nic. Though the LC comments today suggest we’re not yet done with this
doc, :-(
___
DNSOP mailing list
On 7/4/24 10:55, Petr Špaček wrote:
Only comment I have is that LABELCOUNT could have been TYPE-dependent so a new
TYPE could define different mechanism to identify zone, but hey, wasting 1 byte
is not a big deal in the age of multi-gigabyte videos playing in the background
constantly.
Tha
On 7/4/24 10:00, Joe Abley wrote:
---
3.2. Responders
... A name server MAY also include more than one ZONEVERSION option in the
response if it is authoritative for more than one zone of the corresponding
QNAME. A name server MUST NOT include more than one ZONEVERSION option for a
given TYP
On 04. 07. 24 10:28, Joe Abley wrote:
Hey,
On 4 Jul 2024, at 09:15, Petr Špaček wrote:
To be clear:
Let's not hang too tight on this particular example. It could be
something crazy like
qname.zone1.test. CNAME target2.example.
target2.example. CNAME final.example.net.
final.example.net. A
Hey,
On 4 Jul 2024, at 09:15, Petr Špaček wrote:
> To be clear:
> Let's not hang too tight on this particular example. It could be something
> crazy like
>
> qname.zone1.test. CNAME target2.example.
> target2.example. CNAME final.example.net.
> final.example.net. A 192.0.2.1
>
> (i.e. zone na
On 04. 07. 24 10:00, Joe Abley wrote:
On 4 Jul 2024, at 08:38, Petr Špaček wrote:
when re-reading this document I've realized one limitation which is not
explicitly mentioned:
---
3.2. Responders
... A name server MAY also include more than one ZONEVERSION option in the
response if it is a
On 4 Jul 2024, at 08:38, Petr Špaček wrote:
> when re-reading this document I've realized one limitation which is not
> explicitly mentioned:
>
> ---
> 3.2. Responders
>
> ... A name server MAY also include more than one ZONEVERSION option in the
> response if it is authoritative for more tha
Hello everyone,
when re-reading this document I've realized one limitation which is not
explicitly mentioned:
---
3.2. Responders
... A name server MAY also include more than one ZONEVERSION option in
the response if it is authoritative for more than one zone of the
corresponding QNAME. A n
I've reviewed version 18 and it seems okay.
I have only nit:
Section C.1. BIND 9 is using somewhat confusing references to
recommendations. Sometimes it says "recommendation 3" but it means
something else than R3 in the preceding text.
Some unification would be good, but that's really a nit.
19 matches
Mail list logo
