Subject: Re: [Netconf] New Version Notification for draft-mahesh-netconf-binary-encoding-00.txt

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 15 Mar 2018 19:08:47 -0700

Robert,

Thanks for your review of the document. Here are some initial responses, and we can discuss this further in London also.

> On Feb 23, 2018, at 4:08 AM, Robert Wilton <[email-masked]> wrote:
> 
> Hi Mahesh,
> 
> Some quick thoughts/comments on this draft:
> 
> 1) I think that it is good for NETCONF to support other encodings, particularly CBOR, and possibly JSON as well.  I particularly the like the CBOR+SID encoding that seems to be compact but not hard to support.
> 
Agree. 
> 2) I think that it would be good if RESTCONF could also support CBOR as well.  I'm not sure whether that could be covered by this draft of something else.
> 
Are you looking for a similar new capability URI for restconf to be added?
> 3) There needs to be a well defined registry of encodings, perhaps as identities.
> 
Ok. We need to decide where these identities can be defined. Currently, there is no YANG model defined in the draft.
> 4) CBOR supports using SIDs or strings for identifiers, so there would need to be a way of choosing between these.  Perhaps these would be listed as two different encodings.
> 
Yes.
> 5) Versioning might want to be considered, e.g. if there was an updated version of CBOR how would that be reported.
> 
How does CBOR report its version today? Or do they?
> 6) If CBOR is being used, and in which case, SIDs is probably the way to go, then there might need to be some consideration about how the client learns the SIDs, this may be covered by some of the CORE WG drafts, or might require new NETCONF/RESTCONF RPCs.
> 
I need to be educated here. We can discuss this further in London.
> 7) There is no encoding of metadata in CBOR, it might be useful if that was also considered, probably that would end up being a separate draft.
> 7b) Related to 7, how would the <edit-config> operations (merge, create, remove,  etc) be encoded.
> 7c) Would errors also be reported using a binary encoding, or would they stay in XML?
> 
Juergen had a similar question. After discussing with him, we will clarify in the next version of the document that the encoding will be for everything above the Messages layer per Figure 1 of RFC 6241. So the answer to 7c is that it will stay in XML. 

For 7b, and example conversion of a XML to JSON encoding would look like this:

In XML:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
  <source>
    <running/>
  </source>
  <filter type="subtree">
        <interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg">
     <interface-configuration>
      <active>act</active>
      <interface-name>GigabitEthernet0/0/0/0</interface-name>
     </interface-configuration>
    </interface-configurations>
  </filter>
</get-config>
</rpc> 

After switching to JSON encoding the same request would look something like (just noticed that type=“subtree” got dropped)

<rpc message-id="103" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
{
  "ietf-netconf:get-config": {
    "source": {
      "running": null
   },
    "filter": {
      "interface-configurations": {
        “xmlns":"http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg <http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg>",
        "interface-configuration": {
          "active": "act",
          "interface-name": "GigabitEthernet0/0/0/0"
        }
      }
    }
  }
}
</rpc>

> 8) Does there need to be any comment/considerations regarding YANG push and friends.
> 
Yes, there are considerations for YANG push and friends drafts. Eric tells me that there is an ability in subscribed notifications to change the encoding mid-stream.
> But in general, I'm supportive of IETF allowing binary encodings to be used in NETCONF/RESTCONF for devices that want to use them.  They seem to be particularly relevant to streaming telemetry related applications.
> 
Agree.
> Thanks,
> Rob
> 
> On 22/02/2018 02:29, Mahesh Jethanandani wrote:
>> This short draft proposes a mechanism for NETCONF clients and servers to negotiate an alternate form of encoding, e.g. binary encoding.
>> 
>> Cheers.
>> 
>>> Begin forwarded message:
>>> 
>>> From: [email-masked] <mailto:[email-masked]>
>>> Subject: New Version Notification for draft-mahesh-netconf-binary-encoding-00.txt
>>> Date: February 21, 2018 at 6:18:45 PM PST
>>> To: "Jason Lam" <[email-masked] <mailto:[email-masked]>>, "Alfred Leung" <[email-masked] <mailto:[email-masked]>>, "Mahesh Jethanandani" <[email-masked] <mailto:[email-masked]>>
>>> 
>>> 
>>> A new version of I-D, draft-mahesh-netconf-binary-encoding-00.txt
>>> has been successfully submitted by Mahesh Jethanandani and posted to the
>>> IETF repository.
>>> 
>>> Name:		draft-mahesh-netconf-binary-encoding
>>> Revision:	00
>>> Title:		Binary Encoding for NETCONF
>>> Document date:	2018-02-23
>>> Group:		Individual Submission
>>> Pages:		6
>>> URL:            https://www.ietf.org/internet-drafts/draft-mahesh-netconf-binary-encoding-00.txt <https://www.ietf.org/internet-drafts/draft-mahesh-netconf-binary-encoding-00.txt>
>>> Status:         https://datatracker.ietf.org/doc/draft-mahesh-netconf-binary-encoding/ <https://datatracker.ietf.org/doc/draft-mahesh-netconf-binary-encoding/>
>>> Htmlized:       https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-00 <https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-00>
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-mahesh-netconf-binary-encoding-00 <https://datatracker.ietf.org/doc/html/draft-mahesh-netconf-binary-encoding-00>
>>> 
>>> 
>>> Abstract:
>>>   This document describes a method by which a NETCONF [RFC6241] client
>>>   and server can negotiate an alternate form of encoding.
>>> 
>>>   This document updates RFC 6241.
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> Mahesh Jethanandani
>> [email-masked] <mailto:[email-masked]>
>> 
>> 
>> _______________________________________________
>> Netconf mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> 

Mahesh Jethanandani
[email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 18 Mar 2018 16:11:47 +0100 (CET)

Hi,

Mahesh Jethanandani <[email-masked]> wrote:
> Robert,
> 
> Thanks for your review of the document. Here are some initial
> responses, and we can discuss this further in London also.
> 
> > 1) I think that it is good for NETCONF to support other encodings,
> > particularly CBOR, and possibly JSON as well.  I particularly the like
> > the CBOR+SID encoding that seems to be compact but not hard to
> > support.
> > 
> Agree. 

Regarding the proposed solution, I think we should use the same
mechanism as is used for negotiation of the framing mechanism.
Specifically, the server would in its <hello> advertise the supported
encodings, and the client would advertise the supported encodings in
preferred order.  Both sides would then immediately start to use the
first encoding in the client's list that also the server supports, or
xml if no such encoding exists.

> > 2) I think that it would be good if RESTCONF could also support CBOR
> > as well.  I'm not sure whether that could be covered by this draft of
> > something else.
> > 
> Ok. We need to decide where these identities can be
> defined. Currently, there is no YANG model defined in the draft.

I think we should use a simple IANA-maintained registry of encoding names
("xml", "cbor", "json", ...).  I don't think we need the
flexibility of YANG identities for these encodings.

> > 4) CBOR supports using SIDs or strings for identifiers, so there would
> > need to be a way of choosing between these.  Perhaps these would be
> > listed as two different encodings.
> > 
> Yes.
> > 5) Versioning might want to be considered, e.g. if there was an
> > updated version of CBOR how would that be reported.

If a new version of some encodings is developed, it would be a new string
("cbor-2"), which would be registered in the IANA registry (if we
choose that route, otherwise it would be a new identity).

> > 6) If CBOR is being used, and in which case, SIDs is probably the way
> > to go, then there might need to be some consideration about how the
> > client learns the SIDs, this may be covered by some of the CORE WG
> > drafts, or might require new NETCONF/RESTCONF RPCs.
> > 
> > 7) There is no encoding of metadata in CBOR, it might be useful if
> > that was also considered, probably that would end up being a separate
> > draft.
> Juergen had a similar question. After discussing with him, we will
> clarify in the next version of the document that the encoding will be
> for everything above the Messages layer per Figure 1 of RFC 6241. So
> the answer to 7c is that it will stay in XML.

I think this would be odd.  Note that you can't pass arbitrary binary
data in XML.  I think the entire Messages layer (and above) should use
the new encoding.

What's needed for each encoding is probably that each encoding defines
how the Messages layer is encoded (i.e., rpc, rpc-reply and
notification).

>         <interface-configurations
>         xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg">
> After switching to JSON encoding the same request would look something
> like (just noticed that type=“subtree” got dropped)
> 
>         “xmlns":"http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg
>         <http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg>",
> Yes, there are considerations for YANG push and friends drafts. Eric
> tells me that there is an ability in subscribed notifications to
> change the encoding mid-stream.

I think this is a mistake.  I think the encoding for notifs should be
fixed.

BTW, we should probably ensure that we use the same encodings for the
notif draft and this one.

/martin

> > But in general, I'm supportive of IETF allowing binary encodings to be
> > used in NETCONF/RESTCONF for devices that want to use them.  They seem
> > to be particularly relevant to streaming telemetry related
> > applications.
> > 
> Agree.
> > Thanks,
> > Rob
> > 
> >> This short draft proposes a mechanism for NETCONF clients and servers
> >> to negotiate an alternate form of encoding, e.g. binary encoding.
> >> 
> >> Cheers.
> >> 
> >>> Begin forwarded message:
> >>> 
> >>> Subject: New Version Notification for
> >>> draft-mahesh-netconf-binary-encoding-00.txt
> >>> To: "Jason Lam" <[email-masked] <mailto:[email-masked]>>, "Alfred
> >>> Leung" <[email-masked] <mailto:[email-masked]>>, "Mahesh
> >>> Jethanandani" <[email-masked]
> >>> <mailto:[email-masked]>>
> >>> 
> >>> 
> >>> URL:
> >>> https://www.ietf.org/internet-drafts/draft-mahesh-netconf-binary-encoding-00.txt
> >>> <https://www.ietf.org/internet-drafts/draft-mahesh-netconf-binary-encoding-00.txt>
> >>> Status:
> >>> https://datatracker.ietf.org/doc/draft-mahesh-netconf-binary-encoding/
> >>> <https://datatracker.ietf.org/doc/draft-mahesh-netconf-binary-encoding/>
> >>> Htmlized:
> >>> https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-00
> >>> <https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-00>
> >>> Htmlized:
> >>> https://datatracker.ietf.org/doc/html/draft-mahesh-netconf-binary-encoding-00
> >>> <https://datatracker.ietf.org/doc/html/draft-mahesh-netconf-binary-encoding-00>
> >>> 
> >>> 
> >>> Abstract:
> >> https://www.ietf.org/mailman/listinfo/netconf
> >> <https://www.ietf.org/mailman/listinfo/netconf>
> > 
> 
> Mahesh Jethanandani
> [email-masked]
>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 18 Mar 2018 08:42:21 -0700

> xml if no such encoding exists.

+1

In fact, I proposed this exact mechanism 4 years ago:

https://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-01#section-2.2

> flexibility of YANG identities for these encodings.

The existing media types registry should be sufficient

> choose that route, otherwise it would be a new identity).

https://tools.ietf.org/html/draft-ietf-core-yang-cbor-06

The CBOR work is already being done in CORE WG (not CBOR WG, just to
confuse you ;-)

> > the answer to 7c is that it will stay in XML.

Lack of support for metadata impacts operational data as well (e.g.
'origin' attribute).

> I think this is a mistake.  I think the encoding for notifs should be
+1

> notif draft and this one.

Andy

> > >>> <https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-00
> >
> > >>> Htmlized:
> [email-masked]