On Mon, Apr 9, 2018 at 3:45 AM, Ladislav Lhotka <[email protected]> wrote:
> Andy Bierman <[email protected]> writes: > > > 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. > > I think nobody is suggesting to dump iana-if-types, just create an > alternative hierarchy of identities. So it's not disruptive at all. > > I guess we really disagree on the nature of the problem that needs to be solved. Since the "type" leaf and existing identities cannot be changed, then it seems you are suggesting an entire new set of identities. So servers will need to handle the old identities and the new ones. Not disruptive, but not helpful either. At the end of all of this work, the client will still be unable to answer the question "What identities are allowed for interface X on server Y, right now?" I don't see how rearranging the identities lets the client know what identities a server will accept to create or modify a particular interface. Andy > > > First, this is a server capabilities problem, so it is related to the > > implementation, not the schema. > > I disagree, it is also a data modelling problem. What's needed is to be > able to define parameters that are common to e.g. Ethernet interfaces in > one place and let them be inherited by all Ethernet-like interfaces. The > flat list of identities - even if the contents was much better than it > currently is - allows to do it only in a way that's clumsy and > non-scalable. > > > > > 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 { > > But this is an ad hoc solution that works only for this particular > registry. > > Lada > > > 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 <[email protected]> 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 <[email protected]> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
