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." or
"a.b.example.com" or "a.b.c.example.com" inside a "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://www.rfc-editor.org/info/rfc6891>
[RFC6891 <https://www.rfc-editor.org/info/rfc6891>] 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://www.rfc-editor.org/info/rfc6891>
[RFC6891 <https://www.rfc-editor.org/info/rfc6891>] 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://rfc-editor.org/rfc/rfc4786#section-4.9> of [RFC4786
<https://www.rfc-editor.org/info/rfc4786>]), 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://www.ietf.org/mailman/listinfo/dnsop
