Subject: [Netconf] a joint discussion on dynamic subscription

From: Tianran Zhou <[email-masked]>
Date: Wed, 13 Jun 2018 03:47:26 +0000

Hi Eric,

When we are discussing the draft-ietf-netconf-udp-pub-channel, we find a conflict with current dynamic subscription design.
1. The dynamic subscription requires notification to use the same channel as the subscription.
2. The RPC does not have the input information about the receiver because the above assumption.

However, when we talk about the distributed data collection (multi data originators), the publication channel is always different from the subscription channel.
So either the distributed data collection does not support dynamic subscription, or current dynamic subscription definition may need modification.

What's your thoughts?

Regards,
Tianran

---

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

Hi Tianran,

> From: Tianran Zhou, June 12, 2018 11:47 PM
> 
> Hi Eric,
> 
> When we are discussing the draft-ietf-netconf-udp-pub-channel, we find a
> conflict with current dynamic subscription design.

This is true when you look at the NETCONF transport draft.  However this is *not* required by the base subscribed-notification draft.  And in fact, the HTTP transport draft might not use the same logical channel.  E.g., see how the URI is returned within:
https://github.com/netconf-wg/notif-restconf/blob/master/draft-ietf-netconf-restconf-notif-05.txt 

So if you wanted to define some transport session independence for a UDP transport, subscribed-notifications should permit that.   And if you believe there is something in the text which prohibits this, let me know.

> However, when we talk about the distributed data collection (multi data
> originators), the publication channel is always different from the subscription
> channel.

While it likely isn't what you want, even with NETCONF, the single NETCONF session doesn't means that distributed line card generation of the notification messages is impossible.  For example, the inclusion of the header object message-generator-id (as defined within draft-ietf-netconf-notification-messages) allows the notification message generation to be distributed onto linecards even if the messages themselves are still driven back to a central transport session.  Note that I am not recommending this, but the specifications would support this.

> So either the distributed data collection does not support dynamic
> subscription, or current dynamic subscription definition may need
> modification.

I think for UDP, you will want to define a way to bind the lifecycle of the dynamic subscription's channels across multiple line cards.  This will require some thinking as well as coordination within the publisher.

Perhaps returning multiple URIs (one for each linecard) might be something which could make this easier.  If you go down this path, you still will need to fate-share the lifecycle of the subscription across all of those line cards.

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Jun 2018 09:18:28 +0200 (CEST)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> > 1. The dynamic subscription requires notification to use the same
> > channel as
> > the subscription.
> 
> This is true when you look at the NETCONF transport draft.  However
> this is *not* required by the base subscribed-notification draft.  And
> in fact, the HTTP transport draft might not use the same logical
> channel.  E.g., see how the URI is returned within:
> So if you wanted to define some transport session independence for a
> UDP transport, subscribed-notifications should permit that.  And if
> you believe there is something in the text which prohibits this, let
> me know.

Cool!  I think that this should be explcitly described in the
subscribed-notifications document.

In the case of RESTCONF, decision to use a separate channel for the
notifs is implicit in the transport of the request to
establish-subscription.

In the case of UDP, I think the idea is that the
establish-subscription is sent over any protocol that can do RPCs
(NETCONF, RESTCONF, ...), but then some specific input parameter
informs the server that the notifs are supposed to be sent over some
other transport.

While reading the text about sessions, I found this:

In 2.4.3:

   The "modify-subscription" operation permits changing the terms of an
   existing dynamic subscription established on that transport session
   via "establish-subscription".

Which session does "that transport session" mean?  Perhaps simply:

NEW:

   The "modify-subscription" operation permits changing the terms of an
   existing dynamic subscription.

> > 2. The RPC does not have the input information about the receiver
> > because the
> > above assumption.
> > 
> While it likely isn't what you want, even with NETCONF, the single
> NETCONF session doesn't means that distributed line card generation of
> the notification messages is impossible.  For example, the inclusion
> of the header object message-generator-id (as defined within
> draft-ietf-netconf-notification-messages) allows the notification
> message generation to be distributed onto linecards even if the
> messages themselves are still driven back to a central transport
> session.  Note that I am not recommending this, but the specifications
> would support this.
> 
> I think for UDP, you will want to define a way to bind the lifecycle
> of the dynamic subscription's channels across multiple line cards.
> This will require some thinking as well as coordination within the
> publisher.

But this is an implementation detail.  However, it is true that the
specification must work out the fate-sharing details between the
session that sent the establish-subscription and the notif channel.
Just as in the "restconf" draft.

/martin

> Perhaps returning multiple URIs (one for each linecard) might be
> something which could make this easier.  If you go down this path, you
> still will need to fate-share the lifecycle of the subscription across
> all of those line cards.
> 
> Eric
>  
> > What's your thoughts?
> > 
> > Regards,
> > Tianran
>

---

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

Hi,

Another thing related to this.   You have:

   Receiver: A target to which a publisher pushes subscribed event
   records.  For dynamic subscriptions, the receiver and subscriber are
   the same entity.

But in the HTTP and UDP cases this last sentence is probably not true,
right?

Also, I have always struggled with the terms "publisher", "receiver",
"subscriber" vs. "client" and "server".

I think that a "subscriber" is always the "client".  If so, I think
this should be mentioned in 1.2 (and the term "client" imported from
RFC 8342).

Also, I think it would be useful to draw a picture that demonstrates
the roles:

      subscriber/client    receiver
          |                   ^
          | (1)               | (3)
          |                   |
          |                   |
          v        (2)        |
        server  ----------> publisher

(1) is creation of the subscriptionE; dynamic or configured
(2) is implementation specific
(3) is the delivery of notifications / event records

NOTE: the subscriber and receiver MAY be the same entity
NOTE: for some transports, if (1) is dynamic, (3) is sent over the
      same session as (1)
NOTE: for some transports, the sevrer and publisher are the same entity

If we can agree on an architectural picture like this, the different
transport docs can refer to this architecture and be defined related
to it.   For example, the netconf transport doc can state that the
publisher is always the same entity etc.

/martin

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Jun 2018 11:57:01 +0200

>       subscriber/client    receiver

So why do we need the distinct role of a publisher?

> publisher is always the same entity etc.

So we introduce the role of a publisher because of some transports
that do have a server? If the publisher is truely distinct entity from
the server (and the state it has), we may get interesting security
considerations to write.

/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: Tianran Zhou <[email-masked]>
Date: Thu, 14 Jun 2018 11:42:32 +0000

I am not sure if the figure 3 in draft-zhou-netconf-multi-stream-originators can help to explain.
In this distributed data collection scenario, each stream originator include two components. One for subscription, one for publication.

                  +-------------------------------------+
                  |      Collector      +-------------+ |
                  |                    +|-----------+ | |
                  |   +------------+   || Receiver  | <-----+
                  |   | Subscriber |   |+-------------+ |   |
                  |   +-^----+-----+   +------------+   |   |
                  |     |    |                |         |   |
                  +-------------------------------------+   |
             Global     |    |Global          | push        |
             Capability |    |Subscription    |             |
                  +-------------------------------------+   |
                  |     |    |   Master       |         |   |
                  |  +--+----v------+  +------+------+  |   |
                  |  | Subscription |  | Publisher   |  |   |
                  |  | Server       |  |             |  |   |
                  |  +--^----+------+  +-------------+  |   |
                  |     |    |                          |   |
                  +-------------------------------------+   |
             Component  |    | Component               push |
             Capability |    | Subscription                 |
                  +-------------------------------------+   |
                  |     |    |   Agent                  |   |
                  |  +--+----v------+  +-------------+  |   |
                  |  | Component    |  | Publisher   |  |   |
                  |  | Subscription |  |             +------+
                  |  | Server       |  +-------------+  |
                  |  +--------------+                   |
                  +-------------------------------------+

         Fig. 3 The Generic Distributed Data Collection Framework

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Thursday, June 14, 2018 5:57 PM
> To: Martin Bjorklund <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Netconf] a joint discussion on dynamic subscription
> 
> So we introduce the role of a publisher because of some transports that do
> have a server? If the publisher is truely distinct entity from the server
> (and the state it has), we may get interesting security considerations to
> write.
> 
> /js
> 
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Jun 2018 14:05:55 +0200

Well, if I fail to understand four terms, it usually does not help me
much to add a couple of additional terms that I do not understand
either. Note that device internal mechanisms likely should remain
device internal implementation details and not subject to any
standardization. Whether this applies to your figure or not, I do not
know (since I do not know what the figure tells me, see first remark).

/js

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 14 Jun 2018 12:38:01 +0000

Hi,

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Thursday, June 14, 2018 3:18 PM
> To: [email-masked]
> Cc: Tianran Zhou <[email-masked]>; Alexander Clemm
> <[email-masked]>; Zhengguangying (Walker)
> <[email-masked]>; [email-masked]
> Subject: Re: a joint discussion on dynamic subscription
> 
> Hi,
> 
> > > When we are discussing the draft-ietf-netconf-udp-pub-channel, we
> > > find a conflict with current dynamic subscription design.
> > > channel as the subscription.
> >
> In the case of RESTCONF, decision to use a separate channel for the notifs
> is implicit in the transport of the request to establish-subscription.
> 
> In the case of UDP, I think the idea is that the establish-subscription is
> sent over any protocol that can do RPCs (NETCONF, RESTCONF, ...), but then
> some specific input parameter informs the server that the notifs are supposed
> to be sent over some other transport.

Yes. I did not see this is the current RPC. Maybe similar the configured subscription, to describe transport of the receiver.

> > > because the above assumption.
> > >
> > > However, when we talk about the distributed data collection (multi
> > > data originators), the publication channel is always different from
> > > the subscription channel.
> >
> specification must work out the fate-sharing details between the session that
> sent the establish-subscription and the notif channel.

We can just describe this fate-sharing requirement explicitly in the document. On implementation, I do not think it's hard to bind the lifecycle of the subscription channel and the publication channel.

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Jun 2018 15:38:24 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> that do have a server?

I assume you mean "do not".  Yes, that's my understanding.  But I
might be wrong.  Eric and Alex?

> If the publisher is truely distinct entity from

Isn't this what the UDP transport does?  It uses a NETCONF/RESTCONF
server to set up the subscription, then UDP to send the notifications.

/martin

---

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

> From: Martin Bjorklund, June 14, 2018 3:18 AM
>
> Hi,
> 
> Cool!  I think that this should be explcitly described in the subscribed-
> notifications document.

Right now it is explicitly described in the RESTCONF-notif draft.  But I see your point on adding it as guidance for future transports like Tianran's.  So I added the following to the "Transport Requirements" (section 5.3):

A specific transport specification built upon this document may or may not choose to require the use of the same logical channel for the RPCs and the event records.  However the event records and the subscription state notifications MUST be sent on the same transport session to ensure the properly ordered delivery.

> In the case of RESTCONF, decision to use a separate channel for the notifs is
> implicit in the transport of the request to establish-subscription.
> 
> In the case of UDP, I think the idea is that the establish-subscription is sent
> over any protocol that can do RPCs (NETCONF, RESTCONF, ...), but then some
> specific input parameter informs the server that the notifs are supposed to be
> sent over some other transport.
> 

Change made.  

As this change does impact NETCONF-notif, I placed the following requirement in that document's "Dynamic Subscription" section.

For a dynamic subscription a "modify-subscription", "delete-subscription", or "resynch-subscription" RPC MUST be sent using same the NETCONF session upon which the referenced subscription was established.".

Eric

> But this is an implementation detail.  However, it is true that the specification
> must work out the fate-sharing details between the session that sent the
> establish-subscription and the notif channel.

---

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

> From: Tianran Zhou, June 14, 2018 8:38 AM
> 
> Hi,
> 
> > > this is *not* required by the base subscribed-notification draft.
> > > And in fact, the HTTP transport draft might not use the same logical
> > > https://github.com/netconf-wg/notif-restconf/blob/master/draft-ietf-
> > > ne
> > > tconf-restconf-notif-05.txt
> > >
> > notifs is implicit in the transport of the request to establish-subscription.
> >
> > informs the server that the notifs are supposed to be sent over some other
> transport.
> 
> Yes. I did not see this is the current RPC. Maybe similar the configured
> subscription, to describe transport of the receiver.

draft-ietf-netconf-restconf-notif contains a YANG model and examples showing how transport specific parameters can be augmented to the "establish-subscription RPC".  Search the document for "URI".

On other addition...  Several months ago we chatted that the multi-channel line-card separation and the UDP transport might be supported by different YANG models.  This should allow any parameters needed for multi-line card to be supportable without also requiring the corresponding implementation to also support UDP transport.

Eric

> > > > data originators), the publication channel is always different
> > > > from the subscription channel.
> > >
> > > NETCONF session doesn't means that distributed line card generation
> > > of the notification messages is impossible.  For example, the
> > > inclusion of the header object message-generator-id (as defined
> > > within
> > > session.  Note that I am not recommending this, but the
> > > specifications would support this.
> > >
> We can just describe this fate-sharing requirement explicitly in the document.
> On implementation, I do not think it's hard to bind the lifecycle of the
> subscription channel and the publication channel.
> 
> > /martin
> >
> >
> >
> > > something which could make this easier.  If you go down this path,
> > > you still will need to fate-share the lifecycle of the subscription
> > > across all of those line cards.
> > >
> > > Eric
> > >
> > > > What's your thoughts?
> > > >
> > > > Regards,
> > > > Tianran
> > >

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 14 Jun 2018 15:04:01 +0000

> From: Martin Bjorklund, June 14, 2018 9:38 AM

> Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

> > > NOTE: for some transports, the sevrer and publisher are the same

> > > entity

> > So why do we need the distinct role of a publisher?

I would argue that the server and publisher are the same (see below for why).  If this is true perhaps we could define the term "distributed publisher" which matches to the term "Subscribed Domain" in draft-ietf-netconf-udp-pub-channel.  A distributed publisher would be a type of publisher, inheriting all requirements for that device from subscribed-notifications.

If this is acceptable, then (2) is an implementation detail which can be hidden.  This addresses Juergen's comment that having (2) inserts error conditions which might need to be understood by the outside world.   My mental model for udp on mult-linecard  (when building on the terminology of subscribed-notifications) would be something like:

       subscriber        receiver

           |             ^     ^

           | (1)         | (3) |

            |             |     |

        .---V-------------|-----|-------.

       | .------.  .-------. .-------. |

       | |master|  | agent | | agent | |

        | '------'  '-------' '-------' |

       |    distributed  publisher     |

        '-------------------------------'

Note that this is very close to figure 1 of the UDP draft.  The difference is that it gets rid of the 's' in Agents and Receivers.  And turns subscribed domain into a single publisher.  This allows the hiding of error states between master and agent.

Note that this is different than the distribution of terms within draft-zhou-netconf-multi-stream-originators.  And some work would be needed there to merge the terminology.

> I assume you mean "do not".  Yes, that's my understanding.  But I might be

> wrong.  Eric and Alex?

The term "server" is only used once in draft-ietf-netconf-udp-pub-channel.   And then it refers to "push server".  I am assuming the "push server" is a publisher.  Based on this, I do believe we can get away from using the term "server".

Eric

> > If the publisher is truely distinct entity from the server (and the

> > state it has), we may get interesting security considerations to

> Isn't this what the UDP transport does?  It uses a NETCONF/RESTCONF server

> to set up the subscription, then UDP to send the notifications.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 14 Jun 2018 15:28:30 +0000

> From: Martin Bjorklund, June 14, 2018 4:38 AM
> 
> Hi,
> 
> But in the HTTP and UDP cases this last sentence is probably not true, right?
> 
> I think that a "subscriber" is always the "client".  If so, I think this should be
> mentioned in 1.2 (and the term "client" imported from RFC 8342).

The subscriber need not always the transport client.  This is dependent on the transport selected.  For example in the RESTCONF draft for configured subscriptions, the HTTP client is the Publisher, and the HTTP server is the receiver.  See section 4.2 & Figure 3 of draft-ietf-netconf-restconf-notif.   

For draft-ietf-netconf-udp-pub-channel draft, I can see the possibility of transport client session being initiated from the line cards.

Eric
 
> Also, I think it would be useful to draw a picture that demonstrates the roles:
> 
> If we can agree on an architectural picture like this, the different transport
> docs can refer to this architecture and be defined related
> > > netconf-restconf-notif-05.txt
> > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Jun 2018 17:31:53 +0200

> I would argue that the server and publisher are the same (see below for why).  If this is true perhaps we could define the term "distributed publisher" which matches to the term "Subscribed Domain"…

If A and B are the same, why do we need to introduce C?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Jun 2018 17:33:36 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> > this should be
> The subscriber need not always the transport client.  This is
> dependent on the transport selected.  For example in the RESTCONF
> draft for configured subscriptions, the HTTP client is the Publisher,
> and the HTTP server is the receiver.  See section 4.2 & Figure 3 of
> draft-ietf-netconf-restconf-notif.

How does this change the fact that the subscriber is the client (RFC
8342 term)?

> For draft-ietf-netconf-udp-pub-channel draft, I can see the
> possibility of transport client session being initiated from the line
> cards.

Right, that's why I assumed there is a separation between server and
publisher.  "server" again in RFC 8342 terms.  It is the server for
establish-subscription or the server where configured subscriptions
are managed.

/martin

> > transport

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 14 Jun 2018 15:35:48 +0000

> From: Juergen Schoenwaelder, June 14, 2018 11:32 AM
> 
> > I would argue that the server and publisher are the same (see below for
> why).  If this is true perhaps we could define the term "distributed publisher"
> which matches to the term "Subscribed Domain" in draft-ietf-netconf-udp-
> pub-channel.  A distributed publisher would be a type of publisher, inheriting
> all requirements for that device from subscribed-notifications.
> >
> 

I don't think it is required to introduce "C".  It is just that "C" might be a valid subset of {A/B}.  We can let the authors assert whether this valid subset requires a new term.

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Jun 2018 17:36:52 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> > Juergen Schoenwaelder
> > <[email-masked]<mailto:[email-masked]>>
> > wrote:
> 
> I would argue that the server and publisher are the same (see below
> for why).  If this is true perhaps we could define the term
> "distributed publisher"

I'd say that if this is true, let's use the term "server" (RFC 8342)
and do not introduce new terms!

> which matches to the term "Subscribed Domain"
> in draft-ietf-netconf-udp-pub-channel.  A distributed publisher would
> be a type of publisher, inheriting all requirements for that device
> from subscribed-notifications.
> 
> 
> 
> If this is acceptable, then (2) is an implementation detail which can
> be hidden.  This addresses Juergen's comment that having (2) inserts
> error conditions which might need to be understood by the outside
> world.  My mental model for udp on mult-linecard (when building on the
> terminology of subscribed-notifications) would be something like:
> 
> 
> 
>        subscriber        receiver
> 
>            |             ^     ^
> 
>            | (1)         | (3) |
> 
>             |             |     |
> 
> Note that this is very close to figure 1 of the UDP draft.  The
> difference is that it gets rid of the 's' in Agents and Receivers.
> And turns subscribed domain into a single publisher.  This allows the
> hiding of error states between master and agent.
> 
> 
> Note that this is different than the distribution of terms within
> draft-zhou-netconf-multi-stream-originators.  And some work would be
> needed there to merge the terminology.
> 
> 
> 
> > might be
> The term "server" is only used once in
> draft-ietf-netconf-udp-pub-channel.  And then it refers to "push
> server".  I am assuming the "push server" is a publisher.  Based on
> this, I do believe we can get away from using the term "server".

Again, I think it is useful to use terms that already exists.  So if
publisher and server means the same thing, let's stick to server.

/martin

> > server

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 14 Jun 2018 15:43:05 +0000

> From: Martin Bjorklund, June 14, 2018 11:34 AM
> 
> > > Also, I have always struggled with the terms "publisher",
> > > "receiver", "subscriber" vs. "client" and "server".
> > >

On that point, I was just trying to limit the use of the word "client", as it has so many meanings already.

Beyond the many meanings of client, there is another reason why a subscriber isn't necessarily an RFC8342 client.  The RFC8342 definition of client is based on YANG data.  As event streams might not be YANG data, this definition isn't a full match for what is covered by subscribed-notifications.  (However it would be a match for a YANG-Push subscriber.)

Eric
 
> Right, that's why I assumed there is a separation between server and publisher.
> "server" again in RFC 8342 terms.  It is the server for establish-subscription or
> the server where configured subscriptions are managed.
> 
> 
> /martin
> 
> 
> >
> > Eric
> >
> > > > > > When we are discussing the draft-ietf-netconf-udp-pub-channel,
> > > > > > we find a conflict with current dynamic subscription design.
> > > > > This is true when you look at the NETCONF transport draft.
> > > > > However this is *not* required by the base subscribed-notification
> draft.
> > > > > And in fact, the HTTP transport draft might not use the same
> > > > > logical channel.  E.g., see how the URI is returned within:
> > > > > So if you wanted to define some transport session independence
> > > > > for a UDP transport, subscribed-notifications should permit
> > > > > that.  And if you believe there is something in the text which
> > > > > prohibits this, let me know.
> > > >
> > > > In the case of RESTCONF, decision to use a separate channel for
> > > > the notifs is implicit in the transport of the request to
> > > > establish-subscription.
> > > >
> > > > informs the server that the notifs are supposed to be sent over
> > > > some other transport.
> > > >
> > > > > > However, when we talk about the distributed data collection
> > > > > > (multi data originators), the publication channel is always
> > > > > > different from the subscription channel.
> > > > >
> > > > > While it likely isn't what you want, even with NETCONF, the
> > > > > single NETCONF session doesn't means that distributed line card
> > > > > generation of the notification messages is impossible.  For
> > > > > example, the inclusion of the header object message-generator-id
> > > > > (as defined within
> > > > > draft-ietf-netconf-notification-messages) allows the
> > > > > notification message generation to be distributed onto linecards
> > > > > even if the messages themselves are still driven back to a
> > > > > central transport session.  Note that I am not recommending
> > > > > this, but the specifications would support this.
> > > > >
> > > > > > So either the distributed data collection does not support
> > > > > > dynamic subscription, or current dynamic subscription
> > > > > > definition may need modification.
> > > > >
> > > > > I think for UDP, you will want to define a way to bind the
> > > > > lifecycle of the dynamic subscription's channels across multiple line
> cards.
> > > > > This will require some thinking as well as coordination within
> > > > > the publisher.
> > > >
> > > > But this is an implementation detail.  However, it is true that
> > > > the specification must work out the fate-sharing details between
> > > > the session that sent the establish-subscription and the notif channel.
> > > > > something which could make this easier.  If you go down this
> > > > > path, you still will need to fate-share the lifecycle of the
> > > > > subscription across all of those line cards.
> > > > >
> > > > > Eric
> > > > >
> > > > > > What's your thoughts?
> > > > > >
> > > > > > Regards,
> > > > > > Tianran
> > > > >
> > > >

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Jun 2018 19:17:52 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> On that point, I was just trying to limit the use of the word
> "client", as it has so many meanings already.
> 
> Beyond the many meanings of client, there is another reason why a
> subscriber isn't necessarily an RFC8342 client.  The RFC8342
> definition of client is based on YANG data.  As event streams might
> not be YANG data, this definition isn't a full match for what is
> covered by subscribed-notifications.

Your definition is:

   Subscriber: An entity able to request and negotiate a contract for
   the generation and push of event records from a publisher.

How can this NOT be a client, in the 8342 meaning?  AFAICT, the
subscriber can either set up a dynamic subscription, using
establish-subscription.  This is certainly a "client".  Or it can set
up a configured subscription, by creating configuration in the
/subscriptions/subscription list.  This is also a "client".

I do understand that the *receiver* may not be a client.

/martin

(However it would be a match
> for a YANG-Push subscriber.)
> 
> Eric
>

---

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

> From: Martin Bjorklund, June 14, 2018 1:18 PM
> 
> > > > > I think that a "subscriber" is always the "client".  If so, I
> > > > > think this should be mentioned in 1.2 (and the term "client"
> > > > > imported from RFC 8342).
> > > >
> > > > draft for configured subscriptions, the HTTP client is the
> > > > Publisher, and the HTTP server is the receiver.  See section 4.2 &
> > > > Figure 3 of draft-ietf-netconf-restconf-notif.
> > >
> How can this NOT be a client, in the 8342 meaning?  AFAICT, the subscriber can
> either set up a dynamic subscription, using establish-subscription.  This is
> certainly a "client".  Or it can set up a configured subscription, by creating
> configuration in the /subscriptions/subscription list.  This is also a "client".

In RFC-8341, the term client is defined as:

   o  client: An entity that can access YANG-defined data on a server,
      over some network management protocol.

As an event stream might not include YANG-defined data, the definition didn't seem to fit.

If we wanted to import the term RFC8342 term client, we could do in YANG-push.  There we could say that a subscriber to a YANG datastore is covered by the RFC-8342 definition of client.   

Would this cover your concern?

Eric

> > > > possibility of transport client session being initiated from the
> > > > line cards.
> > >
> > > "server" again in RFC 8342 terms.  It is the server for
> > > establish-subscription or the server where configured subscriptions are
> managed.
> > >
> > >
> > > /martin
> > >
> > >
> > > >
> > > > Eric
> > > >
> > > > > If we can agree on an architectural picture like this, the
> > > > > different transport docs can refer to this architecture and be defined
> related
> > > > > > > https://github.com/netconf-wg/notif-restconf/blob/master/dra
> > > > > > > ft-i
> > > > > > > etf-
> > > > > > > So if you wanted to define some transport session
> > > > > > > independence for a UDP transport, subscribed-notifications
> > > > > > > should permit that.  And if you believe there is something
> > > > > > > in the text which prohibits this, let me know.
> > > > > >
> > > > > > In the case of RESTCONF, decision to use a separate channel
> > > > > > for the notifs is implicit in the transport of the request to
> > > > > > establish-subscription.
> > > > > >
> > > > > > establish-subscription is sent over any protocol that can do
> > > > > > RPCs (NETCONF, RESTCONF, ...), but then some specific input
> > > > > > parameter informs the server that the notifs are supposed to
> > > > > > be sent over some other transport.
> > > > > >
> > > > > > > > However, when we talk about the distributed data
> > > > > > > > collection (multi data originators), the publication
> > > > > > > > channel is always different from the subscription channel.
> > > > > > >
> > > > > > > single NETCONF session doesn't means that distributed line
> > > > > > > card generation of the notification messages is impossible.
> > > > > > > For example, the inclusion of the header object
> > > > > > > message-generator-id (as defined within
> > > > > > > notification message generation to be distributed onto
> > > > > > > linecards even if the messages themselves are still driven
> > > > > > > back to a central transport session.  Note that I am not
> > > > > > > recommending this, but the specifications would support this.
> > > > > > >
> > > > > > > This will require some thinking as well as coordination
> > > > > > > within the publisher.
> > > > > >
> > > > > > But this is an implementation detail.  However, it is true
> > > > > > that the specification must work out the fate-sharing details
> > > > > > between the session that sent the establish-subscription and the notif
> channel.
> > > > > > > Perhaps returning multiple URIs (one for each linecard)
> > > > > > > might be something which could make this easier.  If you go
> > > > > > > down this path, you still will need to fate-share the
> > > > > > > lifecycle of the subscription across all of those line cards.
> > > > > > >
> > > > > > > Eric
> > > > > > >
> > > > > > > > What's your thoughts?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Tianran
> > > > > > >
> > > > > >

---

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

"Eric Voit (evoit)" <[email-masked]> wrote:
> > subscriber can 

But the subscriber doesn't even see content from any event stream, so
how does this matter?  An entity that sends the RPC
"establish-subscription" *is* a "client".

> If we wanted to import the term RFC8342 term client, we could do in
> YANG-push.  There we could say that a subscriber to a YANG datastore
> is covered by the RFC-8342 definition of client.
> 

No, see above.

/martin

---

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

> From: Martin Bjorklund, June 14, 2018 2:14 PM
>
> > > > > > > I think that a "subscriber" is always the "client".  If so,
> > > > > > > I think this should be mentioned in 1.2 (and the term "client"
> > > > > > > imported from RFC 8342).
> > > > > >
> > > > > > dependent on the transport selected.  For example in the
> > > > > > RESTCONF draft for configured subscriptions, the HTTP client
> > > > > > is the Publisher, and the HTTP server is the receiver.  See
> > > > > > section 4.2 & Figure 3 of draft-ietf-netconf-restconf-notif.
> > > > >
> > > > definition of client is based on YANG data.  As event streams
> > > > might not be YANG data, this definition isn't a full match for
> > > > what is covered by subscribed-notifications.
> > >
> > > Your definition is:
> > >
> > > establish-subscription.  This is certainly a "client".  Or it can
> > > set up a configured subscription, by creating configuration in the
> But the subscriber doesn't even see content from any event stream, so how
> does this matter?  An entity that sends the RPC "establish-subscription" *is* a
> "client".

Hmm.  So your augment is that as the subscriber never receives event records (this is always the receiver), then even a subscribed-notifications subscriber is a valid RFC-8342 client.   

As not all clients are subscribers. I can see where it could be useful to make this correlation within subscribed-notifications.  To support this, are you good with a tweak of the definition of Subscriber to:

OLD
An entity able to request and negotiate a contract for the generation and push of event records from a publisher.  For dynamic subscriptions, the receiver and subscriber are the same entity.

NEW
An RFC-8342 client able to request and negotiate a contract for the generation and push of event records from a publisher.  For dynamic subscriptions, the receiver and subscriber are the same entity.

Eric
 
> > > > > > possibility of transport client session being initiated from
> > > > > > the line cards.
> > > > >
> > > > > > > > > > 1. The dynamic subscription requires notification to
> > > > > > > > > > use the same channel as the subscription.
> > > > > > > > >
> > > > > > > > > And in fact, the HTTP transport draft might not use the
> > > > > > > > > same logical channel.  E.g., see how the URI is returned within:
> > > > > > > > > independence for a UDP transport,
> > > > > > > > > subscribed-notifications should permit that.  And if you
> > > > > > > > > believe there is something in the text which prohibits this, let
> me know.
> > > > > > > >
> > > > > > > > Cool!  I think that this should be explcitly described in
> > > > > > > > the subscribed-notifications document.
> > > > > > > >
> > > > > > > > In the case of RESTCONF, decision to use a separate
> > > > > > > > channel for the notifs is implicit in the transport of the
> > > > > > > > request to establish-subscription.
> > > > > > > >
> > > > > > > > establish-subscription is sent over any protocol that can
> > > > > > > > do RPCs (NETCONF, RESTCONF, ...), but then some specific
> > > > > > > > input parameter informs the server that the notifs are
> > > > > > > > supposed to be sent over some other transport.
> > > > > > > >
> > > > > > > >    The "modify-subscription" operation permits changing
> > > > > > > > the terms of
> > > an
> > > > > > > >    The "modify-subscription" operation permits changing
> > > > > > > > the terms of
> > > an
> > > > > > > > > > 2. The RPC does not have the input information about
> > > > > > > > > > the receiver because the above assumption.
> > > > > > > > > >
> > > > > > > > > While it likely isn't what you want, even with NETCONF,
> > > > > > > > > the single NETCONF session doesn't means that
> > > > > > > > > distributed line card generation of the notification messages is
> impossible.
> > > > > > > > > linecards even if the messages themselves are still
> > > > > > > > > driven back to a central transport session.  Note that I
> > > > > > > > > am not recommending this, but the specifications would support
> this.
> > > > > > > > >
> > > > > > > > > > So either the distributed data collection does not
> > > > > > > > > > support dynamic subscription, or current dynamic
> > > > > > > > > > subscription definition may need modification.
> > > > > > > > >
> > > > > > > > > I think for UDP, you will want to define a way to bind
> > > > > > > > > the lifecycle of the dynamic subscription's channels
> > > > > > > > > across multiple line
> > > > > cards.
> > > > > > > > that the specification must work out the fate-sharing
> > > > > > > > details between the session that sent the
> > > > > > > > > might be something which could make this easier.  If you
> > > > > > > > > go down this path, you still will need to fate-share the

---

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

> An RFC-8342 client able to request and negotiate a contract for the generation and push of event records from a publisher.  For dynamic subscriptions, the receiver and subscriber are the same entit…

I would import the term "client" from 8342, and then just write "A
client able to ...".

/martin