Re: [Netconf] netconf-binary-encoding comments

I want to see transaction efficiency can be improved together with NETCONF efficiency, e.g., multiple operations can be
handled as a work flow in sequence or in parallel. In some case, the output of one operation can be input of another operation,
in some other cases, in parallel operations have no interference with each other.

In addition, we have some idea to improve RPC efficiency before, but that require the client and sever to be stateful.
We didn’t bring it up for some reasons. Whether we focus on rpc efficiency or notification efficiency,
I hope they are transport independent.

-Qin
发件人: Netconf [mailto:netconf-bounces@ietf.org] 代表 Kent Watsen
发送时间: 2018年7月6日 1:06
收件人: Andy Bierman; Balazs Lengyel
抄送: netconf@ietf.org
主题: Re: [Netconf] netconf-binary-encoding comments

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

Kent

On 7/5/18, 12:07 PM, "Netconf on behalf of Andy Bierman" <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org> on behalf of andy@yumaworks.com<mailto: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<mailto: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<mailto:Balazs.Lengyel@ericsson.com>

_______________________________________________
Netconf mailing list
Netconf@ietf.org<mailto: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=>