Re: [Netconf] a joint discussion on dynamic subscription

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

On Thu, Jun 14, 2018 at 11:42:32AM +0000, Tianran Zhou wrote:
> 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:netconf-bounces@ietf.org] On Behalf Of Juergen
> > Schoenwaelder
> > Sent: Thursday, June 14, 2018 5:57 PM
> > To: Martin Bjorklund <mbj@tail-f.com>
> > Cc: netconf@ietf.org
> > Subject: Re: [Netconf] a joint discussion on dynamic subscription
> > 
> > On Thu, Jun 14, 2018 at 10:37:46AM +0200, Martin Bjorklund wrote:
> > >
> > > 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
> > 
> > So why do we need the distinct role of a publisher?
> > 
> > > 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.
> > 
> > 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/>
> > 
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf

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