Re: [Netconf] a joint discussion on dynamic subscription

[Martin Bjorklund <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> wrote:
> 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?

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
> the server (and the state it has), we may get interesting security
> considerations to write.

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