Warren, authors, and WG:
Thanks Warren for being so clear about your concerns with this document.
Authors-- Please review Warren's comments. Tim won't be in Prague, but Benno or
I would be happy to sit down with you (and Warren if you/he want) to discuss.
Once you've had a chance to consider his comments we can put together a plan
for when revisions can be done, or what issues might need more discussion
before they can be addressed.
WG: If substantive revisions are needed, we'll have to do another WGLC so the
WG can consider them. Even if the revisions are only editorial, however, we'll
want some additional review before asking Warren to take it to the IESG and
IETF Last Call. If you want to be part of that review cycle, please let the
authors or chairs know.
Thanks everyone for your patience and some further effort to make sure we've
got this right.
Best,
Suzanne
For the chairs
On Oct 23, 2023, at 11:30 AM, Warren Kumari <war...@kumari.net> wrote:
Hi there, authors (and WG),
I support what the document is trying to accomplish — I think that ZONEVERSIONs
will be really useful once standardized and deployed.
Unfortunately though, I believe that it needs revision and clarification before
it is ready for last call.
I started performing my AD review, and found a bunch of nits (for which I have
tried to suggest some fixes). I then ran into the description of the
LABELCOUNT parameter ("The LABELCOUNT number helps to disambiguate the name of
the zone that this ZONEVERSION refers to. For example if the response is a
downward referral and the server is authoritative for some portion of the QNAME
that differs from a server that is below the zone cut and is completely
authoritative for a longer match of the labels in the QNAME. Also, if the
ANSWER section has more than one RR set with different zones (like a CNAME and
a target name in another zone) the number of labels in the QNAME disambiguate
such situation.") needs much more work than is appropriate for me to provide.
Even if one starts with an understanding of what it is trying to say, this text
is very very unclear.
The next few sentences don't really fix it either ("For example, a QNAME
"www.example.com<https://protect-us.mimecast.com/s/vqTQClYNZ7CAz9DUqERFe?domain=example.com>."
or
"a.b.example.com<https://protect-us.mimecast.com/s/DLKpCmZg1yCAR0GUQfQ7x?domain=a.b.example.com>"
or
"a.b.c.example.com<https://protect-us.mimecast.com/s/oPyICn5j2OfK6yQiECZZ5?domain=a.b.c.example.com>"
inside a
"example.com<https://protect-us.mimecast.com/s/cfrrCo2k3ytBKoJFWW3P3?domain=example.com>."
zone, that is not delegated not authoritative for those sub-zones in the same
nameserver, has a LABELCOUNT field value of 2 for all such cases.") - what is
"that is not delegated not authoritative" supposed to mean?
In addition to the LABELCOUNT issue, the rest of the document would also
benefit from careful reading and cleanup, including of the Security
Considerations section.
Nits:
1: Abstract
O: "This "ZONEVERSION" data allows to debug and diagnose problems by"
P: "This "ZONEVERSION" data allows for debugging and diagnosing problems by"
C: Grammar.
2: Introduction.
O: "The "ZONEVERSION" EDNS
option<https://protect-us.mimecast.com/s/wPAJCgJNR2fmYgnCNnhyy?domain=rfc-editor.org>
[RFC6891<https://protect-us.mimecast.com/s/wPAJCgJNR2fmYgnCNnhyy?domain=rfc-editor.org>]
allows a DNS querier to request to a DNS authoritative server to add an EDNS
option in the answer of such query with a token field representing the version
of the zone associated to the answered Resource Record (RR),"
P: "The "ZONEVERSION" EDNS
option<https://protect-us.mimecast.com/s/wPAJCgJNR2fmYgnCNnhyy?domain=rfc-editor.org>
[RFC6891<https://protect-us.mimecast.com/s/wPAJCgJNR2fmYgnCNnhyy?domain=rfc-editor.org>]
allows a DNS querier to request that a DNS authoritative server add an EDNS
option containing a token field representing the version of the zone associated
to the answered Resource Record (RR),"
C: Readability - the original seemed very long and complicated.
3:
O: "DNS data is of loose coherent nature,"
P: "DNS data is of loosely coherent nature,"
C: Grammar
4:
O: "Even when in zones where the SOA serial field have the meaning of zone
version you could use a separate query to ask for the SOA RR of the zone and
therefore know its SOA serial, but such separate query is performed in a
different time and could arrive from another authoritative source (for example,
in the case the server is anycasted as described in Section
4.9<https://protect-us.mimecast.com/s/K6oaCjRNX8i3y6kiRbsbu?domain=rfc-editor.org>
of
[RFC4786<https://protect-us.mimecast.com/s/xkTOCkRNY7irqLZhQ72uy?domain=rfc-editor.org>]),
so it's not directly correlated with the original query."
C: This sentence needs a complete rewrite.
5:
O: "The ZONEVERSION EDNS extension can have different meaning depending on the
semantics of the zone maintainer and implementation of nameservers."
P: "The ZONEVERSION EDNS extension can have different meanings, depending on
the semantics of the zone maintainer and nameserver implementation"
C: This also needs a rewrite — people will ask what the different meanings are.
The next 2 sentences don't really answer that.
6:
O: "As of the writing of this document, we recognize there are cases where
nameservers use different backends for its data sources (like relational
databases or by using a different off-DNS synchronicity among others)
therefore, the SOA version field doesn't offer much relevance as a versioning
to its content, and in those cases the ZONEVERSION EDNS extension SHOULD be
extended with a different type and have an opaque value for its data token."
C: This sentence is very unclear, but also it is not clear why this document
doesn't also create Type 1 which is just "opaque string" or something. Aren't
all versions either "something like an incrementing serial number" or
"something you are not expected to understand"?
7: The ZONEVERSION Option
O: "The OPTION-LENGTH for the ZONEVERSION option MUST have a value of 0 for
queries, and MUST have the value of the length in octets for the next
OPTION-DATA for responses."
P: "The OPTION-LENGTH for the ZONEVERSION option MUST have a value of 0 for
queries, and MUST have the value of the length (in octets) of the OPTION-DATA
for responses."
C: Why did this say "*next** OPTION-DATA? That implies more than one, and
(AFAIU) that cannot happen?
O: "An unsigned 1 byte Label Count number (LABELCOUNT) indicating the number of
labels in the QNAME owner name this answer's zone name refers to"
P: "An unsigned 1 byte Label Count number (LABELCOUNT) indicating the number of
labels in the QNAME that this answer
W
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://protect-us.mimecast.com/s/2cDlCpYl42CvxlPFkuORl?domain=ietf.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
