From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>, "Einar Nilsen-Nygaard (einarnn)"
 <einarnn@cisco.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] Issue SN #4: Can Transport vary across different
 receivers of a single configured subscription?
Thread-Index: AdNdw8aKy+YwdoNoSQ+TUlgDzy0olQAXxPeAAAB8W7AAC1/ogAABuWFw
Date: Wed, 15 Nov 2017 21:53:28 +0000
Message-ID: <7da6319e524f4c6b85652c0fdaf6644c@XCH-RTP-013.cisco.com>
References: <868e65f523c04a38b696649cfaec3666@XCH-RTP-013.cisco.com>
 <20171115.110311.268174371353663424.mbj@tail-f.com>
 <4f48c351c272493eb4d3e5efc8730615@XCH-RTP-013.cisco.com>
 <20171115.164247.1419508866071356464.mbj@tail-f.com>
In-Reply-To: <20171115.164247.1419508866071356464.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/NWobwRwVSzeyZTFMTuLjD7hpsDo>
Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different
 receivers of a single configured subscription?
Precedence: list

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
>=20
> "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > Hi Martin,
> >
> > > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > >
> > > "Eric Voit (evoit)" <evoit@cisco.com> 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 en=
coding
> 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
>=20
> 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 ser=
vice a single subscription into multiple encodings.   If such a condition e=
xisted, it would be far easier to create two subscriptions.  This also woul=
d have fewer error conditions.
=20
> > , 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.
>=20
> 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 encod=
ing and transport and the same level. There is an option proposed in the sl=
ides which does that.

Eric

> /martin