On Mon, 2019-11-18 at 01:10 -0500, Paul Wouters wrote:
> On Mon, 18 Nov 2019, Roman Danyliw wrote:
>
> [ cc:ing ietf@xxxxxxxx for wider discussion, see attachment for Design
> Patterns ]
>
> > Paul Wouters wrote:
> > > During a plenary at the last or second last IETF, I raised an issue about
> > > people
> > > stuffing incomplete and obsolete/deprecated partial IANA registiries in
> > > yang
> > > drafts/RFCs. The IESG confirmed this as a problem to me and one of the
> > > IESG
> > > members said they were aware and would get back on this.
> > >
> > > I have not heard anything. The issue is still a problem. Originally, this
> > > came up
> > > in i2nsf/ipsecme, and has now resurfaced for me in dnsop.
> > The IESG talked about this issue during the last IETF meeting. See
> > attached.
> >
> > The outcome of this discussion was that there is no single "right answer"
> > and individual ADs should intervene on specific instances as appropriate.
>
> Thanks for the answer. Unfortunately, it is not much of guidance and
> does not really address the issue I raised, namely that we are putting
> snapshots of IANA registries in RFC documents. One of your three Design
> Patterns still does this.
The snapshot should represent the consensus of a corresponding working group
regarding the best way of modelling a given IANA registry in YANG. After the
publication of that RFC, IANA is expected to update the YANG module along with
the registry so as to keep both in sync.
I do agree that careless YANG modellers that don't bother to read the RFC could
take the YANG module snapshot published therein as the most recent revision
because the RFC itself isn't updated. Perhaps the purpose and expeced use of the
module can be stated more clearly in the RFC, but it still won't help those who
don't read it.
>
> Note also that Design Pattern #1 you quote is exactly the one I am
> trying to avoid from happening and Design Pattern #2 happened because
> I _did_ convince those people not to do Design Pattern #1.
I strongly disagree with the statement that design pattern #1 cannot be updated.
First, as described in draft-lhotka-dnsop-iana-class-type-yang-02, the YANG
module is expected to be updated (by IANA) every time the corresponding registry
changes. So the enumeration can be updated with new mnemonic names.
And second, implementors of the YANG module can in fact use the type 'dns-class'
that is defined as follows:In effect, the 'dns-class' type combines desing
patterns #1 and #2. BTW, t
typedef dns-class {
type union {
type uint16;
type dns-class-name;
}
description
"This type allows for referring to a DNS class using either the
assigned mnemonic name or numeric value.";
}
I apologize to those who don't speak YANG but the meaning should be clear: if
somebody wants to use a DNS class that is not defined in the 'dns-class-name'
enumeration, he or she can use the numeric value instead. This is analogical to
using CLASS42 in other contexts as per RFC 3597.
In effect, the 'dns-class' type above combines design patterns #1 and #2.
Roman's presentation also doesn't mention another design pattern that was used
in the aforemetioned RFC 7224 for the interface types registry, namely to model
interface types as YANG identities.
Lada
>
> I would like to see the IESG discourage/forbid Design Pattern #1. The
> "yang native" advantage of this Design Pattern seems odd to me, because
> as far as I know there will be specific yang documents created elsewhere
> anyway that are supposed to be updated and used by automation tools?
>
> Paul
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
