AD Review: Catalog Zones.
Hi there,
Thank you for all of the work you have put into this document; I think that
catalog zones are a really useful feature, and should be documented.
Before I can start IETF Last Call, however, there are some questions and
issues that need to be addressed - the majority of these are simply
editorial changes where the document could be made clearer and more
readable, but there are also some more substantive questions / places that
need additional text.
Thank you again for writing this, and please SHOUT LOUDLY once you've had a
chance to address these and post a new version, or if you'd like to discuss
/ have any questions, etc.
W
----
Meta: The document has 7 authors, which exceeds the recommended 5. While we
can approve more, but it requires justification - why does this document
have 7?
Sec 1:
O: "... they must also add/remove the
zone from all secondaries, either manually or via an external
application."
P: "they must also add/remove the configuration for the zone from all
secondaries"
C: Just above it says that the zone is transferred using [AI]XFR.
O: "This can be both inconvenient and error-prone; it is
also dependent on the nameserver implementation."
C: I don't have proposed text, but it is unclear what is mean by "it".
Perhaps "... and error-prone; the configuration syntax ..."
O: "This document describes a method in which the catalog is..."
C: Perhaps "list of zones" instead of catalog? Otherwise it feels a bit
like a circular definition. Just a thought...
O: "As zones are added to or removed from the
catalog zone, these changes are distributed to the secondary
nameservers in the normal way."
C: Well, no - it's really not "in the normal way" - the normal way is that
you edit the config file. I understand what you are trying to say, but I
don't think that this says it. I propose just "As zones are added to or
removed from the catalog zone, these changes are distributed to the
secondary nameservers." or "... this zone is distributed to the secondary
namesservers (just like any other zone)."
Sec 3:
O: "Catalog consumers MUST ignore any RR in the catalog zone which is
meaningless or useless to the implementation."
C: Ourgrgh... Can you reword this? "useless to the implementation" is
really really vague, and this *will* result in DISCUSS ballots.
O: "The SOA record's SERIAL, REFRESH, RETRY and EXPIRE fields [RFC1035]
are used during zone transfer."
C: Erm, "are used" how? Perhaps either drop this sentence (it doesn't seem
to add anything), or "The SOA record's SERIAL, REFRESH, RETRY and EXPIRE
fields [RFC1035] are used during zone transfer, just like they would be for
any other zone"?
Sec 4:
O: "More than one record in the RRset denotes a broken
catalog zone..."
C: Can you come up with a better word than "denotes"? To me "denotes"
implies that the user has *chosen* to do this. Perhaps "results in"? Sorry
I don't have a better suggestion.
O: "The TTL field's value is not defined by this memo."
C: Erm... perhaos "The TTL field's value has no meaning in this context,
and [MUST/SHOULD] be ignored."? Otherwise someone will ask what it means...
Sec 4.4.2.1. Example
I think that the example is quite unclear, and it will raise more questions
than it answers -- for example, people are going to ask who exactly parses
"operator-x-sign-with-nsec3", and they will also try and figure out where
these verbs (e.g 'nodnssec') are defined. I think that you need to clarify
that the meaning of the text records are opaque / defined between the
producer and consumer. This is discussed above ("The exact handling of
configuration referred to by the group property value is left to the
consumer's implementation and configuration."), but it's not clear in the
example.
Sec 4.5:
"A custom property is named as follows:
; a global custom property:
<your-property>.ext.$CATZ
; a member zone custom property:
<your-property>.ext.<unique-N>.zones.$CATZ"
vs
"For
example by including the name of the implementation in the property,
e.g. like: <property-name>.<implementation-name>.ext.$CATZ."
So, which is it? '<your-property>', or '<implementation-name>'? If these
are the same thing, then that's not clear (I'd guess that this is that the
<your-property> is supposed to show that it can be composed of <property>
and <implementation>, but it's really not clear). It's also not really
clear how people should name their properties, and some examples here might
help.
O: "A property description should clearly say what semantics apply, and
whether a property is global, member, or both."
C: Ok, fair enough -- but this is the first mention of property
descriptions. If I write one, I'll happil say what the semantics are, etc
-- but where should I put this? Who do I shate it with? Is this for my own
internal use, or should I publish it externally? If you have this level of
suggestion, then it implies that these will be used somewhere...
Sec 6:
O: "Although any valid domain name can be used for the catalog name
$CATZ, it is RECOMMENDED to use either a domain name owned by the
catalog producer, or to use a name under a suitable Special-Use
Domain Name [RFC6761]."
C: I'm very confused. If I am Yahoo, are you saying that I *could* use
microsoft.com as the catalog name? Presumably that woould end badly....
Also, what is a "suitable Special-Use Domain Name"? 10.in-addr.arpa.?
localhost.? example.com.? Why doesn't this just say that the catalog name
MUST be under a domain owned by the catalog producer?
Sec 7. Security Considerations
O: " Administrative control over what zones are served from the configured
name servers shifts completely from the server operator (consumer) to
the "owner" (producer) of the catalog zone content."
C: Ok, so I'm Coca-Cola, and I've contracted with DNS-R-Us to serve as my
secondary nameserver service. I have a bunch of zones (coke.com, fanta.net,
monster-energy-ultra.org), and so I send you a catalog zone. One day I
decide to send you a catalog zone containing pepsi.com (who also uses
DNS-R-Us), and hilarity ensues...
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
