Re: [netconf] Virtual hum for the question on "https-notif" draft

At least the hum seems to have narrowed it down to two choices (assuming sufficient voices).

But I can see interop benefit in defining at least one encoding that clients know will be supported by the server.

Hence, I wonder if anyone wouldn’t be able to live with:

  “The default encoding is JSON.  Publishers MUST support JSON encoding”

* or a slight variant (that I don’t like so much) would be to soften the MUST to a SHOULD, with the expectation that servers that don’t support JSON would reject the configuration unless the clients had specified an alternative supported encoding.

Rob
[As a contributor]

From: Kent Watsen <kent+ietf@watsen.net>
Sent: 27 April 2020 16:28
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>; netconf@ietf.org
Subject: Re: [netconf] Virtual hum for the question on "https-notif" draft

On Apr 27, 2020, at 8:08 AM, Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org<mailto:rwilton=40cisco.com@dmarc.ietf.org>> wrote:

[As an individual contributor]

Changing my stance somewhat from the NETCONF meeting …

After looking into the details a bit more, section 7 of rfc8639 states:

   A specification for a transport MUST identify any encodings that are
   supported.  If a configured subscription's transport allows different
   encodings, the specification MUST identify the default encoding.

Does this imply that the http-notif draft either must state a default encoding (or otherwise update rfc8639)?

It seems that way...at least when https-notif is being used for RFC 8639 (it doesn’t have to be).

Looking at the hum-results so far, 70% picked "Let the market decide” (with the remaining 30% all picking "Publisher MUST implement JSON encoding”).

In light of the RFC 8639 text quoted above, we might question the validity of the hum…or, given the strong preference from the hum, we might question the validity of that constraint in RFC 8639.  If questioning RFC 8639, a better question to ask might be why the configurable “encoding” leaf isn’t mandatory (also eliminating this issue and seemingly cleaner)?

If so, my thinking is to make the default encoding JSON, because it is easier to generate than XML, and easier to convert into CBOR.  Clients don’t have to support JSON if they know that the publisher supports a different encoding that they do support.

If we had to pick one, JSON is more agreeable than XML.  Picking JSON would likely also be the kiss-of-death for XML, as once support for JSON has been coded, it’s unlikely XML support would be coded (like how XPath-filters are rarely implemented due to subtree-filters having to implemented).  Picking JSON would NOT be the kiss-of-death for CBOR (or some other binary encoding) as *binary* offers real value in space and time consumption.

Kent // contributor

I’ve also filled in the virtual hum.

Regards,
Rob

From: netconf <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> On Behalf Of Mahesh Jethanandani
Sent: 21 April 2020 01:48
To: Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: [netconf] Virtual hum for the question on "https-notif" draft

At the 107 NETCONF virtual meeting, the authors posed the question of mandatory encoding for draft-ietf-netconf-https-notif<https://tools.ietf.org/html/draft-ietf-netconf-https-notif-02> draft to the WG. This virtual hum in the form of a survey is being presented to record the response from the WG.

Please respond by selecting one of the options in the survey page.

https://www.surveymonkey.com/r/68W3DX3

The relevant slide that was used for discussion was this. In addition to the options discussed here, Rob suggested that the WG could defer to the market to decide.

Thanks

Mahesh & Kent (as co-chairs)
_______________________________________________
netconf mailing list
netconf@ietf.org<mailto:netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf