Subject: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg

From: David Kessens <[email-masked]>
Date: Sun, 3 Nov 2013 18:20:32 -0800

Hi,

As the document shepherd for:

draft-ietf-netmod-interfaces-cfg-12
and
draft-ietf-netmod-ip-cfg-11

I have requested our Area Director Benoit whether he can take up the
document for final IESG review.

I have done a final review and I have not found any changes that are more
than minor/already has consensus since our last calls.

Since Benoit will be busy during this week, you will have until the end of
this week if there is anything that escaped our attention that you believe
needs more discussion.

Thanks,

David Kessens
---

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Nov 2013 10:43:38 -0800 (PST)

Hi,

> this week if there is anything that escaped our attention that you

I think the latest discussion about the interface type in
draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the
type from an enum to an identity.  (the mail thread was actually
called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt").

(Lada already changed the enums in the routing draft to identites)

To be very concrete, here are the proposed changes:

o  Remove the document draft-ietf-netmod-iana-if-type-07 - it is not
   needed anymore.

o  Change the leaf type from OLD:

      leaf type {
        type ianaift:iana-if-type;

   to NEW:

      leaf type {
        type identityref {
          base interface-type;
        }

o  Define the base identity, and define an identity for loopback
   interfaces:

  identity interface-type {
    description
      "Base identity from which specific interface types are
       derived.";
  }

  identity loopback {
    base if:interface-type;
    description
      "This interface type represents a loopback interface.";
  }

o  Update the examples to reflect this.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Nov 2013 10:51:16 -0800

> o  Update the examples to reflect this.

I fully support these changes.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Nov 2013 10:55:25 -0800

Hi,

My concern over identityref has been that vendors will make up their
own identities and even the enumerations that are currently useful
will become proprietary.

The proposal on the list was that the standard enums would of course be
replaced with standard identities. Now the proposal is to only
standardize 'loopback' and vendors will make up the rest on their own.
I do not think it is realistic that enum --> identity standardization will
happen in an ad-hoc fashion.  If this WG does not do it now, then it
is not going to happen.  Waiting years for the identities will only make
things worse
as vendor identities get deployed and become legacy baggage.
I think the enum draft needs to be rewritten to use identities.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Nov 2013 11:08:31 -0800

On 05 Nov 2013, at 10:55, Andy Bierman <[email-masked]> wrote:

> is not going to happen.  Waiting years for the identities will only make things worse

I think it would be helpful to treat identities not as a way for classifying the universe, but rather in a very practical YANGish way: it is a tag that is mainly useful for conditional inclusion of certain data definitions based on interface type or other identityref. Then it also makes a very good sense to bundle the corresponding identity with said data definitions.

If there is a high quality YANG module that vendors want to adopt, why should they have a problem with using the standard identity - or making their own identity derived from the standard one? And if there is no good standard model, vendors will write their proprietary models anyway, and standardized interface type identities won’t help.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Nov 2013 11:16:15 -0800

On Tue, Nov 5, 2013 at 11:08 AM, Ladislav Lhotka <[email-masked]> wrote:

> I think it would be helpful to treat identities not as a way for
> classifying the universe, but rather in a very practical YANGish way: it is
> a tag that is mainly useful for conditional inclusion of certain data
> definitions based on interface type or other identityref. Then it also
> makes a very good sense to bundle the corresponding identity with said data
> definitions.
>
>
then throw out if-type and call it something else.
I do not agree with this view of this leaf.

> If there is a high quality YANG module that vendors want to adopt, why
> should they have a problem with using the standard identity - or making
> their own identity derived from the standard one? And if there is no good
> standard model, vendors will write their proprietary models anyway, and
> standardized interface type identities won’t help.
>
>
There is no problem using the standard identity most appropriate to the
interface type.
This assumes there actually is a standard list of interface types.  That
was your original
proposal.  Now that has changed and vendors will have no standard  list to
choose from.
I am strongly opposed to this new proposal to only standardize the base
identity + loopback.

Lada
Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Nov 2013 13:37:00 -0800 (PST)

Hi,

> as vendor identities get deployed and become legacy baggage.

Even if we make identities of the iana ifType registry, there are no
standard configuration modules for these types.  So vendors will make
them, until something gets standardized.  We can't do much about it,
unless we wait until we have modelled everything before publishing...

So I don't think there's much value in having these standard
identities w/o accompanying modules.

OTOH, I can accept this (i.e., create identities from the iana
registry) as a way to move forward.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Nov 2013 13:51:03 -0800

On 05 Nov 2013, at 11:16, Andy Bierman <[email-masked]> wrote:

> There is no problem using the standard identity most appropriate to the interface type.
> This assumes there actually is a standard list of interface types.  That was your original
> proposal.  Now that has changed and vendors will have no standard  list to choose from.
> I am strongly opposed to this new proposal to only standardize the base identity + loopback.

Can you describe a scenario you are worried about? Vendors can do whatever they want, but their proprietary identities will remain in their private modules and namespaces, and will not pollute any global registry - because there will be no such thing in the first place.

If there is (ever) a useful set of standard modules for real-world interfaces, the same modules can also define a decent hierarchy of identities in a step-by-step fashion.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Nov 2013 14:03:19 -0800

> registry) as a way to move forward.

Yes, as long as they won’t be somehow mandatory to use.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Nov 2013 14:09:31 -0800

> standardized interface type identities won’t help.

The standard registry you propose only  has 1 entry -- loopback.
I find it hard to believe this is the only enum from ifType that
is used in real products.

> Can you describe a scenario you are worried about? Vendors can do whatever
> they want, but their proprietary identities will remain in their private
> modules and namespaces, and will not pollute any global registry - because
> there will be no such thing in the first place.
>
>
The scenario is obvious -- the standard registry you propose is empty.
Vendors have no standard values to choose from so they have to
use their own proprietary values.

> If there is (ever) a useful set of standard modules for real-world
> interfaces, the same modules can also define a decent hierarchy of
> identities in a step-by-step fashion.
>

No they can't.  There are not going to be WGs formed to create YANG
identities for
each interface type any time soon, if ever. The main use-case given in the
draft for the
existence of this leaf is so other data can sparse-augment the interfaces
table
(e.g. augment when "if-type = foo").

The current set of enumerations may contains cruft, there may be extra
classification
objects needed (e.g. tunnels).  So what. That is still better than nothing.
 Vendors still use
their own identities for some interface types if the standard identities
are insufficient.
WGs can define new identities over time as needed as well.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Nov 2013 14:23:12 -0800

> Yes, as long as they won’t be somehow mandatory to use.
Agreed. SHOULD use most appropriate value .
MAY use an alternate value if no appropriate standard value available.
(MAY use 'other' as well?)

Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Nov 2013 14:33:35 -0800

> (MAY use 'other' as well?)

The perspective of having “ethernetCsmacd” as the base identity for all Ethernet interfaces makes me seriously sick.

Lada

---

From: David Kessens <[email-masked]>
Date: Tue, 5 Nov 2013 16:04:07 -0800

All, Andy,

It is really getting time to get these documents published. The goal is
"good enough". The goal is not perfection.

We now have one concrete proposal for change from Martin.

We can either adopt it or stay with the original.

At this point disagreeing is not good enough, we need an alternative with
text that can be disscussed, or make it clear that you prefer the current
version without changes.

David Kessens
---

-- 

David Kessens
---

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Nov 2013 16:28:56 -0800

Hi,

The concrete proposal I agreed to on the list was to change the
if-type enums to identities.  If you want me to do the emacs
search-and-replace
to convert the enums to identities I can do that.  I am not suggesting
that the values in the registry be re-engineered at all.

The new proposal to remove all standard interface types except 'loopback'
is not acceptable.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Nov 2013 16:35:27 -0800

On 05 Nov 2013, at 16:28, Andy Bierman <[email-masked]> wrote:

> if-type enums to identities.  If you want me to do the emacs search-and-replace

It is not that simple - I assume you want to keep these identities synchronised with the IANA enumeration, right?

Lada

> 
> The new proposal to remove all standard interface types except 'loopback' is not acceptable.
> 
> 
> Andy
> 
> 
> On Tue, Nov 5, 2013 at 4:04 PM, David Kessens <[email-masked]> wrote:
> All, Andy,
> 
> It is really getting time to get these documents published. The goal is "good enough". The goal is not perfection. 
> 
> At this point disagreeing is not good enough, we need an alternative with text that can be disscussed, or make it clear that you prefer the current version without changes.
> 
> David Kessens
> ---
> 
> 
> 
>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Nov 2013 16:41:56 -0800 (PST)

Ladislav Lhotka <[email-masked]> wrote:
> It is not that simple - I assume you want to keep these identities
> synchronised with the IANA enumeration, right?

I understand the edits Andy wants, and the IANA draft already
instructs IANA to keep the YANG module in sync with the registry.  So
I think what Andy suggests is easy to do (in the documents).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Nov 2013 16:42:43 -0800

> synchronised with the IANA enumeration, right?
This issue was obviously part of the problem space whether the type
was enumeration or identity.  The RFC can be updated every couple years
as needed. The IANA registry is the normative list, not this YANG module.

Andy

> > At this point disagreeing is not good enough, we need an alternative
> with text that can be disscussed, or make it clear that you prefer the
> current version without changes.
> >
> > David Kessens
> > ---
> >
> >
> >
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Nov 2013 17:00:30 -0800

> I think what Andy suggests is easy to do (in the documents).

Two questions:

1. If somebody introduces a new ifType identity in a YANG module, is he also required to register it with IANA?

2. What if somebody wants to make use of a hierarchy of identities, i. e. derive a new identity from an existing base? The IANA registry is flat, so mapping a tree structure to it may not be possible.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Nov 2013 17:04:55 -0800 (PST)

Ladislav Lhotka <[email-masked]> wrote:
> 1. If somebody introduces a new ifType identity in a YANG module, is
> he also required to register it with IANA?

No!

> 2. What if somebody wants to make use of a hierarchy of identities,
> i. e. derive a new identity from an existing base? The IANA registry
> is flat, so mapping a tree structure to it may not be possible.

Correct.  If you want to make a hierarchy, go ahead and do that.  The
IANA types are separate.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Nov 2013 17:15:08 -0800

> also required to register it with IANA?
IMO they should not do that.
It is not an IANA type unless they register it with IANA.
That process is not changing I hope.

> 2. What if somebody wants to make use of a hierarchy of identities, i. e.
> derive a new identity from an existing base? The IANA registry is flat, so
> mapping a tree structure to it may not be possible.
>
>
Nobody is trying to change the SMIv2 data type.  The base-stmt in
a YANG identity is not coupled in any way to the IANA registry.
I don't agree that creating a tree structure is that important.
It may be more elegant, but real apps are going to hard-wire code
to match up to identities.  Finding a "close enough" interface type
doesn't seem very worthwhile as a fallback design approach.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Nov 2013 17:26:57 -0800

> > he also required to register it with IANA?

This implies that a WG is going to create new interface types that will
not be supportable in SNMP and that NETCONF is going to diverge
from the IANA registry and create its own.

This implies that the IANA considerations section of the RFC defining
the new if-type identity is not going to request IANA to allocate
a new ifType enumeration at the same time the RFC is published.
Why would we want to do that?

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Nov 2013 17:36:28 -0800

> doesn't seem very worthwhile as a fallback design approach.

The hierarchy is important for the data model. In instance data, the identity value will always be a single QName.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Nov 2013 17:36:48 -0800 (PST)

> from the IANA registry and create its own.

Not necessarily.

> Why would we want to do that?

Maybe there's already an IANA type that can be used for monitoring.
If a new IANA type is needed, then of course the WG will request a new
type.

/martin

---

From: David Kessens <[email-masked]>
Date: Tue, 5 Nov 2013 17:44:02 -0800

But you side step the question whether you can live with Andy's proposal or
not.

We really need to bring this to closure.

As the document shepherd/working group co-chair, I cannot move this
document to the next stage if we don't know where people stand.

David Kessens
---

-- 

David Kessens
---

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Nov 2013 17:44:23 -0800

On Tue, Nov 5, 2013 at 5:36 PM, Ladislav Lhotka <[email-masked]> wrote:

> > 2. What if somebody wants to make use of a hierarchy of identities, i.
> e. derive a new identity from an existing base? The IANA registry is flat,
> so mapping a tree structure to it may not be possible.
> >
> >
> The hierarchy is important for the data model. In instance data, the
> identity value will always be a single QName.
>
>
It is not important for the data model.
The identity provides a unique value whether the base is interface-type
or whether it is something derived from interface-type.
The important feature here is that identities allow any naming authority
to extend the value set.  That is why enumerations are being replaced.

Lada
Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Nov 2013 17:52:42 -0800 (PST)

> But you side step the question whether you can live with Andy's

Sorry, I thought I made it clear that I can live with Andy's
proposal.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Nov 2013 17:53:09 -0800

> to extend the value set.  That is why enumerations are being replaced.

This is only one reason. The other is that a hierarchy of identities can be effectively used for defining common parts of the data model only once and then use it for all interface types that are derived from the “abstract” type.

In my view, this kind of inheritance will be heavily used, and then the relationship with SNMP ifType will be lost anyway. 

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Nov 2013 07:13:43 -0800

Hi,

one idea, maybe - would it help to add a leaf like this?

leaf if-type {
  if-feature if-mib;

The document "draft-ietf-netmod-iana-if-type" could then remain unchanged, and the keys of the interface list would be incrementally defined identities, along the lines of Martin's original proposal.

Lada

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Wed, 6 Nov 2013 15:16:50 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ladislav Lhotka
> Sent: Wednesday, November 06, 2013 10:14 AM
> To: [email-masked]
> Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg &
> draft-ietf-netmod-ip-cfg
> 
> Hi,
> 
> The document "draft-ietf-netmod-iana-if-type" could then remain unchanged,
> and the keys of the interface list would be incrementally defined
> identities, along the lines of Martin's original proposal.
> 

Assuming this is part of the interfaces-state tree I really like this idea.

-Jeff

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Nov 2013 07:55:29 -0800

Hi,

This does not really address the problem because this leaf would not
be available unless the if-mib feature was supported, or the fact that
there are not going to be any standard YANG modules defining identities.

An empty set of identities is effectively a proprietary solution.
I do not see any standards value for 3rd party application developers
if interface types are all proprietary.

There is no reason that the current enums could not populate the
set of identities from the start.  It can be improved over time.
IMO there is no value in creating a tree of identifiers.  A hierarchical
classification system for interface types is not in the charter.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Nov 2013 08:55:24 -0800 (PST)

Hi,

>   type ianaift:iana-if-type;

If this is in config I think it would be worse.  You don't want the
user to have to figure out two values to fill in.

And if it is in oper state only it doesn't address Andy's concern.

So I prefer Andy's solution over this.

/martin

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Wed, 6 Nov 2013 17:04:46 +0000

> Of Martin Bjorklund
> Sent: Wednesday, November 06, 2013 11:55 AM
> To: [email-masked]
> Cc: [email-masked]

If the concern is that there is no "standard" way to retrieve the interface type that is compatible with SNMP, then I think this does address that. If you do not implement the if-mib feature, you are already saying that you don't care about compatibility with the SNMP defined types.

-Jeff

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Nov 2013 09:08:59 -0800 (PST)

"Lange, Jeffrey K (GE Energy Management)" <[email-masked]> wrote:
> If the concern is that there is no "standard" way to retrieve the
> interface type that is compatible with SNMP, then I think this does
> address that.

It does, but that's not the concern.  The concern is that since we
have set of standard types already, vendors that can and want to
should be able to use them w/o defining their own identities.  Vendors
that cannot use the standard identities (for one or more interfaces),
define their own identities.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Nov 2013 09:19:14 -0800

On Wed, Nov 6, 2013 at 9:04 AM, Lange, Jeffrey K (GE Energy Management) <
[email-masked]> wrote:

> interface type that is compatible with SNMP, then I think this does address
> that. If you do not implement the if-mib feature, you are already saying
> that you don't care about compatibility with the SNMP defined types.
>
>
The concern is that standard interface types are being thrown out by
NETCONF in favor
of a proprietary classification system.  Standard identifiers are needed
for interoperable management
of network interfaces.  It has  nothing to do with SNMP at all.

The original problem that you stated was the set of enums was insufficient
and identities would
allow the gaps to be filled with new interface types (defined outside
IANA).  This problem does
not logically lead to a solution that starts with an empty registry.  That
creates new problems
which are not even related to your initial concern.

Andy

---

From: t.petch <[email-masked]>
Date: Fri, 8 Nov 2013 17:58:13 +0000

David

Again harking back to May, another lengthy discussion over interfaces
was about name, which is in both interfaces/interface and
interfaces-state/interface.

Where I think we ended up was that an interface could appear in one list
or the other list or both, but when it does appear in botch (mmm
interesting typo, both I think), then it is this name that ties the
entries in the two lists together.  This is sort of implied but not
explicitly stated, and while it may become obvious, it was not so on
this list in May so I think it shoud be explicitly stated, as in my
first sentence, in s.3.1.

Tom Petch

----- Original Message -----
From: "David Kessens" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 04, 2013 2:20 AM

> this week if there is anything that escaped our attention that you
believe

------------------------------------------------------------------------
--------

---

From: t.petch <[email-masked]>
Date: Fri, 8 Nov 2013 17:52:32 +0000

David

Back in May there was a lengthy debate about what identifier should be
used for the two  types of interfaces and what the semantic difference
between them was.  We now have
system-controlled interface
and
user-controlled interface
with definitions of both, which I think good, but I think the work is
not quite complete.

We still have quite a lot of 'physical' and a pair of
'logical', which, to me, are the obsoleted terms and most of them I
think should be replaced.
e.g.
"The data model should support both physical interfaces as well as
      logical interfaces"
which, given the length of discussion we had on those terms, I think
cannot help the reader.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 8 Nov 2013 11:32:07 -0800

Hi, Tom,

> first sentence, in s.3.1.

Yes. If you look at the routing draft, it is explicitly stated in sec. 4.1.

If 6020bis is started some day, these definitions should probably go there, and maybe there could even be an annotation identifying system-controlled entries.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Nov 2013 11:53:48 -0800 (PST)

t.petch <[email-masked]> wrote:
> explicitly stated

Section 3.1 has this:

   When a system-controlled interface is created by the system, the
   system tries to apply the interface configuration in /interfaces/
   interface with the same name as the new interface.

/martin

, and while it may become obvious, it was not so on

---

From: t.petch <[email-masked]>
Date: Sat, 9 Nov 2013 12:31:40 +0000

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, November 08, 2013 7:53 PM
>    interface with the same name as the new interface.

Which makes my point nicely.  It is sort of implied but not stated
explicitly.  Read what is there and then, gosh, I just realised, can
entries be in both, how are they related?  mmm ...well, if that sentence
is accurate, then yes, sort of.

Tom Petch

> > > I have done a final review and I have not found any changes that
are
> > more
> > > Since Benoit will be busy during this week, you will have until
the
> > end of