Re: [Netconf] netconf-binary-encoding comments

On Thu, Jul 5, 2018 at 10:06 AM, Kent Watsen <kwatsen@juniper.net> wrote:

>
>
> > When I brought up this issue 5 years ago there was zero interest in
> improving
>
> > the efficiency of NETCONF. Maybe YANG Push will change that POV.
>
>
>
> I agree that there is little appetite to improve the efficiency of
> configuration-oriented
>
> workflows.   Monitoring, for which notifications supports in a big way,
> have a strong
>
> push for efficiency.  I think the primary question is if this efficiency
> must be realizable
>
> for NC/RC based subscriptions, or if the efficiency can come from the use
> of more
>
> suitable transports (e.g., gRPC), that can be defined by future "notif"
> drafts?
>
>
>
> If we were only interested in such efficiency for configured
> subscriptions, then I think
>
> a "notif" draft to define the transport would be relatively easy.   If
> such efficiency is
>
> also needed for dynamic subscriptions, then it seems like something along
> the lines
>
> of what binary-encoding draft proposes might be needed.
>
>
>
> Is there a need for efficiency for any other workflow?   What about for
> RPCs that are
>
> executed often (e.g., polling) or return very large responses?   Does we
> care about
>
> making these use cases more efficient too, or are we primarily only
> interested in
>
> just making notifications efficient?
>
>
>

RESTCONF/HTTP has the ability to change message encoding on every message,
but I have never seen it used this way.  Client developers pick XML or JSON
as the
preferred media type (in the Accept header) and do not change it.
So the idea that a client will use XML when it expects short replies,
and use binary when it expects long replies does not make sense.
It is possible a notif-only solution is all that is needed for NETCONF.

Kent
>

Andy

>
>
>
>
>
>
> On 7/5/18, 12:07 PM, "Netconf on behalf of Andy Bierman" <
> netconf-bounces@ietf.org on behalf of andy@yumaworks.com> wrote:
>
>
>
> Hi,
>
>
>
> I think the first-order issue is for the WG to decide if there is a
> problem to be
>
> solved by this WG, and if so, what is the problem scope.
>
>
>
> Details like the SID assignments for rpc, rpc-reply, etc do not really
> impact that decision.
>
>
>
> When I brought up this issue 5 years ago there was zero interest in
> improving the
>
> efficiency of NETCONF. Maybe YANG Push will change that POV.
>
>
>
> https://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-00
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbierman-2Dnetconf-2Defficiency-2Dextensions-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=oAFOh8ZwuiodqCiPKKq5-n9X4-VYRoFJXIfDMi8vvJs&s=rPGpbkoE7L63ymXNzHmAKazwljYuJVs3pa2Pf1arT-A&e=>
>
>
>
> I think this draft should focus on the protocol mechanisms and not define
>
> any media types. Definitions of GPB and other formats are not trivial and
> need
>
> their own RFCs.
>
>
>
>
>
> Andy
>
>
>
>
>
> On Thu, Jul 5, 2018 at 8:07 AM, Balazs Lengyel <
> balazs.lengyel@ericsson.com> wrote:
>
> Hello,
> Is this applicable for Restconf? Would a Restconf binary encoding be
> interesting?
>
> Chapter 2)
>
> - A more detailed explanation of which parts are encoded would be good.
> What is the top XML element that will be encoded? <rpc>, <RPC-reply>,
> <RPC-error>, <notification> ? Just referencing a figure in another draft is
> not enough.
>
> - SHOULD, SHALL or SHALL NOT a client server declare support for the XML
> encoding? Is that always implicit? State it.
>
> 4.2) Shouldn't we also have a JSON encoding here?
>
> I would think that all encodings need some official reference, defining
> how they are used with YANG: RFC, web link
>
> Is the Thrift and gpb encoding trivial or is it described somewhere or do
> we need an RFC about it? Please state whichever is the case.
>
> regards Balazs
>
>
>
>
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs..Lengyel@ericsson.com
> <Balazs.Lengyel@ericsson.com>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=oAFOh8ZwuiodqCiPKKq5-n9X4-VYRoFJXIfDMi8vvJs&s=g9t4wEhl67_O_ZmVRrFI1qv3g4UdY2tUiwYOV3Xny0o&e=>
>
>
>