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

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:evoit@cisco.com] 
Sent: Wednesday, March 15, 2017 8:15 AM
To: Ladislav Lhotka <lhotka@nic.cz>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Alexander Clemm <alexander.clemm@huawei.com>; Andy Bierman (andy@yumaworks.com) <andy@yumaworks.com>
Cc: netmod@ietf.org
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
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod