Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Tue, 1 Oct 2013 18:07:39 +0000

I just wanted to pass along that I have created an implementation against this model (and the corresponding interfaces model). I did not find any issues with it in the process other than to reiterate what Jeurgen mentioned about the fact that /interfaces-state/interface/ipv[46] are presence containers. This doesn't seem to make a lot of sense for config-false data.  Was there ever a definitive answer on if this is truly desired?

And as I've mentioned before, the iana-if-type enum doesn't work for us. I've implemented this using my own identity type for interfaces due to the fact that we have way too many proprietary interface types to make it work with the if-type enum. I know this was brought up before and rejected due to MIB interoperability issues, but that's the only real limitation we are hitting with these models. If this was an identity we would be able to use them as is.

-Jeff

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Sunday, August 25, 2013 4:39 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the NETCONF Data Modeling Language Working
> Group of the IETF.
> 
> 	Title           : A YANG Data Model for IP Management
> 	Author(s)       : Martin Bjorklund
> 	Filename        : draft-ietf-netmod-ip-cfg-10.txt
> 	Pages           : 33
> 	Date            : 2013-08-25
> 
> Abstract:
>    This document defines a YANG data model for management of IP
>    implementations.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-10
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-ip-cfg-10
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Oct 2013 20:40:34 +0200 (CEST)

Hi,

Thank you for this implementation report!

"Lange, Jeffrey K (GE Energy Management)" <[email-masked]> wrote:
> I just wanted to pass along that I have created an implementation against this
> model (and the corresponding interfaces model). I did not find any issues with
> it in the process other than to reiterate what Jeurgen mentioned about the fact
> that /interfaces-state/interface/ipv[46] are presence containers. This doesn't
> seem to make a lot of sense for config-false data.  Was there ever a definitive
> answer on if this is truly desired?

The only discussion I find re. presence containers was about the
config tree
(http://www.ietf.org/mail-archive/web/netmod/current/msg08479.html).

If there was some other discussion that I don't remember, please point
me in the right direction.

In any case, I'd like to understand why you think using presence
containers in the -state tree is problematic?  The statement says:

   container ipv4 {
      presence "Present if IPv4 is enabled on this interface";
      config false;

... so if ipv4 is disabled, this container will not show up in a <get>
reply.

> And as I've mentioned before, the iana-if-type enum doesn't work for us. I've
> implemented this using my own identity type for interfaces due to the fact that
> we have way too many proprietary interface types to make it work with the
> if-type enum. I know this was brought up before and rejected due to MIB
> interoperability issues, but that's the only real limitation we are hitting
> with these models. If this was an identity we would be able to use them as is.

I believe Juergen also asked why you could not use the IANA procedure
and register your proprietary interface types?

/martin

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Tue, 1 Oct 2013 19:05:39 +0000

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Tuesday, October 01, 2013 2:41 PM
> To: Lange, Jeffrey K (GE Energy Management)
> Cc: [email-masked]
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt
> 
> Hi,
> 

>From a previous email:
> >    /if:interfaces-state/if:interface/ipv4
> >    /if:interfaces-state/if:interface/ipv6
> >    /ip-state/ipv4
> >    /ip-state/ipv6
> >    
> >    These leafs indicate that IPvX is enabled and hence they do
> >    actually carry semantics - if they do not show up, then
> >    /if:interfaces/if:interface/ipvX/enabled is most likely false.

> containers in the -state tree is problematic?  The statement says:

It's not problematic per-se, but seems unneeded.  If it's not configured, nothing is returned.  If there was mandatory leafs under there it would make sense I guess, but there is not.

> and register your proprietary interface types?

We have lots of custom interface types, and one-off designs that would mean absolutely nothing to the Internet community at large.  If we need to submit to an international standard body every time we want to create a new custom interface type, it just doesn't make any sense.  If this was an identity, with all the currently defined iana-iftypes defined as identities sharing the same common base identity type, we (and others in the same position as us) would be simply define a new interface type by creating a new identity in our yang models.

-Jeff

---

From: Andy Bierman <[email-masked]>
Date: Tue, 1 Oct 2013 12:52:31 -0700

On Tue, Oct 1, 2013 at 12:05 PM, Lange, Jeffrey K (GE Energy Management) <
[email-masked]> wrote:

> > > I just wanted to pass along that I have created an implementation
> against
> > this
> > > model (and the corresponding interfaces model). I did not find any
> issues
> > with
> > > it in the process other than to reiterate what Jeurgen mentioned about
> the
> > fact
> It's not problematic per-se, but seems unneeded.  If it's not configured,
> nothing is returned.  If there was mandatory leafs under there it would
> make sense I guess, but there is not.
>
>

IMO a presence container in config=false is a bit confusing.
I also think the mandatory=true in a config=false node is confusing.
If seems to mean "server MUST implement".  But that would imply
that mandatory=false means "server MAY implement".
However the module base + YANG features are supposed
to be the only conformance mechanisms.  It is not very clear what
mandatory-stmt means for config=false nodes.

> > > And as I've mentioned before, the iana-if-type enum doesn't work for
> us.
> > I've
> > > implemented this using my own identity type for interfaces due to the
> fact
> > that
> > > with these models. If this was an identity we would be able to use
> them as
> > is.
> >
> We have lots of custom interface types, and one-off designs that would
> mean absolutely nothing to the Internet community at large.  If we need to
> submit to an international standard body every time we want to create a new
> custom interface type, it just doesn't make any sense.  If this was an
> identity, with all the currently defined iana-iftypes defined as identities
> sharing the same common base identity type, we (and others in the same
> position as us) would be simply define a new interface type by creating a
> new identity in our yang models

This is a standard module so we need to make sure that there is
some hope of interoperability.  I think you can augment the module
with additional classifiers that only your apps understand (since they
are the only ones that understand your if-type enums).  Pick the
closest enum or use 'other' as a last resort.

-Jeff
Andy

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Wed, 2 Oct 2013 13:18:34 +0000

>> We have lots of custom interface types, and one-off designs that would mean absolutely
>> nothing to the Internet community at large.  If we need to submit to an international standard
>> body every time we want to create a new custom interface type, it just doesn't make any sense.
>> If this was an identity, with all the currently defined iana-iftypes defined as identities sharing the
>> same common base identity type, we (and others in the same position as us) would be simply
>> define a new interface type by creating a new identity in our yang models

>Andy

Perhaps I'm missing part of an old conversation, but what would the drawbacks be to making the if type an identity vs an enum? Is it simply and argument of "we don't' want to change it" or is there a more fundamental technical reason that it must remain an enum?  I think the arguments for making it an identity are pretty compelling from an extensibility standpoint.

-Jeff

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Oct 2013 17:09:11 +0200

> Perhaps I'm missing part of an old conversation, but what would the drawbacks be to making the if type an identity vs an enum? Is it simply and argument of "we don't' want to change it" or is there…

There is one technical issue, namely that there is no support for identities in XPath expressions:

1. 'must' and 'when' conditions based on equality of identities are necessarily fragile. Consider an equivalent for

    when "if:type = 'ethernetCsmacd'";

With identities, the XPath expression would have to match *qualified names* of identities, and this cannot be done properly, i.e., without relying on the equality of namespace prefixes.

2. It is impossible to make use of the hierarchy of identities. For example, suppose you modify a standard interface X into a new interface type Y, and you want to reuse configuration parameters of type X and perhaps add several new ones. Then, if the parameters of X are defined with
 
    when "if:type = X";

you are out of luck because the interface type is Y != X. What's really needed in this case is to
have Y as an identity derived from X, and then specify the 'when' condition for X like this:

    when "yang:derived-from(if:type, X)";

Interface types based on the IANA registry do not have problem #1 but, on the other hand, they do not offer any solution to #2 (and probably never will).

Lada

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

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Wed, 2 Oct 2013 15:46:10 +0000

> With identities, the XPath expression would have to match *qualified
> names* of identities, and this cannot be done properly, i.e., without relying
> on the equality of namespace prefixes.
> 

I'm not seeing how this is different than having:
module iana-if-type {
     namespace "urn:ietf:params:xml:ns:yang:iana-if-type";
     prefix ianaift;

  identity iftype {
    description
      "Base Interface type";
  }
  identity ethernetCsmacd {
    base iftype;
    description
      "Ethernet interface type";
  }
}

And then using:
  when "if:type = 'ianaift:ethernetCsmacd";

This is in essence what I am doing today, and it works perfectly fine.

> 2. It is impossible to make use of the hierarchy of identities. For example,
> suppose you modify a standard interface X into a new interface type Y, and
> you want to reuse configuration parameters of type X and perhaps add
> several new ones. Then, if the parameters of X are defined with
> 
>     when "if:type = X";
> 

I don't see how either enums or identities have any bearing on the above.

-Jeff

> Interface types based on the IANA registry do not have problem #1 but, on
> the other hand, they do not offer any solution to #2 (and probably never
> will).
> 
> Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 2 Oct 2013 09:06:35 -0700

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

> mean absolutely
> Perhaps I'm missing part of an old conversation, but what would the
> drawbacks be to making the if type an identity vs an enum? Is it simply and
> argument of "we don't' want to change it" or is there a more fundamental
> technical reason that it must remain an enum?  I think the arguments for
> making it an identity are pretty compelling from an extensibility
> standpoint.
>

YANG identities are too extensible for this particular leaf.
YANG enumerations are defined by a single centralized
naming authority (IANA).  The entire set of values is
contained within 1 YANG statement.  Identities are defined
by any naming authority (hence the need for QNames).
The entire set of values is unknowable since any YANG module
can add new identity-stmts and extend it.

A lot of investment has been made in the IANA interface
type registry and I want vendors to use it.  If every
vendor can replace these enums with their own definitions,
then 3rd party clients will have to hard-code the identities
used by each server vendor.  That is not very interoperable.

Andy

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Wed, 2 Oct 2013 16:29:13 +0000

> can add new identity-stmts and extend it.

My counter-argument is that by making the if type an identity you are actually increasing the interoperability of things.  Take the example where there is a product that has a custom XYZ interface.  In order to use the XYZ interface seamlessly with the standard interfaces list (assuming the current iftype enum) you would have to set the type to "other" then augment in some other selector as to what the type of the interface is so that you can augment in any XYZ specific configuration variables. If an external management application wants to configure that interface, they already need to special case the code to deal with that custom interface type.  

This extra selector code is not interoperable because every vendor would do it differently. If on the other hand, the current IANA iftype list was converted to identities, then there is still a standard and common list of values that the majority of all "standard" devices would be able to use for their interfaces. BUT, it allows the extensibility of proprietary interfaces in a STANDARD way.

> used by each server vendor.  That is not very interoperable.

I am in no way advocating abandoning this registry, but forewarning that if it is overly restrictive in allowing someone to do what they need, it won't get used at all.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 2 Oct 2013 11:59:30 -0700

Hi,

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

> My counter-argument is that by making the if type an identity you are
> actually increasing the interoperability of things.  Take the example where
> there is a product that has a custom XYZ interface.  In order to use the
> XYZ interface seamlessly with the standard interfaces list (assuming the
> current iftype enum) you would have to set the type to "other" then augment
> in some other selector as to what the type of the interface is so that you
> can augment in any XYZ specific configuration variables. If an external
> management application wants to configure that interface, they already need
> to special case the code to deal with that custom interface type.
>
>

If you are saying the standard identifier does not support proprietary
non-standard extensions, you are correct.  IMO that is a feature, not a bug.
You can augment the interface list with all the proprietary classifiers that
you want.  Or you can get IANA to assign new standard interface types.

> This extra selector code is not interoperable because every vendor would
> do it differently. If on the other hand, the current IANA iftype list was
> converted to identities, then there is still a standard and common list of
> values that the majority of all "standard" devices would be able to use for
> their interfaces. BUT, it allows the extensibility of proprietary
> interfaces in a STANDARD way.
>
>

No -- just because my code can validate an identityref as
being valid for the specified base, it does not imply that my code
knows what your identity means.  It is no more valuable
than 'other' unless the client knows the non-standard extension.

> I am in no way advocating abandoning this registry, but forewarning that
> if it is overly restrictive in allowing someone to do what they need, it
> won't get used at all.
>
>
I do not agree the current IANA-based registry is unusable.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 2 Oct 2013 21:16:04 +0200

> This is in essence what I am doing today, and it works perfectly fine.

The "identityref" type doesn't have a canonical form, so the value of "if:type" may use another prefix than "ianaift" or sometimes even no prefix, and then the XPath string comparison will break.
  
> I don't see how either enums or identities have any bearing on the above.

Take the example in appendix A of interfaces-cfg. The parameters defined in that module cannot be reused by an interface type other than 'ethernetCsmacd', even if it is only a slightly modified Ethernet. 

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 2 Oct 2013 21:27:09 +0200

On Oct 2, 2013, at 6:06 PM, Andy Bierman <[email-masked]> wrote:

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

Hmm… The registry contains many values that are obsolete, obscure or even funny ("coffee"), but the most common interface types are represented only by very general entries - all Ethernet interfaces fall under ethernetCsmacd, and different types of tunnels also have only one entry "tunnel". That's probably why vendors don't use the registry in their CLIs.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 2 Oct 2013 12:51:34 -0700

On Wed, Oct 2, 2013 at 12:27 PM, Ladislav Lhotka <[email-masked]> wrote:

> ...
> Hmm… The registry contains many values that are obsolete, obscure or even
> funny ("coffee"), but the most common interface types are represented only
> by very general entries - all Ethernet interfaces fall under
> ethernetCsmacd, and different types of tunnels also have only one entry
> "tunnel". That's probably why vendors don't use the registry in their CLIs.
>
>

If many vendors are not able to pick appropriate standard enumerations
for their standard interface types, then that is a general problem
that affects SNMP ifType and NETCONF if-type.  I am not aware of
such a problem.

I expect the registry to contain all entries ever assigned, so
the values never get reused inadvertently.

Andy

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Wed, 2 Oct 2013 19:52:11 +0000

> Hmm... The registry contains many values that are obsolete, obscure or even
> funny ("coffee"), but the most common interface types are represented
> only by very general entries - all Ethernet interfaces fall under

+1

---

From: Andy Bierman <[email-masked]>
Date: Wed, 2 Oct 2013 13:05:41 -0700

> > "tunnel". That's probably why vendors don't use the registry in their
I do not object to an additional optional leaf that is type identityref.
Inventing a new standard interface classification system takes time.
I do not like using embedded semantics in the interface name
to add classifiers to the interface. Something like:

identity interface-clasifier;

Add to /interfaces/interface:

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

    }

---

From: Andy Bierman <[email-masked]>
Date: Wed, 2 Oct 2013 13:10:43 -0700

oops - gmail sent this before I was done (I hate the new gmail!)

On Wed, Oct 2, 2013 at 1:05 PM, Andy Bierman <[email-masked]> wrote:

> identity interface-classifier;
>
                "Standard or vendor specific interface classification";

Also add to /interfaces/interface-state,
If the client knows what to provide it can set it in the interface entry
when the interface is created.  If not, it can read the interface-state
to see if there is an additional classifier.

Andy

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Fri, 4 Oct 2013 15:12:12 +0000

Unrelated to previous messages about this draft, Why is it that /ip-state/ipv6/neighbor has a 'state' leaf (incomplete/reachable/etc..), but /ip-state/ipv4/neighbor does not?

This is valid for ipv4 neighbors as well. e.g on Linux:
# ip neigh show
192.168.1.2 dev eth0 lladdr 00:12:17:5c:4f:2d STALE

I also question why the neighbor entries are at the top-level ip-state as opposed to per-interface?  If you are configuring static ARP entries, you do it at the interface level, not at some top-level IP configuration container.  It seems to follow that the state should match the same hierarchy.  This would allow the removal of the interface lead from the neighbor list, as it would already be relative to a specific interface.

-Jeff

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Fri, 4 Oct 2013 20:41:14 +0000

Also, in regards to the neighbor state enum values.  Is there a reason it does not also include the standard values of:

- failed
- noarp
- permanent

-Jeff

> Behalf Of Lange, Jeffrey K (GE Energy Management)
> Sent: Friday, October 04, 2013 11:12 AM
> To: [email-masked]
> Unrelated to previous messages about this draft, Why is it that /ip-
> state/ipv6/neighbor has a 'state' leaf (incomplete/reachable/etc..), but /ip-
> state/ipv4/neighbor does not?
> 
> I also question why the neighbor entries are at the top-level ip-state as
> opposed to per-interface?  If you are configuring static ARP entries, you do it
> at the interface level, not at some top-level IP configuration container.  It
> seems to follow that the state should match the same hierarchy.  This would
> allow the removal of the interface lead from the neighbor list, as it would
> already be relative to a specific interface.
> 
> -Jeff
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Oct 2013 16:20:48 +0200 (CEST)

Hi,

"Lange, Jeffrey K (GE Energy Management)" <[email-masked]> wrote:
> Unrelated to previous messages about this draft, Why is it that
> /ip-state/ipv6/neighbor has a 'state' leaf
> (incomplete/reachable/etc..), but /ip-state/ipv4/neighbor does not?

ARP does not define such states.  The IP-MIB says this re. this
object:

   If Neighbor Unreachability Detection is not in use (e.g. for
   IPv4), this object is always unknown(6)

> 192.168.1.2 dev eth0 lladdr 00:12:17:5c:4f:2d STALE

Yes.  It is a bit unclear to me what the different states would mean
for ARP.

> I also question why the neighbor entries are at the top-level ip-state
> as opposed to per-interface?

The only reason is that this how the neighbor info commonly is
queried; e.g., you used "ip neigh show" above.

OTOH, it is straight-forward to get all neigbor info from all
interfaces with a filter.

And RFC 4861 defines the neighbor cache to be a per interface
structure.

I think both ways work - what does other people think?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Oct 2013 16:30:45 +0200 (CEST)

Hi,

"Lange, Jeffrey K (GE Energy Management)" <[email-masked]> wrote:
> Also, in regards to the neighbor state enum values.  Is there a reason
> it does not also include the standard values of:

The enumerations included are the five values defined in RFC 4861.

> - permanent

As for permanent, this is typically (only?) set if the entry was
configured; this information is present in the 'origin' leaf.

/martin

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Mon, 7 Oct 2013 15:14:27 +0000

> Sent: Monday, October 07, 2013 10:31 AM
While this may be true, adding it as an option makes it consistent with how windows and linux both show their neighbor entry statuses.

Linux:
$ip neigh show dev eth1
1.2.3.4 lladdr 00:11:22:33:44:55 PERMANENT

Window:
>netsh interface ipv4 show neighbors

Internet Address                              Physical Address   Type
--------------------------------------------  -----------------  -----------
224.0.0.2                                     01-00-5e-00-00-02  Permanent

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 7 Oct 2013 17:46:13 +0200

> queried; e.g., you used "ip neigh show" above.

Same in Cisco IOS: "show ip arp". And static ARP entries are configured as global:

arp 10.0.0.0 aabb.cc03.8200 arpa

Lada

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Mon, 7 Oct 2013 16:00:43 +0000

> From: Ladislav Lhotka [mailto:[email-masked]]
> Sent: Monday, October 07, 2013 11:46 AM
> To: Martin Bjorklund
> Cc: Lange, Jeffrey K (GE Energy Management); [email-masked]

My feeling on this is that it can go either way, but that the configuration should match the status. If static neighbor entries are configured per interface (/interfaces/interface/ipv4/neighbor) then it should follow that the state be laid out in the same manor.

Either:
/interfaces/interface/ipv4/neighbor & /interfaces-state/interface/ipv4/neighbor
Or
/ip/ipv4/neighbor & /ip-state/ipv4/neighbor

-Jeff

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 7 Oct 2013 18:09:09 +0200

> /ip/ipv4/neighbor & /ip-state/ipv4/neighbor

Yes, I agree both config and state should use the same organization.

Lada

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Mon, 7 Oct 2013 21:04:57 +0000

> >
> > My feeling on this is that it can go either way, but that the
> configuration should match the status. If static neighbor entries are
> configured per interface (/interfaces/interface/ipv4/neighbor) then it
> should follow that the state be laid out in the same manor.
> >
> > Either:

How about the following?

Move /interfaces/interface/ipv[46]/neighbor to /ip/ipv[46]/neighbor and add an optional interface-ref to the list?
I also made link-layer-address mandatory, as without that it's not a very useful configuration entry.  This now gives a place where system-wide IP settings can be augmented into.

Should /ip/ipv[46] be presence containers for global ipv[46] disabling?

  container ip {
    container ipv4 {
      list neighbor {
        key "ip";
        description
          "A list of mappings from IPv4 addresses to
           link-layer addresses.

           Entries in this list are used as static entries in the
           ARP cache.";
        reference
          "RFC 826: An Ethernet Address Resolution Protocol";

        leaf ip {
          type inet:ipv4-address-no-zone;
          description
            "The IPv4 address of the neighbor node.";
        }
        leaf link-layer-address {
          type yang:phys-address;
          mandatory true;
          description
            "The link-layer address of the neighbor node.";
        }
        leaf interface {
          type if:interface-ref;
          description
            "The interface to which the neighbor is attached.";
        }
      }
    }
    container ipv6 {
    list neighbor {
      key "ip";
        description
          "A list of mappings from IPv6 addresses to
           link-layer addresses.

           Entries in this list are used as static entries in the
           Neighbor Cache.";
        reference
          "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)";

        leaf ip {
          type inet:ipv6-address-no-zone;
          description
            "The IPv6 address of the neighbor node.";
        }
        leaf link-layer-address {
          type yang:phys-address;
          mandatory true;
          description
            "The link-layer address of the neighbor node.";
        }
        leaf interface {
          type if:interface-ref;
          description
            "The interface to which the neighbor is attached.";
        }
      }
    }
  }

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 08 Oct 2013 18:26:33 +0200

+1

+1

> Should /ip/ipv[46] be presence containers for global ipv[46] disabling?

Would this be useful? Without any static neigbour entries (which is IMO a common case) the containers needn't be present in the configuration.

Lada

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Tue, 8 Oct 2013 18:22:33 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ladislav Lhotka
> Sent: Tuesday, October 08, 2013 12:27 PM
> To: [email-masked]
> > Move /interfaces/interface/ipv[46]/neighbor to /ip/ipv[46]/neighbor and
> add an optional interface-ref to the list?
> 
> +1
> 
> > I also made link-layer-address mandatory, as without that it's not a
> very useful configuration entry.  This now gives a place where system-wide
> IP settings can be augmented into.
> 
> +1
> 

After playing with this a bit, on Linux at least, you cannot create a static neighbor entry without specifying an interface. So placing this at a top level /ip may not make as much sense as leaving it in /interfaces/interface.  And if that is the case, then the status version should also live in /interfaces-state/interface.

What is the behavior in other environments (Cisco/Juniper)? 

-Jeff

> Would this be useful? Without any static neigbour entries (which is IMO a
> common case) the containers needn't be present in the configuration.
> 
> Lada
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 8 Oct 2013 21:05:42 +0200

On Oct 8, 2013, at 8:22 PM, "Lange, Jeffrey K (GE Energy Management)" <[email-masked]> wrote:

> After playing with this a bit, on Linux at least, you cannot create a static neighbor entry without specifying an interface. So placing this at a top level /ip may not make as much sense as leaving it in

Why not? This works on my Linux box:

$ sudo arp -s 172.29.2.224 44:87:fc:9e:7e:bb

In Linux, the neighbour cache is global but every neighbour structure has the "dev" member containing the pointer to the device/interface, and actually the device is also part of the input to the hash function for neighbour lookup.

But still, I believe it is useful to be able to *configure* ARP/neighbour entries without specifying the interface, because such a configuration remains valid even after the interface to which the neighbour is connected changes. It can be left to the server to figure out the interface when processing the configuration.

> /interfaces/interface.  And if that is the case, then the status version should also live in /interfaces-state/interface.
> 

As I wrote earlier, the IOS command doesn't need the interface:

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 08 Oct 2013 23:15:55 +0200 (CEST)

Hi,

Ladislav Lhotka <[email-masked]> wrote:
> > After playing with this a bit, on Linux at least, you cannot create a static
> > neighbor entry without specifying an interface. So placing this at a top
> > level /ip may not make as much sense as leaving it in
> 

It works, but the man page says:

   if  this  option [interface] is not used, the kernel will
   guess based on the routing table.

> In Linux, the neighbour cache is global but every neighbour structure has the
> "dev" member containing the pointer to the device/interface, and actually the
> device is also part of the input to the hash function for neighbour lookup.
> 
> But still, I believe it is useful to be able to *configure* ARP/neighbour
> entries without specifying the interface, because such a configuration remains
> valid even after the interface to which the neighbour is connected changes. It
> can be left to the server to figure out the interface when processing the
> configuration.

I don't think this is a good idea.  This complicates things quite a
lot.  We'd need to specify exactly during which circumstances
(interfaces come and go, routing changes...) the mapping is (re)done.

I prefer to keep the config as it is, and move the state structure to
match the config, as Jeff suggested.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 9 Oct 2013 09:39:03 +0200

>   guess based on the routing table.

And that's exactly my point - given the L3 address, the interface info is redundant. I can put such static ARP entries to an init script, and they will continue to work after the corresponding interface changes from eth0 to eth1. It is less of a problem with the "arbitrary-names" feature though.
 
> match the config, as Jeff suggested.

Note that Cisco IOS, JUNOS and Linux display the ARP cache as a global table - presumably because it *is* a global table. So I think it is better to keep at least the state data as they are in -10.

Lada

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Wed, 9 Oct 2013 12:26:44 +0000

> > After playing with this a bit, on Linux at least, you cannot create a
> static neighbor entry without specifying an interface. So placing this at
> a top level /ip may not make as much sense as leaving it in
> 

If you are attempting to add an IPv6 entry, you need to use the "ip" command

$ sudo ip -6 neigh add dead:beef::23 lladdr 00:11:22:33:44:55
Device and destination are required arguments.
$ sudo ip -6 neigh add dead:beef::23 lladdr 00:11:22:33:44:55 dev eth0
$

-Jeff

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 9 Oct 2013 15:52:24 +0200

> $ sudo ip -6 neigh add dead:beef::23 lladdr 00:11:22:33:44:55 dev eth0

I checked four platforms (JUNOS, Cisco IOS, Mikrotik RouterOS, Linux) and it seems that

- for setting static ARP (IPv4) entries, some platforms/commands require an interface (JUNOS, RouterOS, Linux "ip") and some don't (IOS, Linux "arp"),

- for setting IPv6 neighbour entries, an interface is always required,

- show-like commands always present neighbour caches as a global table, with various filtering options (show entries for a given interface, show the entry for a given IP address).

So I am now leaning towards keeping the neighbour stuff as it is in -10.

Lada

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Wed, 9 Oct 2013 14:06:01 +0000

> Sent: Wednesday, October 09, 2013 9:52 AM
> - for setting static ARP (IPv4) entries, some platforms/commands require
> an interface (JUNOS, RouterOS, Linux "ip") and some don't (IOS, Linux
> "arp"),
> 
> - show-like commands always present neighbour caches as a global table,
> with various filtering options (show entries for a given interface, show
> the entry for a given IP address).
> 

If things are kept how they are, I would still change the link-layer-address in the neighbor list to be mandatory.

I also still suggest adding the neighbor state to /ip-state/ipv4/neighbor, although I understand Martin's concern that this is not "defined" as a standard for ARP.  This is very useful information when you are trying to debug connectivity issues.

-Jeff

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Oct 2013 16:18:30 +0200 (CEST)

"Lange, Jeffrey K (GE Energy Management)" <[email-masked]> wrote:
> If things are kept how they are

I can go either way - keep it as it is, or move the neighbor state to
per-interface.  I think it is pretty trivial to implement this even if
there is a global table, and it is also pretty trivial to filter in
all lists; for example, to get all neighbors w/ ip address 10.0.0.1:

   /interfaces-state/interface/ipv4/neighbor[ip='10.0.0.1']

The same query with the current design (one global list):

   /ip-state/ipv4/neighbor[ip='10.0.0.1']

> I would still change the
> link-layer-address in the neighbor list to be mandatory.

Agreed.

/martin

> I also still suggest adding the neighbor state to
> /ip-state/ipv4/neighbor, although I understand Martin's concern that
> this is not "defined" as a standard for ARP.  This is very useful
> information when you are trying to debug connectivity issues.
> 
> -Jeff
> 
> > Lada
> > 
> > >
> > > -Jeff
> > >
> > 
> > --

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Wed, 9 Oct 2013 14:28:00 +0000

> Sent: Wednesday, October 09, 2013 10:19 AM
> Cc: [email-masked]; [email-masked]

My feelings are that "/ip-state" just seems out of place in this model. All IP configuration that is defined is per-interface. So it just seems a bit awkward to have this extra state container sitting at the top of the tree.

-Jeff

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Oct 2013 16:32:19 +0200 (CEST)

"Lange, Jeffrey K (GE Energy Management)" <[email-masked]> wrote:
> My feelings are that "/ip-state" just seems out of place in this
> model. All IP configuration that is defined is per-interface. So it
> just seems a bit awkward to have this extra state container sitting at
> the top of the tree.

Yes, I think you are right.  It would be very useful to hear other
people's opinions as well.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Oct 2013 09:27:01 +0200

> I also made link-layer-address mandatory, as without that it's not a very useful configuration entry.  This now gives a place where system-wide IP settings can be augmented into.

I think this approach fails if you need to configure the same IP
address neighbor on different interfaces. We need to consider
link-local addresses etc. in our design.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Oct 2013 09:34:55 +0200

> I do not agree the current IANA-based registry is unusable.

My conclusion (as technical contributor) here is that the IANA
registry (a) contains junk (ugly but not really a problem) and (b) has
been optimized for monitoring (since entries are related to interface
type specific monitoring MIB modules), not for configuration. 

The later is a problem - whatever we do, we will likely need
additional registrations for configuration - so whether we have a flat
registry (the current one) or a new one, we will face this sooner than
later.

As Lada said, a type hierarchy requires XPATH functions to be able to
use it effectively in YANG data models. We discussed before that YANG
needs a collection of XPATH functions - but we don't have them. So
we essentially have two options:

a) Use the flat IANA registry and be done, even though it is not very
   flexible.

b) Stall the document until a suitable collection of XPATH functions
   has been defined.

c) Move to an identity based type hierarchy with an understanding that
   this requires to define XPATH functions to be really useful.

Personally, I believe for configuration, you likely want an interface
type hierarchy if you were to design a product yourself. Getting this
hierarchy defined/standardized properly, however, will not be trivial.
If this is done carelessly, we will end up with a mess over the years.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Oct 2013 05:04:31 -0700

Hi,

I strongly object to replacing the enumeration controlled by IANA
with an identityref controlled by vendors.

An additional leaf with values not controlled by IANA is acceptable.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Oct 2013 14:13:47 +0200

> An additional leaf with values not controlled by IANA is acceptable.

It might be more constructive to respond to the technical issues and
trade-offs I have described. IANA can very well maintain standard
identities. A standard to configure, lets say 802.11 networks, will
have to allocate a standard interface type. The same goes to a
standard to configure PPP tunnels.

You have worked for several vendors in the past and you may want to
check how many of them used the currently registered interface types
for _configuration_.

/js

PS: As co-chair, I note your position.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Oct 2013 05:20:00 -0700

Hi,

I have brought up this concern before a few times, so I wonder why
it was ignored in your issue summary.  IMO, picking the most appropriate
value from a closed standard list is better than picking what amounts
to an arbitrary value from an unbounded list.

If every vendor is allowed to replace the IANA identities with their
own, then it isn't IANA if-type anymore. A 3rd party client developer has
no idea what values will be used on a server implementation.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 15 Oct 2013 14:34:54 +0200 (CEST)

> to an arbitrary value from an unbounded list.

We are talking about the situation where a vendor must pick an
appropriate interface type for the hardware he's got.  If there is a
matching if-type available, we're good in both cases (enum or
identity).  The question is what happens when there is no matching
if-type available, as in Jeff's case.  You are worried that a client
won't know what to use in this case.  But the current
recommendation is to use if-type 'other' and use a vendor-specific
leaf to identify the real type.  Why is this solution better than an
identity?

I would argue that identities solves this problem; a third-party
client can load all YANG modules available on the server, and present
a list of all identities derived from 'if:interface-type'.  This is
much better than the vendor-specific extra leaf and if-type 'other'.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Oct 2013 14:40:13 +0200

> to an arbitrary value from an unbounded list.

Because, as I keep writing, you can standardize identities as well.
 
> no idea what values will be used on a server implementation.

If the configuration data model is standardized, the data model will
also standardize the interface type. If the data model is not
standardized, the value of having a known interface type is very
small.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Oct 2013 14:45:02 +0200

+1

And we just have to do the long-postponed homework and write a spec for the new XPath functions. They are badly needed anyway.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Oct 2013 06:21:45 -0700

> Because, as I keep writing, you can standardize identities as well.

There is nothing to prevent every vendor from replacing the IANA values
with their own identities.  This is not possible with an enumeration.

> standardized, the value of having a known interface type is very

If IANA if-type is not useful then why bother using it at all?
Come up with a new enumeration, or give up and call it
a proprietary field.  Make if-type a plain string so vendors
have maximum flexibility.  Why bother encoding arbitrary strings
as arbitrary identities?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Oct 2013 16:00:51 +0200

> have maximum flexibility.  Why bother encoding arbitrary strings

As I keep saying, you can have standardized identities. I guess I will
stop repeating this now.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Oct 2013 07:22:06 -0700

> As I keep saying, you can have standardized identities. I guess I will
And I keep saying that there is a difference between the value
MUST be a standard value or not.  This makes a big difference
to client developers.

The "name" field is a proprietary string that can have embedded
semantics that the client needs to know in advance in order to
create an interface.

       A device MAY restrict the allowed values for this leaf,
       possibly depending on the type of the interface.

Whether the "type" field is a proprietary identityref or proprietary string
doesn't make much difference.  If the client does not know the
exact values to use apriori then it cannot create interfaces.

I do not understand why an additional leaf is not being considered:

   leaf extended-type {
      when "../type = 'other'";
      type identityref {
          base if-extended-types;
      }
   }

If the IANA type is sufficient then use it.
If it says 'other' then the server uses the extended if-type
instead.

BTW, why is the XPath problem such a big deal?
Our code fully supports identityrefs in XPath.
We also have a YANG extension that tags string types
as QNames, so the XPath parser knows what to do.
http://www.netconfcentral.org/modules/yuma-ncx/2013-05-25#qname.631

So how many vendors out there support the :xpath capability
but do not support identityrefs as QNames?  If this is not a real
problem then identityrefs should not be avoided.

(If you don't support XPath evaluation then you can hardwire
identityref handling along with everything else when supporting
must/when expressions.

/js
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Oct 2013 16:26:33 +0200

On Oct 15, 2013, at 3:21 PM, Andy Bierman <[email-masked]> wrote:

> 
> 
> 
> On Tue, Oct 15, 2013 at 5:40 AM, Juergen Schoenwaelder <[email-masked]> wrote:

Most likely, the registry entries like "ethernetCsmacd", "tunnel" or "other" will be heavily overloaded, hence not very interesting. If there is another vendor-controlled leaf, it will be the distinguishing parameter for augments etc. IMO it is much better if a vendor *derives* their own identity from a standardised identity such as "iana-if:ethernet".

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Oct 2013 07:37:03 -0700

On Tue, Oct 15, 2013 at 7:26 AM, Ladislav Lhotka <[email-masked]> wrote:

> Most likely, the registry entries like "ethernetCsmacd", "tunnel" or
> "other" will be heavily overloaded, hence not very interesting. If there is
> another vendor-controlled leaf, it will be the distinguishing parameter for
> augments etc. IMO it is much better if a vendor *derives* their own
> identity from a standardised identity such as "iana-if:ethernet".
>
>

I do not think this is a valuable feature.
Vendors manage their own registration roots already.
The undocumented embedded semantics in the "name" field
take care of ambiguities in the "type" field.

There is another problem with identities instead of enumerations.
If identities are used exclusively then the "value-stmt" data is lost in
standard YANG.
This is important for SNMP alignment because ifType is encoded
on the wire as an integer.   There is no way whatsoever to map
a YANG identity to an integer without using the description-stmt
or a new extension.

Lada
Andy

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Tue, 15 Oct 2013 14:43:32 +0000

>If it says 'other' then the server uses the extended if-type

The end-user usability of this is very poor.  If a user is creating a configuration entry for an interface type, they will want a singular configuration point ('type'). Making someone have to remember that when they are configuring an interface that is not somewhere in the nearly 300 entries in the iana-if-type enum that they have to use the value 'other' is an unreasonable expectation for a user of a product. If someone is configuring a LTE cellular interface, in their minds they are not configuring an interface of type 'other', they are configuring a LTE interface.

We MUST remember that not all users of systems that will implement this data model will be certified network professionals.  Any place where things can be simplified without losing functionality should be simplified.  And adding a second leaf just so we can keep the iana-iftype as is just doesn't make sense from a simplified usability standpoint.

<rant> Even something as standard as the "ethernetCsmacd" is horrible from a usability standpoint. Who refers to Ethernet devices as "Ethernet Csmacd"??? </rant>

-Jeff

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Oct 2013 16:45:40 +0200

On Oct 15, 2013, at 4:22 PM, Andy Bierman <[email-masked]> wrote:

> 
> 
> 
> On Tue, Oct 15, 2013 at 7:00 AM, Juergen Schoenwaelder <[email-masked]> wrote:

A client may just check that an interface type is derived from a supported standard type and be happy with it. 

>       when "../type = 'other'";

What if a new interface is a special version of Ethernet? 

> as QNames, so the XPath parser knows what to do.

This is all non-standard because RFC 6020 states:

YANG relies on XML Path Language (XPath) 1.0 [XPATH] …

and 

    o  The function library is the core function library defined in
      [XPATH], and a function "current()" that returns a node set with
      the initial context node.

> problem then identityrefs should not be avoided.

It is not only equality of identities that matters but also their partial ordering, otherwise identities don't make much sense.

Lada

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 15 Oct 2013 10:54:12 -0400

Channeling Jeff Case ...

Repetition is the key to learning.
Let me repeat that.
Repetition is the key to learning.

David Harrington
[email-masked]
+1-603-828-1401
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, October 15, 2013 10:01 AM
> To: Andy Bierman
> Cc: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Oct 2013 07:57:28 -0700

Hi,

...

> <rant> Even something as standard as the "ethernetCsmacd" is horrible from
> a usability standpoint. Who refers to Ethernet devices as "Ethernet
> Csmacd"??? </rant>
>
>
You are making my points for me:

#1) if vendors all pick their own favorite names for this enum then client
      apps will have to deal with several identities that mean the same
thing.

#2) You are confusing the GUI display string with the on-the-wire PDU value.
      They do not have to be the same. You can achieve #1 in your GUIs
      using the standard enum.
      (BTW, SNMP uses an integer on-the-wire. I wonder if SNMP developers
       will try to convert their code to work with identities.)

-Jeff

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Oct 2013 08:32:03 -0700

Hi,

> If this is done carelessly, we will end up with a mess over the years.
IMO (b) is a strawman since adding new XPath functions for YANG
and/or :xpath filtering would require a new YANG language version.

I will remove my objection and support (c).
Interface creation is already proprietary
because of the "name" leaf, so keeping this leaf
an an enum does not preserve interoperability anyway.

/js

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Oct 2013 08:51:22 -0700

> As I keep saying, you can have standardized identities. I guess I will
You can have standardized enumerations too.
The difference is that you cannot have non-standard
enumeration leaf values, but you can for identityref leafs.
That distinction does not seem to be important to the WG.

/js

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 15 Oct 2013 21:23:02 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> doesn't make much difference.

The idea is to have standardized identities as well (did someone say
this? ;)  We need to consider vendors that see a value in following the
standard.  If there is a standard type available that matches what
they need, they will use it.  Vendors that don't want to follow the
standard can invent whatever proprietary model they want.

> If the client does not know the

Agreed.  Same goes for 'other' + vendor-specific leaf.  Hmm, actually,
the situation is slightly better for identities, at least for
system-controlled interfaces, since the type of the interface is
available in the /interfaces-state/interface list.  A client that sees
a proprietary identity that is derived from a standard identity it
knows about knows more about the type than if it was a plain string.

> http://www.netconfcentral.org/modules/yuma-ncx/2013-05-25#qname.631

Again I agree.  You have this extension, and we do something similar.
The idea is to have a standard way of handling this instead of each
vendor inventing something own.  (Also, as Lada pointed out, both of
us formally violate the spec with these extensions).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Oct 2013 12:38:06 -0700

> standard can invent whatever proprietary model they want.
I agreed to bail on the enumeration.
The value field goes away so the coupling to SNMP
is removed.   Might aw well get rid of the values
that are not relevant and start a standard if-type tree
before vendors get too entrenched in proprietary solutions.

> knows about knows more about the type than if it was a plain string.

Inspecting the identity tree helps for reading the value
but not for knowing apriori what identities the server accepts for
interface creation for a given request.

> us formally violate the spec with these extensions).

This is needed to encode XML correctly in a retrieval reply,
not just for XPath.  If the string node content has an XML prefix then
there has to be an xmlns attribute to map it to a namespace
or the client will not be able to determine the extended name.

If we have to bump the YANG version number and create YANG2,
then a whole lot of little details and wish-list items should
be on the table.  I don't know if starting on YANG 2.0
would discourage people from using YANG 1.0, or if YANG 2.0
should be a high priority right now.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 15 Oct 2013 21:39:28 +0200 (CEST)

> I will remove my objection and support (c).

I support (c) as well.

Should we create identities for all types in the 'ifType defintions'
registry; i.e., simply keep the iana-if-type YANG module, but with 272
identities instead of 272 enums?  Or should we somehow try to use a
"cleaned up" registry?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Oct 2013 08:02:17 +0200

>> I will remove my objection and support (c).

Me too.

> identities instead of 272 enums?  Or should we somehow try to use a

I think the identity tree should be built incrementally. That is, each module will define identities for the interfaces it deals with. We also needn't harass IANA with it, it is sufficient that they register YANG modules.

I guess we should then do the same with address families, too. I2RS folks will be delighted.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 Oct 2013 11:08:58 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> I think the identity tree should be built incrementally. That is, each module
> will define identities for the interfaces it deals with. We also needn't harass
> IANA with it, it is sufficient that they register YANG modules.

The problem is that if we do this, there are no standard types from
the start.  This means that vendors will _have_ to use proprietary
identities, even if they don't want to.

Or we try to pick some "useful" types, but we'll probably get it
wrong...

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Oct 2013 11:31:14 +0200

> identities, even if they don't want to.

IMO, this is in fact no problem: if an identity is not standardized, it means that a standard data model for that interface type doesn't exist yet, so the vendor will have to define a proprietary data model anyway.

In my view, an identity is just a tag that enables certain objects to be conditionally included in the data model. And identity derivation potentially allows to do it not only for the exact interface type but also for all types derived from it.

Lada