[netmod] notifications2, new draft (was RE: notifications...and yang-next)

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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod