Subject: [Netconf] yang-api comment: decouple protocol and encoding

From: Kent Watsen <[email-masked]>
Date: Wed, 13 Mar 2013 20:40:00 +0000

Hi Andy,

A follow-up to my comment during the NETCONF meeting, I think we should decouple protocol and encoding.

This is easily done for REST APIs, since HTTP's "Accept" and "Content-Type" header fields are defined for just this purpose.   If the client fails to provide an Accept header, the server needs to default to something.  FWIW, our REST API use to default to JSON but we changed it to XML after receiving significant feedback…

I'd also like to open the floor to alternate encodings for the NETCONF protocol - e.g. Google Protocol Buffers (protobufs) or maybe even binary (raised by an I2RS member).  For protobufs, we experimented passing a flag in the RPC indicating that the RPC-reply should be encoded as a Google Protocol Buffer - it's asymmetric (RPCs are always XML), but effective as we find that most data flows in that direction.  That said, we might consider negotiated it at the session-level.  Does anyone have interest in alternate data encodings for NETCONF?

Thanks,
Kent

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 13 Mar 2013 22:00:04 +0000

FWIW, I think decoupling protocol and encoding makes sense.  I am not sure if the encodings apply to the protocol as a whole, or if should allow them to apply also just the payload.  I.e., do you mean data encodings for YANG, or for Netconf (or maybe for both)?  For example, presumably, a motivation for a binary protocol includes the desire for efficiency, which may call for protocol operations that are lighter-weight than what is supplied by Netconf (not a criticism on Netconf, just placing the tradeoffs a bit differently - just like REST API is a YANG/REST versus Netconf/REST).  I think there are definitely use cases for alternate encoding schemes for the payload, whether or not Netconf protocol operations are used.
--- Alex

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Wednesday, March 13, 2013 1:40 PM
To: NetConf
Subject: [Netconf] yang-api comment: decouple protocol and encoding

Hi Andy,

This is easily done for REST APIs, since HTTP's "Accept" and "Content-Type" header fields are defined for just this purpose.   If the client fails to provide an Accept header, the server needs to default to something.  FWIW, our REST API use to default to JSON but we changed it to XML after receiving significant feedback...

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Mar 2013 15:11:40 -0700

On Wed, Mar 13, 2013 at 3:00 PM, Alexander Clemm (alex) <[email-masked]> wrote:
> FWIW, I think decoupling protocol and encoding makes sense.  I am not sure
> if the encodings apply to the protocol as a whole, or if should allow them
> to apply also just the payload.  I.e., do you mean data encodings for YANG,
> or for Netconf (or maybe for both)?  For example, presumably, a motivation
> for a binary protocol includes the desire for efficiency, which may call for
> protocol operations that are lighter-weight than what is supplied by Netconf
> (not a criticism on Netconf, just placing the tradeoffs a bit differently –
> just like REST API is a YANG/REST versus Netconf/REST).  I think there are
> definitely use cases for alternate encoding schemes for the payload, whether
> or not Netconf protocol operations are used.

IMO using multiple encodings in the same message is too complicated.
In my implementation, the encoding is negotiated at the same control point
as the framing -- after the <hello> message in base:1.0 framing in XML encoding
is processed.

As the session startup gets more complicated, I realized that Teramoto is right
and a debug comment (XML comment) should be sent with the
"session-dropped-reason".
That way a client can find out if it was unsupported encoding vs.
unsupported base
version that caused the session to be rejected.

> --- Alex

Andy

> This is easily done for REST APIs, since HTTP's "Accept" and "Content-Type"
> header fields are defined for just this purpose.   If the client fails to
> provide an Accept header, the server needs to default to something.  FWIW,
> our REST API use to default to JSON but we changed it to XML after receiving
> significant feedback…
>
>
>
> I'd also like to open the floor to alternate encodings for the NETCONF
> protocol - e.g. Google Protocol Buffers (protobufs) or maybe even binary
> (raised by an I2RS member).  For protobufs, we experimented passing a flag
> in the RPC indicating that the RPC-reply should be encoded as a Google
> Protocol Buffer - it's asymmetric (RPCs are always XML), but effective as we
> find that most data flows in that direction.  That said, we might consider
> negotiated it at the session-level.  Does anyone have interest in alternate
> data encodings for NETCONF?
>
>
>
> Thanks,
>
> Kent
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Phil Shafer <[email-masked]>
Date: Thu, 14 Mar 2013 09:12:03 -0400

Andy Bierman writes:
>unsupported base version that caused the session to be rejected.

It might be better for you to syslog this, so you aren't counting
on comment processing/logging in the client and you're support folks
can see the error without futzing with the client.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Mar 2013 14:23:16 +0100

> can see the error without futzing with the client.

Simply do both. ;-)

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Mar 2013 06:23:29 -0700

Hi Phil,

Good point.
yangcli code drops PIs and comments and you need to set a fairly high
debug trace level
to actually see XML comments in the log. My thinking was, if a client
developer or operator
is having sessions rejected, they would turn on debugging.

I think 1 issue that was brought up is that the client developer may
not have access
to the server logs or server syslog feed.

I guess a robust solution would be an actual XML response from the server
before dropping the connection.  But in the case of improper framing, the server
cannot trust what it got and has no choice but to ignore the client <hello> and
drop the connection.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Mar 2013 10:05:50 -0400

> cannot trust what it got and has no choice but to ignore the client <hello> and

I guess the server can still send an error message before shutting down.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C