Alex, Tim, Andy, & I have posted at new draft at: https://tools.ietf.org/html/draft-voit-netmod-yang-notifications2-00
Explored here are notification capabilities beyond RFC-7950 section 7.16: * what are the set of transport agnostic header objects which might be useful within a YANG notification * how might a set of YANG notifications be bundled for bulk transport. * how do you query the originator of a notification to troubleshoot elements of this process. Any feedback would be appreciated. Thanks, Eric > From: netmod, January 25, 2017 8:53 PM > Subject: Re: [netmod] notifications...and yang-next > > > The NETCONF and NETMOD chairs are actively discussing how we might move > content around between drafts maintained by the two groups. Resolving this > notification statement issue is part of that. Here are some of my thoughts > about this: > > 1) I think that YANG is primarily used to define the notification's data > tree, the > payload, which may be wrapped by a protocol-specific envelop that includes, > for instance, a timestamp. This being the case, I'm hoping that there isn't > much > to do here. > > 2) Yes, RFC 7950 references RFC 5277, but note that it does so only in a > section > called "NETCONF XML Encoding Rules". It is my hope that we will move all > such sections out in the next revision RFC 7950 (see > https://github.com/netmod-wg/yang-next/issues/11) > > 3) Above and beyond the notification statement issue, Lada also notes that RFC > 7950 Section 3 references RFC 6241 for some terms. I believe that, in order > to > remove these normative references to 6241, these terms should be moved to > the revised-datastore draft (see https://github.com/netmod-wg/yang- > next/issues/12). > > Thoughts? > > > Kent // mostly as a contributor > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
