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

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Jun 2018 17:32:13 +0200 (CEST)

Hi,

I checked draft-ietf-netconf-subscribed-notifications-12 (and to some
extent draft-ietf-netconf-subscribed-notifications-13 in github) wrt
my previous LC comments and new text.  Here are my additional
comments:

o  Section 1.4

  This is a left-over from my previous review; you accepted the
  proposed change, but it seems you forgot to change the text.

  OLD:

     o  the one way operation of [RFC5277], Section 4 is used.

  NEW:

     o  the <notification> message defined in [RFC5277] is still used.

o  Section 1.4

  Also a left-over.

  OLD:

   o  a publisher MAY implement both the Notification Management Schema
      and RPCs defined in [RFC5277] and this new document concurrently,
      in order to support old clients.  However the use of both
      alternatives on a single transport session is prohibited.

  NEW:

   o  a publisher MAY implement both the Notification Management Schema
      and RPCs defined in [RFC5277] and this new document concurrently,
      in order to support old clients.

o  Section 2.3

  s/"QoS" feature/"qos" feature/  (twice)

o  Section 2.4.5

  OLD:

   "subscriptions/subscription/receivers/receiver/address".

  NEW:

   "/subscriptions/subscription/receivers/receiver/address".

o  Section 2.7.6

  OLD:

   This notification indicates that a configured subscription, which
   includes a "stop-time", has successfully finished passing event
   records upon the reaching of that time.

  NEW:

   This notification indicates that a subscription that includes a
   "stop-time" has successfully finished passing event records upon
   the reaching of that time.

o  Section 4

  It seems you changed the state names from "active" to "ACTIVE",
  etc, i.e., all caps.  The 6087bis guidelines say that lower case
  should be used.

  My suggestion is to change to lower case in the model (which was in
  -10 that was in LC), and change ACTIVE to "active" in the text
  body.  (which I proposed in my LC review as well)

o  Section 4

  You have:

          leaf pushed-notifications {
            type yang:counter64;
            config false;
            description
              "Operational data which provides the number of update
               notification messages pushed to a receiver.";
          }

  Is this a left-over from previous versions?  This document doesn't
  define YANG push, and it doesn't define the term "update
  notification message".

  Should it simply be notifications-sent, with description "A count of
  the number of notifications sent to the receiver."?

o  Section 4

    leaf encoding  should have "if-feature configured;"

    (it is dependent on ../transport, which has the if-feature)

    Also, the description for this leaf is in -12:

        "The type of encoding for the subscribed data. If not
        included as part of the RPC, the encoding MUST be set by the
        publisher to be the encoding used by this RPC.";

   and in the not-yet-published -13 (from github):

        "The type of encoding for the subscribed data.   If not
        included, the encoding used will be the default for one
        encoding expected with a transport.";

   I can't parse from "the encoding used ...".

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 7 Jun 2018 22:05:48 +0000

Hi Martin,

Updated file at:
https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-subscribed-notifications-13.txt 

> From: Martin Bjorklund, June 7, 2018 11:32 AM
> 
> Hi,
> 
> I checked draft-ietf-netconf-subscribed-notifications-12 (and to some extent
> draft-ietf-netconf-subscribed-notifications-13 in github) wrt my previous LC
> comments and new text.  Here are my additional
> comments:
> 
> 
> 
> o  Section 1.4
> 

In there now.  

>       in order to support old clients.

Done

>    "/subscriptions/subscription/receivers/receiver/address".

Done

>    the reaching of that time.

Done

>   body.  (which I proposed in my LC review as well)

Done.  I changed *all* states in this and NETCONF-notif to lower case.  This includes the YANG file.

>   the number of notifications sent to the receiver."?

Text wasn't left over.   But to make it as clean as possible, I changed to:

          leaf count-sent {
            type yang:counter64;
            config false;
            description
              "The number of event records sent to the receiver.  The 
              count is initialized when a dynamic subscription is 
              established, or when a configured subscription 
              transitions to the valid state.";
          } 
          leaf count-excluded {
            type yang:counter64;
            config false;
            description
              "The number of event records explicitly removed either 
              via an event stream filter or an access control filter so 
              that they are not passed to a receiver.  This count is 
              set to zero each time 'count-sent' is initialized.";
          }

>     (it is dependent on ../transport, which has the if-feature)

The encoding can be set by RPC, so the issue is with the constraint.   (E.g., when HTTP is used, JSON and CBOR might be encodings.)

Maybe the way to address this (as can be seen in the draft) is to enhance the constraint to:

When  ' not(boolean(../transport))  or derived-from(../transport, "sn:configurable-encoding")'

And add an identity error to cover when an attempt is made establish a subscription with an unsupported encoding:

  identity encoding-not-supported {
    base establish-subscription-error;
    description
      "Unable to encode notification messages in the desired format.";
  }

>    I can't parse from "the encoding used ...".

Made it:

"The type of encoding for notification messages.   For a dynamic subscription, if not included as part of an establish-subscription RPC, the encoding will be populated with the encoding used by that RPC.  For a configured subscription, if not explicitly configured the encoding with be the default encoding for an underlying transport.";

Thanks,
Eric

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Jun 2018 11:02:05 +0200 (CEST)

Hi,

> > From: Martin Bjorklund, June 7, 2018 11:32 AM

[...]

> >   s/"QoS" feature/"qos" feature/  (twice)

You forgot this one.  The feature in the YANG model is "qos", not
"QoS".

> Text wasn't left over.   But to make it as clean as possible, I changed to:

You may want to use yang:zero-based-counter64.

>From the description below, you definately want
yang:zero-based-counter64.

>               set to zero each time 'count-sent' is initialized.";

Ok with this, but I would prefer more descriptive leaf names.
event-records-sent and event-records-excluded perhaps.

> The encoding can be set by RPC, so the issue is with the constraint.
> > (E.g., when HTTP is used, JSON and CBOR might be encodings.)
> 

You don't need the boolean(...):

  when 'not(../transport) or derived-from(...)';

/martin

> And add an identity error to cover when an attempt is made establish
> a subscription with an unsupported encoding:
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 8 Jun 2018 13:16:46 +0000

Updated version at:

> From: Martin Bjorklund, June 8, 2018 5:02 AM
> 
> Hi,
> 
> 
> You forgot this one.  The feature in the YANG model is "qos", not "QoS".

Change made.

> You may want to use yang:zero-based-counter64.

Change made
 
> From the description below, you definately want yang:zero-based-counter64.

Change made

> event-records-sent and event-records-excluded perhaps.

Left it as "count-sent" and "count-excluded".  Reason is that the "count-sent" can be reused for yang-push notifications without casual users needing to read through all the descriptions to understand that a "push-update" notification is actually a form of event record.

>   when 'not(../transport) or derived-from(...)';

Change made

Eric

> /martin
> 
> 
> 
> > And add an identity error to cover when an attempt is made establish a
> > subscription with an unsupported encoding:
> >
> > "The type of encoding for notification messages.   For a dynamic subscription,
> if not included as part of an establish-subscription RPC, the encoding will be
> populated with the encoding used by that RPC.  For a configured subscription,
> if not explicitly configured the encoding with be the default encoding for an
> underlying transport.";
> >
> > Thanks,
> > Eric
> >
> > > /martin
> > >

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Jun 2018 16:22:33 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> Left it as "count-sent" and "count-excluded".  Reason is that the
> "count-sent" can be reused for yang-push notifications without casual
> users needing to read through all the descriptions to understand that
> a "push-update" notification is actually a form of event record.

But the name of the leaf doesn't change the semantics.  The
description says "number of event records", so your casual user still
have to understand that a YANG Push notif is an event record.

BTW, it is not clear from the YANG push document that a YANG push
notif really is an event record.  It uses the term "update record",
and use the term "event record" in just one place.  This term should
be imported from Subscribed-notifications, and used.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 8 Jun 2018 14:57:01 +0000

> From: Martin Bjorklund, June 8, 2018 10:23 AM
> 
<snip>
> But the name of the leaf doesn't change the semantics.  The description says
> "number of event records", so your casual user still have to understand that a
> YANG Push notif is an event record.
> 
> BTW, it is not clear from the YANG push document that a YANG push notif
> really is an event record.  It uses the term "update record", and use the term
> "event record" in just one place.  This term should be imported from
> Subscribed-notifications, and used.

Update record has additional constraints.  Probably the way to handle this is to tweak the definition of update record in YANG push to the following:

"Update record: An event record which contains a representation of one or more datastore node updates.  In addition, an update record may contain which type of  update led to the datastore node update (e.g., whether the datastore node was added, changed, deleted).  Also included in the  update record may be other metadata, such as a subscription identifier of the subscription as part of which the update record was generated."

Eric

---

From: Kent Watsen <[email-masked]>
Date: Tue, 12 Jun 2018 21:16:53 +0000

Sure, but can YP import the "Event Record" term from SN?

Also, I think that the definition could be improved.  It currently reads:

   Event record: A set of information detailing an event.

Kent // contributor

<snip>

Eric

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=ChdyY-tKTlPquVOwbOXya3_PcGgirMepotW7UY8_V68&s=Bd-V3zeqTlVJmJa9OVqUUYf4I2RqZU5ce49Jd2xY37E&e=

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 12 Jun 2018 21:32:19 +0000

> Sure, but can YP import the "Event Record" term from SN?

Sure.  It imports other terms.  Alex, do you want to bring it in?
 
>    Event record: A set of information detailing an event.

Yes.  But the word 'event' here is itself defined as:

   Event: An occurrence of something that may be of interest.  Examples
   include a configuration change, a fault, a change in status, crossing
   a threshold, or an external input to the system.

Reviewers have liked separation of the event itself from the record about it.

Eric

> Update record has additional constraints.  Probably the way to handle this is to
> tweak the definition of update record in YANG push to the following:
> 
> "Update record: An event record which contains a representation of one or
> more datastore node updates.  In addition, an update record may contain
> which type of  update led to the datastore node update (e.g., whether the
> datastore node was added, changed, deleted).  Also included in the  update
> record may be other metadata, such as a subscription identifier of the
> subscription as part of which the update record was generated."
> 
> Eric
> 
> > /martin
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=C
> hdyY-tKTlPquVOwbOXya3_PcGgirMepotW7UY8_V68&s=Bd-
> V3zeqTlVJmJa9OVqUUYf4I2RqZU5ce49Jd2xY37E&e=
>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 12 Jun 2018 22:45:16 +0000

>Reviewers have liked separation of the event itself from the record about it.

I'm okay with separation.  On one hand, it seems like common English, but
it might be good to have it well-defined in this draft.  Still it seems 
that the definition could be improved, maybe by contrasting it to an event?
One is the what happened, the other a record about what happened...

Kent // contributor

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 12 Jun 2018 23:39:30 +0000

Two quick replies inline, <ALEX>
--- Alex
> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
> Sent: Tuesday, June 12, 2018 3:45 PM
> To: Eric Voit (evoit) <[email-masked]>; Martin Bjorklund <[email-masked]>;
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Netconf] comments on draft-ietf-netconf-subscribed-notifications-
> 12
> 
> 
> 
> 

<ALEX> Why should we bring it into YP?  We basically don't use the term there.  We use "update record" (which we do define).  </ALEX>

> I'm okay with separation.  On one hand, it seems like common English, but it
> might be good to have it well-defined in this draft.  Still it seems that the
> definition could be improved, maybe by contrasting it to an event?

<ALEX> The separation makes sense and I think is something we always had in mind.  I am not clear what is needed.  We currently have "event record", which is distinguished from the "event" itself, and the "notification message", in addition to "event stream".  (We could rename "notification message" to "event notification message", which woudl become rather lengthy; we did not call it "event message" since there might be notification messages that notify of updates, which are different from events.)  
In short, I am not convinced that any changes are needed; I do think we have captured the right terms; but of course if you would like to see alternative definition text please make a suggestion.  
</ALEX>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Jun 2018 08:02:16 +0200

> One is the what happened, the other a record about what happened...

Regarding terminology:

   Configured subscription: A subscription installed via configuration
   into a configuration datastore.

OK

   Dynamic subscription: A subscription agreed between subscriber and
   publisher created via an "establish-subscription" RPC.

Try to define what it is, avoiding tying it into a specific RPC.

   Event stream: A continuous, chronologically ordered set of events
   aggregated under some context.

   Notification message: Information intended for a receiver indicating
   that one or more event(s) have occurred.

RFC 7950 does not define 'notification' in the terminology section (it
probably should). But RFC 6241 has this definition:

   o  notification: A server-initiated message indicating that a certain
      event has been recognized by the server.

So how do 'event record' and 'notification' relate to each other? Are
RFC 6241 notifications the same as notifications defined here? If so,
why not use a common definition? (It seems RFC 5277 likes to talk about
'event notifications' - so we even have a third term for what may be the
same.)

/js

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 13 Jun 2018 09:04:21 +0200 (CEST)

Alexander Clemm <[email-masked]> wrote:
> <ALEX> Why should we bring it into YP?  We basically don't use the
> term there.  We use "update record" (which we do define).  </ALEX>

Alex, see the previous emails in this thread for context.  The initial
problem was the counter "pushed-notifications" in
subscribed-notifications.  Eric suggested to rename it and describe it
as:

         leaf count-sent {
           type yang:counter64;
           config false;
           description

The question is what this leaf really counts.  Does it count the
number of <notification> messages sent?  The number of "event
records"?  Does it include "update records"?

(Does this change if we have a mechanism to bundle several event
records into a single <notification> message, as has been proposed?)

> <ALEX> The separation makes sense and I think is something we always
> had in mind.  I am not clear what is needed.  We currently have
> "event record", which is distinguished from the "event" itself, and
> the "notification message", in addition to "event stream".  (We
> could rename "notification message" to "event notification message",
> which woudl become rather lengthy; we did not call it "event
> message" since there might be notification messages that notify of
> updates, which are different from events.)   
> In short, I am not convinced that any changes are needed; I do think
> we have captured the right terms; but of course if you would like to
> see alternative definition text please make a suggestion.   

As Juergen noted you have "event record" and "notification message"
defined as new terms in subscribed-notifications.  It is not clear how
this relates to YANG's "notification" statement and RFC 6241/5277
<notification> message.

I *think* that YANG's "notification" statement defines an "event
record", and that your term "notification message" is the same as
6241/5277 "notification" (message).

Also, I think that an "update record" is represented as one of
"push-update" and "push-change-update" YANG notifications.  So aren't
these "event records"?  I.e., an "update record" is a special case of
an "event record"?

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 13 Jun 2018 15:36:01 +0000

Each of the terms used are different.  While they all are defined in the first document they are used, let me paraphrase the meanings of the definitions...

Event - something that happened

Event record - the recorded details of a single event

Update record - one or more datastore node updates

<notification> - a structure defined in RFC5277 which is as a wrapper which contains an event record.  A <notification> can exist without any active subscription.

"notification" statement - a structure defined in RFC-7950 section 7.16 which allows the definition of event record types specific to a YANG module. The results of the a YANG "notification" statement are encoded in a <notification>.  

Notification message - a message intended for a specific subscription receiver which includes one or more <notification>. A notification message will have undergone any security/content filtering on embedded <notification> as appropriate for that receiver.

Per the discussion below, I see an update record being a specialized type of event record.  For YANG push, the 'event' is driven by the update trigger: i.e., either the expiration of a periodic timer (for periodic subscriptions), or a change to the datastore (on-change subscription).

More below....

> From: Martin Bjorklund, June 13, 2018 3:04 AM
> 
> > > To: Eric Voit (evoit) <[email-masked]>; Martin Bjorklund
> > > <[email-masked]>; [email-masked]
> > > Cc: [email-masked]
> > > Subject: Re: [Netconf] comments on
> > > draft-ietf-netconf-subscribed-notifications-
> > > 12
> > >
> > >
> > >
> > >
> Alex, see the previous emails in this thread for context.  The initial problem
> was the counter "pushed-notifications" in subscribed-notifications.  Eric
> suggested to rename it and describe it
> as:
> 
>          leaf count-sent {
>            type yang:counter64;
>            config false;
>            description
> The question is what this leaf really counts.  Does it count the number of
> <notification> messages sent?  The number of "event records"?  Does it include
> "update records"?

It should count the number of event records.  

The reason is driven by Martin's point below: draft-ietf-netconf-notification-messages.  With this draft, a notification message may contain more than one event record.  Also with this draft, a notification message may contain a single event record could have been sent to serve the needs of multiple subscriptions.  For these reasons, post RFC-5277, having a count the notification messages won't provide any per-receiver insight into what was missed/delivered for a particular subscription.
 
> (Does this change if we have a mechanism to bundle several event records into
> a single <notification> message, as has been proposed?)
> 
> 
> 
> > > I'm okay with separation.  On one hand, it seems like common
> > > English, but it might be good to have it well-defined in this draft.
> > > Still it seems that the definition could be improved, maybe by contrasting it
> to an event?
> > had in mind.  I am not clear what is needed.  We currently have "event
> > record", which is distinguished from the "event" itself, and the
> > "notification message", in addition to "event stream".  (We could
> > rename "notification message" to "event notification message", which
> > woudl become rather lengthy; we did not call it "event message" since
> > there might be notification messages that notify of
> defined as new terms in subscribed-notifications.  It is not clear how this
> relates to YANG's "notification" statement and RFC 6241/5277 <notification>
> message.

Hopefully the text at the beginning highlights the needed differentiation.   I can also place the above definitions of <notification> and "notification" statement into the subscribed-notifications terminology definitions if this clears things up.

> I *think* that YANG's "notification" statement defines an "event record", 

Yes

> and that your term "notification message" is the same as

Yes.   

The reason to differentiate the terms now is that when draft-ietf-netconf-notification-messages completes, the term "notification message" will be able to refer to both the RFC-5277 and the draft-ietf-netconf-notification-messages mechanisms for encapsulating event records.

> Also, I think that an "update record" is represented as one of "push-update"
> and "push-change-update" YANG notifications.  So aren't these "event
> records"?  I.e., an "update record" is a special case of an "event record"?

Yes.

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 13 Jun 2018 15:56:14 +0000

> From: Kent Watsen <[email-masked]>
> Sent: Tuesday, June 12, 2018 6:45 PM
> Subject: Re: [Netconf] comments on draft-ietf-netconf-subscribed-
> notifications-12
> 
> 
> 
> 

What I am hearing from you is:

Event record: A set of information detailing an event.  This information is different from the event itself, and provides a recorded history of what happened.

If yes, I am fine with this.

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Jun 2018 18:02:06 +0200

> "notification" statement - a structure defined in RFC-7950 section 7.16 which allows the definition of event record types specific to a YANG module. The results of the a YANG "notification" stateme…

Here is where I am getting lost. The RFC 7950 notification statement
(its not a structure btw) does define the content of a notification.
And notification used to be defined in RFC 6241 as a "server-initiated
message indicating that a certain event has been recognized by the
server." Your notion of an event record may come from the RFC 5277
format that adds an eventTime etc. but the relationship of what is a
YANG defined notification and how it related to your event record and
the <notification> structure is still unclear.
 
> Notification message - a message intended for a specific subscription receiver which includes one or more <notification>. A notification message will have undergone any security/content filtering o…

So how does this fit Figure 1 of RFC 6241? This figure indicates that
<notification> is a message as seen from the messages layer. You are
saying a notification message is something else that includes one or
more <notification>s. Yes, I know that the diagram in RFC 5277 is
different but the diagram in RFC 6241 is the newer one.

> Per the discussion below, I see an update record being a specialized type of event record.  For YANG push, the 'event' is driven by the update trigger: i.e., either the expiration of a periodic tim…

I am missing a definition what an Update record is. It is surely not
in this email. Anyway, if there are changes to architectural concepts,
it would be nice to find them in a coherent well explained section.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 13 Jun 2018 17:01:25 +0000

Hi Juergen,

> From: Juergen Schoenwaelder, June 13, 2018 2:02 AM
> 
> > I'm okay with separation.  On one hand, it seems like common English,
> > but it might be good to have it well-defined in this draft.  Still it
> > seems that the definition could be improved, maybe by contrasting it to an
> event?

How about:

Dynamic subscription: A subscription agreed between subscriber and publisher as driven by an RPC request originating from the subscriber.

> RFC 7950 does not define 'notification' in the terminology section (it probably
> should). But RFC 6241 has this definition:
> 
> So how do 'event record' and 'notification' relate to each other? 

The mail:
https://www.ietf.org/mail-archive/web/netconf/current/msg14684.html 
which I just sent contains my view of the interplay between 'event-record', <notification>, and other terms.  It is probably better if I don't replicate the full info from that email here just so that we don't fork the discussions. But I will comment on each of your specific questions:

> Are RFC 6241 notifications the same as notifications defined here?

While it doesn't explicitly say it, my reading of RFC-6241 Figure 1 says that RFC-6271 notifications correspond 1:1 with the RFC-5277 <notification>.  With this reading, an RFC-6241 notification is absolutely a valid "notification message".  However over time there may be new forms of "notification message" which are not of type <notification>.  For example, with draft-ietf-netconf-notification-messages, we will have a form of "notification message" which can support the bundling of multiple event records.  The result is we need a term which can expand beyond <notification>.

>  If so, why not use a
> common definition? (It seems RFC 5277 likes to talk about 'event notifications'
> - so we even have a third term for what may be the
> same.)

Regarding RFC-5277 "event notification".  Actually the term "event notification" is not formally defined in RFC-5277.  Instead the closest definition comes in Section 2.2.1., where "event notification" is equated to <notification>.  So these two seemingly equivalent terms come from that single document.  And I didn't want to perpetuate the "event notification" term knowing that the underlying definition seems to preclude the bundling of events.  

Thanks,
Eric

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 13 Jun 2018 17:15:26 +0000

Hi Martin, Eric,

ok.  I am still not sure why we would need the term in YP then?

I do agree we need to be clear on the semantics of what it is that is being counted.  As you indicate, we should distinguish the number of notification messages from the number of event records, specifically if they could be different (like in the case of bundles), and be clear which one we count here.  I don't think we need to get too fancy with statistics here.  If we do count the number of event-records, the question is what we count in case of YP; counting the number of update-records in that case is probably what makes sense (but update-record is defined independently of event-record).  If this is the case, perhaps we should update the definition of update-record to have the first sentence read as follows: "An update-record is a special type of event record that represents one or more datastore node updates" (and in this case we would have the reference to event record, which would then be a term to refer to from subscribed notifications).  Is this what you had in mind? 

--- Alex

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2018 12:04 AM
> To: Alexander Clemm <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Alex, see the previous emails in this thread for context.  The initial problem was
> the counter "pushed-notifications" in subscribed-notifications.  Eric suggested to
> rename it and describe it
> as:
> 
>          leaf count-sent {
>            type yang:counter64;
>            config false;
>            description
> (Does this change if we have a mechanism to bundle several event records into a
> single <notification> message, as has been proposed?)
> 
> 
> 
> > > Still it seems that the definition could be improved, maybe by contrasting it to
> an event?
> defined as new terms in subscribed-notifications.  It is not clear how this relates
> to YANG's "notification" statement and RFC 6241/5277 <notification> message.
> 
> I *think* that YANG's "notification" statement defines an "event record", and
> that your term "notification message" is the same as
> Also, I think that an "update record" is represented as one of "push-update" and
> "push-change-update" YANG notifications.  So aren't these "event records"?  I.e.,
> an "update record" is a special case of an "event record"?
> 
> 
> 
> /martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Jun 2018 19:17:34 +0200

> Dynamic subscription: A subscription agreed between subscriber and publisher as driven by an RPC request originating from the subscriber.

Why not simply:

Dynamic subscription: A subscription created dynamically by a
subscriber via a remote procedure call.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 13 Jun 2018 17:21:12 +0000

> From: Juergen Schoenwaelder, June 13, 2018 1:18 PM
> 
> publisher as driven by an RPC request originating from the subscriber.
> >
> 
> Why not simply:
> 
> Dynamic subscription: A subscription created dynamically by a subscriber via a
> remote procedure call.

Works for me.

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Jun 2018 10:12:04 +0200 (CEST)

Hi,

Alexander Clemm <[email-masked]> wrote:
> I do agree we need to be clear on the semantics of what it is that is
> being counted.  As you indicate, we should distinguish the number of
> notification messages from the number of event records, specifically
> if they could be different (like in the case of bundles), and be clear
> which one we count here.  I don't think we need to get too fancy with
> statistics here.  If we do count the number of event-records, the
> question is what we count in case of YP; counting the number of
> update-records in that case is probably what makes sense (but
> update-record is defined independently of event-record).  If this is
> the case, perhaps we should update the definition of update-record to
> have the first sentence read as follows: "An update-record is a
> special type of event record that represents one or more datastore
> node updates" (and in this case we would have the reference to event
> record, which would then be a term to refer to from subscribed
> notifications).  Is this what you had in mind?

Yes.

/martin

> > problem was
> > number of
> > records into a
> > this relates
> > record", and
> > "push-update" and

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Jun 2018 10:22:16 +0200 (CEST)

Hi,

> the <notification> structure is still unclear.

I don't think we should align terminology with 5277.  More important
is to align with the current set of documents; 7950 and 6241.

If subscribed-notifications is transport-independent, it should
probably not talk too much about <notifcation> etc; this should go
into the transport docs.

7950 says that the "notification" statement defines a notification.
As Juergen pointed out this term is not defined in the terminology
section, but nevertheless the term is used.

Does the WG now want to introduce a new term for what the
"notification" statement defines?  It seems to me that the term "event
record" is being proposed for this.  The answer to this question will
have a big impact on the rest of the terminology.

> different but the diagram in RFC 6241 is the newer one.

This confuses me as well.

How much of this do we have to define in this document, and how much
should go into the transport docs?

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 14 Jun 2018 17:18:39 +0000

> From: Martin Bjorklund, June 14, 2018 4:22 AM
> 
> Hi,
> 
> > > Each of the terms used are different.  While they all are defined in the first
> document they are used, let me paraphrase the meanings of the definitions...
> > >
> > > <notification> - a structure defined in RFC5277 which is as a wrapper which
> contains an event record.  A <notification> can exist without any active
> subscription.
> > >
> > > "notification" statement - a structure defined in RFC-7950 section 7.16
> which allows the definition of event record types specific to a YANG module.
> The results of the a YANG "notification" statement are encoded in a
> <notification>.
> >
> I don't think we should align terminology with 5277.  More important is to
> align with the current set of documents; 7950 and 6241.

Exactly.  

Note that there was no terms imported from 5277.  Subscribed-notifications does define an umbrella term "notification message", and uses Section 2.6 to make the minimal connection necessary to show that an RFC-5277  <notification> is a valid "notification message".  BTW: We had text in earlier versions of subscribed-notifications stating the need to support future types of "notification messages" such as those defined in draft-ietf-netconf-notification-messages.  However reviewers asked these evolving references to be removed.

We do have the option of importing terms from 6241 into the NETCONF-notif document.  This would be the right place to do it because in the subscribed-notifications document we want to limit any introduction of NETCONF dependencies.   (Maybe NETCONF-notif adds text to say that a "RFC6241 client" maps to subscriber, and "RFC6241 server" maps to publisher?)

> If subscribed-notifications is transport-independent, it should probably not talk
> too much about <notifcation> etc; this should go into the transport docs.

In general, this is what is done.  In subscribed-notifications, the only place <notification> is mentioned at all is section 2.6.    If necessary, we could move this section to NETCONF-notif, but that would leave no transport independent framing for the notifications.  I guess it is possible to live without that, but it would leave the subscribed-notifications feeling incomplete.  I suspect a similar thought process drove the inclusion of <notification> within RFC-6020 and then RFC-7950.
 
> As Juergen pointed out this term is not defined in the terminology section, but
> nevertheless the term is used.
>
> Does the WG now want to introduce a new term for what the "notification"
> statement defines?

It certainly might make sense to have a future update of RFC-7950 with something like this.    I spend a bit of time trying to understand the connection of YANG notification statement with <notification>.  Having this be better defined would be helpful.

>  It seems to me that the term "event record" is being
> proposed for this.

An event record is not necessarily a YANG notification, as the event record's payload might not be driven by the result of a YANG statement.

> The answer to this question will have a big impact on the
> rest of the terminology.

As event record has a larger scope than what can come from a YANG notification statement, my suggestion would be for the revision of RFC-7950 to import "event record", and then specify a new subtype term (maybe "YANG event record"?).  If that term works, a YANG event record could then be an event record where the contents are populated by the results of the YANG notification statement.

> > > Notification message - a message intended for a specific subscription
> receiver which includes one or more <notification>. A notification message will
> have undergone any security/content filtering on embedded <notification> as
> appropriate for that receiver.
> >

The requirement for the bundling of many events is being driven by large data center telemetry.  It is unclear at this point whether NETCONF will be a transport used in this environment.

If NETCONF does care about this environment, and does want to support something like draft-ietf-netconf-notification-messages, I do think tweaks to RFC-6241 will be needed.  For example what is the definition of <notification> within 6241, Figure 1 (right now point RFC-5277 isn't explicitly mentioned.).   Must this figure only be interpreted as a RFC 5277 <notification>?  Can the figure also mean a draft-ietf-netconf-notification-messages "message"?

> should go into the transport docs?

Beyond what I describe above, impacts would be to new/updated transport drafts.   Plus an update to subscribed-notifications section 2.6 to indicate that a new transport independent <notification> construct exists.

Eric

> /martin
> 
> 
> > > Per the discussion below, I see an update record being a specialized type of
> event record.  For YANG push, the 'event' is driven by the update trigger: i.e.,
> either the expiration of a periodic timer (for periodic subscriptions), or a
> change to the datastore (on-change subscription).
> > >
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Jun 2018 20:39:59 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> > is to
> Note that there was no terms imported from 5277.
> Subscribed-notifications does define an umbrella term "notification
> message", and uses Section 2.6 to make the minimal connection
> necessary to show that an RFC-5277 <notification> is a valid
> "notification message".  BTW: We had text in earlier versions of
> subscribed-notifications stating the need to support future types of
> "notification messages" such as those defined in
> draft-ietf-netconf-notification-messages.  However reviewers asked
> these evolving references to be removed.
> 
> We do have the option of importing terms from 6241 into the
> NETCONF-notif document.  This would be the right place to do it
> because in the subscribed-notifications document we want to limit any
> introduction of NETCONF dependencies.  (Maybe NETCONF-notif adds text
> to say that a "RFC6241 client" maps to subscriber, and "RFC6241
> server" maps to publisher?)

8342 defines the terms "client" and "server" in a transport-agnostic
way.  I think we should try to use these terms in new documents, where
applicable.  In this document, the term "subscriber" is a special
"client".  I am not sure that a "publisher" is always a "server"; this
needs to be decided.

> > probably not talk
> In general, this is what is done.  In subscribed-notifications, the
> only place <notification> is mentioned at all is section 2.6.  If
> necessary, we could move this section to NETCONF-notif, but that would
> leave no transport independent framing for the notifications.  I guess
> it is possible to live without that, but it would leave the
> subscribed-notifications feeling incomplete.

If subscribed-notifications is transport independent, it should not
have the NETCONF-specific text in 2.6.

2.6 also says:

   In all cases, a single transport session MUST
   be capable of supporting the intermixing of RPCs and notifications
   from different subscriptions.

This applies to NETCONF, but not for the UDP transport, and I suspect
not for the HTTP transport either?

> I suspect a similar
> thought process drove the inclusion of <notification> within RFC-6020
> and then RFC-7950.

No; for various reasons YANG was initially positioned as a data
modelling language for NETCONF only.  Hence all text about how to map
YANG to NETCONF and XML.

> > "notification"
> It certainly might make sense to have a future update of RFC-7950 with
> something like this.  I spend a bit of time trying to understand the
> connection of YANG notification statement with <notification>.  Having
> this be better defined would be helpful.
> 
> An event record is not necessarily a YANG notification, as the event
> record's payload might not be driven by the result of a YANG
> statement.

I don't get this.  Can you give an example of when an event record is
not defined as a YANG "notification"?

> As event record has a larger scope than what can come from a YANG
> notification statement, my suggestion would be for the revision of
> RFC-7950 to import "event record", and then specify a new subtype term
> (maybe "YANG event record"?).  If that term works, a YANG event record
> could then be an event record where the contents are populated by the
> results of the YANG notification statement.
> 
> The requirement for the bundling of many events is being driven by
> large data center telemetry.  It is unclear at this point whether
> NETCONF will be a transport used in this environment.
> 
> If NETCONF does care about this environment, and does want to support
> something like draft-ietf-netconf-notification-messages, I do think
> tweaks to RFC-6241 will be needed.

Yes, somehow.

> For example what is the definition
> of <notification> within 6241, Figure 1 (right now point RFC-5277
> isn't explicitly mentioned.).  Must this figure only be interpreted as
> a RFC 5277 <notification>?  Can the figure also mean a
> draft-ietf-netconf-notification-messages "message"?

RFC 6241 says that <notification> is defined in RFC 5277.  (ok,
there's an error in there, and it points to 5717, but there's an
errata for that).

> Beyond what I describe above, impacts would be to new/updated
> transport drafts.  Plus an update to subscribed-notifications section
> 2.6 to indicate that a new transport independent <notification>
> construct exists.

Ok.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 14 Jun 2018 20:11:38 +0000

> From: Martin Bjorklund, June 14, 2018 2:40 PM
> 
> > > contains an event record.  A <notification> can exist without any
> > > active subscription.
> > > > >
> > > > > "notification" statement - a structure defined in RFC-7950
> > > > > section
> > > > > 7.16
> > > > Here is where I am getting lost. The RFC 7950 notification
> > > > statement (its not a structure btw) does define the content of a
> notification.
> > > > And notification used to be defined in RFC 6241 as a
> > > > "server-initiated message indicating that a certain event has been
> > > > recognized by the server." Your notion of an event record may come
> > > > from the RFC 5277 format that adds an eventTime etc. but the
> > > > relationship of what is a YANG defined notification and how it
> > > > related to your event record and the <notification> structure is still
> unclear.
> > >
> 8342 defines the terms "client" and "server" in a transport-agnostic way.  I
> think we should try to use these terms in new documents, where applicable.
> In this document, the term "subscriber" is a special "client". 

Agreed.  Terminology section updated per the last email.

> I am not sure that a "publisher" is always a "server"; this needs to be decided.

I think that within YANG-push, a publisher is a special RFC-8342 "server".  Perhaps what we could add to YANG push in the terminology a sentence which says "In this document, the term publisher also includes the role of RFC-8342 server."    Alex, what do you think about that?

However my belief is that we shouldn't do a global cut-and-paste of "publisher" with some new term for this intersection to use throughout the document.   This could end up being confusing.  For example, if we define a new term like "YANG-push publisher" a reader of the YANG model would need to jump back and forth between the definitions of "publisher" and "YANG-push publisher" knowing that both are equally valid in this context. 
 
> If subscribed-notifications is transport independent, it should not have the
> NETCONF-specific text in 2.6.

RESTCONF also refers to RFC-5277's <notification>.   See section 6.4.    So there is precedent and adoption for reuse of the transport element beyond NETCONF.

So while pulling this section out and placing it within NETCONF-notif is possible, it would mean either replicating this information RESTCONF-notif, or forcing RESTCONF-notif to await the completion of  draft-ietf-netconf-notification-messages.

> This applies to NETCONF, but not for the UDP transport, and I suspect not for
> the HTTP transport either?

Agreed.  This statement is now removed. 
 
> No; for various reasons YANG was initially positioned as a data modelling
> language for NETCONF only.  Hence all text about how to map YANG to
> NETCONF and XML.
> 
> > >  It seems to me that the term "event record" is being proposed for
> > > this.
> >
> I don't get this.  Can you give an example of when an event record is not
> defined as a YANG "notification"?

Another way to put this is that the event record within the <notification> might not be encoding YANG data.  For examples, all the <notification> within RFC5277 were defined before the availability of YANG.
 
> > > The answer to this question will have a big impact on the rest of
> > > the terminology.
> >
> > > receiver which includes one or more <notification>. A notification
> > > message will have undergone any security/content filtering on
> > > embedded <notification> as appropriate for that receiver.
> > > >
> > > > So how does this fit Figure 1 of RFC 6241? This figure indicates
> > > > that <notification> is a message as seen from the messages layer.
> > > > You are saying a notification message is something else that
> > > > includes one or more <notification>s. Yes, I know that the diagram
> > > > in RFC 5277 is different but the diagram in RFC 6241 is the newer one.
> > >

Ok

Eric
 
> RFC 6241 says that <notification> is defined in RFC 5277.  (ok, there's an error
> in there, and it points to 5717, but there's an errata for that).
> 
> > > either the expiration of a periodic timer (for periodic
> > > subscriptions), or a change to the datastore (on-change
> > > subscription).
> > > > >
> > > >
> > > > I am missing a definition what an Update record is. It is surely
> > > > not in this email. Anyway, if there are changes to architectural
> > > > concepts, it would be nice to find them in a coherent well explained
> section.
> > > >
> > > > /js
> > > >
> > > > --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Jun 2018 08:27:51 +0200

> not defined as a YANG "notification"?

Why do we care about non-YANG-defined notification messages? How are
systems expected to interoperate on such opaque data blobs? Perhaps
there is a need to reduce complexity in order to get something that is
coherent and consistent and at the end interoperable. The very goal of
IETF standards is to enable interoperable implementations; it is not a
goal to define a framework that allows multiple non-interoperable
implementations to declare compliance to a standard.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 15 Jun 2018 10:49:29 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> > way.  I
> I think that within YANG-push, a publisher is a special RFC-8342
> "server".  Perhaps what we could add to YANG push in the terminology a
> sentence which says "In this document, the term publisher also
> includes the role of RFC-8342 server."

Can we first agree on the basic terminology in
subscribed-notifications?

First question: are server and publisher potentially different entites
or not?

Looking at restconf-notif, it seems to me that the publisher is an
HTTP2 client, i.e., a different entity than the RESTCONF server.

Is this correct:

NETCONF:
   subscriber is a NETCONF client
   publisher is a NETCONF server
   receiver is a NETCONF client

RESTCONF

   subscriber is a RESTCONF client
   (NOTE 1)
   publisher is a HTTP2 client
   receiver is a HTTP2 server

UDP

   subscriber is a NETCONF/RESTCONF client
   publisher is a UDP client
   receiver is a UDP server

NOTE 1: the RESTCONF server is missing from this picture.  It doesn't
have a special term...

I assume this work is not applicable to CoMI?

/martin

> However my belief is that we shouldn't do a global cut-and-paste of
> "publisher" with some new term for this intersection to use throughout
> the document.  This could end up being confusing.  For example, if we
> define a new term like "YANG-push publisher" a reader of the YANG
> model would need to jump back and forth between the definitions of
> "publisher" and "YANG-push publisher" knowing that both are equally
> valid in this context.
>  
> RESTCONF also refers to RFC-5277's <notification>.  See section 6.4.
> So there is precedent and adoption for reuse of the transport element
> beyond NETCONF.
> 
> So while pulling this section out and placing it within NETCONF-notif
> is possible, it would mean either replicating this information
> RESTCONF-notif, or forcing RESTCONF-notif to await the completion of
> draft-ietf-netconf-notification-messages.
> 
> > 2.6 also says:
> > 
> > modelling
> Another way to put this is that the event record within the
> <notification> might not be encoding YANG data.  For examples, all the
> <notification> within RFC5277 were defined before the availability of
> YANG.
>  
> > there's an error

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 15 Jun 2018 10:56:31 +0200

Hello all,

on one hand, I understand the need for interoperability and therefore 
avoid non-interoperable solutions, obviously.

On the other hand, I would strongly recommend to allow for 
non-YANG-molded data here. Over the years we have seen a lot of 
convergence wrt to endpoint-, network- and function- visualization. 
While this might sound like the first sentence of yet another boring 
ivory tower publication - it is a fact that for multiple reasons code 
bases merge to simply onboarding, enrollment, deploylmen and maintenance 
of network equipment.

Using YANG-based interfaces to support this ongoing convergence by 
allowing for non-YANG-modled data is considered vital by a multitude of 
stakeholders. And while it is of course more difficult to enable 
interoperable implementations in this regard, it seems to me due to the 
fact how the "YANG-part" is structured/modled today it is neither 
harmful nor useless to the internet - and in contrast very useful to 
migrate away from older legacy interface.

I am new to the domain of NETCONF, but I am in strong support of 
allowing for non-YANG-defined notification messages wrt migration, 
simplification of implementation and well... simply moving away from a 
zoo of procedures that are already a nightmare. This is a chance get rid 
of that existing "nightmare" step-by-step and provide a path forward to 
enable structural and semantic convergence of data conveyed.

This is why I care very much about non-YANG-modeled telemetry provided 
by a YANG-based interface.

Viele Grüße,

Henk

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Jun 2018 11:43:06 +0200

> HTTP2 client, i.e., a different entity than the RESTCONF server.

There is a difference between transport client/server roles and the
NETCONF/RESTCONF client server roles, see the call home work.
 
>    publisher is a UDP client

I am not sure what UDP client and UDP server really means, perhaps
'UDP sender' and 'UDP receiver' are more appropriate here since there
is not much more than that. That said, I am concerned that such a
plain UDP transport may struggle getting approved by the IESG due to
security and privacy concerns that are taken somewhat seriously by the
IESG (but it also depends a bit on who is on the IESG at the time you
hit it). If it will be necessary to mandate say DTLS in order to get
IESG approval, then you get a more significant client and server role
back at the security layer.

Given that there are a large number of message queue middleware
systems out there, does it really make sense to try to create a
special purpose baby with (compared to the grown ups) rather limited
functionality? Are we not hitting the 'oh there are N different
standards, lets create another one to replace them and at the end we
have N+1' syndrome?

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 15 Jun 2018 12:20:42 +0000

> From: Juergen Schoenwaelder, June 15, 2018 2:28 AM
> 
> systems expected to interoperate on such opaque data blobs?

Opaque data blobs is what RFC-5277 can carry.  The WG asked to update RFC-5277 using the improved control plane of YANG-Push.  This is what makes up the documents in LC.   

> Perhaps there is
> a need to reduce complexity in order to get something that is coherent and
> consistent and at the end interoperable. The very goal of IETF standards is to
> enable interoperable implementations; it is not a goal to define a framework
> that allows multiple non-interoperable implementations to declare compliance
> to a standard.

The drafts in LC adds RPC / signaling mechanisms.  The opaque data blobs are not in scope.

It would be helpful to get some comments on draft-ietf-netconf-notification-messages.  This draft address improvements to the opaque data blobs.

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 15 Jun 2018 13:24:56 +0000

> From: Martin Bjorklund, June 15, 2018 4:49 AM
> 
> > > > > contains an event record.  A <notification> can exist without
> > > > > any active subscription.
> > > > > > >
> > > > > The results of the a YANG "notification" statement are encoded
> > > > > in a <notification>.
> > > > > >
> > > > > > "server-initiated message indicating that a certain event has
> > > > > > been recognized by the server." Your notion of an event record
> > > > > > may come from the RFC 5277 format that adds an eventTime etc.
> > > > > > but the relationship of what is a YANG defined notification
> > > > > > and how it related to your event record and the <notification>
> > > > > > structure is still
> > > unclear.
> > > > >
> > > > > I don't think we should align terminology with 5277.  More
> > > > > important is to align with the current set of documents; 7950 and 6241.
> > > >
> > > > Exactly.
> > > >
> > > > Subscribed-notifications does define an umbrella term
> > > > "notification message", and uses Section 2.6 to make the minimal
> > > > connection necessary to show that an RFC-5277 <notification> is a
> > > > valid "notification message".  BTW: We had text in earlier
> > > > versions of subscribed-notifications stating the need to support
> > > > future types of "notification messages" such as those defined in
> > > > because in the subscribed-notifications document we want to limit
> > > > any introduction of NETCONF dependencies.  (Maybe NETCONF-notif
> > > > adds text to say that a "RFC6241 client" maps to subscriber, and
> > > > "RFC6241 server" maps to publisher?)
> > >
> > > way.  I think we should try to use these terms in new documents,
> > > where applicable.
> Can we first agree on the basic terminology in subscribed-notifications?
> 
> First question: are server and publisher potentially different entites or not?

Yes.  Here is my reading:

(a) A publisher sending YANG formatted notifications will be an RFC-8342 server.  

(b) A publisher sending non YANG formatted notifications (e.g.,  XSD) will not be an RFC-8342 server. 

(c) An RFC-8342 server might not be a publisher.

(d) An RFC-8342 server that supports at least one YANG model using the notification statement, and which also supports subscribed-notifications will be a publisher.

> HTTP2 client, i.e., a different entity than the RESTCONF server.

For configured subscriptions, there is no RESTCONF.  The publisher is just an HTTP2 client.

For dynamic subscriptions, the publisher is both a RESTCONF server and HTTP2 client.  (Note: this is the closest IETF match to what GRPC might be able to transport that I can see.)

Yes

Yes

Also note that Andy also wants HTTP1.1 support for dynamic subscriptions.  And while this is in Section 3.5 of document, personally I don't think it worth inclusion.  This is a debate we should have for that draft.
 
>    publisher is a UDP client

Walker, can you comment on this?  It hits on the terminology diagram discussion over the last few days.

> NOTE 1: the RESTCONF server is missing from this picture.  It doesn't have a
> special term...
> 
> 

It is applicable to CoMI.   See:
https://tools.ietf.org/id/draft-birkholz-yang-push-coap-problemstatement-00.html

Eric

> > > > > probably not talk too much about <notifcation> etc; this should
> > > > > go into the transport docs.
> > > >
> > > > In general, this is what is done.  In subscribed-notifications,
> > > > the only place <notification> is mentioned at all is section 2.6.
> > > > If necessary, we could move this section to NETCONF-notif, but
> > > > that would leave no transport independent framing for the
> > > > notifications.  I guess it is possible to live without that, but
> > > > it would leave the subscribed-notifications feeling incomplete.
> > >
> > > This applies to NETCONF, but not for the UDP transport, and I
> > > suspect not for the HTTP transport either?
> >
> > > > thought process drove the inclusion of <notification> within
> > > > RFC-6020 and then RFC-7950.
> > >
> > > modelling language for NETCONF only.  Hence all text about how to
> > > map YANG to NETCONF and XML.
> > >
> > > > > As Juergen pointed out this term is not defined in the
> > > > > terminology section, but nevertheless the term is used.
> > > > >
> > > > It certainly might make sense to have a future update of RFC-7950
> > > > with something like this.  I spend a bit of time trying to
> > > > understand the connection of YANG notification statement with
> > > > <notification>.  Having this be better defined would be helpful.
> > > >
> > > > >  It seems to me that the term "event record" is being proposed
> > > > > for this.
> > > >
> > > > An event record is not necessarily a YANG notification, as the
> > > > event record's payload might not be driven by the result of a YANG
> > > > statement.
> > >
> > > I don't get this.  Can you give an example of when an event record
> > > is not defined as a YANG "notification"?
> >
> > > > > The answer to this question will have a big impact on the rest
> > > > > of the terminology.
> > > >
> > > > RFC-7950 to import "event record", and then specify a new subtype
> > > > term (maybe "YANG event record"?).  If that term works, a YANG
> > > > event record could then be an event record where the contents are
> > > > populated by the results of the YANG notification statement.
> > > >
> > > > > receiver which includes one or more <notification>. A
> > > > > notification message will have undergone any security/content
> > > > > filtering on embedded <notification> as appropriate for that receiver.
> > > > > >
> > > > > > So how does this fit Figure 1 of RFC 6241? This figure
> > > > > > indicates that <notification> is a message as seen from the messages
> layer.
> > > > > > includes one or more <notification>s. Yes, I know that the
> > > > > > diagram in RFC 5277 is different but the diagram in RFC 6241 is the
> newer one.
> > > > >
> > > > If NETCONF does care about this environment, and does want to
> > > > support something like draft-ietf-netconf-notification-messages, I
> > > > do think tweaks to RFC-6241 will be needed.
> > >
> > > Yes, somehow.
> >
> > Ok
> >
> > Eric
> >
> > > > For example what is the definition of <notification> within 6241,
> > > > Figure 1 (right now point RFC-5277 isn't explicitly mentioned.).
> > > > Must this figure only be interpreted as a RFC 5277 <notification>?
> > > > Can the figure also mean a
> > > > > How much of this do we have to define in this document, and how
> > > > > much should go into the transport docs?
> > > >
> > > > > event record.  For YANG push, the 'event' is driven by the
> > > > > update
> > > > > trigger: i.e.,
> > > > > > I am missing a definition what an Update record is. It is
> > > > > > surely not in this email. Anyway, if there are changes to
> > > > > > architectural concepts, it would be nice to find them in a
> > > > > > coherent well explained
> > > section.
> > > > > >
> > > > > > /js
> > > > > >
> > > > > > --

---

From: Kent Watsen <[email-masked]>
Date: Tue, 19 Jun 2018 21:58:22 +0000

> Opaque data blobs is what RFC-5277 can carry.  The WG asked to update 
> RFC-5277 using the improved control plane of YANG-Push.  This is what
> makes up the documents in LC.   
>
> <snip/>
>

RFC 5277 may have allowed opaque data blocks, but I think that we should 
try to bury that support now.  Can this document say that all notifications
MUST be defined by a YANG-defined "notification" statement?  Could this
break in compatibility be advertised somehow?

> It would be helpful to get some comments on draft-ietf-netconf-notification-messages.
> This draft address improvements to the opaque data blobs.

Perhaps tease us with a little more detail?  ;)

Kent

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 19 Jun 2018 23:33:26 +0000

> From: Kent Watsen, June 19, 2018 5:58 PM
> 
> > > > > event record's payload might not be driven by the result of a
> > > > > YANG statement.
> > > >
> RFC 5277 may have allowed opaque data blocks, but I think that we should try
> to bury that support now.  Can this document say that all notifications MUST
> be defined by a YANG-defined "notification" statement?  Could this break in
> compatibility be advertised somehow?

I had always seen as subscribed-notifications as a control plane improvement to RFC-5277.   Explicitly excluding XSD, SYSLOG, vendor structures, etc. seems unnecessary.   

I can ping a few people who have legacy implementations which might be closer to this than I.   Narrowing the scope in this way should be broadly discussed.

> Perhaps tease us with a little more detail?  ;)

Pretty much all the common headers in Section 3 and the message bundling in Section 4 are both improvements which are relevant to this thread. Tianran likely will have some new headers he wants added as part of the multi-line card work.

Eric

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Jun 2018 16:41:15 -0700

On Tue, Jun 19, 2018 at 4:33 PM, Eric Voit (evoit) <
evoit=[email-masked]> wrote:

> > > The drafts in LC adds RPC / signaling mechanisms.  The opaque data
> blobs are
> > not in scope.
> >
> try
MUST be defined in YANG is a bit strong.
I would say SHOULD be defined in YANG, for the "NETCONF" stream.
Other streams do not have to use YANG notification statements.

Andy

I had always seen as subscribed-notifications as a control plane
> improvement to RFC-5277.   Explicitly excluding XSD, SYSLOG, vendor
> structures, etc. seems unnecessary.
>
> I can ping a few people who have legacy implementations which might be
> closer to this than I.   Narrowing the scope in this way should be broadly
> discussed.
>
> > > It would be helpful to get some comments on draft-ietf-netconf-
> notification-
> > messages.
> Pretty much all the common headers in Section 3 and the message bundling
> in Section 4 are both improvements which are relevant to this thread.
> Tianran likely will have some new headers he wants added as part of the
> multi-line card work.
>
> Eric
>
> > Kent
> >
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 20 Jun 2018 02:27:33 +0000

> I had always seen as subscribed-notifications as a control plane improvement to RFC-5277.

Let hope so  ;)

> Explicitly excluding XSD, SYSLOG, vendor structures, etc. seems unnecessary.   

XSD is another DML, maybe you meant XML?  

SYSLOG is a protocol, I think you mean to say that folks might encapsulate
syslog messages inside a <notification> element.  This is fine, I suggest
defining a notification called something like "syslog-message" that is
essentially a leaf of type "string".

Vendor structures are like Syslog, they can be even be binary if the leaf
is of type "binary".

I'm not trying to exclude anything, what gets excluded?

> I can ping a few people who have legacy implementations which might
> be closer to this than I.   Narrowing the scope in this way should
> be broadly discussed.

But is it narrowing the scope any? (see above)

> > > notification-messages.
> Pretty much all the common headers in Section 3 and the message
> bundling in Section 4 are both improvements which are relevant
> to this thread. Tianran likely will have some new headers he
> wants added as part of the multi-line card work.

I don't see the relation to opaque data here. The "notification-contents"
description says "Encapsulates objects following YANG's notification-stmt
grammar of RFC-7950 section 14."  That doesn't sound like it would be
very opaque.

Kent

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 20 Jun 2018 14:33:41 +0000

Hi Kent,

> From: Kent Watsen, June 19, 2018 10:28 PM
> 
> syslog messages inside a <notification> element.  This is fine, I suggest defining
> a notification called something like "syslog-message" that is essentially a leaf of
> type "string".
> 
> Vendor structures are like Syslog, they can be even be binary if the leaf is of
> type "binary".
> 

Whew, I was getting worried!

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

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

> > bundling in Section 4 are both improvements which are relevant to this
> > thread. Tianran likely will have some new headers he wants added as
> > part of the multi-line card work.
> 
> I don't see the relation to opaque data here.

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

> The "notification-contents"
> grammar of RFC-7950 section 14."  That doesn't sound like it would be very
> opaque.

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

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 Jun 2018 16:36:44 +0200 (CEST)

> I'm not trying to exclude anything, what gets excluded?

I agree with Kent.  5277 was pre-YANG, so it could not be tied to the
"notification" message.  Even 5277 could not transport any data - it
had to be encoded in XML.  This new draft is more flexible since it
can be used with XML and JSON (and other encodings) - *because* it
transports YANG notifications.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 20 Jun 2018 15:47:09 +0000

> From: Martin Bjorklund, June 20, 2018 10:37 AM
> 
> improvement to RFC-5277.
> > SYSLOG is a protocol, I think you mean to say that folks might
> > encapsulate syslog messages inside a <notification> element.  This is
> > fine, I suggest defining a notification called something like
> > "syslog-message" that is essentially a leaf of type "string".
> >
> > Vendor structures are like Syslog, they can be even be binary if the
> > leaf is of type "binary".
> >
> "notification" message.  Even 5277 could not transport any data - it had to be
> encoded in XML.  This new draft is more flexible since it can be used with XML
> and JSON (and other encodings) - *because* it transports YANG notifications.

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

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

Eric

> > > bundling in Section 4 are both improvements which are relevant to
> > > this thread. Tianran likely will have some new headers he wants
> > > added as part of the multi-line card work.
> >
> > description says "Encapsulates objects following YANG's
> > notification-stmt grammar of RFC-7950 section 14."  That doesn't sound
> > like it would be very opaque.
> >
> >
> > Kent
> >
> >

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 20 Jun 2018 17:39:14 +0000

+1

This is what has been intended (and I believe we have been in agreement on) all along.

There is no reason to narrow the scope.  We have a model/mechanism to manage and control the subscriptions, and then separately from that we have the actual message streams.  Because the former is defined in YANG does not mean the content of the latter has to be,  although in many cases of course it will be.

--- Alex

From: Andy Bierman [mailto:[email-masked]]
Sent: Tuesday, June 19, 2018 4:41 PM
...
  Can this document say that all notifications MUST

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 20 Jun 2018 22:42:28 +0000

This makes sense to me. I would like to see messages like syslog can alse be streamed by this notificatuons.

Tianran

________________________________
Sent from WeLink

发件人： Andy Bierman
收件人： Eric Voit (evoit)<evoit=[email-masked]<mailto:evoit=[email-masked]>>
抄送： alex<[email-masked]<mailto:[email-masked]>>;netconf<[email-masked]<mailto:[email-masked]>>
主题： Re: [Netconf] comments on draft-ietf-netconf-subscribed-notifications-12
时间： 2018-06-20 07:42:09

Andy

Eric

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Jun 2018 09:46:03 +0200 (CEST)

> alse be streamed by this notificatuons.

What exactly do you mean?  If you mean syslog messages wrapped in a
notification like this:

  notification syslog-message {
    leaf msg {
      type string;
    }
  }

then it is trivially supported by this spec.

/martin

> 收件人： Eric Voit
> (evoit)<evoit=[email-masked]<mailto:evoit=[email-masked]>>
> 抄送：
> alex<[email-masked]<mailto:[email-masked]>>;netconf<[email-masked]<mailto:[email-masked]>>
> 主题： Re: [Netconf] comments on
> draft-ietf-netconf-subscribed-notifications-12
> 时间： 2018-06-20 07:42:09
> 
> 
> 
> On Tue, Jun 19, 2018 at 4:33 PM, Eric Voit (evoit)
> <evoit=[email-masked]<mailto:evoit=[email-masked]>>
> wrote:
> closer to this than I.  Narrowing the scope in this way should be
> broadly discussed.
> 
> > > It would be helpful to get some comments on

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 21 Jun 2018 08:23:22 +0000

Hi Martin,

Your example is exactly what I mean. There is no need to structuralize the syslog message by YANG. So a string is OK, leaving the application to parse the message. The same situation to some binary message.
If not this, I do not quite understand what the "non-YANG-defined notification messages" mean. :-)

Tianran

> Sent: Thursday, June 21, 2018 3:46 PM
> To: Tianran Zhou <[email-masked]>
> Cc: [email-masked]; evoit=[email-masked]; [email-masked];
> [email-masked]
> > > > > > > An event record is not necessarily a YANG notification, as
> > > > > > > the event record's payload might not be driven by the result
> > > > > > > of a YANG statement.
> > > > > >
> > > > > > I don't get this.  Can you give an example of when an event
> > > > > > record is not defined as a YANG "notification"?
> > > > >
> > > > > Why do we care about non-YANG-defined notification messages? How
> > > > > are systems expected to interoperate on such opaque data blobs?
> > > >
> > > > RFC-5277 using the improved control plane of YANG-Push.  This is
> > > > what makes up the documents in LC.
> > > >
> > > > <snip/>
> > > >
> > > RFC 5277 may have allowed opaque data blocks, but I think that we
> > > should try to bury that support now.  Can this document say that all
> > > notifications MUST be defined by a YANG-defined "notification"
> > > statement?  Could this break in compatibility be advertised somehow?
> >
> >

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 21 Jun 2018 11:55:24 +0000

> From: Martin Bjorklund, June 21, 2018 3:46 AM
> 

I think the encapsulation is useful too.

Do you see a reason for subscribed-notifications to mandate this when transporting event records?  Or do you see this as something which should be mandated for draft-ietf-netconf-notification-messages?

Eric

> alex<[email-masked]<mailto:[email-masked]>>;netconf<[email-masked]<
> m
> > ailto:[email-masked]>>