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.
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
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
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
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: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
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 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 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
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
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
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
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
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
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
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 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
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 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
19 matches
Mail list logo
