Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.txt

[Ladislav Lhotka <[e-mail]>]

On Jun 17, 2013, at 4:41 PM, Andy Bierman <[e-mail]> wrote:

> Hi,
> 
> I think we should publish what we have, which is more aligned with
> existing implementations and SNMP.  The enhancements you
> describe could be added in the future with augments or a module update.
> An identity in addition to an IANA enum is OK.

The crucial thing is what will be used for restricting augments in future modules (be it in "when" statements or just in descriptions). The current document assumes and recommends the "type" leaf for this purpose, but I am arguing it can hardly work in reality.

The alignment with SNMP can be approached from the opposite end by introducing an extra leaf, say "iana-type", that could be a part of the "if-mib" feature.

Lada

> 
> 
> Andy
> 
> 
> On Mon, Jun 17, 2013 at 5:49 AM, Ladislav Lhotka <[e-mail]> wrote:
> Hi,
> 
> the discussion below doesn't seem to have reached any conclusion. But whatever the answer to Juergen's question might be, I think we should consider the "type" leaf again, because:
> 
> 1. The "type" leaf is useful in YANG for restricting some configuration parameters for use only with a certain interface type. The existing values in the "iana-if-type" enumeration, such as "ethernetCsmacd" or "tunnel", don't seem very effective in this respect. What we need is the type information that's often encoded in (platform-specific) interface names, for example TenGigabitEthernet0/1, gr-0/0/0 or ppp0.
> 
> 2. We actually need a *hierarchy* of interface types, whereas "iana-if-type" is flat. For instance, take the Ethernet example in Appendix A: The "when" condition
> 
>        when "if:type = 'ethernetCsmacd'";
> 
> causes the generic Ethernet parameters to apply only to this particular type, but not to any specialized Ethernet type, say "ieee-802.11bgn" (if this was ever registered by IANA).
> 
> 3. The set of permitted types should be easily extensible, without the need to go to IANA first.
> 
> In my opinion, YANG identity is a much better choice for the type of "type" because it satisfies all three requirements. No extra registry is needed for identities because they will be registered indirectly through the module where they are defined.
> 
> It is possible that a simple hierarchy of interface types won't be enough for representing the variety of real-world interfaces with all their properties and features. But then additional (type-specific) parameters could be introduced and used along with "type" for conditional augments.
> 
> Lada
> 
> Juergen Schoenwaelder <[e-mail]> writes:
> 
> > On Wed, May 29, 2013 at 05:53:19PM +0000, Lange, Jeffrey K (GE Energy Management) wrote:
> >> Martin asked that I provide my $0.02 on this draft as we've created
> >> an implementation against the -08 version. So here we go...
> >>
> >> In general I like having the interface-state separate from the
> >> interface configuration, it provides an easy way for a user to see
> >> what devices are currently in the system and are available for
> >> configuration.  In our -08 implementation we created a
> >> /interfaces/physical-interfaces table that would be pre-populated by
> >> the factory with the interfaces that are available for that
> >> particular product.  Note that our product is not customer
> >> expandable, so the interfaces that ship with the unit are the only
> >> ones that the customer can configure (ignoring logical interfaces).
> >> By having this config false list of interfaces we could achieve the
> >> same thing in a more standard way.
> >
> > This is _very_ welcome feedback. Implementation experience is always
> > very welcome - if others implement things as well, please consider to
> > share your experiences. This helps a lot.
> >
> >> We have many proprietary interface types (primarily different types
> >> of in-house radio interfaces) that do not fit into the categories
> >> defined by iana-if-type.  Sure you could use the argument "well then
> >> get them added via iana".  But that will never happen.
> >
> > I have to ask this so I do better understand. Why will this never
> > happen?
> >
> > - Is the procedure to register your interface type too complex?
> >
> > - Is the interface type kind of secret and hence you do not want to
> >   have it registered somewhere?
> >
> > - Is it that developers simply would not know how to register a new
> >   interface type and choose a random value anyway?
> >
> > - Something else?
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   [phone]         <http://www.jacobs-university.de/>
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

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