Robert, I have read your draft and consider it useful for folks who are trying to use/configure/monitor particular characteristics of a physical interface. While it is an extension of the interfaces module, a lot of modules are extensions of the interface module. A more appropriate name would probably help convey the contents of the module. How about physical-interface-extensions or phys-intr-ext for short?
More comments on the draft. 3.2. Is there a counter kept for the actual short transition changes that were suppressed? 3.6 The general suggestion in YANG is to provide for one way to do things, and leave other ways of specifying or configuring to extensions/deviations etc. With that in mind, I would think keeping one leaf for MTU that is the max. size of the layer 2 frame including header and payload would make sense. 4. I am not a particular fan of creating yet another module for ethernet-like interfaces, when I assume there is going to be a ethernet-interface module. Is there something in this module that cannot be minimally represented by a more general IEEE ethernet-interface module? Thanks. > On Jul 8, 2015, at 9:11 AM, Robert Wilton <rwil...@cisco.com> wrote: > > Hi, > > I have submitted a new draft for provides several augmentations to the ietf > if:interfaces to define configuration YANG for basic interface parameters > that are commonly supported on network devices. E.g. it is includes leaves > such as bandwidth, carrier delay, dampening, loopback, mtu, & sub-interface > parent ref, and configurable interface MAC addresses. I am hoping that this > draft could be adopted and standardized by the netmod WG. > > https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-ext-yang/ > > Any comments or feedback is appreciated. > > Potential points of interest/discussion may be: > - Is it acceptable to define standard YANG for features that are not backed > by any formal standard if they are commonly implemented? > - We've tried to restrict the leaves to just the interface types (using when > if:type = ...) that the configuration applies to rather than adding them to > all interfaces. Feedback would be welcome on whether this approach is a good > idea/maintainable. > - For MTU, I've defined two different MTU leaves because devices program > interface MTU in different ways based on whether the configured MTU value > includes the L2 header overhead or not. Is this a reasonable approach? > > Thanks, > Rob > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
