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

[Andy Bierman <[e-mail]>]

On Sun, Mar 18, 2018 at 8:11 AM, Martin Bjorklund <[e-mail]> wrote:

> Hi,
>
>
> Mahesh Jethanandani <[e-mail]> wrote:
> > 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 <[e-mail]> 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.
>
> 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.
>



+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



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



The existing media types registry should be sufficient



>
>
> > > 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).
>


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 ;-)



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


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


>
> 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).
>
> > 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.
>
> I think this is a mistake.  I think the encoding for notifs should be
> fixed.
>
>
+1


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

Andy


>
>
> > > 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: [e-mail] <mailto:[e-mail]>
> > >>> 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" <[e-mail] <mailto:[e-mail]>>, "Alfred
> > >>> Leung" <[e-mail] <mailto:[e-mail]>>, "Mahesh
> > >>> Jethanandani" <[e-mail]
> > >>> <mailto:[e-mail]>>
> > >>>
> > >>>
> > >>> 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
> > >> [e-mail] <mailto:[e-mail]>
> > >>
> > >>
> > >> _______________________________________________
> > >> Netconf mailing list
> > >> [e-mail] <mailto:[e-mail]>
> > >> https://www.ietf.org/mailman/listinfo/netconf
> > >> <https://www.ietf.org/mailman/listinfo/netconf>
> > >
> >
> > Mahesh Jethanandani
> > [e-mail]
> >
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>