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

From: "Normen B. Kowalewski" <[email-masked]>
Date: Wed, 2 Oct 2019 22:10:53 +0200

Hi Benno, DNSWG members,

Is there is still any open issue that keeps people from seeing the reuse of
the general purpose DNS definitinons in the IANA registry in a formal model
and by YANG as useful enough for supporting adotion?

Best regards, 

Normen

-----Ursprüngliche Nachricht-----
Von: DNSOP [mailto:[email-masked]] Im Auftrag von Normen Kowalewski
Gesendet: Dienstag, 23. Juli 2019 00:04
An: Ladislav Lhotka
Cc: Benno Overeinder; DNSOP WG
Betreff: Re: [DNSOP] Call for Adoptions:
draft-lhotka-dnsop-iana-class-type-yang

Dear DNSWG,

I also support the adoption. 

Normen Kowalewski 

> On 22. Jul 2019, at 20:13, Ladislav Lhotka <[email-masked]> wrote:
> 
> Benno Overeinder <[email-masked]> writes:
> 
>> 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.
> 
> As a co-author, I support the adoption.
> 
> Thanks, Lada
>> 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
> 
> --
> Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

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

---

From: Benno Overeinder <[email-masked]>
Date: Mon, 7 Oct 2019 17:54:10 +0200

Hi Normen and DNSOP working group,

> and by YANG as useful enough for supporting adotion?

The chairs have discussed options to proceed with the draft.  There was
some support for adoption from the DNSOP WG, but not much.  We do want
to have sufficient support in the WG, and the commitment of people to
review and contribute to the draft.

Alternatively we can ask OPSAWG to adopt the draft.  Other NETCONF/YANG
documents have previously been adopted by OPSAWG and we can request an
early review of the document.

The following question is very relevant for follow-up work, namely
whether the DNSOP WG would be interested in the further development of
YANG data models for DNS servers or other devices (for example those for
DNS telemetry).

Operators in DNSOP WG, please speak-up that this is something that
operators need and ask for.

Obviously DNSOP expertise would certainly be needed in this case, and
the proper place is DNSOP WG.

Questions to WG:

1) iana-class-type-yang document to OPSAWG?

2) follow-up work on YANG data models for DNS servers in DNSOP?

Best regards,

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

---

From: Paul Wouters <[email-masked]>
Date: Mon, 7 Oct 2019 13:31:38 -0400 (EDT)

> 1) iana-class-type-yang document to OPSAWG?

I would assume most people here will the same about the document,
wherever it is discussed ? So this option seems odd.

> 2) follow-up work on YANG data models for DNS servers in DNSOP?

Speaking for myself, as long as we are not populating RFCs with
obsoleted DNS data or just create RFC with copies of IANA registries,
I'm fine with helping on a document. But not if it is a blind copy
and paste from IANA (whether at DNSOP or OPSAWG)

Paul

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 08 Oct 2019 10:44:05 +0200

> and paste from IANA (whether at DNSOP or OPSAWG)

I still have difficulties to understand this objection. IANA registries (presumably) serve some purpose, and the only way for using them in YANG data models currently is to translate them to YANG.

If something is felt to be broken in IANA registries, then it should be corrected there in the first place. Making a YANG module as an improved version of an IANA registry sounds like a bad idea to me, also because it would be difficult to coordinate future updates.

Or do you have another suggestion?

Lada

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

---

From: Normen Kowalewski <[email-masked]>
Date: Tue, 8 Oct 2019 15:23:25 +0200

Dear Paul, Benno,

thanks for your replies.

> On 7. Oct 2019, at 19:31, Paul Wouters <[email-masked]> wrote:
> 

We should IMHO be as close to the DNS experts as possible, to me that feels rather like DNSOP than like OPSAWG.  
A "YANG doctors” expert review is part of the publication process, so this will happen anyway. It’s also worth nothing that one author is one of these experts himself.

> and paste from IANA (whether at DNSOP or OPSAWG)

In order for the IANA registry to be re-used by other YANG modules, a YANG modelled version of the registry is needed. There is precedence for doing this for other registries. e.g. The IANA ifType registry has a corresponding YANG module in RFC8343. A number of other registries also have corresponding YANG modules published or in draft (iana-identity-mib, bfd-parameters, smi-numbers).

Updating and maintaining the contents of the IANA registry as a whole is an orthogonal question to creating a YANG representation of an existing registry and should be handled as a separate task.

Finally, one reason why we would like to see this draft adopted is because we’d like to use it within a real world DNS server implementation.

BR, 

Normen

---

From: Bob Harold <[email-masked]>
Date: Tue, 8 Oct 2019 09:47:33 -0400

On Tue, Oct 8, 2019 at 9:23 AM Normen Kowalewski <[email-masked]>
wrote:

> We should IMHO be as close to the DNS experts as possible, to me that
> feels rather like DNSOP than like OPSAWG.
> A "YANG doctors” expert review is part of the publication process, so this
> will happen anyway. It’s also worth nothing that one author is one of these
> experts himself.
>
>
> In order for the IANA registry to be re-used by other YANG modules, a YANG
> modelled version of the registry is needed. There is precedence for doing
> this for other registries. e.g. The IANA ifType registry has a
> corresponding YANG module in RFC8343. A number of other registries also
> have corresponding YANG modules published or in draft (iana-identity-mib,
> bfd-parameters, smi-numbers).
>
> Updating and maintaining the contents of the IANA registry as a whole is
> an orthogonal question to creating a YANG representation of an existing
> registry and should be handled as a separate task.
>
> Finally, one reason why we would like to see this draft adopted is because
> we’d like to use it within a real world DNS server implementation.
>
> BR,
>
> Normen
>

We don't want to have to update the RFC every time the registry is
updated.  Could the RFC just describe exactly how to to convert the
registry to YANG?   Then it won't need updates.

-- 
Bob Harold

---

From: Normen Kowalewski <[email-masked]>
Date: Tue, 8 Oct 2019 15:42:36 +0200

Errmmm, sincere apologies for that typo.

I did think it is worth *noting* that one author is one of these experts himself, quite the opposite of *nothing*. 

BR, Normen

> On 8. Oct 2019, at 15:23, Normen Kowalewski <[email-masked]> wrote:
> 
> It’s also worth nothing that one author is one of these experts himself.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 08 Oct 2019 16:44:23 +0200

On Tue, 2019-10-08 at 09:47 -0400, Bob Harold wrote:
> 
> On Tue, Oct 8, 2019 at 9:23 AM Normen Kowalewski <[email-masked]> wrote:
> > Dear Paul, Benno,
> > 
> > thanks for your replies.
> > 
> > this for other registries. e.g. The IANA ifType registry has a corresponding
> > YANG module in RFC8343. A number of other registries also have corresponding
> > YANG modules published or in draft (iana-identity-mib, bfd-parameters, smi-
> > numbers).
> > 
> > Updating and maintaining the contents of the IANA registry as a whole is an
> > orthogonal question to creating a YANG representation of an existing
> We don't want to have to update the RFC every time the registry is updated. 
> Could the RFC just describe exactly how to to convert the registry to YANG? 
>  Then it won't need updates.

Only the initial version of the YANG module will be published as an RFC, and
IANA will then handle all future updates on their own. This is explained in the
I-D itself (last paragraph of the Introduction) and has already been discussed
in this mailing list.

The IANA Considerations sections then gives details about converting new
registry entries into the corresponding YANG types.

Several years of experience with the interface type registry (RFC 7224) shows
that this process works quite smoothly.

Lada

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Oct 2019 16:44:01 -0400 (EDT)

On Tue, 8 Oct 2019, Ladislav Lhotka wrote:

(added IESG to CC:)

> I-D itself (last paragraph of the Introduction) and has already been discussed

What is "future updates on its own"? How are implementors reading the
this (now old) RFC to know what they are missing or what obsoleted and
deprecated options listed in the RFC should not be implemented?

> that this process works quite smoothly.

I think this claim is both an unquantifed appeal to authority and unfair. The
technical debt of doing this happens 10+ years from now, when people are
implementing obsolete record types because a modern DNS Yang RFC references
these record types, and might be missing new record types because the
modern DNS Yang RFC did not yet have this new record type listed.

I have brought this issue of putting IANA snapshots in RFC's up on a
number of occasions and WGs now, including at IETF Plenaries. I was told
the IESG is working on it. Can the IESG tell me what is being done here,
and what the IESG believes should happen to drafts suggesting to do this
meanwhile?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Oct 2019 17:14:53 -0400 (EDT)

> I still have difficulties to understand this objection. IANA registries (presumably) serve some purpose, and the only way for using them in YANG data models currently is to translate them to YANG.

What I meant was something like this:

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

            typedef encryption-algorithm-type {
                type uint16;
                description
                    "The encryption algorithm is specified with a 16-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).";
            }

Wouldn't this define what you need, without hardcoding all the valid
values from the snapshot of the IANA registry?

This would instruct the implementor to go to the IANA registry, notice
there what is obsoleted/deprecated, and they will know they will have
to check IANA when doing a release update.

Am I misunderstanding something?

Paul

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Oct 2019 09:31:11 +0200

> deprecated options listed in the RFC should not be implemented?

They should not actually be reading the RFC but get the latest revision of the module from this page:

https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

Along with every update to the ifTypes registry, IANA also updates the iana-if-type module, the current revision date is 2019-07-16.

I do admit that this may not be clear to everybody. What we are really missing is a well-known and authoritative repository of YANG modules, at least those produced by IETF and managed by IANA.

Would it help to reclassify the RFC as historic as soon as IANA takes over the responsibility for such a module?

> modern DNS Yang RFC did not yet have this new record type listed.

I really don't understand. What DNS Yang RFC are you referring to? I am not aware of any.

> and what the IESG believes should happen to drafts suggesting to do this

We are open to all reasonable suggestions.

Thanks, Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Oct 2019 11:47:58 +0200

> Am I misunderstanding something?

This may be acceptable for humans but tools cannot do much with it. One benefit of an explicit enumeration is that tools can generate sensible code from it, e.g. to provide the user with the list of available choices.  

Lada

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Oct 2019 09:16:39 -0400 (EDT)

> This may be acceptable for humans but tools cannot do much with it. One benefit of an explicit enumeration is that tools can generate sensible code from it, e.g. to provide the user with the list o…

You can use tools to parse the IANA registry, but yes. The work _should
not_ be to blindly pick up an obsoleted/incomplete set of data that is
deemed valid a few years ago in time. People will read your enumeration
and start coding support for all those things because those are
"implemented" by you and then we see people implemented things like
the MD or MF or A6 RRTYPEs just because your yang model listed these
obsoleted record types.

So I would argue this is a feature, not a bug.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Oct 2019 09:55:50 -0400 (EDT)

> https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

You are asking for text to go into an RFC, which you then say they
(implementors) should not read. Clearly then the text should not go
into the RFC.

> I do admit that this may not be clear to everybody. What we are really missing is a well-known and authoritative repository of YANG modules, at least those produced by IETF and managed by IANA.

Right. This is why I was hoping the IESG would have made some progress
on this, as they said they were working on "this".

> Would it help to reclassify the RFC as historic as soon as IANA takes over the responsibility for such a module?

I doubt it. Since developers that need to implement some RFC number have
no idea about the historic status. They tend to not even know the
difference between experimental, standard, informational.

> I really don't understand. What DNS Yang RFC are you referring to? I am not aware of any.

Your draft.

> We are open to all reasonable suggestions.

My suggestion was a link the proper IANA registries, which _are_ updated
by other RFCs to place things into obsolete/deprecated and receive new
entries based on other new RFCs.

As you said the implementors need to go to the IANA/YANG module place, a
link to that would be more useful than including a current snapshot of
the IANA registries.

Paul

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Oct 2019 15:33:35 +0200

> (implementors) should not read. Clearly then the text should not go

It is true that the RFC is actually intended for IANA. Martin Bjorklund suggested in the NETMOD mailing list that similar RFCs only contain a template for the YANG module rather than a snapshot of the registry.

On the other hand, no syntax is defined for specifying such templates, so providing a registry snapshot as a concrete example seems logical. Moreover, IANA can use the snapshot right away as an initial revision.

...

> link to that would be more useful than including a current snapshot of

I agree but, unfortunately, any proper solution might take quite some time. As a temporary solution, would it be possible to continue with the current draft (in DNSOP WG or elsewhere) provided that it will be emphasized that the RFC is intended primarily for IANA, and that implementors should look for the module at the IANA page? 

Lada

---

From: Joe Abley <[email-masked]>
Date: Fri, 11 Oct 2019 10:03:23 -0400

> (implementors) should not read. Clearly then the text should not go

I'm not sure I fully understand the concern, here.

When a document instructs the IANA to create a registry, those instructions contain the initial rows that should seed the registry along with directions about how the registry is to be maintained following creation. Is this document fundamentally different from that?

Has anybody actually asked PTI what they think the best way of doing this would be?

Joe

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Oct 2019 16:25:41 +0200

On Fri, 2019-10-11 at 10:03 -0400, Joe Abley wrote:
> When a document instructs the IANA to create a registry, those instructions
> contain the initial rows that should seed the registry along with directions
> about how the registry is to be maintained following creation. Is this
> document fundamentally different from that?

IMO, it isn't. The purpose is also stated in the text, perhaps more explanations
can be added here and there.

> Has anybody actually asked PTI what they think the best way of doing this

I haven't, based on the precedent of RFC 7224 I took for granted that IANA is
happy with the current workflow.

Lada

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Oct 2019 10:28:16 -0400 (EDT)

> I agree but, unfortunately, any proper solution might take quite some time. As a temporary solution, would it be possible to continue with the current draft (in DNSOP WG or elsewhere) provided that…

Let's see what the IESG has to say on this, as they have been working on
this issue.

Paul