Re: [Netconf] comments on draft-ietf-netconf-subscribed-notifications-12

> From: Martin Bjorklund, June 20, 2018 10:37 AM
> 
> Kent Watsen <kwatsen@juniper.net> wrote:
> >
> > > I had always seen as subscribed-notifications as a control plane
> improvement to RFC-5277.
> >
> > Let hope so  ;)
> >
> >
> >
> > > Explicitly excluding XSD, SYSLOG, vendor structures, etc. seems
> unnecessary.
> >
> > XSD is another DML, maybe you meant XML?
> >
> > SYSLOG is a protocol, I think you mean to say that folks might
> > encapsulate syslog messages inside a <notification> element.  This is
> > fine, I suggest defining a notification called something like
> > "syslog-message" that is essentially a leaf of type "string".
> >
> > Vendor structures are like Syslog, they can be even be binary if the
> > leaf is of type "binary".
> >
> > I'm not trying to exclude anything, what gets excluded?
> 
> I agree with Kent.  5277 was pre-YANG, so it could not be tied to the
> "notification" message.  Even 5277 could not transport any data - it had to be
> encoded in XML.  This new draft is more flexible since it can be used with XML
> and JSON (and other encodings) - *because* it transports YANG notifications.

Right now, draft-ietf-netconf-notification-messages is framed in a way which just supports YANG notifications (see "anydata notification-contents").   When people move to this new one-way notification, it would seem a natural time to impose the placement of a "must be in a YANG notification wrapper" constraint. (Assuming we would want to do this.)  

Placing such a constraint on the new one-way notification would then leave the subscribed-notifications control plane as supporting any existing/embedded 5277 one-way notifications. 

Eric

> /martin
> 
> 
> > > I can ping a few people who have legacy implementations which might
> > > be closer to this than I.   Narrowing the scope in this way should
> > > be broadly discussed.
> >
> > But is it narrowing the scope any? (see above)
> >
> >
> >
> > > > > It would be helpful to get some comments on draft-ietf-netconf-
> > > > > notification-messages.
> > > > > This draft address improvements to the opaque data blobs.
> > > >
> > > > Perhaps tease us with a little more detail?  ;)
> > >
> > > Pretty much all the common headers in Section 3 and the message
> > > bundling in Section 4 are both improvements which are relevant to
> > > this thread. Tianran likely will have some new headers he wants
> > > added as part of the multi-line card work.
> >
> > I don't see the relation to opaque data here. The "notification-contents"
> > description says "Encapsulates objects following YANG's
> > notification-stmt grammar of RFC-7950 section 14."  That doesn't sound
> > like it would be very opaque.
> >
> >
> > Kent
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >