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

From: Benno Overeinder <[email-masked]>
Date: Mon, 15 Jul 2019 22:00:19 +0200

Dear DNSOP WG,

The draft YANG Types for DNS Classes and Resource Record Types,
draft-lhotka-dnsop-iana-class-type-yang, has been presented at the IETF
103 and IETF 104.

During the IETF 104 meeting, the authors asked for adoption by the DNSOP
WG.  The feedback from the DNSOP WG room was positive and also previous
discussions on the DNSOP mailing list (dd. 12 November 2018) were also
supportive.

This starts a Call for Adoption for:
draft-lhotka-dnsop-iana-class-type-yang

The draft is available here:
https://datatracker.ietf.org/doc/draft-lhotka-dnsop-iana-class-type-yang/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 29 July 2019

Thanks,

Benno Overeinder
DNSOP co-chair

---

From: Paul Wouters <[email-masked]>
Date: Mon, 15 Jul 2019 17:25:02 -0400 (EDT)

> discussions on the DNSOP mailing list (dd. 12 November 2018) were also

I have stated before, in dnsop and other places (such as ipsecme/i2nsf) that
yang documents MUST NOT populate RFC's with snapshots of IANA registries. It
leads to people implementing things long obsoleted/deprecated, and to
new things not getting included because items are newer than the yang
RFC publication date.

This advise was widely agreed upon for i2nsf/ipsecme that a yangdoctors
discussion on how to reference IANA registries in yang documents was
started. I understood work needed to happen to allow the referencing
of IANA registries in yang modules. I'm not sure where we are with that
work now.

This document should not be adopted in its current form. It should only
be adopted once the authors have ensured the new method of referencing
IANA registries is used instead of the current hardcoding method.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 15 Jul 2019 17:35:55 -0400 (EDT)

See also: https://marc.info/?l=ietf&m=154416657729620&w=2

An example of using IANA registries:

https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05

eg:

            typedef encryption-algorithm-type {
                type uint32;
                description
                    "The encryption algorithm is specified with a 32-bit
                    number extracted from IANA Registry. The acceptable
                    values MUST follow the requirement levels for
                    encryption algorithms for ESP and IKEv2.";
                reference
                     "IANA Registry- Transform Type 1 - Encryption
                     Algorithm Transform IDs. RFC 8221 - Cryptographic
                     Algorithm Implementation Requirements and Usage
                     Guidance for Encapsulating Security Payload (ESP)
                     and Authentication Header (AH) and RFC 8247 -
                     Algorithm Implementation Requirements and Usage
                     Guidance for the Internet Key Exchange Protocol
                     Version 2 (IKEv2).";
            }

This prevents an incomplete enumeration and prevents obsolete/deprecated
items to be specified in yang RFCs. Since we have quite a number of dead
RRtypes, it is really important to not to create new RFCs that enumerate
things like MD, MF, A6, etc etc

Paul

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 15 Jul 2019 19:13:42 -0400

Also, the current draft enumerates DLV
which needs to be removed.

On Mon, Jul 15, 2019 at 5:36 PM Paul Wouters <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Joe Abley <[email-masked]>
Date: Mon, 15 Jul 2019 16:49:04 -0700

> 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?

Joe

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 16 Jul 2019 10:03:39 +0200

> 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.

Best regards,

Matthijs

---

From: Petr Špaček <[email-masked]>
Date: Tue, 16 Jul 2019 12:02:35 +0200

> proves Paul's argument that putting snapshots of IANA registries in an

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:

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

---

From: Tony Finch <[email-masked]>
Date: Tue, 16 Jul 2019 11:25:10 +0100

> proves Paul's argument that putting snapshots of IANA registries in an

Right, this yang draft should not mention any of these things directly.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Utsire, South Utsire: Northerly 4 or 5, occasionally 6 at first.
Moderate becoming slight. Fair. Good.

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Jul 2019 14:12:40 -0400

Petr Špaček <[email-masked]> writes:

>>>> 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). 
>>> 
>>  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. 
>  
>>    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. 
>  
> 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? 
> 
> --  Petr Špaček  @  CZ.NIC 
> _______________________________________________ DNSOP mailing 
> list [email-masked] https://www.ietf.org/mailman/listinfo/dnsop 

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Jul 2019 14:13:58 -0400

Benno Overeinder <[email-masked]> writes:

> draft-lhotka-dnsop-iana-class-type-yang, has been presented at 
> the IETF 103 and IETF 104. 
> 
> During the IETF 104 meeting, the authors asked for adoption by 
> the DNSOP WG.  The feedback from the DNSOP WG room was positive 
> and also previous discussions on the DNSOP mailing list (dd. 12 
> November 2018) were also supportive. 
> 
> Please review this draft to see if you think it is suitable for 
> adoption by DNSOP, and comments to the list, clearly stating 
> your view.

As a co-author, I support the adoption.

Thanks, Lada
 
> Benno Overeinder DNSOP co-chair 
>

---

From: Normen Kowalewski <[email-masked]>
Date: Tue, 23 Jul 2019 00:03:32 +0200

Dear DNSWG,

I also support the adoption. 

Normen Kowalewski 

> On 22. Jul 2019, at 20:13, Ladislav Lhotka <[email-masked]> wrote:
> 
>> Dear DNSOP WG, The draft YANG Types for DNS Classes and Resource Record Types, draft-lhotka-dnsop-iana-class-type-yang, has been presented at the IETF 103 and IETF 104. During the IETF 104 meeting, the authors asked for adoption by the DNSOP WG.  The feedback from the DNSOP WG room was positive and also previous discussions on the DNSOP mailing list (dd. 12 November 2018) were also supportive. This starts a Call for Adoption for: draft-lhotka-dnsop-iana-class-type-yang The draft is available here: https://datatracker.ietf.org/doc/draft-lhotka-dnsop-iana-class-type-yang/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view.
> 
>> Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 29 July 2019 Thanks, Benno Overeinder DNSOP co-chair _______________________________________________ DNSOP mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dnsop 
> 
> --

---

From: Normen Kowalewski <[email-masked]>
Date: Tue, 23 Jul 2019 00:05:28 +0200

Apologies I meant, DNSOP WG of course, well - its late down here...

> On 23. Jul 2019, at 00:03, Normen Kowalewski <[email-masked]> wrote:
> 
> Dear DNSWG,
>

---

From: Pieter Lexis <[email-masked]>
Date: Wed, 24 Jul 2019 13:45:54 +0200

Hello DNSOP,

> draft-lhotka-dnsop-iana-class-type-yang

I support adoption of this draft, the idea is non-controversial. I
believe the comments that have been made can be worked out and I believe
the YANG/NETCONF ecosystem can benefit from this document being
published.

Best regards,

Pieter

-- 
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com