Petr Špaček <[email protected]> writes:
On 16. 07. 19 10:03, Matthijs Mekking wrote:
On 7/16/19 1:49 AM, Joe Abley wrote:
On Jul 15, 2019, at 19:13, Tim Wicinski <[email protected]>
wrote:
Also, the current draft enumerates DLV which needs to be
removed.
Can you explain this?
I can understand a forthcoming clarification on the use of DLV
that might make it ill-advised to publish such an RRType, but
it's not obvious that a dictionary of once-used RRTypes in any
particular format is useless (for example in understanding
observed RRTypes in order to track the length of a deprecated
type's tail).
Are archaic English worlds redacted from dictionaries?
This may be my fault: I had put text in
draft-mekking-dnsop-obsolete-dlv that the DLV reference in this
draft should be removed. But you are right, the reference to
DLV can stay in draft-lhotka-dnsop-iana-class-type-yang, just
like there is a reference to A6. The status of A6 in this
draft is set to obsolete, as it should be. But what should the
status of DLV be in this document? This question I guess proves
Paul's argument that putting snapshots of IANA registries in an
I-D is a bad idea.
Ladislav Lhotka, the primary author of the draft and our YANG
expert is not reachable till beginning of IETF, so I will try
reply non-authoritatively to this concern:
Thanks, Petr, I can only second what you wrote
below. Specifically, the idea is *not* to update the RFC after
every change in the IANA registry. As an example, take the
iana-if-type module:
https://www.iana.org/assignments/iana-if-type/iana-if-type.xhtml
Note that the latest revision is 2019-07-16 whereas the revision
that appeared in RFC 7224 is 2014-05-08.
It might be better to free IANA from this additional burden, but
unless we find a better mechanism, I see this as the only only way
how parameters from IANA registries can be used in YANG modules.
Lada
Purpose of draft-lhotka-dnsop-iana-class-type-yang-02 is to
establish relationship between existing IANA registries (for DNS
classes and types) and their coresponding YANG modules, and to
and instruct IANA to update the respective YANG module when IANA
DNS registries are updated.
Last two paragraphs from Introduction:
This document is a first step in translating DNS-related
IANA registries to YANG. It contains the initial revision
of the YANG module "iana-dns-class-rr-type" that defines
derived types for the common parameters of DNS resource
records (RR): class and type. These YANG types, "dns-class"
and "rr-type", reflect the IANA registries "DNS CLASSes" and
"Resource Record (RR) TYPEs" [IANA-DNS-PARAMETERS].
It is worth emphasizing that the role of the DNSOP Working
Group is only in preparing and publishing this initial
revision of the YANG module. Subsequently, whenever a new
class or RR type is added to the above registries, IANA will
also update the iana-dns-class-rr- type YANG module,
following the instructions in Section 4 below.
Having said that, I do not understand the concerns expressed
above.
What exactly are you objecting to?
That the RFC will contain initial state of the registries (at
time of publication)?
Or that IANA will automatically update the YANG module from
other registries?
Please clarify your concerns, I'm lost. Thank you.
-- Petr Špaček @ CZ.NIC
_______________________________________________ DNSOP mailing
list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
--
Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
