Re: [Netconf] a joint discussion on dynamic subscription

["Eric Voit (evoit)" <[e-mail]>]

> 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" 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".

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