Re: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?

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

Adding Einar as he had some strong opinions on this a few years ago when we were setting the model...


> From: Martin Bjorklund, November 15, 2017 10:43 AM
> 
> "Eric Voit (evoit)" <[e-mail]> wrote:
> > Hi Martin,
> >
> > > From: Martin Bjorklund [mailto:[e-mail]]
> > >
> > > "Eric Voit (evoit)" <[e-mail]> wrote:
> > > > In the WG session tomorrow, I am hoping to get "hum feedback" on:
> > > >
> > > >
> > > >
> > > > draft-ietf-netconf-subscribed-notifications
> > > >
> > > > https://github.com/netconf-wg/rfc5277bis/issues/4
> > > >
> > > >
> > > >
> > > > The two choices and their issues exposed during the two week
> > > > review on
> > > "Can Transport vary across different receivers of a single
> > > configured subscription?" are:
> > > >
> > > >
> > > >
> > > > (1) Yes, Transport can vary by receiver
> > > >
> > > > *        Fewer subscriptions (scale benefit)
> > > >
> > > > *        Can convert transport without requiring an application to learn
> a
> > > multiple subscription ids
> > > >
> > > > *        No duplication of content during transport conversion.
> > > >
> > > > *        (Potential confusion in allowing transport to vary, but encoding
> not
> > > to vary?)
> > > >
> > > >
> > > >
> > > > (2) No, only one Transport across all subscriptions
> > > >
> > > > *        Simpler model
> > > >
> > > > *        But applications may need to create and track multiple
> > > subscription-ids for the same content.
> > > >
> > > > *        Temporary duplication of content streams during transport
> change.
> > > >
> > > >
> > > >
> > > > The current draft does (1).
> > >
> > > Actually, the github issue lists 3 options, but here you just list 2.
> >
> > In reviewing tomorrow's slides with Mahesh, he preferred 2 options.
> > And as varying the encoding by receiver seems unlikely in
> > implementation
> 
> Why is this unlikely?  Suppose I have two receivers for the same
> subscription, one wants NETCONF/XML and the other RESTCONF/JSON.  Is
> that unlikely?

Einar's belief was that a publisher implementation would be unlikely to service a single subscription into multiple encodings.   If such a condition existed, it would be far easier to create two subscriptions.  This also would have fewer error conditions.
 
> > , there is little reason to socialize this unlikely variant before
> > the whole WG.   Since as your opinion was either both encoding and
> > transport or neither encoding and transport vary by receiver, the more
> > likely of your primary ask is supported.
> >
> >
> > > I think the point is that in the term "Transport", we need to
> > > include both protocol and encoding (in the case the protocol
> > > supports multiple encodings).
> >
> > While most likely the case for NETCONF and RESTCONF, Tianran's
> > draft-ietf-netconf-udp-pub-channel shows that there can be encoding
> > variation by transports .   It Therefore it seems better to let them
> > both vary independently.
> 
> Not sure I understand what you mean.  To be clear, do you think the
> "encoding" leaf should stay where it is, or be moved down to the receiver,
> as a sibling to "protocol"?

Encoding leaf should stay where it is.   Your previous ask was to put encoding and transport and the same level. There is an option proposed in the slides which does that.

Eric

> /martin