Subject: [DNSOP] request for adoption

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 12 Nov 2018 11:31:09 +0100

Hi,

we would like to ask the working group to adopt the following I-D as a
WG item:

https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-00

Let me emphasize again that the adoption doesn't mean any long-term
commitment and burden for the WG: this document only provides an initial
revision of the YANG module, and all future updates to it will be
handled by IANA, along with updates to the corresponding
registries. This process already works e.g. for the iana-if-type module:

https://www.iana.org/assignments/iana-if-type/iana-if-type.xhtml

Comments to the draft are of course welcome.

Thanks,

Lada and Petr

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

---

From: Joe Abley <[email-masked]>
Date: Mon, 12 Nov 2018 12:37:40 +0200

Hi Ladislav,

> https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-00

I have read this document, and I actually can't think of anything that would make it better. I think that it makes sense for this to be a working-group document, though, even if there's not much left for the working group to do. So there's a space-efficient review for you.

The question of adoption is one that I think would most usefully be asked by the chairs. When they ask, I shall hum approvingly.

Joe

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 12 Nov 2018 12:33:21 +0100

On Mon, 2018-11-12 at 12:37 +0200, Joe Abley wrote:
> I have read this document, and I actually can't think of anything that would
> make it better. I think that it makes sense for this to be a working-group
> document, though, even if there's not much left for the working group to do.
> So there's a space-efficient review for you.

We would like to push this document (and similar documents for the other DNS-
related IANA registries) through the IETF process as fast as possible so that a
more interesting data modelling work can start. On the other hand, we have to be
reasonably sure that we don't screw things up as mistakes could be quite
expensive.

> 
> The question of adoption is one that I think would most usefully be asked by
> the chairs. When they ask, I shall hum approvingly.

Yes, thank you.

Lada

---

From: Paul Wouters <[email-masked]>
Date: Tue, 13 Nov 2018 01:03:16 -0500 (EST)

> https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-00

I'll leave that call up to the chairs bit it sounds like a good idea.

I have reviewed the document.

First, the yand model is correct in the draft. But unfortunately, the IANA registry
itself has flaws.

I am also confused by the difference between deprecated and obsoleted. I guess the
yang model interprets the IANA regitry, but the registry has no official column
designation for this. I wonder if it should be given one. I also then suggest that
the terms obsoleted and deprecated be merged into one term.

I see some RRTYPES are listed as EXPERIMENTAL in the IANA registry while these are
really OBSOLETED. I wonder if we can do a quick draft that moves those to HISTORIC,
so this yang model can use the proper "obsoleted" entry for these. I am referring to:

MB 	7 	a mailbox domain name (EXPERIMENTAL) 	[RFC1035] 
MG 	8 	a mail group member (EXPERIMENTAL) 	[RFC1035] 
MR 	9 	a mail rename domain name (EXPERIMENTAL) 	[RFC1035]

RP 	17 	for Responsible Person

X25 	19 	for X.25 PSDN address

ISDN 	20 	for ISDN address 	[RFC1183] 
RT 	21 	for Route Through 	[RFC1183] 
NSAP 	22 	for NSAP address, NSAP style A record 	[RFC1706] 
NSAP-PTR 	23 	for domain name pointer, NSAP style

PX 	26 	X.400 mail mapping information 	[RFC2163] 
GPOS 	27 	Geographical Position 	[RFC1712]

KX 	36 	Key Exchanger 	[RFC2230]

A6 	38 	A6 (OBSOLETE - use AAAA)

DLV 	32769 	DNSSEC Lookaside Validation

The following entries are deprecated or obsoleted by an RFC, but not marked as such in the IANA
registry:

AFSDB 	18 	for AFS Data Base location  	[RFC1183][RFC5864]
SIG 	24 	for security signature 	[RFC4034][RFC3755][RFC2535][RFC2536][RFC2537][RFC2931][RFC3110][RFC3008] 
KEY 	25 	for security key 	[RFC4034][RFC3755][RFC2535][RFC2536][RFC2537][RFC2539][RFC3008][RFC3110]

NXT 	30 	Next Domain (OBSOLETE)

(Odd how NXT is marked obsolete but not SIG or KEY. These are a set and should be treated the same)

(I'm skipping NULL, MINFO/HINFO on purpose to due Olafur :)

NITS:

It seems that the IANA address in Section 3 implies Canada (CA) or more likely suffers
from the assumption that no country specified means "United States". Please specify
the country :)

Paul

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Nov 2018 17:15:27 +1100

> On 13 Nov 2018, at 5:03 pm, Paul Wouters <[email-masked]> wrote:
> 
> MB 	7 	a mailbox domain name (EXPERIMENTAL) 	[RFC1035] MG 	8 	a mail group member (EXPERIMENTAL) 	[RFC1035] MR 	9 	a mail rename domain name (EXPERIMENTAL) 	[RFC1035]
> 
> ISDN 	20 	for ISDN address 	[RFC1183] RT 	21 	for Route Through 	[RFC1183] NSAP 	22 	for NSAP address, NSAP style A record 	[RFC1706] NSAP-PTR 	23 	for domain name pointer, NSAP style
> 
> PX 	26 	X.400 mail mapping information 	[RFC2163] GPOS 	27 	Geographical Position 	[RFC1712]
> 

DLV isn’t obsolete.  The registry ISC published is gone but anyone can publish their own
registry.

> SIG 	24 	for security signature 	[RFC4034][RFC3755][RFC2535][RFC2536][RFC2537][RFC2931][RFC3110][RFC3008] KEY 	25 	for security key 	[RFC4034][RFC3755][RFC2535][RFC2536][RFC2537][RFC2539][RFC3008][RFC3110]

SIG is NOT OBSOLETE.  It is used for SIG(0).  It’s use *for DNSSEC* is obsolete.
KEY is NOT OBSOLETE.  It is used for SIG(0).  It’s use *for DNSSEC* is obsolete.

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 13 Nov 2018 01:19:16 -0500 (EST)

> DLV isn’t obsolete.  The registry ISC published is gone but anyone can publish their own

The question is if that is a bug or feature. I think it is a bug and its
time for the code base to remove this. It's ripe for abuse.

> KEY is NOT OBSOLETE.  It is used for SIG(0).  It’s use *for DNSSEC* is obsolete.

Ohhhh. Thanks for this. I didn't realise that!

Paul

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Nov 2018 08:26:42 +0000

> time for the code base to remove this. It's ripe for abuse.

what arguments or evidence do you have that it's a bug of any kind?

it's been quite useful for internal DNSSEC for non-public zones.

-- 
P Vixie

---

From: Tony Finch <[email-masked]>
Date: Tue, 13 Nov 2018 11:50:28 +0000

> it's been quite useful for internal DNSSEC for non-public zones.

Yes.

(I would like something like DLV but with slightly different semantics,
so that it is used as a fallback when the parent zone isn't reachable,
as well as when it is reachable but missing the DS records.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fitzroy: Variable 4 in southeast, otherwise southerly 6 to gale 8. Rough,
occasionally very rough in northwest, becoming moderate later in southeast.
Occasional rain in northwest. Good, occasionally moderate.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Nov 2018 13:07:55 +0100

Paul Wouters <[email-masked]> writes:

> First, the yand model is correct in the draft. But unfortunately, the
> IANA registry itself has flaws.

Hmm, I think the module should only reflect the registry contents, so
any problems should be fixed in the registry first.

>
> I am also confused by the difference between deprecated and
> obsoleted. I guess the yang model interprets the IANA regitry, but the
> registry has no official column designation for this. I wonder if it
> should be given one. I also then suggest that the terms obsoleted and
> deprecated be merged into one term.

Actually, I copied the corresponding text from RFC 7224, but I am not
sure whether the deprecated status is used at all in IANA registries. If
not, we can remove that part and leave only "obsolete". Unless somebody
knows the answer right away, I will ask IANA about it. 

>
> I see some RRTYPES are listed as EXPERIMENTAL in the IANA registry
> while these are really OBSOLETED. I wonder if we can do a quick draft

YANG doesn't define experimental status (maybe it should).

> that moves those to HISTORIC, so this yang model can use the proper

Yes, this would be a good thing to do. I assume that "historic" can be
interpreted as obsolete. BTW, the semantics of the status terms in YANG
is defined here:

https://tools.ietf.org/html/rfc7950#section-7.21.2

Thanks, Lada

> "obsoleted" entry for these. I am referring to:
>

---

From: Joe Abley <[email-masked]>
Date: Tue, 13 Nov 2018 14:18:41 +0200

> any problems should be fixed in the registry first.

I don't agree that that ordering is necessary (or desirable). If the YANG type definitions plus change processes are sufficient for a consistent representation of the registries concerned in YANG, and if the YANG continues to track the registry as I understand is intended, then fixes to the registry can happen at any time after the goals of this document have been achieved.

If accuracy of the registries is a prerequisite for progress on this document, we may as well pour concrete over it. Better to treat registry quality and the representation of the registry in YANG as orthogonal, I think.

Joe

---

From: Bjørn Mork <[email-masked]>
Date: Tue, 13 Nov 2018 13:30:44 +0100

> knows the answer right away, I will ask IANA about it. 

Don't know if it is directly relevant to DNS, but the RFC6918 abstract
makes this a question of standardisation:

   A number of ICMPv4 message types have become obsolete in practice,
   but have never been formally deprecated.  This document deprecates
   such ICMPv4 message types, thus cleaning up the corresponding IANA
   registry.

The corresponding ICMPv4 type registry does of course use the term
"deprecated" for these.

Translated to DNS, this would make MB etc "obsolete" until some future
standards track RFC officially "deprecates" them. Makes sense?

Bjørn

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Nov 2018 11:02:19 +0100

Joe Abley <[email-masked]> writes:

> I don't agree that that ordering is necessary (or desirable). If the
> YANG type definitions plus change processes are sufficient for a
> consistent representation of the registries concerned in YANG, and if
> the YANG continues to track the registry as I understand is intended,
> then fixes to the registry can happen at any time after the goals of
> this document have been achieved.
>
> If accuracy of the registries is a prerequisite for progress on this
> document, we may as well pour concrete over it. Better to treat
> registry quality and the representation of the registry in YANG as
> orthogonal, I think.

The thing is that we want IANA to perform further updates on their own,
and the instructions in the "IANA Considerations" section are intended
to be one way: if the registry changes, update the module so and so. It
would become more complicated if IANA was expected to figure out what
changes had already been applied to the module.

But I guess it also depends on the character of the changes. For
example, adding new enums that are not in the registry should certainly
be avoided.

Lada

---

From: Joe Abley <[email-masked]>
Date: Wed, 14 Nov 2018 02:10:06 -0800

> changes had already been applied to the module.

Yes. That's what I understood. I support that.

Joe

---

From: Petr Špaček <[email-masked]>
Date: Tue, 27 Nov 2018 18:00:11 +0100

On 13. 11. 18 7:03, Paul Wouters wrote:
> MB     7     a mailbox domain name (EXPERIMENTAL)     [RFC1035] MG    
> 8     a mail group member (EXPERIMENTAL)     [RFC1035] MR     9     a
> mail rename domain name (EXPERIMENTAL)     [RFC1035]

Is there any *technical* use for this field? Do we need it in the YANG
model?

Maybe we can just omit it while transforming the registry into model and
be done with it ...

-- 
Petr Špaček  @  CZ.NIC

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 28 Nov 2018 10:59:26 +0100

> Maybe we can just omit it while transforming the registry into model and

FWIW, I asked IANA whether they have a fixed list of these status terms
and what is their semantics. I got one reply so far saying that they
will discuss it with YANG experts, which of course misses my point. In
YANG, status terms are reasonably well defined, so once we know what they
mean in IANA registries, we can try to map it to YANG.

BTW, there is now a proposal to introduce "preliminary" or
"experimental" status in the next version of YANG:

https://github.com/netmod-wg/yang-next/issues/59

Lada

---

From: Paul Wouters <[email-masked]>
Date: Wed, 28 Nov 2018 08:40:14 -0500 (EST)

> Is there any *technical* use for this field? Do we need it in the YANG

The technical reason would be "It's dead Jim! Don't bother implementing this"

But if people pick up the yang model and it has all these obsolete
entries, those people in turn will start some basic implementation /
support of these. So I understand yang is not the group that should
make this decision, hence my thought of quickly adding a column to the
registry to obsolete/deprecate so that yang can skip these.

> Maybe we can just omit it while transforming the registry into model and

But then people think the yang model is incomplete?

Paul

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 30 Nov 2018 16:58:39 +0100

> support of these. So I understand yang is not the group that should

They should not, if they follow RFC 7950:

   o  "obsolete" means that the definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.

But again, the question is whether OBSOLETE in IANA registries means the
same thing.

> But then people think the yang model is incomplete?

Yes, I think it is important to keep the 1-1 mapping between the
registry and YANG module.

Enums tagged as obsolete should be no problem for implementors of the
module, and clients of management protocols such as NETCONF cannot
expect anything else from the server than an error, if they use such an
enum value.

Lada