Re: [DNSOP] Call for Adoptions: draft-lhotka-dnsop-iana-class-type-yang

[Ladislav Lhotka <[e-mail]>]

Petr Špaček <[e-mail]> 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 <[e-mail]> 
>>> 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 [e-mail] https://www.ietf.org/mailman/listinfo/dnsop 

-- 
Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67