Subject: [Netconf] netconf-binary-encoding comments

From: Balazs Lengyel <[email-masked]>
Date: Thu, 5 Jul 2018 17:07:42 +0200

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: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Jul 2018 09:07:01 -0700

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

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 <[email-masked]>
wrote:

> <RPC-error>, <notification> ? Just referencing a figure in another draft is
> not enough.
>
> 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
>
>
>
>
>
> --
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 5 Jul 2018 17:06:27 +0000

> 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" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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.

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: [email-masked]<mailto:[email-masked]>

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
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=>

---

From: Qin Wu <[email-masked]>
Date: Fri, 6 Jul 2018 09:03:41 +0000

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:[email-masked]] 代表 Kent Watsen
发送时间: 2018年7月6日 1:06
收件人: Andy Bierman; Balazs Lengyel
抄送: [email-masked]
主题: Re: [Netconf] netconf-binary-encoding comments

Kent

Hi,

Andy

Chapter 2)

regards Balazs

---

From: Robert Wilton <[email-masked]>
Date: Fri, 6 Jul 2018 10:17:55 +0100

> solved by this WG, and if so, what is the problem scope.
+1.

I actually wonder whether extending RESTCONF wouldn't be a more 
efficient path here.  Adding support for CBOR to RESTCONF looks like it 
would be much easier than adding it to NETCONF.

But then, it is unclear to me what the long term relationship between 
NETCONF and RESTCONF is meant to be.

Thanks,
Rob

> On Thu, Jul 5, 2018 at 8:07 AM, Balazs Lengyel 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello,
>     - 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.
>
>     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
>
>
>
>
>
>     -- 
>     Mobile: +36-70-330-7909              email:
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netconf>
>
>
>
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 6 Jul 2018 15:58:59 +0000

Over in the Core WG, there is a new draft which intersects CBOR, YANG Push in the context of CoAP:

https://tools.ietf.org/html/draft-birkholz-yang-core-telemetry-00.txt

So as other groups are looking at this space, a position by the WG would seem timely.

Eric

From: Robert Wilton, July 6, 2018 5:18 AM

I actually wonder whether extending RESTCONF wouldn't be a more efficient path here.  Adding support for CBOR to RESTCONF looks like it would be much easier than adding it to NETCONF.

But then, it is unclear to me what the long term relationship between NETCONF and RESTCONF is meant to be.

Thanks,
Rob

Andy

Chapter 2)

regards Balazs

Netconf mailing list

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Jul 2018 08:59:21 -0700

On Fri, Jul 6, 2018 at 2:17 AM, Robert Wilton <[email-masked]> wrote:

> I actually wonder whether extending RESTCONF wouldn't be a more efficient
> path here.  Adding support for CBOR to RESTCONF looks like it would be much
> easier than adding it to NETCONF.
>

of course, because HTTP already supports content-type negotiation.
There is nothing to add to RESTCONF.
You can use other media types than XML or JSON now.

> NETCONF and RESTCONF is meant to be.
Maybe "let the market decide" and not worry about it too much in the IETF

Andy

> On Thu, Jul 5, 2018 at 8:07 AM, Balazs Lengyel <
> [email-masked]> wrote:
>
>> Hello,
>> Mobile: +36-70-330-7909              email: [email-masked]
>> <[email-masked]>
>>
> Netconf mailing [email-masked]://www.ietf.org/mailman/listinfo/netconf
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Jul 2018 09:35:11 -0700

On Thu, Jul 5, 2018 at 10:06 AM, Kent Watsen <[email-masked]> wrote:

> improving

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" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
> Hi,
>
>
>
> <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=>
>
>
>
> <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=>
>
>
>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 6 Jul 2018 17:38:28 +0100

On 06/07/2018 16:59, Andy Bierman wrote:
>
>
> On Fri, Jul 6, 2018 at 2:17 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     efficient path here.  Adding support for CBOR to RESTCONF looks
>     like it would be much easier than adding it to NETCONF.
>
>
Yes, that should make it a very simple draft :-)

>
>
>
>     But then, it is unclear to me what the long term relationship
>     between NETCONF and RESTCONF is meant to be.
>
>
My consideration was more: where should the NETCONF WG be spending its 
effort?

Thanks,
Rob

>>     <https://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-00>
>>
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         Hello,
>>         - 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.
>>
>>         I would think that all encodings need some official
>>         reference, defining how they are used with YANG: RFC, web link
>>
>>         somewhere or do we need an RFC about it? Please state
>>         whichever is the case.
>>
>>         regards Balazs
>>
>>
>>
>>
>>
>>         -- 
>>         <mailto:[email-masked]>
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Jul 2018 19:23:08 +0200

> My consideration was more: where should the NETCONF WG be spending its

So is there running code? Who is doing binary NETCONF and who is doing
binary RESTCONF? What are the _measured_ (not expected) savings with
binary NETCONF and binary RESTCONF? If all the running code moving
binary values is neither NETCONF nor RESTCONF, why would we spent
effort to extend NETCONF so that it can support multiple encodings?
Are people eager to migrate from what they use to this new solution?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Jul 2018 10:42:10 -0700

> Are people eager to migrate from what they use to this new solution?

Working on binary (gNMI).
Very interested in CBOR+SID as a better solution.
The NETCONF WG is done wrt/ RESTCONF.
CORE WG will standardize YANG to CBOR and SID.
Seems like any use of CBOR in NETCONF, YANG Push, or RESTCONF
is gated on the completion of these RFCs.

Andy

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 6 Jul 2018 19:41:31 +0200

Hi all,

I cannot speak for NETCONF or RESTCONF, but there is a CoMI Hackathon 
project in Montreal. The champion is Alexander Pelov.

https://trac.ietf.org/trac/ietf/meeting/wiki/102hackathon

If you have the time, expertise or simply are curious, I am certain that 
every contribution or comment is welcome.

Viele Grüße,

Henk

---

From: Kent Watsen <[email-masked]>
Date: Fri, 6 Jul 2018 20:39:38 +0000

> The NETCONF WG is done wrt/ RESTCONF.

Collections are still pending and, if RESTCONF is ever to supersede NETCONF, there would need to be something like a commit-confirmed, or perhaps this is already taken care of via /restconf/operations/ietf-netconf:commit?

BTW, I notice that nowhere in the nmda-restconf draft does it mention that the auto-commit feature of the "unified" datastore is no active and that clients must(?) now use /restconf/operations/* to do things.  Is this an oversight?

> is gated on the completion of these RFCs.

Regarding YANG-push, perhaps the NETCONF WG should consider a "coap-notif" transport layer draft and, by extension, the CORE WG should consider defining a "coap-client-server" draft.

> Andy

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Jul 2018 16:37:34 -0700

On Fri, Jul 6, 2018 at 1:39 PM, Kent Watsen <[email-masked]> wrote:

> Collections are still pending and, if RESTCONF is ever to supersede
> NETCONF, there would need to be something like a commit-confirmed, or
> perhaps this is already taken care of via /restconf/operations/ietf-
> netconf:commit?
>
>
>
> BTW, I notice that nowhere in the nmda-restconf draft does it mention that
> the auto-commit feature of the "unified" datastore is no active and that
> clients must(?) now use /restconf/operations/* to do things.  Is this an
> oversight?
>
>
>
>
>

Why would the unified API be considered harmful to the Internet if NMDA
datastores are also present?
I see no reason to remove existing APIs just because new ones are added.

With NMDA, a client has to edit candidate and then use POST
/restconf/operations/commit to finish the edit,
which requires 2 steps (or 6 if locking is used). With unified (RFC 8040) 1
step is needed and no locking
is required.

Andy

> Regarding YANG-push, perhaps the NETCONF WG should consider a "coap-notif"
> transport layer draft and, by extension, the CORE WG should consider
> defining a "coap-client-server" draft.
>
>
>
>
>
> > Andy
>
>
>
> Kent // contributor
>
>
>
>
>
>
>

---

From: Kent Watsen <[email-masked]>
Date: Sat, 7 Jul 2018 00:05:02 +0000

> Why would the unified API be considered harmful to the Internet if NMDA datastores are also present?

nmda-restconf preserves the /data resource from RFC 8040.  My comment is more about the lack of information for when the client chooses to use <running> or <candidate> instead.  Maybe it's obvious, not sure, hence the comment.

> With NMDA, a client has to edit candidate and then use POST /restconf/operations/commit to finish the
> edit, which requires 2 steps (or 6 if locking is used). With unified (RFC 8040) 1 step is needed and no
> locking is required.

True.

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 7 Jul 2018 10:14:04 +0200

> step is needed and no locking

I do not think that NMDA requires that <candidate> is used to perform
edits. The <candidate> datastore is still an optional capability.

/js

---

From: Qin Wu <[email-masked]>
Date: Mon, 9 Jul 2018 01:30:21 +0000

[Qin]: If my understanding is correct, when :writable-running capability is supported, the client will chose to use <running>,only when <candidate> capability is supported, the client will choose to use <candidate>.

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 9 Jul 2018 13:28:39 +0200

Efficiency is mostly interesting for yang-push data and not so
much for <edit-config>  <edit-data> <get-config>
<get-data>.

However we are more interested in dynamic-subscriptions then in
configured subscriptions.

Eegards Balazs

On 7/5/2018 7:06 PM, Kent Watsen wrote:

> When
I brought up this issue 5 years ago there was zero interest
in improving

> the

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" <[email-masked] on
behalf of
[email-masked]>
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.

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 <[email-masked]>
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.

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:
[email-masked]

Netconf mailing list

[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 9 Jul 2018 17:05:44 -0700

> On Jul 9, 2018, at 4:28 AM, Balazs Lengyel <[email-masked]> wrote:
> 
> Efficiency is mostly interesting for yang-push data and not so much for <edit-config>  <edit-data> <get-config> <get-data>.
> 
I would generally agree that it is not as interesting for <edit-config> or <get-config>. But we have seen instances of <get-data> where the data set being returned can be rather large, e.g. BGP route entries, where encoding of the data would have helped.

But the question is, do we want to be selective in what we encode? Would it not be easier/simpler for all transaction to be in a single form of encoding?
> However we are more interested in dynamic-subscriptions then in configured subscriptions. 
> Eegards Balazs
> 
> 
>> On 7/5/18, 12:07 PM, "Netconf on behalf of Andy Bierman" <[email-masked] <mailto:[email-masked]> on behalf [email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Hi, 
>>  
>> 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=>
>>  
>> On Thu, Jul 5, 2018 at 8:07 AM, Balazs Lengyel <[email-masked] <mailto:[email-masked]>> wrote:
>> Hello,
>> Mobile: +36-70-330-7909              email: [email-masked] <mailto:[email-masked]>
>> 
>> 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=>
>>  
> 
> -- 
> Mobile: +36-70-330-7909              email: [email-masked] <mailto:[email-masked]> 
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

Mahesh Jethanandani
[email-masked]

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Jul 2018 00:52:43 +0000

发件人: Netconf [mailto:[email-masked]] 代表 Mahesh Jethanandani
发送时间: 2018年7月10日 8:06
收件人: Balazs Lengyel
抄送: [email-masked]
主题: Re: [Netconf] netconf-binary-encoding comments

On Jul 9, 2018, at 4:28 AM, Balazs Lengyel <[email-masked]<mailto:[email-masked]>> wrote:

[Qin]: Another complimentary way to improve NETCONF efficiency is to fragment large size data in the RPC message into data chunk in multiple RPC messages, we see this proposal being cooked for quite a long time,
Surprisingly not see any progress on it.

Kent

On 7/5/18, 12:07 PM, "Netconf on behalf of Andy Bierman" <[email-masked]<mailto:[email-masked]> on behalf [email-masked]<mailto:[email-masked]>> wrote:

Hi,

Andy

Chapter 2)

regards Balazs

--

Senior Specialist

Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>
_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>