Hi Éric,
Thank you for your review!
On 1/2/23 14:59, Éric Vyncke via Datatracker wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-dns-catalog-zones-08
CC @evyncke
Thank you for the work put into this document. I really like the ideas behind
this IETF draft (OTOH, DNS is now used as a control/transport protocol pretty
much BGP nowadays...). But, I second Murray's DISCUSS point about IANA (and his
ask to get an example because the whole document is not really easy to read for
a non expert).
We will add both a IANA section and an appendix with a full example.
They can be previewed in this PR, where we are collecting changes triggered by
the current round of feedback:
https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/55
## COMMENTS
### Lack of revised I-D after IETF Last Call
David Black did a Last Call review for the DNS directorate on the 27th of
December 2022:
https://mailarchive.ietf.org/arch/msg/dnsdir/7v58S0wA1G5KfiwTrrEdYAqT73w/
Probably due to some personal time during that week, no replies/text changes
are done yet. Are the authors intending to reply to David ?
Yes, this has happened in the meantime. We are also going to reply to his
follow-up question.
### Section 1
Should IXFR / AXFR be cited with a reference ? Even if they are part of the RFC
Editor set of known abbreviations.
We have added mentions of these terms in the Terminology section. The change is
part of the above PR.
### Section 4.1
Isn't the SOA serial already specified as being increased as soon as the zone
content is changed ? If so, why repeating the MUST here ?
This has already been rephrased in response to Murray Kucherawy's review. The
change will likely settle on the following relaxed wording:
A catalog zone MUST follow the usual rules for DNS zones. In
particular, SOA and NS record sets MUST be present and adhere to
standard requirements (such as [@!RFC1982]).
... with explicit mentions of SERIAL removed. Please let us know if you have
further suggestions for improvement.
### Section 4.2
Even if the TTL value is to be ignored by secondary servers, is there a
recommended value to be used in the catalog zone ?
There is no recommendation as it would be arbitrary (because the value would
then be ignored).
### Section 4.3.1
Suggest removing "For this memo, ".
Done (part of the above PR).
### Section 4
Should there be a clear indication about which label to use for each property?
I.e., `the "coo" label is used for the change of ownership property`.
The table of contents contains an overview of which is the label for each
property defined in this document:
4.3. Properties
4.3.1. Schema Version (`version` property)
4.4. Member Zone Properties
4.4.1. Change of Ownership (`coo` property)
4.4.2. Groups (`group` property)
4.5. Custom Properties (`*.ext` properties)
If you meant something else, can you please elaborate?
Should there be a IANA registry for all those special labels / property ? Or
would it be an overkill ?
We are going to address this question in response to Murray Kucherawy's review
(which has the same question in more detail).
### Section 4.4.1
Just 2 personal comments, no need to reply... But,
* re-using the same node label among zones may be complex, I would have
specified all zone properties are reset after a migration to start from a clean
state
The specification allows this: If you don't reuse the label, then the state is
reset and you start from a clean state.
However, implementors needed a way to keep the state during a transfer between
catalogs, and settled on indicating this by reusing the label. A practical use
case for this could be that you produce a catalog depending on what anycast
points of presence a customer has booked in their hosting plan. When the plan
gets upgraded, the zone moves to a different catalog, while all other settings
(e.g. DNSSEC state) should remain the same.
* I am unsure whether the last paragraph procedure is reliable and easy
to do.
The procedure is a result of extensive discussion between the various
implementors, who have discussed various ways for doing change-of-ownership
while state-keeping the requirements low. The implementors think that the
procedure is sufficiently reliable and no more complex than necessary.
### Section 4.4.2.1
s/between the producer and the consumer of the catalog/between the producer and
the consumer(s) of the catalog/ ?
Done (part of the above PR).
### Section 6
Mostly at a DISCUSS level, but about the 1st paragraph, the 2 sentences are
contradictory (as "invalid." is not under control of the catalog producer):
* `a catalog producer MUST NOT use names that are not under the control of the
catalog producer`
* `It is RECOMMENDED ...or to use a name under a suitable
name such as "invalid."`
We appended "(with the exception of reserved names)" to the first quoted
sentence (part of the above PR).
Please let us know in case this does not address things adequately.
## NITS
### I.e.
s/i.e./i.e.,/
Done (part of the above PR).
### Section 3
s/Its records/Its resource records/ ? and introduce the RR abbreviation ?
Done (part of the above PR).
s/for such zones/for regular zones/ ?
Done ("for DNS zones", part of the above PR).
### Section 6
s/when catalog zones or another automatic configuration mechanism is not in
place/when catalog zones or another automatic configuration mechanism are not
in place/ ?
Done (part of the above PR).
Thanks,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
