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

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Nov 2016 12:01:36 +0100 (CET)

Hi,

My plan was to review all four documents, but I will start with:

  draft-ietf-netconf-netconf-event-notifications-01.txt
  draft-ietf-netconf-rfc5277bis-01.txt

I still struggle with trying to figure out the purpose of the
different documents.

I think that from a layering perspective we have:

  Protocol:
    NETCONF Support for Event Notifications
    Restconf and HTTP Transport for Event Notifications

  Protocol-independent (YANG-defined) subscription mechanisms:
    Subscribing to Event Notifications
    Subscribing to YANG datastore push updates

But from a document reference perspective we have:

    NETCONF Support for Event Notifications
    Restconf and HTTP Transport for Event Notifications
          |
          | references
          |
          V
    Subscribing to Event Notifications
          ^
          |
          | references
          |
    Subscribing to YANG datastore push updates

Is this correct?

My main concern is with
draft-ietf-netconf-netconf-event-notifications-01.txt.

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.

Another problem with this draft in combination with rfc5277bis is that
they don't get the backwards compatibility issues right.  I assume the
intention is that an old client can work with a server that implements
this new set of drafts?  If so, you need to be careful with the
namespaces in the new YANG modules (we need two YANG modules, not
one).

Comments on draft-ietf-netconf-rfc5277bis-01:

o  Section 1.1

  The text says:

   Predating this work was used within a NETCONF
   implementation.  [RFC5277] which defined a limited defines a
   notification mechanism for for NETCONF.  However, there are various
   [RFC5277] has limitations:, many of which have been exposed in
   [RFC7923].

  I can't really parse this.  I also cheked for any mention of RFC
  5277 in RFC 7293, but I didn't find any, so I'm not sure which
  limitations you refer to.

o  Section 1.3

  The text says:

   This document
   builds on top of the capabilities defined in [RFC5277], extending
   them, and generalizing them to be protocol-agnostic.

  This should be rephrased; since you are obsoleting 5277 you can't
  build on top of it.

o  Section 2.1

  The text says:

   The NETCONF event stream contains all
   NETCONF XML event notifications supported by the publisher,

  First of all, since this document is protocol-agnostic, should it
  really define the stream "NETCONF"?

  Secondly, this would be a new requirement.  There is nothing in RFC
  5277 that says that a notification is sent on "NETCONF" be default.
  I think this text should be removed.  How notifications are mapped
  to streams is should be out of scope for this document.

o  Data model

  The data model should (for now) have two top-level containers,
  e.g. "event-notifications" and "event-notification-state" (or better
  names).

  The "stream" list is pretty limited compared with the corresponding
  list in RFC 5277.  This list should include the same info as the RFC
  5277 one - replaySupport, etc.

  The "filter-type" case "rfc5277" should be renamed to a more
  descriptive name.  Also, since you are obsoleting 5277 you need to
  define what this is, and not refer to RFC 5277.

  In list "filter", change "filter-id" to "id".

  In list "subscription", change "subscription-id" to "id".

  In list "subscription", change "startTime" to "start-time" and
  "stopTime" to "stop-time", for consistency.

  In list "subscription", change choice "push-source" to a better
  name, maybe "egress-interface" (this is how it is described).

  In list "receiver", what is a "multipoint address"?

  In list "receiver", I suggest "protocol" is mandatory instead of
  defaulting to netconf.

  In list "receiver", additional text is needed to explain how this is
  supposed to be used.  I suggest that we say that *how* this
  address/port is used is protocol-specific, and that any specification
  that defines an identity for a certain protocol (derived from
  transport-protocol) MUST specify how the receiver is used for that
  protocol.

  Remove the leaf "source-vrf"; this should eventually be aligned with
  draft-ietf-rtgwg-ni-model.

  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.

o  Section 4.1

  The text says:

   If the subscriber has no authorization to establish the subscription,
   the <subscription-result> indicates an authorization error.

  Why not use NACM?  Also, an authorization error should be reported
  using the protocol-specific error codes; not specialized errors per
  RPC.

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.

o  Section 4.2

  I do not understand this sentence:

   The contents of negative responses to
   modify-subscription requests are the subset of the establish
   subscription request parameters which are allowed to be dynamically
   modified.

o  Section 4.2 (and throughout the document)

   The text says:

    Configured subscriptions cannot be modified (or deleted) using RPCs.

  This wording should be changed; a configured subscription can in
  fact be modified using the <edit-config> RPC.  I suggest you define
  the terms "dynamic subscription" (it is already defined actually)
  and "static subscription" or "configured susbscription", and use
  these terms.  Change all text that says "via RPC" or "using RPC".

o  Section 4.3

  The text says:

   If the publisher can satisfy the request, it sends an OK element.

   If the publisher cannot satisfy the request, it sends an error-rpc
   element.

  Rephrase.  There is no "OK element", and probably not an "error-rpc
  element".  Or actually, just remove these sentences, they don't add
  anything.

o  Section 5.1

  The text says:

   Immediately after a
   subscription is successfully established, the publisher sends to its
   receivers a control-plane notification stating the subscription has
   been established (subscription-started).

  This needs to be clarified; does it mean that if there are two
  configured receivers A and B, and the server forst connects to A,
  then it sends "subscription-started" to A.  Then it connects to B
  and sends "subscription-started" to *both* A and B?  (I guess not,
  but the text is not clear).

o  Section 6

  The text says:

   The event notifications must also include the subscription-id if the
   establish-subscription was used in its establishment, or if it was
   configured via an operational interface.

  How is this "sucbscription-id" supposed to be included?  Where?
  There is no such field defined in a <notification>.

o  Replay

  The document doesn't define how replay works.

/martin

---

From: "Alberto Gonzalez Prieto (albertgo)" <[email-masked]>
Date: Mon, 28 Nov 2016 19:57:43 +0000

Thanks Martin,

On the purpose of the 4 documents and how they relate to each other,
please see inline ([AG])

>    Subscribing to YANG datastore push updates

[AG] It is correct

>NETCONF, and not how RPCs are encoded in XML.

[AG] FWIW, the scope of each doc is summarized on
https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf (slide
#5)
[AG] The key is that the spec for NC comes from the union of 5277-bis and
the NC transport doc
(draft-ietf-netconf-netconf-event-notifications-01.txt) The NC transport
doc is not meant to stand alone.
The doc contains how 5277-bis concepts are realized when using NC and
NC-specific aspects. E.g.:
- the use of NC call-home for configured subscriptions
- backwards compatibility
   - the existence of a NETCONF stream
   - support of /netconf/streams

- the definition of create-subscription may be moved to this doc so that
other transports would ignore create-subscription and use only
establish-subscription, simplifying the solution
- how to issue notifications in JSON are sent using NC (this is also in
5277-bis). Arguably, it belongs in the NC transport doc

>namespaces in the new YANG modules (we need two YANG modules, not

[AG] That is correct. This was identified after the latest version was
uploaded and listed in
https://www.ietf.org/proceedings/97/slides/slides-97-netconf-draft-ietf-net
conf-yang-push-01.pdf (slide #11)

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Nov 2016 12:12:29 -0800

> >NETCONF, and not how RPCs are encoded in XML.

I agree -- maybe get rid of it and just have rfc5277bis contain this text

>    - support of /netconf/streams

I agree with Martin that duplicating normative text is bad.
Not having any normative text is even worse.

> establish-subscription, simplifying the solution

That seems wrong since 5277 had create-subscription so it should stay in
5277bis

> 5277-bis). Arguably, it belongs in the NC transport doc

This is poorly defined.
NETCONF does not support JSON encoding and IMO should not define JSON
encoding unless the entire protocol supports it cleanly.
The proposal seems to be to use XML for <rpc> and <rpc-reply>,
but allow some special mode where <notification> is sent in JSON.

> conf-yang-push-01.pdf (slide #11)
I raised this issue before.
The YANG namespaces and local names need to exactly match the XSD
definitions
for previously defined elements.

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 28 Nov 2016 22:22:16 +0000

Some more thoughts.   And thanks Martin for the extensive comments.  They are greatly appreciated.

From: Netconf, November 28, 2016 3:12 PM
On Mon, Nov 28, 2016 at 11:57 AM, Alberto Gonzalez Prieto (albertgo) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Martin,

[AG] It is correct

<ev> 5277bis is supposed to allow transports other than NETCONF.  If we put the NETCONF specific stuff in here we lose that separation.

<ev> Yes, any 5277bis topic specific to only NETCONF transport should be in netconf-event-notifications

<ev> +1.  To help address that, I just built a whole list of pending changes across the four drafts.  And in quite a few places I pulled out duplicative text.

That seems wrong since 5277 had create-subscription so it should stay in 5277bis

<ev> It is really a style thing so it doesn’t matter that much either way.   Current thinking is that as we need both the new and old namespaces.  Therefore it seems simpler to have anything in the old namespace (“create-subscription”) in netconf-event-notification draft.

This is poorly defined.

I raised this issue before.
The YANG namespaces and local names need to exactly match the XSD definitions
for previously defined elements.

<ev> absolutely.

Andy

>  limitations you refer to.

<ev> We had lots of these in a previous version.  But we removed them to make the draft smaller.  The limitations are things like:
-modify-subscription
-delete-subscription
-Multiple subscriptions over session
     -Subscription suspension

>  This should be rephrased; since you are obsoleting 5277 you can't

<ev> agree

>  really define the stream "NETCONF"?

<ev> Agree, which is why this is going to netconf-event-notification.

>  5277 that says that a notification is sent on "NETCONF" be default.

<ev> 5277 section 3.2.3 talks about the default event stream which has all NETCONF event notifications

>  to streams is should be out of scope for this document.

<ev> Yes, streams as a whole were something we deferred for a while.  Latest thinking is we minimize streams to the degree possible.  Look for legacy stuff to be in netconf-event-notification.

>  e.g. "event-notifications" and "event-notification-state" (or better

<ev> agree that we need to expose the operational state of specific subscriptions.  This is very soon in our to-do list.

>  5277 one - replaySupport, etc.

<ev> Yes. Same point as streams two comments above.  We need this to match everything currently viable with 5277.

>  define what this is, and not refer to RFC 5277.

<ev> Yeah.  And even then, 5277 doesn’t define the boundaries completely.  So this needs some work.

>  In list "subscription", change "subscription-id" to "id".

<ev> Model purity-wise you are correct.  With both subscription id and filter id, several people expressed they wanted the objects to be immediately and obviously differentiable.   Hopefully others will chime in here.

>  "stopTime" to "stop-time", for consistency.

<ev> we kept the old names for backwards equivalency to 5277.

>  name, maybe "egress-interface" (this is how it is described).

<ev> push-source can also be an IP Address.  Another name possibility for this might be “Originates-from”, that is the basic idea.

>  In list "receiver", what is a "multipoint address"?

<ev> we are trying not to limit receivers to hosts.  Perhaps multicast address is ok.  Really we would be good with type: inet:host.

>  In list "receiver", I suggest "protocol" is mandatory instead of

<ev> makes sense.

>  transport-protocol) MUST specify how the receiver is used for that

<ev> makes sense.

>  draft-ietf-rtgwg-ni-model.

Perhaps a place for schema-mount?   We should leave source-vrf in place until we have the proper definition.  But we could update the text showing there is a pending decision.

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

>  using the protocol-specific error codes; not specialized errors per

<ev> Yes, we want to use NACM.  As for how to report the error codes, this makes sense.  We are just getting in to how to do the error codes right and complete.

>  implementations to figure out.  We shouldn't add such things to

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

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.

A worse outcome would be if a Subscriber kept guessing at acceptable parameters and pounding the Publisher with load on this.  This would take more resources than providing hints.

>   subscription request parameters which are allowed to be dynamically

<ev> Yes this is poorly worded.   Effectively this means that here are the negotiation hints on what might have worked.   Will reword.

>  these terms.  Change all text that says "via RPC" or "using RPC".

<ev> Agree.

>  element".  Or actually, just remove these sentences, they don't add

<ev> will remove.

>  but the text is not clear).

<ev> will fix the text.

>  There is no such field defined in a <notification>.

<ev> Unlike yang-push, the Notification events are not specified via the document.   The examples following the requirement do not include a subscription-id when they absolutely should.  (And this proves the point that these are needed :-).   We will update the examples.

>  The document doesn't define how replay works.

<ev> not yet.  We will work that.

Thanks again,
Eric

>[email-masked]<mailto:[email-masked]>

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Nov 2016 16:32:48 -0800

On Mon, Nov 28, 2016 at 2:22 PM, Eric Voit (evoit) <[email-masked]> wrote:

> *From:* Netconf, November 28, 2016 3:12 PM
> <ev> 5277bis is supposed to allow transports other than NETCONF.  If we
> put the NETCONF specific stuff in here we lose that separation.
>
>
>

IMO, 5277bis should just have the YANG modules added to it (that represent
the XSD) and no new features.  This would allow implementations of 5277
to advertise the YANG for <create-subscription>. This RFC has the "old"
notification element.  (Or get rid of 5277bis completely -- see below)

A new draft should have the new configured + dynamic,
<establish_subscription> , etc.
+ the "new" notification element that has subscription-id in it.
The new set of notification drafts should be independent of 5277.
They should just be new proposed standards.

5277bis may not even be needed.  Just let it get fazed out.
It can be classified obsolete.  It is very confusing to say
<create-subscription>
and old <notification> are no longer used, yet they are present in 5277bis.

It is much less confusing to define a new <notification> element, new
operations, etc.
and not mention anything about the old, obsolete way of doing things.

Andy

> <ev> +1.  To help address that, I just built a whole list of pending
> changes across the four drafts.  And in quite a few places I pulled out
> duplicative text.
>
>
>
> <ev> It is really a style thing so it doesn’t matter that much either
> way.   Current thinking is that as we need both the new and old
> namespaces.  Therefore it seems simpler to have anything in the old
> namespace (“create-subscription”) in netconf-event-notification draft.
>
>
>
>
>
> conf-yang-push-01.pdf
> <https://www.ietf.org/proceedings/97/slides/slides-97-netconf-draft-ietf-netconf-yang-push-01.pdf>
> (slide #11)
>
>
>
> <ev> We had lots of these in a previous version.  But we removed them to
> make the draft smaller.  The limitations are things like:
>
> -modify-subscription
>
> -delete-subscription
>
> <ev> Yes, streams as a whole were something we deferred for a while.
> Latest thinking is we minimize streams to the degree possible.  Look for
> legacy stuff to be in netconf-event-notification.
>
>
> >
> >o  Data model
> >
> <ev> agree that we need to expose the operational state of specific
> subscriptions.  This is very soon in our to-do list.
>
>
> <ev> Model purity-wise you are correct.  With both subscription id and
> filter id, several people expressed they wanted the objects to be
> immediately and obviously differentiable.   Hopefully others will chime in
> here.
>
>
> <ev> push-source can also be an IP Address.  Another name possibility for
> this might be “Originates-from”, that is the basic idea.
>
>
> <ev> we are trying not to limit receivers to hosts.  Perhaps multicast
> address is ok.  Really we would be good with type: inet:host.
>
>
> Perhaps a place for schema-mount?   We should leave source-vrf in place
> until we have the proper definition.  But we could update the text showing
> there is a pending decision.
>
>
> <ev> as the majority of the people in the informal design team were
> against the expansion of streams, this is likely a moot point.
>
>
> >o  Section 4.1
> >
> >  The text says:
> >
> <ev> Yes, we want to use NACM.  As for how to report the error codes, this
> makes sense.  We are just getting in to how to do the error codes right and
> complete.
>
>
> >
> >o  Section 4.1
> >
> >  The text says:
> >
> >   If the
> <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.
>
>
>
> 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.
>
>
>
> A worse outcome would be if a Subscriber kept guessing at acceptable
> parameters and pounding the Publisher with load on this.  This would take
> more resources than providing hints.
>
>
> >
> >o  Section 4.2
> >
> <ev> Yes this is poorly worded.   Effectively this means that here are the
> negotiation hints on what might have worked.   Will reword.
>
>
> >
> <ev> Unlike yang-push, the Notification events are not specified via the
> document.   The examples following the requirement do not include a
> subscription-id when they absolutely should.  (And this proves the point
> that these are needed :-).   We will update the examples.
>
>
> >o  Replay
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Nov 2016 12:40:26 +0100 (CET)

Hi,

Comments inline.  Unfortunately, this thread is already getting a bit
difficult to follow, due to inventive html-based email quoting.  It
would be greatly appreciated if you could configure your clients to
use a quoting style that works also in text.  I believe that using
such a style also works well for html-based clients, so nothing would
be lost.

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

> <ev> It is really a style thing so it doesn’t matter that much either way.   Current thinking is that as we need both the new and old namespaces.  Therefore it seems simpler to have anything in the…

I agree with Andy that anything that comes from 5277 that you need to
keep for backwards compatibility reasons should go into 5277bis.

> -Multiple subscriptions over session

Just make sure the text is correct in the draft at hand.

> <ev> 5277 section 3.2.3 talks about the default event stream which has all NETCONF event notifications

You're right.  The question is then what is an "NETCONF XML event
notification"?  I think the intention was that these would be
"notifications related to NETCONF", rather than "all YANG-defined
notifications".  This needs some disucssion.

> <ev> Yes, streams as a whole were something we deferred for a while.  Latest thinking is we minimize streams to the degree possible.  Look for legacy stuff to be in netconf-event-notification.

Do you mean that you plan to update the text around streams?  If so,
that's fine.

> <ev> Model purity-wise you are correct.  With both subscription id and filter id, several people expressed they wanted the objects to be immediately and obviously differentiable.   Hopefully others…

I think we should try to keep the same style across IETF documents.
Most models do not use redundant qualifiers, especially not for
generic names like 'id' or 'name' when used as a key.

> <ev> we kept the old names for backwards equivalency to 5277.

But there is nothing to be backwards compatible with in this case.
The input paramters to the existing <create-subscription> cannot be
changed, but new nodes should be kept consistent.

> <ev> push-source can also be an IP Address.  Another name possibility for this might be “Originates-from”, that is the basic idea.

The current draft has:

       choice push-source {
         description
           "Identifies the egress interface on the Publisher from
            which notifications will or are being sent.";

You probably need to adjust this, and make it clear what the
ip-address case really means.

> <ev> we are trying not to limit receivers to hosts. Perhaps multicast address is ok.  Really we would be good with type: inet:host.

The type is inet:host already.

You should probably clarify the descriptions.

> Perhaps a place for schema-mount?

Not really, rather an augment.

> We should leave source-vrf in
> place until we have the proper definition.

No I say remove it until you have a proper definition.  If you keep it
you need to have a proper definition of what it is, and it needs to be
interoperable across implementations.

> But we could update the text showing there is a pending decision.
> 

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.

> <ev> Yes, we want to use NACM.  As for how to report the error codes, this makes sense.  We are just getting in to how to do the error codes right and complete.

Ok...

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

So then the text should encourage implementations to provide good
error messages.

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

> A worse outcome would be if a Subscriber kept guessing at acceptable parameters and pounding the Publisher with load on this.  This would take more resources than providing hints.

That would also be quite weird.  But I can't imagine a use case where
a client needs a certain combination of parameters, the server rejcets
them but suggest some other parameters that will give the same result,
and then the client would use them?  Or worse, the server suggest
something that gives another result and the client somehow adjust to
them? 

> <ev> Unlike yang-push, the Notification events are not specified via the document.   The examples following the requirement do not include a subscription-id when they absolutely should.  (And this…

Well, examples are good, but you also need a normative definition.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 29 Nov 2016 16:05:23 +0000

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
> > >replace RFC 5277, it needs to focus on how notifications are sent
> > >over NETCONF, and not how RPCs are encoded in XML.
> > <ev> 5277bis is supposed to allow transports other than NETCONF.  If we put
> the NETCONF specific stuff in here we lose that separation.
> 
> 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.  (And this is why we need separate namespaces.)  

As layering upon RFC-5277 cannot give the new capabilities being requested of us in places like RFC-7923 (e.g., multiple subscriptions/session), we are moving now to put all elements just needed for backwards compatibility in the netconf transport draft.  We could also separate all this out into another independent backwards compatibility extension.  But we felt we had enough drafts in progress where we didn't want/need a fifth one.

> > [AG] The key is that the spec for NC comes from the union of 5277-bis
> > and the NC transport doc
> > (draft-ietf-netconf-netconf-event-notifications-01.txt) The NC
> > transport doc is not meant to stand alone.
> > <ev> +1.  To help address that, I just built a whole list of pending changes
> across the four drafts.  And in quite a few places I pulled out duplicative text.
> >
> > - the definition of create-subscription may be moved to this doc so
> > that other transports would ignore create-subscription and use only
> > <ev> It is really a style thing so it doesn’t matter that much either way.
> Current thinking is that as we need both the new and old namespaces.
> Therefore it seems simpler to have anything in the old namespace (“create-
> subscription”) in netconf-event-notification draft.
> 
> I agree with Andy that anything that comes from 5277 that you need to keep
> for backwards compatibility reasons should go into 5277bis.

Right now it is in 5277bis.  But we already can't have everything needed for backwards compatibility since the 5277bis is transport (NETCONF) independent.  So it seemed logical to put it NETCONF transport draft.  (Again we were trying to limit the proliferation of drafts.)   

In the end, I am ok as long as it lands somewhere.  So if people prefer, we could also have this as a completely separate backwards compatibility section + YANG model in 5277bis.

> > - how to issue notifications in JSON are sent using NC (this is also
> > in 5277-bis). Arguably, it belongs in the NC transport doc
> >
> >
> >
> > This is poorly defined.
> > The proposal seems to be to use XML for <rpc> and <rpc-reply>, but
> > allow some special mode where <notification> is sent in JSON.
> >
> > >
> > >o  Section 2.1
> > >
> > >  The text says:
> > >
> notification"?  I think the intention was that these would be "notifications
> related to NETCONF", rather than "all YANG-defined notifications".  This needs
> some disucssion.

Agree

> > <ev> Yes, streams as a whole were something we deferred for a while.  Latest
> thinking is we minimize streams to the degree possible.  Look for legacy stuff to
> be in netconf-event-notification.
> 
> Do you mean that you plan to update the text around streams?  If so, that's
> fine.

Yes
 
> > <ev> Model purity-wise you are correct.  With both subscription id and filter
> id, several people expressed they wanted the objects to be immediately and
> obviously differentiable.   Hopefully others will chime in here.
> 
> Most models do not use redundant qualifiers, especially not for generic names
> like 'id' or 'name' when used as a key.

I am happy with whatever convention the WG chooses.

> The input paramters to the existing <create-subscription> cannot be changed,
> but new nodes should be kept consistent.

Ok.  So you want start-time in the YANG model, and startTime in the RPC.  That can be done.

> > <ev> push-source can also be an IP Address.  Another name possibility for this
> might be “Originates-from”, that is the basic idea.
> 
> The current draft has:
> 
>        choice push-source {
>          description
> You probably need to adjust this, and make it clear what the ip-address case
> really means.

agree

> > <ev> we are trying not to limit receivers to hosts. Perhaps multicast address is
> ok.  Really we would be good with type: inet:host.
> 

agree

> > >  Remove the leaf "source-vrf"; this should eventually be aligned
> > > with  draft-ietf-rtgwg-ni-model.
> >

Happy to go with whatever convention people want to use.

> No I say remove it until you have a proper definition.  If you keep it you need to
> have a proper definition of what it is, and it needs to be interoperable across
> implementations.

We will address with the proper convention in the next draft

> > <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
(b) custom streams are likely to be the dominant use.
Anyone have an objection  to this change?

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

RFC7923 has it as a MUST (see section 4.2.2.)  Going to SHOULD is already easing off the requirement.

> That would also be quite weird.  But I can't imagine a use case where a client
> needs a certain combination of parameters, the server rejcets them but suggest
> some other parameters that will give the same result, and then the client
> would use them?  Or worse, the server suggest something that gives another
> result and the client somehow adjust to them?

When a subscription is rejected, we can provide a hint at why.  This is a new dampening period, a suggestion to use on-change, etc.  Without this hint, a subscriber could just keep guessing at parameters without guidance.  That is all negotiation is.
 
> subscription-id when they absolutely should.  (And this proves the point that
> these are needed :-).   We will update the examples.
> 
 
Will do.

Eric

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Nov 2016 17:29:52 -0800

On Tue, Nov 29, 2016 at 8:05 AM, Eric Voit (evoit) <[email-masked]> wrote:

> <notification>
> should
> 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.  (And this is why we need separate
> namespaces.)
>
>

We need to parse and understand "full backwards compatible".

Do we want existing implementations to be leveraged into the new solution?
Yes
A server should be capable of supporting <create-subscription> for
old, deprecated subscriptions, and <establish-subscription> for the new
current subscriptions.

Do we need to update RFC 5277 or replace it? IMO, replace it.
Since the <create-subscription> RPC was never in a YANG module,
it can be left out of the new module.

Even more radical, I think streams should be removed, even the NETCONF
stream.
They really serve no purpose now that subscriptions are formalized and can
even be configured.  It is also bad design to couple the output message
encoding
into the input stream. (e.g., NETCONF stream MUST be XML encoded).

Currently, filters are defined as a choice-stmt.
This implied OR-expr is too simplistic. An explicit combination of OR, AND,
and NOT is required
for different types of filters.  (similar to YANG 1.1 if-feature-stmt
syntax).

Andy

As layering upon RFC-5277 cannot give the new capabilities being requested
> of us in places like RFC-7923 (e.g., multiple subscriptions/session), we
> are moving now to put all elements just needed for backwards compatibility
> in the netconf transport draft.  We could also separate all this out into
> another independent backwards compatibility extension.  But we felt we had
> enough drafts in progress where we didn't want/need a fifth one.
>
> changes
> way.
> keep
> Right now it is in 5277bis.  But we already can't have everything needed
> for backwards compatibility since the 5277bis is transport (NETCONF)
> independent.  So it seemed logical to put it NETCONF transport draft.
> (Again we were trying to limit the proliferation of drafts.)
>
> In the end, I am ok as long as it lands somewhere.  So if people prefer,
> we could also have this as a completely separate backwards compatibility
> section + YANG model in 5277bis.
>
> "notifications
> Latest
> that's
> filter
> address is
> you need to
> against
> what
> When a subscription is rejected, we can provide a hint at why.  This is a
> new dampening period, a suggestion to use on-change, etc.  Without this
> hint, a subscriber could just keep guessing at parameters without
> guidance.  That is all negotiation is.
>
> > > >o  Section 6
> > > >
> > > >  The text says:
> > > >
> that