On Thu, May 1, 2014 at 10:14 AM, Jeffrey Haas <[email protected]> wrote:
> On Thu, May 01, 2014 at 09:44:35AM -0700, Andy Bierman wrote: > > > If within the same module, there is the implication of a requirement > for > > > changes to the language to permit them to do so harmoniously. > > > > > > > > I prefer 1 module, but it is not that simple. The user-defined typedefs > and > > identities (for identityref data type) can be shared (e.g. imported from > > a common-types module). Even if the data nodes are separate, the > > definitions can share YANG semantics in various ways. > > > > > > New YANG statements (or extensions) to identify data affected by I2RS > > will allow the data models to be mixed in the same module, augment across > > modules, etc. > > Enumerating those changes would be helpful. > This has been done a few times. Most recently April 22: http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html > > > > If across different modules, there is the suggestion but not > requirement > > > that as Working Groups provide yang modules for managing their > components > > > that they are structured in such a way to permit I2RS re-use in our > > > modules. > > > > > > > > I think it would be most efficient if a WG considered complete management > > of a new protocol feature, and chartered configuration, I2RS, monitoring, > > and notification support at the same time. > > That was a likely outcome. Since other WGs aren't (to my knowledge) > heavily > focused on building their protocol management in yang yet, this suggests a > significant amount of coordination with the related WGs if we want to > define > I2RS functionality impacting them. In effect, they might get their yang > written for free. :-) > > This does, obviously, have charter impact. > > > The IETF approach for the last 2 decades has been to leave most > > of the management to the vendor CLI. The problem with this approach > > is that over-laying monitoring systems (vendor + standard) > > is easy, but not true for APIs that change the system. Once the vendor > API > > is in > > place, it is very difficult to overlay an incompatible standard API. > > Been there, done that and had it... "shape" my opinion of SNMP. > I'll leave it at that. > I don't see how standard I2RS data could use local config data unless it was also standardized. > > -- Jeff > Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
