Subject: Re: [Netconf] YANG Doctor question: empty mandatory choice?

From: Kent Watsen <[email-masked]>
Date: Mon, 30 Jul 2018 20:44:15 +0000

[removing yang-doctors list, and updating subject line accordingly]

>> > Why do all receivers of a subscription have to use the same transport?
>> 
>> This was something that Martin and Eric worked out before we did the first
>> Last Call.  Eric doesn't seem to know the particular reason, other than 
>> Martin seems to think it’s easier.
>
> No; I personally also prefer a design where each receiver has its own
> transport + encoding.  

+1

> The original model had a common "encoding" for
> all receivers, and then a receiver-specific transport - I think this
> is even worse,

Agreed.

> and suggested to have transport + encoding defined
> together preferrably receiver-specifc or else common for all
> receivers.
>
> If the WG now believes that the transport + encoding should be done 
> per receiver, this should be fairly easy to change.

I also prefer per receiver, and I think that doing so will simplify the
model, as neither the mandatory "transport" nor the [not mandatory?]
"encoding" leaves have to be specified.

In particular, my thoughts are that the "notif" model should provide
for the encoding selection, if needed (it's not needed for NETCONF, 
or COAP I imagine).  

In the case of RESTCONF, we could update the ietf-restconf-client and
ietf-restconf-server models to include an "encodings" leaf-list, to 
configure the RESTCONF server which encodings it should support.  We
likely need to do something similar to configure which HTTP versions
should be supported.  Now, in a general RC server, the server could 
support both but, if the restconf-notif draft has its own list of 
restconf-servers (i.e., it uses the "restconf-server-grouping" itself,
see my July 19 email for a YANG example), then a constraint could be
added limiting the number "supported" to just one.  Thus, when the RC
server reboots, and connects to the receiver and *automatically* 
(no client RPC) starts pushing notifications, it can know what 
encoding to use.

I'm still unsure if its legal for an RC server to automatically push 
notifications without a client-initiated RPC of any sort, and I'm 
also uncertain if supporting *configured* subscriptions for NC or RC
is needed (see my message July 20 email).  So, some of this may work
itself out as we progress.

I know that we're not defining the *configured* notif drafts in this
first effort, the we are publishing the SN draft with a configuration
model, my only concern now is configuration model presented in the 
SN draft.

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Mon, 30 Jul 2018 21:14:14 +0000

Regarding my " the [not mandatory?] 'encoding' leaves comment, I see now 
that the "encoding" leaf has the following "when" statement:

    when 'not(../transport) or derived-from(../transport,
      "sn:configurable-encoding")';

But this doesn't negate the need for the leaf to be mandatory, for those
transports deriving from sn:configurable-encoding.

Additionally, I note that the "encoding" leaf is an identityref to base
type "encoding", from which two identities are derived *in the SN draft*
for (encode-xml and encode-json).  That these identities are defined in
the SN document surprises me, I would've thought that each notif draft
would define its own derived "encoding" identity types, if needed.  Sure,
RESTCONF is special, and other notif drafts can still define their own,
but I'd rather see this done for all transports, including RESTCONF.

Of course, these points are only relevant if we keep the "encoding" leaf...

Kent // contributor

===== original message =====

+1

Agreed.

Kent // contributor

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=bqquEUx-vl7noz7TkXXktSCMP5kLDcq4vNfdjGgi6R8&s=iTOeSctIdaKeqG28BJIl9yub8ktRUTUPRjRqjIXlgHY&e=

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 31 Jul 2018 16:51:03 +0200 (CEST)

> for the encoding selection, if needed (it's not needed for NETCONF, 

I agree.  I think this would be a cleaner design.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Jul 2018 19:55:38 +0200

On Mon, Jul 30, 2018 at 08:44:15PM +0000, Kent Watsen wrote:
> configure the RESTCONF server which encodings it should support.

RESTCONF uses SSE for notification delivery. What you have in mind is
likely the HTTP/2 push transport defined in
draft-ietf-netconf-restconf-notif which I think should not be called
RESTCONF just because it uses some version of HTTP.

/js

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

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 31 Jul 2018 19:02:07 +0000

I am wondering why we are reopening the issue of multiple encodings/transports per receiver vs per subscription?  

Having single transport / encoding per subscription is a simpler design (feedback from implementors; simplifies dealing with any error conditions due to encoding that would affect one receiver but not others in the same subscription; Einar has explained this in the past) and, while I am in general a fan of general design, there does not seem to be business requirements and scenarios that demand this - and even if there were, this would constitute merely an optimization (since if you have different receivers who want different encodings/tranport, you can always simply create another subscription).  

If in the future there is really desire to add this as an additional feature, we can put this into a -bis version.  (Adding stuff will be easier than taking things away.)  Let's just be done.  

--- Alex

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Martin
> Bjorklund
> Sent: Tuesday, July 31, 2018 7:51 AM
> To: [email-masked]
> Cc: evoit=[email-masked]; [email-masked]
> Subject: Re: [Netconf] YANG Doctor question: empty mandatory choice?
> 
> > >> This was something that Martin and Eric worked out before we did
> > >> the first Last Call.  Eric doesn't seem to know the particular
> > >> reason, other than Martin seems to think it’s easier.
> > >
> > > No; I personally also prefer a design where each receiver has its
> > > own transport + encoding.
> >
> > +1
> >
> >
> > > The original model had a common "encoding" for all receivers, and
> > > then a receiver-specific transport - I think this is even worse,
> >
> > Agreed.
> >
> >
> > > and suggested to have transport + encoding defined together
> > > preferrably receiver-specifc or else common for all receivers.
> > >
> > I also prefer per receiver, and I think that doing so will simplify
> > the model, as neither the mandatory "transport" nor the [not
> > mandatory?] "encoding" leaves have to be specified.
> >
> > for the encoding selection, if needed (it's not needed for NETCONF, or
> > COAP I imagine).
> 
> > server reboots, and connects to the receiver and *automatically* (no
> > client RPC) starts pushing notifications, it can know what encoding to
> > use.
> >
> > notifications without a client-initiated RPC of any sort, and I'm also
> > uncertain if supporting *configured* subscriptions for NC or RC is
> > needed (see my message July 20 email).  So, some of this may work
> > model, my only concern now is configuration model presented in the SN
> > draft.
> >
> >
> > Kent // contributor
> >
> >
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 Jul 2018 13:48:31 -0700

On Tue, Jul 31, 2018 at 12:02 PM, Alexander Clemm <
[email-masked]> wrote:

> I am wondering why we are reopening the issue of multiple
> encodings/transports per receiver vs per subscription?
>
> Having single transport / encoding per subscription is a simpler design
> (feedback from implementors; simplifies dealing with any error conditions
> due to encoding that would affect one receiver but not others in the same
> subscription; Einar has explained this in the past) and, while I am in
> general a fan of general design, there does not seem to be business
> requirements and scenarios that demand this - and even if there were, this
> would constitute merely an optimization (since if you have different
> receivers who want different encodings/tranport, you can always simply
> create another subscription).
>
> If in the future there is really desire to add this as an additional
> feature, we can put this into a -bis version.  (Adding stuff will be easier
> than taking things away.)  Let's just be done.
>
>
+1, except IMO there are many higher priority work items than a -bis to
this not-even-released draft.

> --- Alex

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 1 Aug 2018 00:01:29 +0000

> draft-ietf-netconf-restconf-notif

Not really.  The thought extends beyond the notifications work.  In 
general, servers are able to be tuned as to which protocols, algorithms,
etc. are supported.  For instance, NGINX has a parameter for if HTTP2
is enabled.  Similarly, it seems that a server may be configured, for
local policy reasons, to support just xml or just json.  The idea is 
that, if we add these tuning params to the ietf-restconf-[client|server]
models, then those tuning params might be used to enable the encoding
selection for *configured* restconf-notif subscriptions. Just an idea.
Really, this is an open restconf-client-server draft issue, and only a
restconf-notif draft issue when we do the bis on that draft.

> which I think should not be called

Agreed.  The "restconf-notif" draft should really only speak about 
the RESTCONF protocol.  That the YANG module in the draft is called
"ietf-http-subscribed-notifications" surprises me.

Actually, the names of the YANG "notif" modules in general seem 
less than ideal.  I appreciate that RFC 6470 took the name
"ietf-netconf-notifications", and these drafts are trying to
follow that naming convention, but maybe we should choose a
more concise pattern like ietf-notifications-<transport>:

  ietf-notifications-netconf
  ietf-notifications-restconf
  ietf-notifications-coap
  ietf-notifications-http2

or maybe ietf-notifications-<transport>[-<encoding>]:

  ietf-notifications-netconf
  ietf-notifications-restconf-xml
  ietf-notifications-restconf-json
  ietf-notifications-coap
  ietf-notifications-http2-xml
  ietf-notifications-http2-json

Kent // contributor