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

["Eric Voit (evoit)" <[e-mail]>]

Hi Kent,

> From: Kent Watsen, June 19, 2018 10:28 PM
> 
> > 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 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)

Whew, I was getting worried!

Effectively you are saying "let's require that a YANG structure be inserted to define anything which might be included in the payload".  (I am assuming that yang-data would also be an acceptable structure as well as something from a YANG notification statement.)

As I don't have existing non-YANG streams, I will defer to others on whether they want to require such insertion.  

> > > > 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.

With common headers defined, elements which might be opaque within a <notification> might be exposable. (The publisher has the option of doing any needed mapping.) 

> 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.

I agree that the current definition of "notification-contents" is not opaque.  Basically (like you) I also like having YANG definitions of event records as they are self-describing.  However I do expect that others might have different opinions, and that we will need to address whether the new bundling mechanisms need to support non-YANG data.  So see this definition is a placeholder for the same discussion you are asking about above.

Eric

> Kent
>