Subject: [yang-doctors] YANG Doctor question: empty mandatory choice? (was RE: [Netconf] YangPush now)

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 26 Jul 2018 19:22:40 +0000

Hi YANG doctors,

We are trying to close on some YANG push drafts.  There is one YANG related question I would like to bounce off of you before making a suggested change.

In the thread:

https://www.ietf.org/mail-archive/web/netconf/current/msg15169.html

is the following request:

> From: Kent Watsen, July 26, 2018 1:48 PM

> <chair hat on>

> ...

> Assuming no objections, to close the issues discussed in Montreal, we're waiting

> for the following updates:

>   ...

>   sub-notif: modify config model to mandate a transport

What I believe Kent is asking for is that the ietf-subscribed-notifications.yang model should be enhanced to mandate that transport specific call home parameters are augmented under the container “receivers”.  He wants to do this by incorporating a mandatory choice, with no cases being identified.  Cases would be added via augmentations in subsequent drafts.

Specifically, Kent's proposal as per

https://www.ietf.org/mail-archive/web/netconf/current/msg15148.html

is "to make the augmentation of a "notif" model mandatory (see the '+' lines below), to ensure that there is always something more than just a name being configured per receiver.

      container receivers {

        list receiver {

          key "name";

          min-elements 1;

          leaf name {

            type string;

          }

   +      choice transport {

   +        mandatory true;

   +        description

   +          "Defines the transport-specific configuration data

   +           for the selected transport.";

   +      }  "

At this point there is an open question from Andy on this approach.

https://www.ietf.org/mail-archive/web/netconf/current/msg15149.html

Andy’s says:

“The notion of an empty mandatory choice really stretches the definition of YANG Conformance. This says you cannot possible implement the SN module without some other module augmenting it. Yet there is no way in YANG (besides import) to say the module bar needs to be present if module foo is present.”

My first question to you is would you object to mandatory choice statements without corresponding case statements?  If you *do* have an issue with an empty mandatory choice, we should likely stay with the current solution.

If you see no issue with an empty mandatory choice, I have a second question for you.    For all receivers in a subscription, the selected transport choice case in Kent’s suggestion above MUST match to the value of the “transport” leaf which is one level higher in the tree.  I.e.:

    +--rw subscriptions

       +--rw subscription* [identifier]

          +--rw transport                                  transport {configured}?

          +--rw receivers

             +--rw receiver* [name]

             +--rw (transport)

                +--rw :(NETCONF)

                |  +--rw (NETCONF specific call home parameters)

                +--rw :(HTTP2)

                    +--rw (HTTP2 specific parameters)

(Note on the tree above, I inserted the NETCONF and HTTP2 cases of transport for illustration purposes for the question below.  These two cases would actually be incorporated via separate augmentations to the ietf-subscribed-notifications.yang model.)

Considering above, It seems difficult to enforce that the transport cases selected under all receivers for a single subscription MUST be identical, and also MUST match to the value of the “transport” leaf under the subscription.

Would the YANG doctors have any issue with the structure Kent suggests above?  If no, would the YANG doctors then mandate that integrity checks per performed across the receiver case instances under a subscription?   And if mandated, how might XPATH be encoded considering transport cases are only added via augmentation?

Thanks,

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jul 2018 00:11:21 +0200

On Thu, Jul 26, 2018 at 07:22:40PM +0000, Eric Voit (evoit) wrote:

> For all receivers in a subscription, the selected transport choice
> case in Kent’s suggestion above MUST match to the value of the
> “transport” leaf which is one level higher in the tree.  I.e.:
> 
>     +--rw subscriptions
> (Note on the tree above, I inserted the NETCONF and HTTP2 cases of
> transport for illustration purposes for the question below.  These
> two cases would actually be incorporated via separate augmentations
> to the ietf-subscribed-notifications.yang model.)
> 
> Considering above, It seems difficult to enforce that the transport
> cases selected under all receivers for a single subscription MUST be
> identical, and also MUST match to the value of the “transport” leaf
> under the subscription.

Why is the transport leaf needed if the choice cases identify the
transport? Why do all receivers of a subscription have to use the same
transport?

/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: Kent Watsen <[email-masked]>
Date: Thu, 26 Jul 2018 23:30:34 +0000

Hi Juergen,

> Why is the transport leaf needed if the choice cases identify the transport? 

My understanding is that this leaf is needed (exclusively?) to support the
enforcement that all the transports for a given subscription use the same
transport.

I've also been asking about this, partly from the "difficultly to enforce"
reason Eric mentions (though see the "when" statement in Eric's 7/20 email
where he resolves this, I thought), but also from a "are we making this
more difficult than needed?" perspective.

> 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.

Thinking out loud, I can sort-of, but not really, understand the motivation
for wanting to enforce the same encoding (xml, json, etc.) across receivers
and, since some transports may require certain encodings (i.e. netconf-->xml,
coap-->cbor, etc.), it carries that the transports should be the same too?

What I don't like about this argument is:

1) It's not user-friendly.  If a server really does have to send similar 
   subscriptions to a set receivers using different transports and/or 
   encodings, we've introduced what looks like an artificial need to 
   duplicate the subscriptions for each unique transport+encoding 
   combination.

2) I don't understand the implementation issue.  My view is that slightly
   clever code that caches encodings used could do this in one loop.  
   Here's some pseudo-pythonic code:

   send-notification-to-receivers(receivers, native-notification):
     xml-notification=None
     json-notification=None
     for receiver in receivers:
       if receiver.encoding is XML:
         if xml-notification is None:
           xml-notification = to-xml(native-notification)
         receiver.send(xml-notification)
       if receiver.encoding is JSON:
         if json-notification is None:
           json-notification = to-json(native-notification)
         receiver.send(json-notification)

Kent // as a contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 26 Jul 2018 23:35:04 +0000

Hi Juergen,

> From: Juergen Schoenwaelder, July 26, 2018 6:11 PM
> To: Eric Voit (evoit) <[email-masked]>
> Cc: Kent Watsen <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Re: [yang-doctors] YANG Doctor question: empty mandatory
> choice? (was RE: [Netconf] YangPush now)
> 
> > transport for illustration purposes for the question below.  These two
> > cases would actually be incorporated via separate augmentations to the
> > ietf-subscribed-notifications.yang model.)
> >

One transport for all receivers was a voted WG decision at IETF 101.  Some of the reasons from threads like:
https://www.ietf.org/mail-archive/web/netconf/current/msg13875.html
https://www.ietf.org/mail-archive/web/netconf/current/msg14899.html 

include:
(1) Simpler YANG model
(2) Simpler implementation possible as a single configured subscription need be connected to only one transport
(3) Simpler implementation in that there is no expectation set on the publisher that there will be no transport loss if the transport type is reconfigured for a particular receiver mid-subscription.
(4) Separation of implementation/troubleshooting concerns, as only one transport is involved

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jul 2018 08:05:07 +0200

> (4) Separation of implementation/troubleshooting concerns, as only one transport is involved

With the proposed choice construct, I think

(1) does not hold,
(2) seems unclear (why are multiple identitical subscriptions for
    different transports cheaper than one subscriptions with multiple
    transports?)
(3) I do not understand
(4) I do not understand (since you can easily distinguish the receiver
    and label log messages by receiver)

If we would be serious about simplification to lower the point of
entry, we would have only a single receiver for a configured
subscription. Allowing multiple receivers as long as they use the
same transport seems like an arbitrary CLR.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jul 2018 08:06:56 +0200

> coap-->cbor, etc.), it carries that the transports should be the same too?

The encoding can't be the reason because a single transport may allow
for different encodings.

/js

---

From: Robert Wilton <[email-masked]>
Date: Fri, 27 Jul 2018 12:11:56 +0100

Hi Eric,

Perhaps you don't need the transport leaf directly under the subscription.

One option would be for the standard to state:
  - Implementations MUST support multiple receivers with the same 
transport, and MAY support receivers with different transports.

A YANG "multiple-transports" feature could be defined to indicate that 
the device support receivers with multiple transports (so that the 
client can determine what is allowed).

If the device didn't implement the multiple-transports feature then this 
could probably be enforced with an must statement under each particular 
transports, although I'm not convinced that this really matters.

Thanks,
Rob

On 27/07/2018 00:35, Eric Voit (evoit) wrote:
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: Robert Wilton <[email-masked]>
Date: Fri, 27 Jul 2018 12:30:14 +0100

Hi Eric,

Please see inline ...

On 26/07/2018 20:22, Eric Voit (evoit) wrote:
>
> Hi YANG doctors,
>
> We are trying to close on some YANG push drafts.  There is one YANG 
> related question I would like to bounce off of you before making a 
> suggested change.
>
> In the thread:
>
> What I believe Kent is asking for is that the 
> ietf-subscribed-notifications.yang model should be enhanced to mandate 
> that transport specific call home parameters are augmented under the 
> container “receivers”.  He wants to do this by incorporating a 
> mandatory choice, with no cases being identified.  Cases would be 
> added via augmentations in subsequent drafts.
>
> is "to make the augmentation of a "notif" model mandatory (see the '+' 
> lines below), to ensure that there is always something more than just 
> a name being configured per receiver.
>
> container receivers {
>
> list receiver {
>
> key "name";
>
> min-elements 1;
>
> leaf name {
>
> type string;
>
> }
>
> +      choice transport {
>
> +        mandatory true;
>
> +        description
>
> “The notion of an empty mandatory choice really stretches the 
> definition of YANG Conformance. This says you cannot possible 
> implement the SN module without some other module augmenting it. Yet 
> there is no way in YANG (besides import) to say the module bar needs 
> to be present if module foo is present.”
>

I can definitely get Andy's point here.  I.e. that using mandatory as a 
conformance tool doesn't seem like a great choice.

However, I think that another angle is that the configuration for a 
receiver a transport must always be specified.  This seems like a 
reasonable constraint, so the mandatory also seems reasonable 
(regardless that it is specified as an empty choice).

> My first question to you is would you object to mandatory choice 
> statements without corresponding case statements?  If you *do* have an 
> issue with an empty mandatory choice, we should likely stay with the 
> current solution.
>
On balance, no I don't object.

> If you see no issue with an empty mandatory choice, I have a second 
> question for you.    For all receivers in a subscription, the selected 
> transport choice case in Kent’s suggestion above MUST match to the 
> value of the “transport” leaf which is one level higher in the tree.  
> I.e.:
>
>     +--rw subscriptions
>
As per my other email, I think that we should allow multiple transports, 
so the transport leaf is not required.

> Would the YANG doctors have any issue with the structure Kent suggests 
> above?  If no, would the YANG doctors then mandate that integrity 
> checks per performed across the receiver case instances under a 
> subscription?   And if mandated, how might XPATH be encoded 
> considering transport cases are only added via augmentation?
>
Personally, I wouldn't mandate an xpath constraint.  There are many real 
life constraints that are not encoded in YANG models today.

If it did need to be enforced then I think that it would be an xpath 
expression on each transport container.  Perhaps something along the 
lines of "the count of 'receivers' under the subscription must equal the 
count of '<transport-specific-container or leaf>".

Thanks,
Rob

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 27 Jul 2018 15:03:21 +0000

Hi Juergen,

I am fine either way if we incorporate the proposal or not.  Do you have the proposed construct is technically acceptable from the perspective of the YANG doctors?

Also below are some thoughts on your other points...

> From: Juergen Schoenwaelder, July 27, 2018 2:05 AM
> 
> > (2) Simpler implementation possible as a single configured
> > subscription need be connected to only one transport
> > (3) Simpler implementation in that there is no expectation set on the
> publisher that there will be no transport loss if the transport type is
> reconfigured for a particular receiver mid-subscription.

Agree.  

>     different transports cheaper than one subscriptions with multiple

Deep within the archived discussions, there were implementation consideration points made about managing content and security filtering across different transports and encodings for a single subscription.  (E.g., what happens if filtering happens after encoding and a change is made to the subscription or security filters, how do you ensure the all filtering is applied at the same event boundary?)

> (3) I do not understand

There are a set of implications which can be avoided.  For example controllers (which are receivers) will be consuming these events.  Controller based applications are less likely to have an expectation that there will no event replication for a single subscription-id for a publisher when that subscription-id transitions from one transport to another.  

> If we would be serious about simplification to lower the point of entry, we
> would have only a single receiver for a configured subscription. Allowing
> multiple receivers as long as they use the same transport seems like an
> arbitrary CLR.

Yes, this was considered.  However there are use cases where identical event streams must be sent for receiver redundancy reasons.  The current design can support that possibility.  Beyond that, there are deployment proof points from oc-telemetry.yang that this is a desirable capability.

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jul 2018 17:19:22 +0200

> I am fine either way if we incorporate the proposal or not.  Do you have the proposed construct is technically acceptable from the perspective of the YANG doctors?

I understand Andy's comment not as a YANG issue but a more general question
whether it is desirable to have a standard without a mandatory to implement
standard transport. This goes beyond YANG syntax.

> Deep within the archived discussions, there were implementation consideration points made about managing content and security filtering across different transports and encodings for a single subscr…

There is only one standard filtering mechanism (NACM) and that does
not filter on the encoding (and it would be a bad layer violation to
filter on the encoding). Since encodings may be negotiated by a
transport, the single encoding argument falls apart as well.
 
> There are a set of implications which can be avoided.  For example controllers (which are receivers) will be consuming these events.  Controller based applications are less likely to have an expect…

I am still clueless. What is a 'transitions of transport'? My naive
understanding of a subscription with a receiver and two transport is
that the data goes to both. Or is the idea that these serve has
failover backups? But then this may interact with similar features in
the call-home documents (I did not check again but I think there were
some failover mechanisms in there some time ago).

> Yes, this was considered.  However there are use cases where identical event streams must be sent for receiver redundancy reasons.  The current design can support that possibility.  Beyond that, th…

OK. But then, I have not yet understood why the transports have to be
the same in the model. (Which does not preclude that an implementation
has a deviation that requires the multiple receivers of a subscription
to use the same transport. And all this is only becoming an issue if
an implementation does actually support multiple transports.)

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 27 Jul 2018 15:33:05 +0000

Hi Robert,

> From: Robert Wilton, July 27, 2018 7:12 AM
> 
> Hi Eric,
> 
> A YANG "multiple-transports" feature could be defined to indicate that the
> device support receivers with multiple transports (so that the client can
> determine what is allowed).
> 

I am sympathetic to the possibilities.  There are some very cool modeling variants here.  Still, per the original thread "YangPush now", a current business objective is to see if we can conclude something with current drafts/scope.  As a single transport was the chosen consensus at and after IETF 100, going down this path would reopen some scoping discussions.   Note: for historical reasons, the discussion can be listened to at:
https://www.ietf.org/audio/ietf100/ietf100-collyer-20171116-1550.mp3
(Note: that starting at 57 minutes, you and others voice a preference for 'single' due to simplicity ;-).  Also in the recording, you can year me recognize Martin's unvarying position that encoding and transport be both the subscription level, or both be at the receiver level.  I.e., I don't see how this gets reopened, and we close soon.)

So stepping back, do you have any thoughts on whether the empty mandatory choice proposal is acceptable from the perspective of the YANG doctors?  I am good with either decision.

Thanks,
Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Jul 2018 18:15:16 +0200

> (Note: that starting at 57 minutes, you and others voice a preference for 'single' due to simplicity ;-).  Also in the recording, you can year me recognize Martin's unvarying position that encoding…

Still looks like a CLR and somewhat odd once you use a choice for the
transports of a receiver (using a choice likely was not yet proposed
back then).

Looking at the draft-ietf-netconf-subscribed-notifications-14.txt, how
do the states of a receiver work with multiple transports? It seems
some text in the draft kind of assumes that a receiver has a single
transport. It seems dynamic subscriptions always have just one
associated transport. Configured subscriptions apparently can have
multiple with some constraints and it is unclear how the configured
subscriptions states work with multiple transports.

I am not sure if I understand things right but it seems to me that a
subscription can have multiple receivers and every receiver can have
multiple transports. Perhaps simplifying this to 'a subscription can
have multiple receivers and every receiver has a single transport
(like in the dynamic subscription case) and there are no constraints
on the type of transports used by the different receivers' gives you a
model that is less complex, easier to clearly define (the state of a
receiver becomes simpler to derived from a single transport state) and
the model likely still does everything that is practically needed.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 27 Jul 2018 17:06:37 +0000

> From: Juergen Schoenwaelder, July 27, 2018 11:19 AM
> 
> > I am fine either way if we incorporate the proposal or not.  Do you have
> the proposed construct is technically acceptable from the perspective of the
> YANG doctors?
> >
> 
> I understand Andy's comment not as a YANG issue 
> but a more general
> question whether it is desirable to have a standard without a mandatory to
> implement standard transport. This goes beyond YANG syntax.

Agree this is a relevant question.  Kent has made a "chair hat" request on this (with Andy on the 'to' line):
https://www.ietf.org/mail-archive/web/netconf/current/msg15169.html 

directly after Andy said he wanted to complete the current drafts in their current form:
https://www.ietf.org/mail-archive/web/netconf/current/msg15167.html 

So I am hoping that thread can be used to close on the mandatory-to-implement question if there are concerns there.

> > > > https://www.ietf.org/mail-
> archive/web/netconf/current/msg13875.htm
> > > > l
> > > > https://www.ietf.org/mail-
> archive/web/netconf/current/msg14899.htm
> > > > l
> > > >
> > > > include:
> > > > (1) Simpler YANG model
> > > publisher that there will be no transport loss if the transport type
> > > is reconfigured for a particular receiver mid-subscription.
> > Deep within the archived discussions, there were implementation
> > consideration points made about managing content and security
> > filtering across different transports and encodings for a single
> > subscription.  (E.g., what happens if filtering happens after encoding
> > and a change is made to the subscription or security filters, how do
> > you ensure the all filtering is applied at the same event boundary?)
> 
> There is only one standard filtering mechanism (NACM) and that does not
> filter on the encoding (and it would be a bad layer violation to filter on the
> encoding). Since encodings may be negotiated by a transport, the single
> encoding argument falls apart as well.

Martin has been adamant over the course of several years that the configuration of both transport and encoding be at the same level of the subscription (either at the receiver level, or the subscription level.)  Perhaps there are legitimate platform implementation considerations.  Previous versions of this debate can be seen at:
https://www.ietf.org/mail-archive/web/netconf/current/msg13875.html

In the end, nobody has ever asserted use cases which demand that transports must be able to vary for a configured subscription.  So the previous WG consensus on this requirement seems reasonable despite the fact that the YANG modeling might end up more complicated (should Kent's empty choice statement proposal be deemed technically valid). 

> > > (3) I do not understand
> >
> > There are a set of implications which can be avoided.  For example
> controllers (which are receivers) will be consuming these events.  Controller
> based applications are less likely to have an expectation that there will no
> event replication for a single subscription-id for a publisher when that
> subscription-id transitions from one transport to another.
> 
> I am still clueless. What is a 'transitions of transport'? 

E.g., If somebody modifies a configured receiver from NETCONF to HTTP2.  Yes, the same issue could be asserted if you change the transport at the subscription level so that all receivers of all a subscription transition at once.  But at least you won't run into issues where there are there are transient deltas for a single subscription in the events delivered to different receivers of that same subscription.  

> My naive
> understanding of a subscription with a receiver and two transport is that
> the data goes to both. Or is the idea that these serve has failover backups?
> But then this may interact with similar features in the call-home documents
> (I did not check again but I think there were some failover mechanisms in
> there some time ago).

In discussions with Kent, there is a difference between failover (as covered by call-home), and dual live (which would be multiple receivers of the same subscription).
 
> > Yes, this was considered.  However there are use cases where identical
> event streams must be sent for receiver redundancy reasons.  The current
> design can support that possibility.  Beyond that, there are deployment
> proof points from oc-telemetry.yang that this is a desirable capability.
> >
> 
> OK. But then, I have not yet understood why the transports have to be the
> same in the model. (Which does not preclude that an implementation has a
> deviation that requires the multiple receivers of a subscription to use the
> same transport. And all this is only becoming an issue if an implementation
> does actually support multiple transports.)

Before IETF 100, transports were allowed to vary by receiver.   At the time, there seemed reasonable reasons to do this.   However previous attempts to see if there were actual use cases for such flexibility ended up with nobody chiming in.
https://www.ietf.org/mail-archive/web/netconf/current/msg13875.html
This is one of the reasons I didn't have an issue when the WG voted to simplify things by configuring the transport at the higher level of the subscription.

So if nothing else,  there is still implementation simplicity as the transport will only be populated once across the entire subscription.

Eric

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 27 Jul 2018 17:37:32 +0000

> From: Juergen Schoenwaelder, July 27, 2018 12:15 PM
> Cc: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
> <[email-masked]>; [email-masked]; [email-masked]
> > I am sympathetic to the possibilities.  There are some very cool modeling
> variants here.  Still, per the original thread "YangPush now", a current
> business objective is to see if we can conclude something with current
> drafts/scope.  As a single transport was the chosen consensus at and after
> IETF 100, going down this path would reopen some scoping discussions.
> Note: for historical reasons, the discussion can be listened to at:
> > (Note: that starting at 57 minutes, you and others voice a preference
> > for 'single' due to simplicity ;-).  Also in the recording, you can
> > year me recognize Martin's unvarying position that encoding and
> > transport be both the subscription level, or both be at the receiver
> > level.  I.e., I don't see how this gets reopened, and we close soon.)
> >
> 
> transports of a receiver
 (using a choice likely was not yet proposed back
> then).

Yes, the empty mandatory choice was not proposed then.   And honestly, I would be absolutely fine if the empty mandatory choice is not included in the final model.  

My intent in starting this thread is that I just want to give a fair hearing for Kent on whether his suggestion is technically acceptable.  While I don't see Kent's proposal as being especially pretty, it might be able to bring us to closure on what is perhaps the last technical issue for the current drafts.

> Looking at the draft-ietf-netconf-subscribed-notifications-14.txt, how do the
> states of a receiver work with multiple transports? It seems some text in
> the draft kind of assumes that a receiver has a single transport. It seems
> dynamic subscriptions always have just one associated transport.
> Configured subscriptions apparently can have multiple with some
> constraints and it is unclear how the configured subscriptions states work
> with multiple transports.

Figure 9 defines receiver state specific just for a single configured subscription from the perspective of a publisher.  It is valid to have a receiver handle multiple subscriptions using different transports.

> multiple transports. Perhaps simplifying this to 'a subscription can have
> multiple receivers and every receiver has a single transport (like in the
> dynamic subscription case)

There is no reason a single dynamic subscriber can't have independent subscriptions using different transports to the same publisher.  

>  and there are no constraints on the type of
> transports used by the different receivers' gives you a model that is less
> complex, easier to clearly define (the state of a receiver becomes simpler to
> derived from a single transport state) and the model likely still does
> everything that is practically needed.

Controllers will spin up and tear down multiple independent subscriptions within a single transport session.  This will be driven by applications sitting on controllers having different data needs.  One example of this would be creating a replay subscription to retrieve events dropped.   Also based on previous threads, there is also a need for the first configured subscription from a receive to initiate a separate transport session (even if a seemingly acceptable one is already is in place).  This avoids the possibility of some over-zealous dynamic subscription application from closing down a transport session subsequently used by a configured subscription.

Eric

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Jul 2018 10:42:41 -0700

Hi,

I would prefer to not add empty mandatory choices to any YANG module.
An empty choice is bad enough. In 2119 terms, using this container is a
SHOULD, not a MUST.

Andy

On Fri, Jul 27, 2018 at 10:37 AM, Eric Voit (evoit) <
evoit=[email-masked]> wrote:

> Yes, the empty mandatory choice was not proposed then.   And honestly, I
> would be absolutely fine if the empty mandatory choice is not included in
> the final model.
>
> My intent in starting this thread is that I just want to give a fair
> hearing for Kent on whether his suggestion is technically acceptable.
> While I don't see Kent's proposal as being especially pretty, it might be
> able to bring us to closure on what is perhaps the last technical issue for
> the current drafts.
>
> do the
> Figure 9 defines receiver state specific just for a single configured
> subscription from the perspective of a publisher.  It is valid to have a
> receiver handle multiple subscriptions using different transports.
>
> There is no reason a single dynamic subscriber can't have independent
> subscriptions using different transports to the same publisher.
>
> Controllers will spin up and tear down multiple independent subscriptions
> within a single transport session.  This will be driven by applications
> sitting on controllers having different data needs.  One example of this
> would be creating a replay subscription to retrieve events dropped.   Also
> based on previous threads, there is also a need for the first configured
> subscription from a receive to initiate a separate transport session (even
> if a seemingly acceptable one is already is in place).  This avoids the
> possibility of some over-zealous dynamic subscription application from
> closing down a transport session subsequently used by a configured
> subscription.
>
> Eric
>
> > /js
> >
> > --
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 27 Jul 2018 18:02:40 +0000

> An empty choice is bad enough. In 2119 terms, using this container is a

Moving past the syntax-level discussion:

1) do you agree that a transport MUST be configured?

       - if not, then how is this a configuration model when half the config is
         hidden behind vendor magic?  In my view, this pushes the limit of
         reasonableness.

  2) do you agree that at most only one transport can be configured per "receiver"?

        - this is perhaps arguable but, if needed, then I'd push for a list with
          min-elements 1.   That said, why support multiple transports under
          a single "receiver", when multiple "receiver" instances can be created,
          one for each?   Additionally, it muddies what the text means by
          "receiver state", as then there would have to be state per transport.

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Jul 2018 11:12:55 -0700

>          hidden behind vendor magic?  In my view, this pushes the limit of

Yes, but I do not agree it helps to force that configuration to be in this
choice-stmt.
A client developer is going to need the vendor YANG module before doing any
work
so they will see exactly where that config is located.

>           "receiver state", as then there would have to be state per

Yes -- I don't even like multiple receivers so the added complexity is not
justified.
(I would have preferred 1 receiver per subscription with the ability to use
another subscription
config by reference. IMO the state data is cleaner and the design is
cleaner, but that's not
what we have)

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 27 Jul 2018 20:27:28 +0000

> From: Kent Watsen, Friday, July 27, 2018 2:03 PM
> 
> > An empty choice is bad enough. In 2119 terms, using this container is
> > a SHOULD, not a MUST.
> 

I think transport MUST be configured.   

But as today's transport configuration is vendor specific, I am not sure as to whether this is a requirement which the SN YANG model structure itself enforces.  (See next comment.)

>   2) do you agree that at most only one transport can be configured per

Yes.  

There are alternative ways to do this.  For example we could assert that when a "-notif" draft designer does a augmentation of transport specific objects, those augmentations MUST include XPATH constraint from those objects to a specific instance of "transport" under the subscription.   (E.g., you can only augment leafref instances pointing to ietf-netconf-server if the subscription's transport is "NETCONF".)  For example:

module ietf-netconf-subscribed-notifications {
 
  prefix nsn;
 
  import ietf-netconf-client { prefix ncc; }
  import ietf-subscribed-notifications { prefix sn; }

  identity netconf {
    base sn:transport;
    base sn:inline-address;
    description
      "NETCONF is used as a transport for notification messages and
       state change notifications.";
  }

  augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
   when 'derived-from(../../../transport, "nsn:netconf")';   
   description
      "This augmentation allows NETCONF specific parameters to be exposed for a receiver.";
    leaf netconf-endpoint {
      type leafref {
        path "/ncc:netconf-client/ncc:initiate/ncc:netconf-server/ncc:endpoints/ncc:endpoint/ncc:name";
      }
      description
        "Remote client which need to initiate the NETCONF transport if an existing NETCONF session from that client is not available.";
    }
  }
  
}

With such models, one transport per receiver should result.

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 29 Jul 2018 17:41:14 +0200 (CEST)

> Martin seems to think it’s easier.

No; I personally also prefer a design where each receiver has its own
transport + encoding.  The original model had a common "encoding" for
all receivers, and then a receiver-specific transport - I think this
is even worse, 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.

>          receiver.send(json-notification)

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 29 Jul 2018 17:53:56 +0200 (CEST)

>    +           for the selected transport.";

In a generic model like this one, I think the construct with a
mandatory choice is ok.  However, I am not convinced that this is the
best solution for this model; it depends a bit if transport is defined
per receiver or per subscription.

I assume that an augmentation would be done like this:

    identity netconf { ... }

    augment /subscriptions/subscription/receivers/receiver/transport {
      when 'derived-from-or-self(../../../transport, "nsn:netconf"');
      
      case netconf {
        // leafref to call-home config
      }
    }
  }

... so that *if* the client configures the mandatory "transport" leaf
to "nsn:netconf", then it also MUST configure the corresponding
netconf-specific params.

/martin

> subscription?  And if mandated, how might XPATH be encoded considering
> transport cases are only added via augmentation?
> 
> 
> 
> Thanks,
> 
> Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 29 Jul 2018 17:59:24 +0200 (CEST)

> standard transport. This goes beyond YANG syntax.

I agree.  But I think it is ok, since we cannot mandate NETCONF or
RESTCONF (and note that RESTCONF doesn't even mandate an encoding...)

> transport, the single encoding argument falls apart as well.

I think that the idea is that if the config contains the encoding
"json", the server would advertise only "json" in the subscription
session.  This said, I also think this is a bad idea...

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 30 Jul 2018 15:28:21 +0000

Hi Martin,

> From: Martin Bjorklund, July 29, 2018 11:54 AM
> 
> In a generic model like this one, I think the construct with a mandatory choice
> is ok.

It sounds like YANG doctors don't have a technical objection to Kent's proposal of an empty mandatory choice.

>  However, I am not convinced that this is the best solution for this model;
> it depends a bit if transport is defined per receiver or per subscription.
> 
> ... so that *if* the client configures the mandatory "transport" leaf to
> "nsn:netconf", then it also MUST configure the corresponding netconf-specific
> params.

I agree that this is what an augmentation would look like.  (And based on the "../../../transport", this augmentation assumes that the WG sticks with it previous position that a transport stays at the subscription level).

As the proposed augmentation by itself enforces a specific set of NETCONF transport parameters are configured (in the form of the leafref when the transport is "nsn:netconf"), do you see the empty mandatory choice as providing value?   I am ok with either answer on this, I am just trying to get closure.

Eric

---

From: Kent Watsen <[email-masked]>
Date: Mon, 30 Jul 2018 18:04:33 +0000

> to "nsn:netconf", then it also MUST configure the corresponding

But this depends greatly on the "notif" model having the right
"when" statement.  Will non-IETF notif models always do this?

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 30 Jul 2018 20:41:42 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> > mandatory choice
> > to
> I agree that this is what an augmentation would look like.  (And based
> on the "../../../transport", this augmentation assumes that the WG
> sticks with it previous position that a transport stays at the
> subscription level).

Right, the when expression needs tweaking if the transport leaf moves.

> As the proposed augmentation by itself enforces a specific set of
> NETCONF transport parameters are configured (in the form of the
> leafref when the transport is "nsn:netconf"), do you see the empty
> mandatory choice as providing value?  I am ok with either answer on
> this, I am just trying to get closure.

The empty mandatory choice does provide value since it requires that
some transport-specific parameters are configured.  However, can we
assume that all transports require configuration parameters here?  It
is probably safest to not have a mandatory choice, and instead ensure
that each transport augements the proper params -- and since this is
YANG 1.1, the transport params that are augmented can actually be
marked as mandatory.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 30 Jul 2018 20:43:38 +0200 (CEST)

> "when" statement.  Will non-IETF notif models always do this?

It is not really crucial.  And if a vendor-specific model is badly
written, well, then it is badly written...

/martin

---

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

On Mon, Jul 30, 2018 at 08:41:42PM +0200, Martin Bjorklund wrote:
> assume that all transports require configuration parameters here?

Can you have a receiver without any transport parameters?

> It is probably safest to not have a mandatory choice, and instead ensure

Frankly, an empty mandatory choice quite clearly says "this is
incomplete and unusable without an augmentation".

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 31 Jul 2018 21:02:17 +0200 (CEST)

> Can you have a receiver without any transport parameters?

Who knows?  Maybe the transport parameters are obvious and static?

> incomplete and unusable without an augmentation".

Yes.  The question is if we can guarantee that *all* transoports
*require* configuration params.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 31 Jul 2018 19:39:18 +0000

> From: Juergen Schoenwaelder, July 31, 2018 1:48 PM
> 
> > It is probably safest to not have a mandatory choice, and instead
> > ensure that each transport augements the proper params -- and since
> > this is YANG 1.1, the transport params that are augmented can actually
> > be marked as mandatory.
> 
> Frankly, an empty mandatory choice quite clearly says "this is incomplete and
> unusable without an augmentation".

My read above is the YANG doctor's position is that we should *not* use the empty mandatory choice.  Let me know if I got this wrong.

That would mean that each transport document supporting configured subscriptions would then augment transport specific parameters to "/subscriptions/subscription/receivers/receiver".   And (assuming the "single transport" decision of IETF100 isn't changed), that the identity "transport" could be leveraged to enforce that only a single transport specific set of credentials are associated with a receiver.   

A sample YANG augmentation for NETCONF would then look like:

  prefix nsn;

  identity netconf {
    base sn:transport;
    base sn:inline-address;
    description

  augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
   when 'derived-from(../../../transport, "nsn:netconf")';   
   description
      "This augmentation allows NETCONF specific parameters to be 
      exposed for a receiver.";
    leaf netconf-endpoint {
      type leafref {
        path "/ncc:netconf-client/ncc:initiate/ncc:netconf-server" + 
                "/ncc:endpoints/ncc:endpoint/ncc:name";
      }
      mandatory true;
      description
        "Remote client which need to initiate the NETCONF transport if 
        an existing NETCONF session from that client is not available.";
    }
  }  
}

Which results in:
  +--rw subscriptions
     +--rw subscription* 
        +--rw transport         transport  {configured}?
        +--rw receivers
           +--rw receiver* 
              +--rw nsn:netconf-endpoint    leafref

Eric

---

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

On Tue, Jul 31, 2018 at 12:39 PM, Eric Voit (evoit) <[email-masked]> wrote:

> My read above is the YANG doctor's position is that we should *not* use
> the empty mandatory choice.  Let me know if I got this wrong.
>
>
I do not think a consensus call has been done yet, but I agree with Juergen
and already raised the point that YANG conformance does not handle a
"MUST augment" use-case very well.

I prefer the MUST be in the description-stmt for the choice,
instead of "mandatory true". (I prefer SHOULD but if the WG wants MUST)

Andy

> That would mean that each transport document supporting configured
> subscriptions would then augment transport specific parameters to
> "/subscriptions/subscription/receivers/receiver".   And (assuming the
> "single transport" decision of IETF100 isn't changed), that the identity
> "transport" could be leveraged to enforce that only a single transport
> specific set of credentials are associated with a receiver.
>