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

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 20 Apr 2020 17:48:19 -0700

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)

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 27 Apr 2020 12:08:08 +0000

[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)?

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.

I've also filled in the virtual hum.

Regards,
Rob

From: netconf <[email-masked]> On Behalf Of Mahesh Jethanandani
Sent: 21 April 2020 01:48
To: Netconf <[email-masked]>
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.

Thanks

---

From: Kent Watsen <[email-masked]>
Date: Mon, 27 Apr 2020 15:27:45 +0000

> On Apr 27, 2020, at 8:08 AM, Rob Wilton (rwilton) <rwilton=[email-masked]> wrote:
> 
> Changing my stance somewhat from the NETCONF meeting …
>  

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 <[email-masked] <mailto:[email-masked]>> On Behalf Of Mahesh Jethanandani
> To: Netconf <[email-masked] <mailto:[email-masked]>>
> https://www.surveymonkey.com/r/68W3DX3 <https://www.surveymonkey.com/r/68W3DX3>
>  
> _______________________________________________
> netconf mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 27 Apr 2020 15:48:00 +0000

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 <[email-masked]>
Sent: 27 April 2020 16:28
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Mahesh Jethanandani <[email-masked]>; [email-masked]
Subject: Re: [netconf] Virtual hum for the question on "https-notif" draft

On Apr 27, 2020, at 8:08 AM, Rob Wilton (rwilton) <rwilton=[email-masked]<mailto:rwilton=[email-masked]>> wrote:

Kent // contributor

Regards,
Rob

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

Thanks

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 29 Apr 2020 17:59:00 +0000

From: Kent Watsen, April 27, 2020 11:28 AM

On Apr 27, 2020, at 8:08 AM, Rob Wilton (rwilton) <rwilton=[email-masked] <mailto:rwilton=[email-masked]> > wrote:

<eric> The WG feedback during RFC-8639 development was that encoding was often implied from transport.  Therefore mandating exposure of this information in the model was overly verbose, and could result in misconfiguration.  

Adding Martin to the thread as he was previosuly involved with this discussion.

Eric

<...>

Kent // contributor

Regards,
Rob

---

From: Martin Björklund <[email-masked]>
Date: Wed, 29 Apr 2020 20:38:38 +0200 (CEST)

Hi,

"Eric Voit \(evoit\)" <evoit=[email-masked]> wrote:
> 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)?

RFC 8639 explains that if the "encoding" leaf isn't configured, the
transport-default is used.  RFC 8639 also says that a transport must
have a transport-default.

That's the answer to the question: "why is 'encoding' optional?".

/martin

> 
> <eric> The WG feedback during RFC-8639 development was that encoding was often implied from
> transport. Therefore mandating exposure of this information in the model was overly verbose,
> and could result in misconfiguration.
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 29 Apr 2020 23:15:00 +0000

> That's the answer to the question: "why is 'encoding' optional?”.

No, that’s just paraphrasing what the RFC says.   Eric’s answer below provides a “why”.

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Wed, 29 Apr 2020 23:50:17 +0000

Eric,

> <eric> The WG feedback during RFC-8639 development was that encoding was often implied from transport.  Therefore mandating exposure of this information in the model was overly verbose, and could r…

Okay, but now our first configurable transport can support multiple encodings and 70% of the WG wants to “let the market decide” (i.e., no required, or default, encoding), it seems almost like we’re contradicting ourselves here...  

You mention the rational making the ”encoding” leaf optional, which seems reasonable to me, but what about mandating a default, do you have a sense for how many people weighed-in on that decision?  

PS: separately, can you look into configuring your mail agent to indent quotes in responses?

Kent // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 30 Apr 2020 16:00:37 +0000

> From: Kent Watsen, April 29, 2020 7:50 PM
> 
> Eric,
>
>
> 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)?
> 
> <eric> The WG feedback during RFC-8639 development was that encoding was often 
> implied from transport.  Therefore mandating exposure of this information in the model 
> was overly verbose, and could result in misconfiguration.  
>
> Okay, but now our first configurable transport can support multiple encodings and 70% 
> of the WG wants to “let the market decide” (i.e., no required, or default, encoding), it 
> seems almost like we’re contradicting ourselves here...  

<eric> Certainly WGs have changed their mind in the past.  If someone wants to re-open this discussion it could touch a lot of structures in the model, and would needs to be considered with other transports in mind.

I feel that "having the market decide" can still be accomplished with the current model by having the desired configurable-encoding identity as part of the datastore write.  To me this seems safer for a Northbound system to handle than for that Northbound system to have to track and adjust its write based the default for any particular vendor.

(FWIW, I voted for "JSON")  

> You mention the rational making the ”encoding” leaf optional, which seems reasonable 
> to me, but what about mandating a default, do you have a sense for how many people 
> weighed-in on that decision?  

<eric>  There were several fairly extensive discussion of the linking between transport and encoding.  This included presentations within a WG sessions.   It was seen as problematic to create XPATH which makes optional the population of an encoding leaf based on it being an configurable-encoding *and* also considering the value of as-yet-unknown transport identities specified within future transport drafts.

IMHO, the current structure balances these objectives reasonably.

Eric