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

["Eric Voit (evoit)" <[e-mail]>]

Kent Watsen, May 5, 2020 9:48 PM



This email closes the virtual hum on the for the question on the "https-notif” draft.

 

As reported before, 70% picked "Let the market decide”, with the remaining 30% all picking "Publisher MUST implement JSON encoding”.

 

Rob raises a good point about the language in RFC 8639, but the results of the poll reveal a contradiction.  How can we “let the market decide” if a default MUST be picked?

 

The chairs are questioning how vetted that text in RFC 8639 is, noting that RESTCONF also doesn’t pick a default.  We wonder if the text in RFC 8639 should be softened.  For instance:

 

  OLD:

   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.


  NEW:

   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, or

   provide a mechanism whereby supported encodings can be discovered.

 

At least, it seems that the intent of the draft is to handle the case for when the “encoding” leaf is not configured (since it’s “mandatory false”), more so than force interoperability, but there are other ways to determine an encoding in such circumstances, and thus maybe the text is overly proscriptive?

 

<eric> I have no problem with the proposed text.

 

Eric

 

 

 

The NETCONF Chairs

 

 

 





On Apr 27, 2020, at 11:48 AM, Rob Wilton (rwilton) <[e-mail] <mailto:[e-mail]> > wrote:

 

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

 

 






On Apr 27, 2020, at 8:08 AM, Rob Wilton (rwilton) <rwilton=[e-mail] <mailto:rwilton=[e-mail]> > 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 < <mailto:[e-mail]> [e-mail]> On Behalf Of Mahesh Jethanandani
Sent: 21 April 2020 01:48
To: Netconf < <mailto:[e-mail]> [e-mail]>
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  <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-02> draft-ietf-netconf-https-notif 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> 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
 <mailto:[e-mail]> [e-mail]
 <https://www.ietf.org/mailman/listinfo/netconf> https://www.ietf.org/mailman/listinfo/netconf