Chassis based systems have line cards that support particular interface types. 
What happens to the output when a line card is plugged in or out of the system? 
In other words, is this a static or a dynamic list?

> On Apr 6, 2018, at 9:03 AM, Andy Bierman <> wrote:
> Hi,
> All of these suggested solutions seem OK if one were looking for the most 
> disruptive
> way to solve the problem.  Tossing iana-if-types and starting over would 
> achieve that result.
> First, this is a server capabilities problem, so it is related to the 
> implementation, not the schema.
> Second, the if-types that are allowed at any given moment can be specific to 
> the implementation
> and the interface name.
> I think this is the 3rd time I have suggested an RPC to solve the actual 
> probem:
>   rpc get-allowed-if-types {
>     description
>       "Retrieve the interface types allowed by the server.";
>     input {
>       leaf name {
>          type if:interface-ref;
>          description
>             "If present, the server will return allowed interface types for 
> this interface name only.
>              If not present, then the server will return all supported 
> interface types.";
>        }
>      }
>      output {
>          leaf-list type {
>             type identityref {
>                base interface-type;
>             }
>             description
>               "Specifies a supported interface type";
>         }
>     }
>  }
> Andy
> On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton < 
> <>> wrote:
> At the moment, I would say that the vast majority of the definitions in 
> IANA.yang are just noise because they refer to definitions that are obsolete. 
>  Our OS seems to use only 10% of the 287+ defined IANA types, and that 10% 
> includes technologies such as frame relay, serial, atm, that very much seem 
> to be on their way out.
> Using hierarchical identities and interface properties seems like a 
> reasonable solution to me (e.g. as described in 
> draft-wilton-netmod-interface-properties-00).  E.g. so rather than having 
> configuration with a direct when statement on a specific list of interface 
> types, instead the when statement can depend on the appropriate interface 
> properties.
> I also like Lada's suggestion of trying to spread out the IANA definitions to 
> the modules that are defining the technology.  So, if a device implements 
> support for PPP configuration/operational state then it would also naturally 
> define any PPP related interface identities at the same time.
> If a vendor wants to define their own flavour of Ethernet interface then they 
> can do so in their vendor specific module without requiring all tooling to 
> become aware of it, and allowing the existing Ethernet configuration to work 
> as normal.
> On 06/04/2018 13:01, Ladislav Lhotka wrote:
> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder < 
> <>> writes:
> If we would have a mechanism to deviate an identityref to a subset of
> identity values supported by an implementation, we would have solved a
> more generic problem. Yes, the IANA list could be 'nicer' but it will
> never be 'nice'.
> Three mechanisms can be used for this:
> - splitting the identities into separate modules
> Whatever module organization you come up with, it won't work for all
> implementations.
> Yes, getting the root of this structure right is perhaps somewhat tricky, but 
> I don't think that it needs to be all encompassing, or perfect.
> - using features
> Making every identity a feature will turn the feature system upside
> down. This is similar to making every leaf a feature.
> - using deviations (even though vendors frown on them)
> If my implementation only supports A and B and C, then a deviation may
> state exactly that and the problem is solved. Hoping that my specific
> In fact, deviations cannot delete identity values because they aren't schema
> nodes, so they are of no use.
> combination of A and B and C matches a set of modules or some set of
> features is in my view an illusion.
> An implementation that supports, say, a given type of tunnel interface will
> implement the module that covers this tunnel type. If the identity for this
> tunnel interface type is defined in the same module, then all is good. I don't
> get why this should be an illusion. On the contrary, I think it is the 
> cleanest
> available solution to this conformance specification problem.
> Vendors not shipping proper deviations are essentially telling their
> customers that they have not yet understood model driven management.
> We need to change the mindset here instead of polluting our data
> models with hundreds or thousands of fine grained 'features'.
> I agree that zillions of features aren't nice but it seems to be the only
> solution that we currently have for modules of the iana-if-type style.
> Having an bulky set of identity values, most of which are of no interest, is 
> much worse and could also be a security issue if implementors aren't careful
> enough.
> I'm not sure there is a security concern here, but a long list where most of 
> the values are cruft doesn't really seem to help anyone.  It also makes it 
> harder to know which is the right type to use.  E.g. will everyone know that 
> they should use "ethernetCsmacd" rather than "gigabitEthernet" for an optical 
> GE interface that doesn't actually use CSMA/CD ...
> Thanks,
> Rob
> Lada
> /js
> _______________________________________________
> netmod mailing list
> <>
> <>
> _______________________________________________
> netmod mailing list

Mahesh Jethanandani

netmod mailing list

Reply via email to