Subject: [Netconf] Stream definition and encoding (was: RE: Martin's thoughts on subscribed-notifications (was RE: two-week review of drafts related to notifications and subscriptions))

From: Alexander Clemm <[email-masked]>
Date: Fri, 13 Oct 2017 21:11:52 +0000

Martin, thank you for your thorough review comments, and Eric, thank you for your very thorough response! 

I have very little to add, just a few small additional comments items mostly regarding streams, inline, <ALEX>, with rest of the thread removed (for better legibility)
--- Alex

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit
> (evoit)
> Sent: Friday, October 13, 2017 12:15 PM
> To: Martin Bjorklund <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Subject: [Netconf] Martin's thoughts on subscribed-notifications (was RE:
> two-week review of drafts related to notifications and subscriptions)
...

> 
> > The relationship to RFC 5277 is not clear.  This document provides a
> > conflicting definition of streams.  Is this new definition supposed to
> > replace the old one, or are both supposed to co-exist?  The stream
> > mechanism in RFC 5277 works, is implemented in many systems, and is
> > used quite a lot in real operations.  I object to replacing it with
> > something new.  Specifically, the stream name should continue to be a
> > string, not an identity, in order to contine to support dynamically created
> streams.
> 
> The authors discussed this often.  We simply had not heard of 5277
> implementations where streams are dynamically created after system
> definition.  So we were waiting to see if someone actually used this capability
> before we wanted to include support, as it creates more validation
> complexity.
> 
> In other words, we are ok with moving to "string".   And the version available
> Monday will do this now that we know the capability is actually used.
> 

<ALEX> 
As Eric mentioned, we can move to string.  That said, I still believe there are good reasons to have it as an identity.
- It establishes a clear semantics as to what a stream means, as it is formally a part of the model.  If we use a string, we will need to have an additional conventions to define string names.  This means that we will need a new registry at IANA (to be maintained in addition to the YANG model), and rely on proper vendor documentation to define what proprietary string names mean.  In that sense it seems a little step backward also in  terms of interoperability.  
- Introducing dynamic streams is possible also under the identity-based model.  In that case, the stream type becomes "custom", and (if needed) you could add an additional designator specifying further what "custom" means.
</ALEX>

...

> >
> > o  Section 2.1
> >
> >   The document adds a stream called SYSLOG, which:
> >
> >    mirrors the
> >    discrete set entries which are concurrently being placed into a
> >    device's local Syslog
> >
> >   I don't understand what this means, and it is not clear how the
> >   syslog messages are to be transported in XML or JSON.
> >
> >   I suggest this stream is removed.
>

 <ALEX> Not sure why syslog messages would have to be transported in XML or JSON?  They could be transported in syslog protocol (RFC 5424).  
Having a syslog stream would be a very different stream than a stream of notifications defined in YANG data models.  We are not specifically designing for such streams, but I don't see why we should prohibit them.  In fact, subscribed-notifications could serve as a subscription model for syslog messages as well, possibly augmented with syslog-specific filter constructs. 

Netconf and RESTCONF were designed mainly for configuration/fulfillment related applications.  We should not be limited to these here.  As we are moving towards service assurance, other transports and encodings may be more suitable, which we should allow to capture using the same subscription control model.  UDP-based streaming telemetry is another such example.  
</ALEX>

...

> >
> >   This section contains some obvious and redundant text and examples,
> >   but misses to explain some important concepts.  First of all, the
> >   first paragraph doesn't really say anything and can be removed.
> 
> As an expert, you for sure know all this.   Others from the Network Element
> development domain learning some of this for the first time seem to find the
> intro text useful to help them understand.   If the WG wants this removed, I
> can do so as it makes the document smaller (which is good).  But we do lose
> something for newer readers.
> 
> >   Second, the example shows how to do an edit-config; this is not very
> >   interesting, so I think it should be removed as well.
> 
> Same comment as above.  We know this.  But newer people to this might
> find value.  Especially as it shows that even configured subscriptions
> ultimately use NETCONF RPCs.    That said I wouldn't lose sleep if it is
> dropped.
> 

<ALEX>
I agree it makes sense to keep this as context, specifically as users of this will include builders of service assurance related applications that may otherwise not have much focus on configuration; they just want to manage subscriptions.  
</ALEX>
...

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Oct 2017 14:56:55 +0200 (CEST)

> - Introducing dynamic streams is possible also under the identity-based model.  In that case, the stream type becomes "custom", and (if needed) you could add an additional designator specifying fur…

Since the identity is the key in the /streams/stream list, you cannot
augment a string to further specify what "custom" means.

>  <ALEX> Not sure why syslog messages would have to be transported in XML or JSON?  They could be transported in syslog protocol (RFC 5424).  

This is confusing.  I am talking about the "SYSLOG" stream, which is
can be subscribed to using NETCONF.  This is not the syslog protocol.

> Having a syslog stream would be a very different stream than a stream of notifications defined in YANG data models.  We are not specifically designing for such streams, but I don't see why we shoul…

Eric just wrote that the idea is that all messages transported on a
stream MUST be <notification> as defined in RFC 5277 for now, and when
the new notif-msg draft is done, MUST be a <notification> as defined
in that draft.

> Netconf and RESTCONF were designed mainly for configuration/fulfillment related applications.  We should not be limited to these here.  As we are moving towards service assurance, other transports…

Then you need to define this, i.e., at least define the extensibility
model, in this document.  The way it is currently written does not
handle this case.

> I agree it makes sense to keep this as context, specifically as users of this will include builders of service assurance related applications that may otherwise not have much focus on configuration…

I don't mind examples, but they should examplify the new concepts
introduce in the document.  In this particular case they just show how
an <edit-config> is done.  And BTW, the example is not valid according
to the data model.

If you want some special examples directed to a certain target
audience, maybe you can do so in an Appendix, or even better a
separate document?

/martin