Hi Eric, I think it might fit better into NETCONF, actually. But as you point out, it could land in either and whichever way the chairs decide is fine with me.
--- Alex -----Original Message----- From: Eric Voit (evoit) [mailto:[email protected]] Sent: Wednesday, March 15, 2017 8:15 AM To: Ladislav Lhotka <[email protected]>; Juergen Schoenwaelder <[email protected]>; Alexander Clemm <[email protected]>; Andy Bierman ([email protected]) <[email protected]> Cc: [email protected] Subject: RE: [netmod] notifications2, new draft (was RE: notifications...and yang-next) Hi Lada, Juergen, Alex, Andy, In January your comments on "notifications" helped frame the context of draft-voit-netmod-yang-notifications2. See thread https://www.ietf.org/mail-archive/web/netmod/current/msg17434.html The is an open question between WG chairs on whether this question is more appropriate for NETMOD or NETCONF. I am ok if it lands in either, but I was wondering if you have opinions on its placement (or where it might be discussed in Chicago) as you commented previously. Eric > From: Eric Voit, February 24, 2017 12:23 PM > > 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
