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 <rwil...@cisco.com> 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 <j.schoenwael...@jacobs-university.de> 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 IMO
>> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
