Subject: Re: [Netconf] review of "event-notification" documents

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Dec 2016 11:07:28 +0100 (CET)

"Eric Voit (evoit)" <[email-masked]> wrote:
> Thanks Martin,
> 
> More in line.  Also I extracted areas where we already agree to make
> this easier to follow.
> 
> > From: Martin Bjorklund, November 29, 2016 6:40 AM
> > > >If I understand the intention correctly, this document is supposed to
> > > >*define* how notifications are sent over NETCONF.  But there is no
> > > >such definition in this document.  Instead it simply repeats
> > > >information already defined in draft-ietf-netconf-rfc5277bis-01.txt,
> > > >and provides lots of examples of how the YANG operations defined in
> > > >rfc5277bis are encoded in XML and sent over NETCONF.
> > > >
> > > >I suggest that this document is rewritten.  Since the idea is to
> > > >replace RFC 5277, it needs to focus on how notifications are sent
> > > >over NETCONF, and not how RPCs are encoded in XML.
> > > I agree -- maybe get rid of it and just have rfc5277bis contain this
> > > text
> > >
> > > <ev> 5277bis is supposed to allow transports other than NETCONF.  If
> > > we put
> > the NETCONF specific stuff in here we lose that separation.
> > 
> > We need *some* document that defines how notifications are sent over
> > NETCONF.  This document needs to have the specification for the
> > <notification>
> > element.
> > 
> > Then we need a protocol-independent document that defines the concept
> > of
> > streams and subscriptions, stream discovery, etc.
> > 
> > I *think* that your intention is that new clients really should be
> > using
> > <establish-subscription> instead of <create-subscription>, since it is
> > protocol-
> > independent and support modification and deletion.
> > 
> > If we also want to be fully backwards compatible with 5277, I think we
> > should
> > create a document that is much closer to the current 5277 -
> > essentially just
> > creating a YANG model for the config false data and for the "old"
> > <create-
> > subscription>.
> 
> We absolutely want to have a full backwards compatible capability.
> The question is how to best frame this in documents.  It is possible
> to rebuild RFC-5277 with a YANG model.  But then you can't just layer
> on new capabilities driving this work.

I think this in fact can be done.  I'll get back to this in a separate
email.

> (And this is why we need
> separate namespaces.)

I also don't think separate namespaces are necessary.

[...]

> > > >  You have made the stream name an identity.  In RFC 5277 it was a
> > > > string.  By using an identity, you severly limit how it can be used;
> > > > with a string new streams can be dynamically created at run-time,
> > > > but with an identity stream names must be known at design-time.
> > > >  I think the stream name should be changed back to a string.
> > >
> > > <ev> as the majority of the people in the informal design team were
> > > against
> > the expansion of streams, this is likely a moot point.
> > 
> > I don't know what "expansion of streams" means, and I don't understand
> > what
> > "this" refers to in "this is likely a moot point".
> > 
> > But if we keep the stream name as an identity we're no longer
> > backwards
> > compatible with RFC 5277, and we severly limit the functionality.  I
> > strongly
> > object to such a change. 
>  
> I am fine with string, especially as:
> (a) we are moving away from strings in favor of filters

I do not understand what this mean.  The string I am talking about is
the stream name.  I don't think a filter can replace that?

> (b) custom streams are likely to be the dominant use.
> Anyone have an objection  to this change?
> 
> > > >o  Section 4.1
> > > >
> > > >  The text says:
> > > >
> > > >   If the
> > > >   request is rejected because the publisher is not able to serve it,
> > > >   the publisher SHOULD include in the returned error what subscription
> > > >   parameters would have been accepted for the request when it was
> > > >   processed.
> > > >
> > > >  I think this is a pretty weird idea.  It seems extremely difficult
> > > > to implement, and the use case is not clear at all.  In an
> > > > automation deployment, do we expect that the client application code
> > > > contains logic to rewrite itself to send proper requests the next
> > > >  time?   If it is for debugging purposes I think this should be up to
> > > >  implementations to figure out.  We shouldn't add such things to
> > > > standard RPCs.
> > >
> > > <ev> there has been lots of discussion on this one.  The biggest issue
> > > has been
> > that there are enough variations of parameters where the guidance on
> > what
> > might be acceptable is the only way to make some scenarios work.  (Was
> > it the
> > period which was a problem?  Was it the complexity of the filter?)
> > Obviously
> > we do need to bound what could be provided back to the subscriber.
> > 
> > So then the text should encourage implementations to provide good
> > error
> > messages.
> 
> yes
> 
> > > The good news is that if a publisher cannot support negotiation, it
> > > can just
> > send back a failure.  Which is why the requirement is only a SHOULD.
> > 
> > SHOULD is too strong.  And even so, this just adds complexity to the
> > specification.  I think this should be removed.
> 
> RFC7923 has it as a MUST (see section 4.2.2.)  Going to SHOULD is
> already easing off the requirement.

Well, in the Informational RFC 7923, section 4.2.2 I find a SHOULD,
not a MUST:

   In cases where a subscription request cannot be fulfilled due to
   insufficient platform resources, the Subscription Service SHOULD
   include within its decline hints on criteria that would have been
   acceptable when the subscription request was made.

But this doesn't change my original concern - it adds complexity to
the spec, server implementations, and client implementations.  I can't
see how this would be implemented and utilized in real-world code.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Dec 2016 19:55:25 +0100 (CET)

[...]

> I think this in fact can be done.  I'll get back to this in a separate

Here's an example of how we can define a YANG module that is backwards
compatible in the sense that an old client can talk to a new server,
and new clients can use the new features when talking to new servers.

With this approach, we can build on the existing
<create-subscription>, and we don't have to add a new
<establish-subscription>.

We also don't have to change the current charter.

  module ietf-event-notification {
    namespace "urn:ietf:params:xml:ns:netconf:notification:1.0";
    prefix ev;
  
    rpc create-subscription {
      input {
        leaf stream {
          type string;
        }
        choice filter-type {
          case netconf-style {
            anyxml filter;
          }
          case andy-style { // see Andy's proposal to the list
            container filters {
              list filter { ... }
            }
          }
          case by-reference {
            leaf filter-ref { ... }
          }
        }
        leaf startTime { ... }
        leaf stopTime { ... }
        leaf return-subscription-id {
          type empty;
          description
            "New leaf that old RFC5277 clients will never send.
  
             A new client that wants to use the new delete/modify rpcs
             need to set this in order to learn the id.";
        }
      }
      output {
        leaf subscription-id {
          type uint32;
          description
            "Only present if the client passed 'return-subscription-id' in
             the rpc input params.";
        }
      }
    }
  
    rpc delete-subscription {
      input {
        leaf subscription-id {
          type uint32;
        }
      }
    }
  
    rpc modify-subscription {
      ...
    }
  }

In order to be fully backwards compatible, we also need to define a
YANG model with the streams:

  module ietf-netconf-notification-streams {
    namespace "urn:ietf:params:xml:ns:netmod:notification";
    prefix ncstreams;

    container netconf {
      config false;
      container streams {
        list stream { ... }
      }
    }
  }

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 5 Dec 2016 12:19:01 -0800

Hi,

I prefer the current solution approach, which is to use
'establish-subscription'.

There is no shortage of RPC names and no value in reusing
create-subscription.

Andy

On Mon, Dec 5, 2016 at 10:55 AM, Martin Bjorklund <[email-masked]> wrote:

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: MehmetErsue <[email-masked]>
Date: Mon, 05 Dec 2016 20:28:16 +0000

Technically spoken I think supporting backwards compatibility
in the sense that an old client can talk to a new server, and new clients
can use the new features when talking to new servers
is valuable.

Mehmet

-- 
Cheers,
Mehmet

---

From: Andy Bierman <[email-masked]>
Date: Mon, 5 Dec 2016 12:31:31 -0800

Hi,

There is nothing preventing a new server from keeping its code that
supports <create-subscription>.
IMO it is better if <create-subscription> continues to work exactly as
expected
so there is no chance an old client using RFC 5277 will break.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Dec 2016 21:37:20 +0100 (CET)

> 'establish-subscription'.

Can you elaborate on why you prefer two operations instead of one,
when they do the same thing?

> There is no shortage of RPC names and no value in reusing

I think it is confusing to have two so similar operations with
different names.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 5 Dec 2016 12:43:18 -0800

> when they do the same thing?

because they don't do the same thing.
The new solution has configured filters, subscription-id, suspend and
cancel operations
and should not need streams.

The old solution can be deprecated and replaced.
IMO this is much less confusing than trying to use create-subscription.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Dec 2016 21:48:31 +0100 (CET)

> The new solution has configured filters, subscription-id, suspend and

These are trivial extensions to the current solution.

If they are truly different the names should not be so similar.

> and should not need streams.

What do you mean "should not need streams"?

> The old solution can be deprecated and replaced.

Sure, if it is broken.  But I don't think it is broken in any way.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 5 Dec 2016 13:02:01 -0800

> What do you mean "should not need streams"?

The streams concept is half-baked and not useful.
We have 1 stream, NETCONF, which MUST contain everything and
MUST be encoded in XML.  Every other stream is purely ad-hoc and
proprietary, with no chance at interoperability.

> Sure, if it is broken.  But I don't think it is broken in any way.
The <nofitication> element is changing so old clients cannot
get the new version that contains a subscription-id and other fields.
IMO it is simpler and clearer if the new solution is separate.

/martin
Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 05 Dec 2016 22:34:43 +0100 (CET)

> The streams concept is half-baked and not useful.

I strongly disagree.  The stream concept including replay is very
powerful.

If you think it should be deprecated and replaced with something else,
I think that requires some careful discussion first.  (such as a
description of its problems, and a description of a new solution).

> We have 1 stream, NETCONF, which MUST contain everything

No it doesn't.  This was dicussed recently.  The text says:

   This stream contains all NETCONF XML event notifications supported by
   the NETCONF server.

Note it says "all NETCONF XML event notifications", not "all
[XML] event notifications".

> and
> MUST be encoded in XML.

Well, NETCONF is encoded in XML so this should not come as a
surprise... 

> Every other stream is purely ad-hoc and
> proprietary

Not really.  All streams supported can be discovered by any client
(with proper access rights).

> with no chance at interoperability.

This is a false statement.  We have defined several different streams
that third party clients use w/o any problems.  If a stream doesn't
interoperate b/c of its name, some implementation is buggy.

> get the new version that contains a subscription-id and other

I haven't seen any proposal for doing this on the ML.

> IMO it is simpler and clearer if the new solution is separate.

Maybe.  Anyway, my post was really in reply to Eric's statement that
these new features could not be built on top of what we have and still
be backwards compatible.

One way of making streams even more useful is to make them
configurable, e.g. instead of creating configurable filters, an idea
is to create a new stream together with a filter, and replay
definition.  Being able to do this dynamically would actually be quite
useful.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 5 Dec 2016 15:16:36 -0800

> Well, NETCONF is encoded in XML so this should not come as a

One reason the new solution is needed is to properly separate the
architectural layers,
so it is not so NETCONF-specific.

> (with proper access rights).

IMO a proper capability-driven framework is needed.
A standard way to discover proprietary extensions is not the same thing.

> I haven't seen any proposal for doing this on the ML.

It is in the drafts.
The new <notification> element is changed.
There will be a subscription-id field and maybe other fields added.
Parsers will not be able to tell them apart without some hacks.

> definition.  Being able to do this dynamically would actually be quite
I prefer to get rid of streams and just have filters.
I don't see the value in both kinds of filters.

The new solution tries to separate filtering, subscription management,
transport protocol, and message encoding.  IMO this is a much better
architecture
than the 'everything-is-hard-wired' approach in RFC 5277.

It's not that 5277 is broken. It's just not a modern solution approach.
A black & white TV doesn't need to be broken to get replaced by a color TV.

I do not know if it is really important to allow YANG push and other
new applications to work with 5277 subscriptions.  They is a valid concern
that the WG should decide.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 5 Dec 2016 19:51:35 -0800

> I haven't seen any proposal for doing this on the ML.

I was wrong -- the 5277bis-01 draft and yang-push-04 draft both reuse the
notification element, instead of making a new notification element.
Every single notification-stmt has to define a subscription-id leaf (yuch!).
Every notification, like replay-complete, is redefined with a
subscription-id leaf
added to it. This really breaks the layering separation I thought was there.

Perhaps the WG needs to agree on the 5277 reuse requirements
before diving working on solution details.

Andy

---

From: <[email-masked]>
Date: Mon, 5 Dec 2016 22:33:09 -0800

Hi, 

I have a couple of comments:

-          I prefer a clear separation between <create-subscription> and <establish-subscription>.  The differences seem clear enough.  It is not just parameters.  It is also that <delete-subscription> and <modify-subscription> are counterparts to <establish-subscription> (but not create-subscription>.  Trying to extend <create-subscription> introduces a lot of context dependencies.  Also, there is still the namespace problem that extensions and “original” RPC have to be in different namespaces (and are thus clearly distinguished) anyway.  I find <establish-subscription> cleaner that way.  

-          The YANG-push draft makes use of the notification statement.  Why wouldn’t it?  This is part of the YANG language.  As far as RFC 5277bis and general event subscriptions are concerned, I do not think that there is any implication that any notification needs to be redefined with a subscription ID for it.  Why?  YANG-Push is a special case in that notification contents can be highly customized per the terms of the subscription, so including the subscription ID seems reasonably, but in general you would not have to do that.  

-          I do think the stream metaphor is useful.  However, I think we really need to distinguish two concepts:  The stream (that is being subscribed to), and the stream (of messages actually delivered to the client, with filtering, subscription policies etc all applied).  

-          The proposed set of “filters” (a term I find confusing in that context IMHO, in particular as there is a secondary set of filters of the subscription itself that would still be applied on top) and existing concept of stream types appear fairly equivalent.  Both are used to simply refer to a sequence of messages/updates being sent by the server, including content per a set of criteria (preestablished for ease of use, but potentially also configurable).   

Thanks

--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Monday, December 5, 2016 7:52 PM
To: Martin Bjorklund <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] review of "event-notification" documents

On Mon, Dec 5, 2016 at 1:34 PM, Martin Bjorklund <[email-masked] <mailto:[email-masked]> > wrote:

Andy Bierman <[email-masked] <mailto:[email-masked]> > wrote:
> On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund <[email-masked] <mailto:[email-masked]> > wrote:
>
> > Andy Bierman <[email-masked] <mailto:[email-masked]> > wrote:
> > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund <[email-masked] <mailto:[email-masked]> >
> > wrote:
> > >
> > > > Andy Bierman <[email-masked] <mailto:[email-masked]> > wrote:
> > > > > Hi,
> > > > >

 

Every notification, like replay-complete, is redefined with a subscription-id leaf

 

 

Andy

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Dec 2016 11:23:09 +0100 (CET)

> before diving working on solution details.

+1

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 6 Dec 2016 14:11:19 +0000

> From: Martin Bjorklund December 6, 2016 5:23 AM
> 
> > Perhaps the WG needs to agree on the 5277 reuse requirements before
> > diving working on solution details.
> 
> +1

Yes.   We have been assuming reuse until now.  This is what is in the WG charter.  And this is what we have been building to in the current draft set.

There are no plans to change this direction unless the WG selects 'obsolete' over 'enhance'.   There are benefits to each.  Below is my summary for benefits of each path.  Please add any that I might have missed...

Benefits of 'enhance'
----------------------------
- Backwards compatibility through single integrated spec
- Single codebase handles all subscription requests if legacy and new will be running concurrently

Benefits of 'obsolete'
----------------------------
- Simpler, smaller specification
- Backwards compatibility through parallel implementation and capabilities exchange
- Subscriptions decoupled from NETCONF namespace
- Fewer error conditions (e.g., what if you get two <create-subscription> from what you thought was a legacy client.)

Worthy of discussion
----------------------------
- Interplay of streams and filters.  Will/must obsolete vs enhance impact this decision?
- How many RPCs, and how complex should they be?  What are the impacts of overloading.

Eric

---

From: Andy Bierman <[email-masked]>
Date: Tue, 6 Dec 2016 06:31:35 -0800

Hi,

The new solution design is completely broken unless a new notification
wrapper is used
or the subscription-id is removed from the design.  There is no way this
field can be defined
as part of the event payload.  Every notification has to define a field
name 'subscription-id'?
The identifier 'subscription-id' becomes reserved so it cannot be used
anywhere

  list foo {
     key subscription-id;
     leaf subscription-id { type string; }
     notification bar;
  }

How would a YANG 1.1 nested notification be supported?
How would any existing notification-stmt that does not define this leaf be
supported?
How will multiple subscriptions be sent over the same connection?

If 5277 support is so important then make it work by eliminating everything
related to subscription IDs from the solution.  IMO it would be better to
design a new solution that is properly layered.

Andy

On Tue, Dec 6, 2016 at 6:11 AM, Eric Voit (evoit) <[email-masked]> wrote:

> Yes.   We have been assuming reuse until now.  This is what is in the WG
> charter.  And this is what we have been building to in the current draft
> set.
>
> There are no plans to change this direction unless the WG selects
> 'obsolete' over 'enhance'.   There are benefits to each.  Below is my
> summary for benefits of each path.  Please add any that I might have
> missed...
>
>
> Benefits of 'enhance'
> - Fewer error conditions (e.g., what if you get two <create-subscription>
> from what you thought was a legacy client.)
>
> Worthy of discussion

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Dec 2016 16:29:12 +0100 (CET)

> The new solution design is completely broken unless a new notification

I agree.  The current XSD in 5277 is very inflexible; it would be
useful with a structure that allows some flexibility, specifically
allows new "header" fields to be added w/o having to modify the
protocol.   I.e., allow elements from other namespaces after the
built-in elements (event-time, subscription-id).

If we want to do this protocol-agnostic, we should define XML and JSON
encoding of notifications in one document; the general concepts of
streams and filters etc in one docuement; protocol-specific mechanisms
to retrieve data from streams in another (unfortunately, we can't
define protocol-agnostic rpc operations for this, since these
operations only work for session-based protocols)

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 6 Dec 2016 15:30:01 +0000

Hi Andy,

The way we were approaching it was to have the 5277 notification element be used when <create-subscription> RPC started the subscription, and a notification element which includes “subscription-id” be used with the <establish-subscription> RPC.  We never expected the two mixed on the same transport.   This second way is what was used in the implementations with OpenDaylight.

Having two different notification type result from the same <create-subscription> RPC is something we should try to avoid.  It is what I was trying to capture below with the bullets ‘fewer error conditions’ and RPC overloading.

The current 5277bis Section 6 examples do not currently show the subscription-id breakdown for notifications.  This was an oversight of we authors.  I only recognized this a few weeks ago (see agenda for last WebEx).  I agree the ultimate solution must properly parse out subscription-id.

Also on your notes below I would love to better understand the nested notification item, because that is something I haven’t thought about.

Ultimately, I believe these notification complexities provide another example why ‘obsolete’ is simpler than ‘enhance’.

Eric

From: Andy Bierman, December 6, 2016 9:32 AM

Hi,

The new solution design is completely broken unless a new notification wrapper is used
or the subscription-id is removed from the design.  There is no way this field can be defined
as part of the event payload.  Every notification has to define a field name 'subscription-id'?
The identifier 'subscription-id' becomes reserved so it cannot be used anywhere

  list foo {
     key subscription-id;

How would a YANG 1.1 nested notification be supported?
How would any existing notification-stmt that does not define this leaf be supported?
How will multiple subscriptions be sent over the same connection?

Andy

On Tue, Dec 6, 2016 at 6:11 AM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
> Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

Benefits of 'enhance'

Benefits of 'obsolete'

Worthy of discussion

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Dec 2016 16:52:39 +0100

> There are no plans to change this direction unless the WG selects 'obsolete' over 'enhance'.   There are benefits to each.  Below is my summary for benefits of each path.  Please add any that I mig…

I do not have a strong opinion on this but I think it is worth
commenting on some of your benefits - and to perhaps provide an
opinion of someone who is just observing things.
 
> Benefits of 'enhance'

Backwards compatibility is a property of a design, it does not matter
how many specs are used to write the design down.

> - Single codebase handles all subscription requests if legacy and new will be running concurrently

This is a pure implementation issue. A single codebase can be used
to support N subscription interfaces equally well.

> Benefits of 'obsolete'

Again, backwards compatibility is a property of a design. Apparently,
it can't be used as an argument to both 'enhance' and 'obsolete'.

> - Fewer error conditions (e.g., what if you get two <create-subscription> from what you thought was a legacy client.)

So these seem to be some arguments here (not sure how strong they are).

> Worthy of discussion

It seems to me that RFC 5277 is pretty much tied to NETCONF/SSH and
that having a much more flexible subscription mechanism as suggested
goes pretty far beyond what RFC 5277 did, both in functionality but
also in trying to support different protocols carrying notifications.
Given that the changes relative to RFC 5277 are significant, it makes
sense to me to view the proposal as a new event subscription interface
and not as an extension of RFC 5277.

Concerning RFC 5277, it may be desirable to make a minor update (e.g.,
to get rid of the XSD and to use YANG) but whether this is worth the
effort I do not know. Perhaps RFC 5277 is good enough to let it rest
in peace.

/js

PS: Note that I have not implemented any of this, hence my opinion
    should likely not count too much.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 6 Dec 2016 08:14:14 -0800

On Tue, Dec 6, 2016 at 7:52 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > - Fewer error conditions (e.g., what if you get two
> <create-subscription> from what you thought was a legacy client.)
>

Actually this is another area that the new solution is really broken.
The RPCs ignore <rpc-error> and instead invent their own error system
using identities.  This does not scale well because it requires clients  to
write special error handling code for each RPC, instead of 1 system that
handles all <rpc-error> messages.

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 6 Dec 2016 18:07:37 +0000

> From: Juergen Schoenwaelder, December 6, 2016 10:53 AM
> 
> charter.  And this is what we have been building to in the current draft set.
> >
> > There are no plans to change this direction unless the WG selects 'obsolete'
> over 'enhance'.   There are benefits to each.  Below is my summary for benefits
> of each path.  Please add any that I might have missed...
> >
> 
> I do not have a strong opinion on this but I think it is worth commenting on
> some of your benefits - and to perhaps provide an opinion of someone who is
> just observing things.
> 
> > Benefits of 'enhance'
> Backwards compatibility is a property of a design, it does not matter how many
> specs are used to write the design down.
> 
> This is a pure implementation issue. A single codebase can be used to support N
> subscription interfaces equally well.

Agree on your two points above.  Note that I am simply doing my best to reflect arguments in favor of 'enhance'.  I don't actually believe that 'enhance' is the right path. 

> Again, backwards compatibility is a property of a design. Apparently, it can't be
> used as an argument to both 'enhance' and 'obsolete'.
> 
> It seems to me that RFC 5277 is pretty much tied to NETCONF/SSH and that
> having a much more flexible subscription mechanism as suggested goes pretty
> far beyond what RFC 5277 did, both in functionality but also in trying to
> support different protocols carrying notifications.
> Given that the changes relative to RFC 5277 are significant, it makes sense to
> me to view the proposal as a new event subscription interface and not as an
> extension of RFC 5277.
> 
> Concerning RFC 5277, it may be desirable to make a minor update (e.g., to get
> rid of the XSD and to use YANG) but whether this is worth the effort I do not
> know. Perhaps RFC 5277 is good enough to let it rest in peace.

Rest-in-peace was the conclusion of a number of us in the Dezign team.   I am not sure if there is anyone actively advocating for 'enhance'.  Martin has made some reasonable proposals on how elements might be approached should the WG want to continue down this path.

Eric

---

From: Andy Bierman <[email-masked]>
Date: Tue, 6 Dec 2016 10:27:43 -0800

> built-in elements (event-time, subscription-id).

This inflexibility has been a problem.
I think a new element in a different namespace would be better.
Clients that use the new header MUST accept and ignore unknown header
fields.

(Examples have namespaces omitted)

 <notification>
    <hdr>
       <subscription-id>1</subscription-id>
       <sequence-id>4242</sequence-id>
       // ... maybe more fields here
   </hdr>
   <foo-event>
      // normal notification contents
   </foo-event>
 </notification>

or YANG 1.1 nested:

 <notification>
    <hdr>
       <subscription-id>1</subscription-id>
       <sequence-id>4242</sequence-id>
       // ... maybe more fields here
   </hdr>
   <interfaces>
      <interface>
         <name>eth0</name>
         <foo-event>
             // normal notification contents
         </foo-event>
      </interface>
    </interfaces>
 </notification>

> operations only work for session-based protocols)
It would be better if the <notification> element could be modeled in YANG
so it can be augmented and also it would be encoding-independent.
(e.g. YANG to CBOR could be used)

Andy

> > > - Single codebase handles all subscription requests if legacy and new
> will
> > > be running concurrently
> > >
> > > Benefits of 'obsolete'
> > > - Backwards compatibility through parallel implementation and
> capabilities
> > > exchange
> <create-subscription>
> > > - Interplay of streams and filters.  Will/must obsolete vs enhance
> impact
> > > this decision?
> > > - How many RPCs, and how complex should they be?  What are the impacts
> of
> > > overloading.
> > >
> > >
> > > Eric
> > >
> > >
> > > >
> > > > /martin
> > >
>

---

From: <[email-masked]>
Date: Tue, 6 Dec 2016 10:55:53 -0800

Hi all,

There is no subscription ID in the notification element.  I don’t think this is a bug.  It is by design choice, but of course we can question if this is the right choice and if it should be changed.  

In the current design, the subscription ID is used to refer to a subscription, but it does not need to be included with every notification.  In other words, when you subscribe to messages, and receive messages, it is transparent which specific subscription the message is related to.  That  is, unless we choose to – like we did in YANG-Push.  

It is possible to devise a transport mapping in which subscription IDs are added to individual messages.  However, then there are more corner cases – such as what to do when there are multiple subscriptions with separate filters, and one message is covered by both.  In that case, would the same message be transmitted redundantly?  Would it be transmitted once, but with multiple subscription IDs in the message?   Would it be a single subscription ID of the subscription with highest priority – which is applied first “as a filter”?  None of these sound appealing to me, but if we want to include subscription IDs with every message, then we have to get a solution for this.  

This is one of the areas where I think we need to have a discussion on requirements before we finalize on a solution.  

--- Alex

From: Eric Voit (evoit) [mailto:[email-masked]] 
Sent: Tuesday, December 6, 2016 7:30 AM
To: Andy Bierman <[email-masked]>; [email-masked]; Alberto Gonzalez Prieto (albertgo) <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>; [email-masked]
Subject: RE: [Netconf] review of "event-notification" documents

Hi Andy,

Eric 

Hi,

  list foo {

     key subscription-id;

     notification bar;

  }

 

Andy

 

Benefits of 'enhance'

Benefits of 'obsolete'

Worthy of discussion

Eric

---

From: Andy Bierman <[email-masked]>
Date: Tue, 6 Dec 2016 11:10:38 -0800

On Tue, Dec 6, 2016 at 10:55 AM, <[email-masked]> wrote:

> Hi all,
>
>
>
> There is no subscription ID in the notification element.  I don’t think
> this is a bug.  It is by design choice, but of course we can question if
> this is the right choice and if it should be changed.
>
>
>

I think ity is a bug that there are subscription-id leafs in the
application notifications,
such as YANG Push.

Only properties of the event should be modeled in the notification-stmt.
The properties of the notification delivery system should not be modeled in
events.

The current 5277 solution is simple -- 1 subscription per session so no
need for subscription-id.
The server will send the same notification to every client using 5277.
This is not a problem.

I am not sure if multiple subscriptions per session and multiple receivers
per subscription
are really important or not. They add lots of complex new problems to solve.

Andy

In the current design, the subscription ID is used to refer to a
> subscription, but it does not need to be included with every notification.
> In other words, when you subscribe to messages, and receive messages, it is
> transparent which specific subscription the message is related to.  That
> is, unless we choose to – like we did in YANG-Push.
>
>
>
> It is possible to devise a transport mapping in which subscription IDs are
> added to individual messages.  However, then there are more corner cases –
> such as what to do when there are multiple subscriptions with separate
> filters, and one message is covered by both.  In that case, would the same
> message be transmitted redundantly?  Would it be transmitted once, but with
> multiple subscription IDs in the message?   Would it be a single
> subscription ID of the subscription with highest priority – which is
> applied first “as a filter”?  None of these sound appealing to me, but if
> we want to include subscription IDs with every message, then we have to get
> a solution for this.
>
>
>
> This is one of the areas where I think we need to have a discussion on
> requirements before we finalize on a solution.
>
> --- Alex
>
>
>
> *From:* Eric Voit (evoit) [mailto:[email-masked]]
> *Sent:* Tuesday, December 6, 2016 7:30 AM
> *To:* Andy Bierman <[email-masked]>; [email-masked]; Alberto Gonzalez
> Prieto (albertgo) <[email-masked]>
> *Cc:* Martin Bjorklund <[email-masked]>; [email-masked]
> *Subject:* RE: [Netconf] review of "event-notification" documents
>
>
>
> Hi Andy,
>
>
>
> The way we were approaching it was to have the 5277 notification element
> be used when <create-subscription> RPC started the subscription, and a
> notification element which includes “subscription-id” be used with the
> <establish-subscription> RPC.  We never expected the two mixed on the same
> transport.   This second way is what was used in the implementations with
> OpenDaylight.
>
>
>
> Having two different notification type result from the same
> <create-subscription> RPC is something we should try to avoid.  It is what
> I was trying to capture below with the bullets ‘fewer error conditions’ and
> RPC overloading.
>
>
>
> The current 5277bis Section 6 examples do not currently show the
> subscription-id breakdown for notifications.  This was an oversight of we
> authors.  I only recognized this a few weeks ago (see agenda for last
> WebEx).  I agree the ultimate solution must properly parse out
> subscription-id.
>
>
>
> Also on your notes below I would love to better understand the nested
> notification item, because that is something I haven’t thought about.
>
>
>
> Ultimately, I believe these notification complexities provide another
> example why ‘obsolete’ is simpler than ‘enhance’.
>
>
>
> Eric
>
>
>
> *From:* Andy Bierman, December 6, 2016 9:32 AM
>
> Hi,
>
>
>

---

From: <[email-masked]>
Date: Tue, 6 Dec 2016 11:22:40 -0800

Well, having a subscription ID in messages will facilitate handling of different message streams, each tied to a specific subscription.  I can see how this would be useful, but it does mean a change of an underlying assumption in our design.  In that case, the subscription ID would indeed need to be included in the way we map messages.  I do think this would also imply that if one client subscribes to the same notification multiple times (respectively, a notification passes the filter criteria of multiple subscriptions), the notification needs effectively to be replicated across message streams.  (A simple way to avoid that in an implementation would be to limit a server to support only a single subscription per receiver.) 

As mentioned earlier, another thing we need to fix is the stream terminology.  We need to have a different term for what it is that a client subscribes to (to which it may apply filters, encoding choices, etc) , and for what the server sends to the client as part of a subscription.  One is the “source” (or “well”?), the other the “stream”.  

--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Tuesday, December 6, 2016 11:11 AM
To: Alexander Clemm <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] review of "event-notification" documents

On Tue, Dec 6, 2016 at 10:55 AM, <[email-masked] <mailto:[email-masked]> > wrote:

Hi all,

 

I think ity is a bug that there are subscription-id leafs in the application notifications,

such as YANG Push.

The properties of the notification delivery system should not be modeled in events.

The current 5277 solution is simple -- 1 subscription per session so no need for subscription-id.

The server will send the same notification to every client using 5277.  This is not a problem.

I am not sure if multiple subscriptions per session and multiple receivers per subscription

 

Andy

 

--- Alex

From: Eric Voit (evoit) [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, December 6, 2016 7:30 AM
To: Andy Bierman <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Alberto Gonzalez Prieto (albertgo) <[email-masked] <mailto:[email-masked]> >
Cc: Martin Bjorklund <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Netconf] review of "event-notification" documents

Hi Andy,

Eric 

Hi,

  list foo {

     key subscription-id;

     notification bar;

  }

 

Andy

 

Benefits of 'enhance'

Benefits of 'obsolete'

Worthy of discussion

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Dec 2016 20:42:44 +0100 (CET)

<[email-masked]> wrote:
> Well, having a subscription ID in messages will facilitate handling of
> different message streams, each tied to a specific subscription.  I
> can see how this would be useful, but it does mean a change of an
> underlying assumption in our design.  In that case, the subscription
> ID would indeed need to be included in the way we map messages.  I do
> think this would also imply that if one client subscribes to the same
> notification multiple times (respectively, a notification passes the
> filter criteria of multiple subscriptions), the notification needs
> effectively to be replicated across message streams.  (A simple way to
> avoid that in an implementation would be to limit a server to support
> only a single subscription per receiver.)

I think it's fine if a client receives the same notification twice if
it has two subscriptions and a notification is generated that matches
both subscriptions.

> As mentioned earlier, another thing we need to fix is the stream
> terminology.  We need to have a different term for what it is that a
> client subscribes to (to which it may apply filters, encoding choices,
> etc) , and for what the server sends to the client as part of a
> subscription.  One is the “source” (or “well”?), the other the
> “stream”.

Can you elaborate a bit?  Are you talking about some new concept that
is not the same as 5277 "stream"?

/martin

---

From: <[email-masked]>
Date: Tue, 6 Dec 2016 12:04:32 -0800

Hi Martin,

Re item 1, agreed.  I think this is the model to go with if we want to be able to associate messages with subscriptions. 

Re item 2, no new concepts, but updates to the terminology of existing concepts.  Currently, the term "stream" is used to refer to the notifications that a client subscribes to.  The stream is still subject to filtering etc, so this is not the same as the sequence of messages that the client actually receives. We do not have a term for that.  It is easy to see the term "stream" getting overloaded, but arguable the two concepts need to be clearly distinguished.  

--- Alex 

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, December 6, 2016 11:43 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Netconf] review of "event-notification" documents

> only a single subscription per receiver.)

I think it's fine if a client receives the same notification twice if it has two subscriptions and a notification is generated that matches both subscriptions.

> subscription.  One is the “source” (or “well”?), the other the 

Can you elaborate a bit?  Are you talking about some new concept that is not the same as 5277 "stream"?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Dec 2016 21:32:41 +0100 (CET)

<[email-masked]> wrote:
> Hi Martin,
> 
> Re item 1, agreed.  I think this is the model to go with if we want to
> be able to associate messages with subscriptions.

Ok.

> Re item 2, no new concepts, but updates to the terminology of existing
> concepts.  Currently, the term "stream" is used to refer to the
> notifications that a client subscribes to.

When you say "currently" I assume you mean your drafts?

I think the term is well-defined in RFC 5277 ("event stream" or
"stream"), and I think we should stick to that definition.

/martin

> The stream is still
> subject to filtering etc, so this is not the same as the sequence of
> messages that the client actually receives. We do not have a term for
> that.  It is easy to see the term "stream" getting overloaded, but
> arguable the two concepts need to be clearly distinguished.
> 
> --- Alex 
>

---

From: <[email-masked]>
Date: Tue, 6 Dec 2016 14:19:12 -0800

Yes.  I do think we need to revisit the definitions.  I don't think the definition of RFC 5277 is sufficient for our purposes.  At least  it does not seem to cover all the concepts that we need to cover.  

The definition in RFC 5277 states:    

Stream:  An event stream is a set of event notifications matching
      some forwarding criteria and available to NETCONF clients for
      subscription. 

What are the forwarding criteria and when are they applied - a subscription can specify its own filters - what would we call the filtered stream that results?  We do need to distinguish the "raw" stream that is being subscribed to, from the stream of messages that are actually delivered to  a receiver as part of a subscription. 

--- Alex

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, December 6, 2016 12:33 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Netconf] review of "event-notification" documents

Ok.

I think the term is well-defined in RFC 5277 ("event stream" or "stream"), and I think we should stick to that definition.

/martin

> > Well, having a subscription ID in messages will facilitate handling 
> > of different message streams, each tied to a specific subscription.  
> > I can see how this would be useful, but it does mean a change of an 
> > ID would indeed need to be included in the way we map messages.  I 
> > do think this would also imply that if one client subscribes to the 
> > same notification multiple times (respectively, a notification 
> > passes the filter criteria of multiple subscriptions), the 
> > notification needs effectively to be replicated across message 
> > streams.  (A simple way to avoid that in an implementation would be 
> > to limit a server to support only a single subscription per 
> > receiver.)
>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Dec 2016 23:37:23 +0100 (CET)

<[email-masked]> wrote:
> Yes.  I do think we need to revisit the definitions.  I don't think
> the definition of RFC 5277 is sufficient for our purposes.  At least
> it does not seem to cover all the concepts that we need to cover.
> 
> What are the forwarding criteria and when are they applied - a
> subscription can specify its own filters - what would we call the
> filtered stream that results?  We do need to distinguish the "raw"
> stream that is being subscribed to,

This is the "event stream".

> from the stream of messages that
> are actually delivered to a receiver as part of a subscription.

Is a term needed for this?  "delivered notifications" maybe?

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 7 Dec 2016 00:52:54 +0000

> From: Andy Bierman, December 6, 2016 1:28 PM
> 
> 
> On Tue, Dec 6, 2016 at 7:29 AM, Martin Bjorklund <mailto:[email-masked]>
> wrote:
> Andy Bierman <mailto:[email-masked]> wrote:
> > Hi,
> >

I see use cases where a controller acts as an aggregator/facilitator for Application subscriptions.   In this case, it is goodness if each subscription can be easily directed to the originating application after transiting through a controller.  Having a subscription ID within the base notification is useful.  Worrying about duplicate object updates across subscription IDs is a future problem which can be fully handled within the domain of the controller. 

In looking at your expandable header below I see usefulness in separating out the header.  This would be a great place to put the current and previous update number as a way to ascertain any update loss.  It could also be extended by transports.

>              // normal notification contents

For YANG 1.1 nested, is there difference between some 5277bis notification for the <foo-event>, and a YANG Datastore update for <foo-event> being encapsulated by anyxml?  Do you see a reason why we wouldn't do the above with on-change YANG Push?

> operations only work for session-based protocols)

I certainly see filters/streams evolving quite a bit over time.  Having a place for new variants of this (including support for OpState) will be coming.

> (e.g. YANG to CBOR could be used)

Makes sense.

Eric

> > On Tue, Dec 6, 2016 at 6:11 AM, Eric Voit (evoit) <mailto:[email-masked]>
> wrote:
> >
> > > > Andy Bierman <mailto:[email-masked]> wrote:

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 07 Dec 2016 09:13:09 +0100 (CET)

> > to get
> Rest-in-peace was the conclusion of a number of us in the Dezign team.

My original point was that the current set of drafts are very
incomplete when it comes to RFC 5277.  They claim they obsolete it,
but they also refer to definitons in it, and they don't talk at all
about how to send notifications over NETCONF.

Keep it as it is (not obsolete) is certainly one option.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 7 Dec 2016 14:33:00 +0000

> From: Martin Bjorklund, December 7, 2016 3:13 AM
> 
> > > Concerning RFC 5277, it may be desirable to make a minor update
> > > (e.g., to get rid of the XSD and to use YANG) but whether this is
> > > worth the effort I do not know. Perhaps RFC 5277 is good enough to
> > > let it rest in peace.
> >
> My original point was that the current set of drafts are very incomplete when it
> comes to RFC 5277.  They claim they obsolete it, but they also refer to
> definitons in it, and they don't talk at all about how to send notifications over
> NETCONF.

The intent has been to get the set of drafts in a place where the 5277bis + notif-netconf drafts could act together as a 'bis'.   You absolutely are correct that not everything was incorporated & cleaned-up yet.
 
> Keep it as it is (not obsolete) is certainly one option.

Are  you advocating for this option?   

The two 'not obsolete' options path I see are:
(a) WG advocates parallel IETF notification subscription mechanisms for NETCONF: 5277 & this newer work.  To me this doesn't seem tenable.
(b) WG has notification subscription capabilities which are less functional the datastore subscription capabilities.  (I.e., notifications would not support capabilities such as multiple subs/transport, modify, delete, configured sub, OAM messages, alternative non-NETCONF transports, etc.)

The yang-push work was originally going down path (b) until the WG requested that subscription capabilities of RFC 7923 be supported for notifications.

Eric

---

From: MehmetErsue <[email-masked]>
Date: Wed, 07 Dec 2016 17:38:01 +0000

All,

> I haven't seen any proposal for doing this on the ML.

Any discussion result from the notification team meetings is still subject
to agree on NETCONF ML.
Such issues should be raised on the ML, the earlier the better.

Mehmet

-- 
Cheers,
Mehmet

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Dec 2016 09:54:01 -0800

> Such issues should be raised on the ML, the earlier the better.
I think Martin has raised valid concerns that we do not yet agree on the
requirements.
The details of a solution do not matter if people do not agree on the
problem first.

What are the must-have, should-have, and nice-to-have features that are
missing from RFC 5277?

E.g., if we agree that is is a terrible burden on the client that 1 session
be used for each subscription,
then multiple subscriptions per session is an important feature.  How to do
that is the next step,
not this step.

Andy

---

From: MehmetErsue <[email-masked]>
Date: Wed, 07 Dec 2016 19:03:04 +0000

> > Benefits of 'enhance'

Technically spoken, I think it would valuable for the industry to support
the future use of 5277 and backwards compatibility with it. Though
achieving the full backwards compatibility in one document will be very
effortful.

> Benefits of 'obsolete'
capabilities exchange
> it can't be used as an argument to both 'enhance' and 'obsolete'.

IMO it actually should be called "Benefits of enabling two solutions" as I
understand there is interest to keep using 5277 instead of obsoleting.
And I think we shouldn't use "backwards compatibility" in this case. It is
rather enabling the use of two solutions through parallel implementation
and capabilities exchange.

> and not as an extension of RFC 5277.

Agree.

> effort I do not know.

I think updating 5277 to use YANG is nice-to-have.

BR,
Mehmet

On Tue, Dec 6, 2016 at 4:53 PM Juergen Schoenwaelder <
[email-masked]> wrote:

> will be running concurrently
>
> capabilities exchange
> impact this decision?
> of overloading.
> Phone: +49 421 200 3587 <0421%202003587>         Campus Ring 1 | 28759
> Bremen | Germany
> Fax:   +49 421 200 3103 <0421%202003103>         <
> http://www.jacobs-university.de/>
>
-- 
Cheers,
Mehmet

---

From: MehmetErsue <[email-masked]>
Date: Wed, 07 Dec 2016 19:03:09 +0000

> (a) WG advocates parallel IETF notification subscription mechanisms for
NETCONF: 5277 & this newer work.  To me this doesn't seem tenable.

Can you please elaborate why this is not tenable?
Technically spoken I think it is the easiest way to enable continuing to
use 5277 as it is and at the same to reduce the necessary effort for the
new solution.

> (b) WG has notification subscription capabilities which are less
functional the datastore subscription capabilities.  (I.e., notifications
would not support capabilities such as multiple subs/transport, modify, >
delete, configured sub, OAM messages, alternative non-NETCONF transports,
etc.)
>
> The yang-push work was originally going down path (b) until the WG
requested that subscription capabilities of RFC 7923 be supported for
notifications.

This requires some discussion to understand the impacts.

BR,
Mehmet

On Wed, Dec 7, 2016 at 3:36 PM Eric Voit (evoit) <[email-masked]> wrote:

> The intent has been to get the set of drafts in a place where the 5277bis
> + notif-netconf drafts could act together as a 'bis'.   You absolutely are
> correct that not everything was incorporated & cleaned-up yet.
>
> (a) WG advocates parallel IETF notification subscription mechanisms for
> NETCONF: 5277 & this newer work.  To me this doesn't seem tenable.
> (b) WG has notification subscription capabilities which are less
> functional the datastore subscription capabilities.  (I.e., notifications
> would not support capabilities such as multiple subs/transport, modify,
> delete, configured sub, OAM messages, alternative non-NETCONF transports,
> etc.)
>
> The yang-push work was originally going down path (b) until the WG
> requested that subscription capabilities of RFC 7923 be supported for
> notifications.
>
> Eric
>
> > /martin
>
-- 
Cheers,
Mehmet

---

From: MehmetErsue <[email-masked]>
Date: Wed, 07 Dec 2016 19:20:32 +0000

Hi Andy, All,

can anybody draft a list of must-have, should-have, and nice-to-have
requirements for discussion on the ML?
I think writing a draft for this would be an over-kill but I'm flexible.

Mehmet

On Wed, Dec 7, 2016 at 6:54 PM Andy Bierman <[email-masked]> wrote:

> E.g., if we agree that is is a terrible burden on the client that 1
> session be used for each subscription,
> then multiple subscriptions per session is an important feature.  How to
> do that is the next step,
> not this step.
>
>
>
>
> Mehmet
>
>
>
>
> Andy
>
>
>
Cheers,
Mehmet

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 7 Dec 2016 19:36:50 +0000

Incremental functionality we have been discussing since IETF 94, 95, 96, 97 include:

- configured subscriptions

- many subscriptions per transport

- modify and delete subscriptions

- control plane notifications

- Restconf & HTTP support

- Data plan notification including subscription-id

Existing documentation detailing these requirements can be seen in places like:

https://www.ietf.org/proceedings/95/slides/slides-95-netconf-7.pdf   Slide 5

https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf   Slides 5, 28

https://www.ietf.org/proceedings/97/slides/slides-97-netconf-draft-ietf-netconf-yang-push-01.pdf  Slides 20 & 21

I2RS's RFC-7923 which drove the functional requirements for yang subscriptions is what was requested by the WG to be made available for event notifications.

as well as various WG meeting minutes.

Based on this, the aggregate set of requirements are sufficient.  If someone wants to propose a revision to the requirements, they can propose deltas from the existing documentation.  I would be quite happy to comment.

Eric

From: Netconf, December 7, 2016 2:21 PM

Hi Andy, All,
can anybody draft a list of must-have, should-have, and nice-to-have requirements for discussion on the ML?
I think writing a draft for this would be an over-kill but I'm flexible.
Mehmet

On Wed, Dec 7, 2016 at 6:54 PM Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Dec 7, 2016 at 9:38 AM, MehmetErsue <[email-masked]<mailto:[email-masked]>> wrote:
All,

> I haven't seen any proposal for doing this on the ML.
Any discussion result from the notification team meetings is still subject to agree on NETCONF ML.
Such issues should be raised on the ML, the earlier the better.

I think Martin has raised valid concerns that we do not yet agree on the requirements.
The details of a solution do not matter if people do not agree on the problem first.

What are the must-have, should-have, and nice-to-have features that are missing from RFC 5277?

E.g., if we agree that is is a terrible burden on the client that 1 session be used for each subscription,
then multiple subscriptions per session is an important feature.  How to do that is the next step,
not this step.

Mehmet

Andy

On Mon, Dec 5, 2016 at 10:35 PM Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:
> On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
>
> > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>>
> > wrote:
> > >

/martin

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf
--
Cheers,
Mehmet
--
Cheers,
Mehmet

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Dec 2016 11:55:32 -0800

Hi,

IMO every feature mentioned so far is the nice-to-have variety.
Given that Call-Home is almost done, configured subscriptions are not that
important.
cancel-subscription is cleaner than dropping the transport connection, but
this (and perhaps other)
features are patented so IPR applies.

I am not a fan of lots of optional-to-implement complexity.
If it not widely supported on servers, then client developers don't want it.

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 7 Dec 2016 20:09:00 +0000

> From: MehmetErsue, December 7, 2016 2:03 PM
>
> Technically spoken I think it is the easiest way to enable continuing to use 5277
> as it is and at the same to reduce the necessary effort for the new solution.

I completely agree people should be good to use RFC-5277 deployments as long as they want.  

The word 'untenable' refers to an IETF recommended approach for new deployments.  Does the IETF really want to advocate two parallel solutions for NETCONF event subscriptions (5277 and what is currently 5277bis)?   I suspect this isn't allowed, hence 'obsolete' as my preference.   

> > functional the datastore subscription capabilities.  (I.e.,
> > notifications would not support capabilities such as multiple
> > subs/transport, modify, > delete, configured sub, OAM messages,
> > alternative non-NETCONF transports, etc.)
> >

?    Maybe I am confused.   The NETCONF WG changed our direction a couple IETFs ago here.  The request was to support the new capabilities with Event Notifications.  Are you suggesting we change that?    

The only question on the table which I believe needs to be addressed is enhance vs obsolete.   What driver/question is raising a general revisiting of requirements?

Eric

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Dec 2016 14:42:15 -0800

Hi,

The real question is what use-cases do we agree need to be supported which
are not currently supported that well. Here are 3, where the 5277 solution
may not scale well enough in implementation

   - notification collector: If subscriptions are provided as a service
then multiple subscriptions
     per session may provide some opportunities for optimization on the
collector and the server.
     e.g., send a notification just once, tagged with all the
subscription-ids that are supposed to
    get this notification

  - telemetry: need high-performance and efficient use of the network;
consider binary encoding
    and non-secure transports; relying on YANG Push so that draft has to
clearly identify lower
    layer requirements

 - datastore replication: need reliable delivery and high performance; YANG
Push is also
   the solution for this use-case

IMO we will not make progress on solution details without a better
understanding of the use-cases.

Andy

---

From: MehmetErsue <[email-masked]>
Date: Wed, 07 Dec 2016 22:46:58 +0000

Hi Eric,

> The word 'untenable' refers to an IETF recommended approach for new
deployments.  Does the IETF really want to advocate two parallel solutions
for NETCONF event subscriptions (5277 and what is
> currently 5277bis)?   I suspect this isn't allowed, hence 'obsolete' as
my preference.

IETF for sure is interested to have one solution. Though there is no rule
written into stone.
Whatever the WG and AD agree and the IESG approves can be published.

> ?    Maybe I am confused.   The NETCONF WG changed our direction a couple
IETFs ago here.  The request was to support the new capabilities with Event
Notifications.  Are you suggesting we change that?
> The only question on the table which I believe needs to be addressed is
enhance vs obsolete.   What driver/question is raising a general revisiting
of requirements?

You actually did what I asked for with listing the requirements.
I think we don't need to re-discuss all requirements.
Though looking at the recent discussion it seems to be useful to revisit
one or the other requirement just to get a certain basis.

Thanks,
Mehmet

On Wed, Dec 7, 2016 at 9:09 PM Eric Voit (evoit) <[email-masked]> wrote:

> use 5277
> The word 'untenable' refers to an IETF recommended approach for new
> deployments.  Does the IETF really want to advocate two parallel solutions
> for NETCONF event subscriptions (5277 and what is currently 5277bis)?   I
> suspect this isn't allowed, hence 'obsolete' as my preference.
>
> ?    Maybe I am confused.   The NETCONF WG changed our direction a couple
> IETFs ago here.  The request was to support the new capabilities with Event
> Notifications.  Are you suggesting we change that?
>
> The only question on the table which I believe needs to be addressed is
> enhance vs obsolete.   What driver/question is raising a general revisiting
> of requirements?
>
> Eric
>
> > BR,
> > Mehmet
>
> --
Cheers,
Mehmet

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Dec 2016 10:41:24 +0100 (CET)

> (e.g. YANG to CBOR could be used)

Yes that would be nice!  There are some use cases for defining
data structures that are not data nodes in a data store; this is one
use case and another is restconf resources (we use rc:yang-data for
this).  I think Kent had another use case recently as well.

We have a vendor-specific YANG extension for this:

   tailf:structure meta-data {
     description "...";
     leaf device-name { ... }
     leaf stream-name { ... }
     ...
   }

Of course, for this to work properly, we'd need this to be a built-in
statement in YANG, so that augment can be made to work as well.

/martin