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

[Martin Bjorklund <[e-mail]>]

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

> , 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"?


/martin