Re: [netconf] time to meet today after 5pm

["Charles Eckel (eckelcu)" <[e-mail]>]

Please see inline.

From: netconf <[e-mail]> on behalf of Kent Watsen <[e-mail]>
Date: Thursday, April 4, 2019 at 7:06 PM
To: Patrick McManus <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [netconf] time to meet today after 5pm



I don't think this is correct.  In what way do you think RESTCONF
tries to use HTTP as a stateful transport?

below


> >> On Tue, Apr 2, 2019 at 6:44 PM Kent Watsen <[e-mail]<mailto:[e-mail]>>

> >> Actually, "managing persistence" is exactly what we're trying to
> >> achieve here.  Our show-stopping driving use-case regards RESTCONF
> >> Call Home (RFC 8071) and, in particular, point "S7" on page 8 of that
> >> document, without which a remote device may become a "brick" and
> >> require a technician to perform on-site repair.

also, in an exchange that wasn't copied to the wg,:

> To give a concrete example, there may be a device, deployed behind a NAT, requiring a persistent management connection to its controller application.  Because the device is behind a NAT, it MUST initiate the connection (the controller cannot) and, thus the device MUST ensure aliveness of the connection to the controller (the controller *needs* the device-initiated connection to be up in order to send commands to the device).   In case the controller disappears, perhaps due to its data-center being hit by a meteor, the device must promptly detect to loss and initiate reconnection to another controller.


To be clear, RESTCONF is not trying to use HTTP as a stateful protocol, but it is ideal to try to keep RESTCONF Call Home connections up, as described above.   Per the "S7" reference, devices SHOULD use RFC 6520 (the TLS heartbeat extension).   This would keep the *stateful* transport (TLS) up but, unfortunately, OpenSSL doesn't want to implement it (worst, they just removed the DTLS code, https://github.com/openssl/openssl/issues/4856, despite Ben Kaduk and myself stating value).

The thinking behind this thread is that maybe some traffic could run on top of TLS (i.e., at the HTTP layer), to do the same and, if not, then maybe we could do it at the RESTCONF layer.  [FWIW, you might recall NETCONF/RESTCONF keepalives discusseded at the IETF 103 meeting.]

Patrick, if HTTP keepalive is not possible, then lets strike the "keepalive" parts from the ietf-http-client and ietf-http-server models, leaving it to implementations to lean more heavily on their TLS suppliers to implement RFC 6520, or fallback to unprotected TCP keepalives (which is what the BBF/Nokia said they would be doing for expediency).  Regarding the rest, let me clean the remaining bits (i.e., post a -01) and present them to you again then.

I would recommend against adding any keepalive mechanism to RESTCONF. Strongly recommending the use of HTTPS when using RESTCONF is fine, but keep in mind that RESTCONF was created, and is viewed in the industry, as a “REST-like” alternative to NETCONF. The tradeoff is functionality built into the protocol vs. complexity of writing an application that uses the protocol. It is trivial to make individual RESTCONF requests but more difficult for an application to implement network transactions using RESTCONF than if using NETCONF. An application developer is free to choose the right protocol for the job. Adding complexity to RESTCONF that make it less REST-like would be a mistake, in my opinion.

Cheers,
Charles

For everyone else, this email thread is from last week when Mahesh and I were trying to meet with the HTTPBIS chairs to discuss the http-client-server draft under adoption poll.  We wanted to proactively engage HTTPBIS rather than have any surprises, such as the exchange with TCPM.   Our hope is that we can come to an agreement, like the one struck with TCPM, whereby domain experts in each WG co-author a bare-minimum grouping that enables our 5-year chartered work effort to come to an end.  With regards to Last Call, we can do it joint Last Call, if desired.   For longterm maintenance of the YANG model, we're happy to turn it over to the domain-specific WG, though we don't have any need or expectation for an update, the bare-minimum is sufficient.

Kent // pick a hat