[DNSOP] Murray Kucherawy's Discuss on draft-ietf-dnsop-dns-catalog-zones-08: (with DISCUSS and COMMENT)

[Murray Kucherawy via Datatracker <[e-mail]>]

Murray Kucherawy has entered the following ballot position for
draft-ietf-dnsop-dns-catalog-zones-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is cool stuff.  I assure you I'm going to ballot "Yes" after what's below
is cleared up.

There's no IANA Considerations section.  Was this intentional?  I ask for a few
reasons:

(1) It's expected (required?), with no actions for IANA, to expressly include a
section that says so.  It's conspicuously missing here.

(2) Why is there no registry for custom properties?  I can see that Section 4.5
takes a run at dealing with the collision risk by SHOULDing a particular way of
naming custom properties, but it feels to me like a registry is the right way
to deal with this.  As a consumer of this work, I might not want to reveal (via
names) which DNS implementation I'm using, for example.

(3) I have a similar question about groups in Section 4.4.2; "nodnssec" is an
example of something that we might want to register with global semantics, or
more generally, that some values might be common in implementations and
therefore worth documenting.

(4) Do we need a registry of names that are special in the context of catalog
zones, e.g., "zones", "ext", "group", "version", "coo", "invalid"?

Separately: What action should be taken if a nameserver is already
authoritative for a zone (say, is a primary), yet it receives a catalog update
that now contains that same zone?  This seems like a possible attack that
should be discussed.  I guess the second-last paragraph of Section 7 covers
this, though indirectly.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

General:

Could I trouble you for an example of a complete sample catalog zone, perhaps
in BIND format, in an appendix?  I can see each individual concept illustrated,
but it would be helpful to see them assembled someplace.

Section 3:

"Catalog consumers MUST ignore any RR in the catalog zone which is meaningless
to or otherwise not supported by the implementation" seems peculiar.  Wouldn't
you do that anyway?

Section 4.1:

Given the text in Section 3 (specifically that a catalog zone follows the same
rules as any other zone), is this section needed?  The third paragraph could be
its own differently-named section, but the rest seems redundant.

Section 4.2:

The SHOULD at the end leaves implementers with a choice.  Why might an
implementer choose to do something other than what it says?  Or should this
really be a MUST?

Section 4.3:

It doesn't say anywhere (unless I missed it) that the RRTYPEs of properties are
unspecified, and depend on the property.  It might be good to make that
explicit, because I kept searching for it.

Section 4.4.1:

Regarding the last paragraph, is there any advice to pass on to operators about
how exactly one can tell when the COO is complete?

Section 7:

Why are the protections of zone transfers and updates only SHOULDs?