Re: [Netconf] a joint discussion on dynamic subscription

[Martin Bjorklund <[e-mail]>]

"Eric Voit (evoit)" <[e-mail]> wrote:
> > From: Martin Bjorklund, June 14, 2018 9:38 AM
> 
> >
> 
> > Juergen Schoenwaelder
> > <[e-mail]<mailto:[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?
> 
> 
> 
> 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) |
> 
>             |             |     |
> 
>         .---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.
> 
> 
> 
> > > > 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?
> 
> 
> 
> 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


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