Re: [DNSOP] Éric Vyncke's Yes on draft-ietf-dnsop-dns-catalog-zones-08: (with COMMENT)

[Peter Thomassen <[e-mail]>]

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/