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

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 1 Aug 2018 15:40:43 +0000

From: Andy Bierman, July 31, 2018 4:32 PM

On Tue, Jul 31, 2018 at 12:39 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
> From: Juergen Schoenwaelder, July 31, 2018 1:48 PM
>
> On Mon, Jul 30, 2018 at 08:41:42PM +0200, Martin Bjorklund wrote:
> >
> > 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?
>
> Can you have a receiver without any transport parameters?
>
> > 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.

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)

<Eric> Do you see value in having the choice exposed?   Or if it is a SHOULD, is the mechanism below sufficient?

I am really ok with either, I just want to close.

Eric

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.

A sample YANG augmentation for NETCONF would then look like:

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";
      }
      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

> /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: Robert Wilton <[email-masked]>
Date: Wed, 1 Aug 2018 17:01:39 +0100

On 31/07/2018 21:31, Andy Bierman 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 think that "empty choice + mandatory true" it is OK from a conformance 
perspective.  The concept seems similar to an programmatic interface, 
abstract class, or even the abstract identity idea that has been 
proposed for YANG.  If a server implements the module but no augments of 
the choice then it cannot be configured because the constraint will 
always fail.  Andy, is your concern that tooling will warn that part of 
the model is unusable?

I have to say that much prefer the option of putting "mandatory: true" 
in the choice than "MUST provide an implementation" in the description 
because the former is machine readable whilst the latter is not.

However, I would also be fine not to have the "mandatory: true", but 
with the choice description to state something along the lines that the 
empty choice is to allow for augmentations of different transports, and 
configured subscriptions may not be usable unless at least one transport 
case statement is available."  But perhaps some implementation will 
provide the flexibility of defining a single transport for all 
subscriptions (if this is feasible).

One other observation that could affect the decision here is that YANG 
allows "mandatory: true" to be removed in a future revision in a 
backwards compatible way, but doesn't allow it to be added.

Thanks,
Rob

>     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.
>
>       augment
>     "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
>     > Fax:   +49 421 200 3103       
>      <https://www.jacobs-university.de/
>     <https://www.jacobs-university.de/>>
>
>
>
>
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Aug 2018 09:09:35 -0700

On Wed, Aug 1, 2018 at 9:01 AM, Robert Wilton <[email-masked]> wrote:

> 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.
>>
>>
> abstract class, or even the abstract identity idea that has been proposed
> for YANG.  If a server implements the module but no augments of the choice
> then it cannot be configured because the constraint will always fail.
> Andy, is your concern that tooling will warn that part of the model is
> unusable?
>

That is possible.
I agree with Juergen that a mandatory empty choice clearly indicates that
the module is incomplete
and unusable on its own.  Is that a feature?

Andy

>
> I have to say that much prefer the option of putting "mandatory: true" in
> the choice than "MUST provide an implementation" in the description because
> the former is machine readable whilst the latter is not.
>
> However, I would also be fine not to have the "mandatory: true", but with
> the choice description to state something along the lines that the empty
> choice is to allow for augmentations of different transports, and
> case statement is available."  But perhaps some implementation will provide
> the flexibility of defining a single transport for all subscriptions (if
> this is feasible).
>
> allows "mandatory: true" to be removed in a future revision in a backwards
> compatible way, but doesn't allow it to be added.
>
> Thanks,
> Rob
>
>
>
>> "/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.
>>
> yang-doctors mailing [email-masked]://www.ietf.org/mailman/listinfo/yang-doctors
>
>
>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 1 Aug 2018 17:48:11 +0100

On 01/08/2018 17:09, Andy Bierman wrote:
>
>
> On Wed, Aug 1, 2018 at 9:01 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>>     On Tue, Jul 31, 2018 at 12:39 PM, Eric Voit (evoit)
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         *not* use the empty mandatory choice.  Let me know if I got
>>         this wrong.
>>
>>
>     I think that "empty choice + mandatory true" it is OK from a
>     conformance perspective.  The concept seems similar to an
>     programmatic interface, abstract class, or even the abstract
>     identity idea that has been proposed for YANG.  If a server
>     implements the module but no augments of the choice then it cannot
>     be configured because the constraint will always fail.  Andy, is
>     your concern that tooling will warn that part of the model is
>     unusable?
>
>
> That is possible.
> I agree with Juergen that a mandatory empty choice clearly indicates 
> that the module is incomplete
Yes, making that indication is the whole purpose of adding the 
"mandatory: true" to the empty choice.  Note, that I see that the 
"mandatory true" is there to say that every configured subscription must 
have a transport configured, which if true, doesn't seem unreasonable.  
I.e. my main point is that I don't have an issue with this generic YANG 
design.

In this particular instance, I'm also fine if "mandatory: true" is left 
out, but I don't really agree with writing the equivalent of "mandatory: 
true" in the description, that seems like a poor compromise.

However, this is probably all bike-shedding.  I think that any of the 
discussed solutions is acceptable, as long as it is obvious to the 
readers of the YANG modules that a case statement must be provided for 
it to be useful, and I make the assumption that sane vendors won't 
enable the "configured" feature, if there is no actual way of 
configuring usable subscriptions.

Perhaps Eric can propose his preferred choice, and we can see if anyone 
still objects, otherwise maybe we can move on?

Thanks,
Rob

>
> Andy
>
>
>     I have to say that much prefer the option of putting "mandatory:
>     true" in the choice than "MUST provide an implementation" in the
>     description because the former is machine readable whilst the
>     latter is not.
>
>     However, I would also be fine not to have the "mandatory: true",
>     but with the choice description to state something along the lines
>     that the empty choice is to allow for augmentations of different
>     transports, and configured subscriptions may not be usable unless
>     at least one transport case statement is available."  But perhaps
>     some implementation will provide the flexibility of defining a
>     single transport for all subscriptions (if this is feasible).
>
>     One other observation that could affect the decision here is that
>     YANG allows "mandatory: true" to be removed in a future revision
>     in a backwards compatible way, but doesn't allow it to be added.
>
>     Thanks,
>     Rob
>
>
>>
>>         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.
>>
>>                 path
>>         "/ncc:netconf-client/ncc:initiate/ncc:netconf-server" +
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/yang-doctors>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Aug 2018 11:42:01 -0700

On Wed, Aug 1, 2018 at 9:48 AM, Robert Wilton <[email-masked]> wrote:

> Yes, making that indication is the whole purpose of adding the "mandatory:
> true" to the empty choice.  Note, that I see that the "mandatory true" is
> there to say that every configured subscription must have a transport
> configured, which if true, doesn't seem unreasonable.  I.e. my main point
> is that I don't have an issue with this generic YANG design.
>
>

It just seems strange that the model designers are positive the solution
belongs in a case-stmt inside
this choice.  So positive that MUST is in order, which means harm to the
Internet will
happen if this choice is not provided, with no possibility of any exception
ever.
That's why I suggested SHOULD in the first place, which would go in the
description-stmt.

I can imagine a vendor augmenting this choice with a <not-used/> leaf, just
to get rid of the
validation error.

Andy

> discussed solutions is acceptable, as long as it is obvious to the readers
> of the YANG modules that a case statement must be provided for it to be
> useful, and I make the assumption that sane vendors won't enable the
> "configured" feature, if there is no actual way of configuring usable
> subscriptions.
>
>>> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Aug 2018 17:00:16 -0700

On Wed, Aug 1, 2018 at 9:01 AM, Robert Wilton <[email-masked]> wrote:

> perspective.

It really is not OK, and has never been OK, which is why I think the next
version of YANG
should try to get this right.

As a client developer, I want to know the contract in advance, without any
missing clauses.
With a self-contained module (only internal + augment + uses) the entire
contract is clear
(at least module names are specified, maybe not revisions on imports  (Ver
DT will fix that)

A mandatory choice depending on 100% external augments is not
self-contained.
It is not a complete contract.

IMO, the way to fix it is to expand the conformance for YANG modules so
that packages
could be specified, or perhaps virtual external dependencies. YANG catalog
says what a vendor
does implement. YANG Conformance says what a vendor is supposed to
implement.
The client developer needs to know both.

Andy

> The concept seems similar to an programmatic interface, abstract class, or
> even the abstract identity idea that has been proposed for YANG.  If a
> server implements the module but no augments of the choice then it cannot
> be configured because the constraint will always fail.  Andy, is your
> concern that tooling will warn that part of the model is unusable?
>
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 2 Aug 2018 01:34:47 +0000

> It just seems strange that the model designers are positive the solution belongs in a
> case-stmt inside this choice.  So positive that MUST is in order, which means harm
> to the Internet will happen if this choice is not provided, with no possibility of any
>  exception ever.

Disagree.  As Robert pointed out, the yang update rules allow mandatory true to
become mandatory false.  In my view, choosing to do the "mandatory true" now
is the conservative choice.

PS: I do not believe it is possible to have a receiver that does not define a transport.
       If that were allowed, then it would be vendor magic.

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Aug 2018 18:42:03 -0700

On Wed, Aug 1, 2018 at 6:34 PM, Kent Watsen <[email-masked]> wrote:

> belongs in a

OK -- I do think it is a huge burden for a vendor to provide an augment,
even if it is just to indicate "my real transport config is over there
or it is not in YANG".

Andy

---

From: Robert Wilton <[email-masked]>
Date: Thu, 2 Aug 2018 11:39:40 +0100

On 02/08/2018 01:00, Andy Bierman wrote:
>     conformance perspective.
> It really is not OK, and has never been OK, which is why I think the 
> next version of YANG
> As a client developer, I want to know the contract in advance, without 
> any missing clauses.
> With a self-contained module (only internal + augment + uses) the 
> entire contract is clear
> (at least module names are specified, maybe not revisions on imports 
>  (Ver DT will fix that)
>
> IMO, the way to fix it is to expand the conformance for YANG modules 
> so that packages
> could be specified, or perhaps virtual external dependencies. YANG 
> catalog says what a vendor
So, this is moving away from Eric's issue.

Yes, I agree that we need to define something like packages.

Although I can partly see conformance at being at the module level, I'm 
not convinced that is most useful.  Instead, once you consider 
deviations and data node lifecycles, then I think that it is more 
helpful to consider conformance at the schema (and per data-node) level.

In the case of schema, I mean the combination of (a set of implemented 
module revisions (including deviations), import-only module revisions, 
supported features, supported datastores).  I.e. the information that is 
being exposed via YANG libary(-bis).

So, for a client to check whether a device will accept its 
configuration, it constructs a schema of all data nodes it is 
configuring/accessing, along with their types and constraints, and then 
compares every data node in the schema against the schema supported by 
the device (yes, I agree that the schema should be available up front 
rather than only via YANG library, which is similar to Balazs's draft 
relating to YANG instance data).

I anticipate that your reaction might be to say that this sounds very 
complicated, but at the end of the day, I think that this is probably 
the simplest robust way of ensuring compatibility, once you take 
deviations, versioning, features all into account.

Thanks,
Rob

>
>
> Andy
>
>     The concept seems similar to an programmatic interface, abstract
>     class, or even the abstract identity idea that has been proposed
>     for YANG.  If a server implements the module but no augments of
>     the choice then it cannot be configured because the constraint
>     will always fail.  Andy, is your concern that tooling will warn
>     that part of the model is unusable?
>
>
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 2 Aug 2018 13:05:07 +0000

From: Andy Bierman, August 1, 2018 9:42 PM

<Eric>  Instead of “augment” for now we will simply going to deviate away the “empty mandatory choice” until call home information is placed into vendor native or IETF YANG models.

That deviate approach is easier than augmentation.  And it matches what we need to do when something isn’t available in YANG anyway.

Does anyone have an issue if we try a consensus call on Kent’s proposal of “empty mandatory choice”?

Eric

Kent // contributor

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 05 Aug 2018 11:11:23 +0200 (CEST)

Robert Wilton <rwilton=[email-masked]> wrote:
> "mandatory true" is there to say that every configured subscription
> must have a transport configured, which if true, doesn't seem
> unreasonable.

Note that the model already has a 'transport' leaf that is mandatory.

The choice is an explicit placeholder for transport-specific
additional parameters.

This proposed design is slightly different than the design in
ietf-interfaces; in interfaces we have:

   leaf type { ... }
   // type-specific augmentations here

For example (from the RFC):

   augment "/if:interfaces/if:interface" {
     when "if:type = 'ianaift:ethernetCsmacd'";

     container ethernet {
       leaf duplex {
         ...
       }
     }
   }

In the notif model the proposal is:

  leaf transport { ... }

  ...
    choice transport-specific-params {
      // transport-specific augmentations here
    }

Note that if the choice is not marked as mandatory, the resulting
model will be less strict / useful compared to using a design like in
the interfaces model (w/o the choice).  To demonstrate, suppose we
have a transport 'example-udp' that needs a mandatory 'address' and an
optional 'port'.  With the choice we'd have:

  augment '/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver'
        + '/sn:transport-specific-params' {
    when 'derived-from(../../../../transport, "ex:example-udp")';

    case example-udp-params {
      leaf address {
        mandatory true;
        ...
      }
      leaf port {
        ...
      }
    }
  }
  
If the choice is not mandatory, the model would allow a client to
configure the transport leaf to 'example-udp', but not configure an
address.

Without the choice, we'd do:

  augment '/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver'
    when 'derived-from(../../../transport, "ex:example-udp")';

    leaf address {
      mandatory true;
      ...
    }
    leaf port {
      ...
    }
  }

In this case, or if the choice is mandatory, the model would require
the client to configure an address if the transport is 'example-udp',
which is what we want.

But if the choice is marked as mandatory, *all* transports MUST define
some transport-specific parameters, even if that is not needed
(unclear if this will ever happen...)

Thus, I prefer Eric's original model w/o the choice.  The choice is
supposed to be clever, but might end up being confusing, and I don't
think it adds any value anyway.

/martin

> I.e. my main point is that I don't have an issue with
> this generic YANG design.
> 
> In this particular instance, I'm also fine if "mandatory: true" is
> left out, but I don't really agree with writing the equivalent of
> "mandatory: true" in the description, that seems like a poor
> compromise.
> 
> Perhaps Eric can propose his preferred choice, and we can see if
> anyone still objects, otherwise maybe we can move on?
> 
> Thanks,
> Rob
> 
> 
> >
> > Andy
> >
> >

---

From: Kent Watsen <[email-masked]>
Date: Mon, 6 Aug 2018 17:02:50 +0000

[top-posting for lack of time]

Hi Martin,

Interesting that you view the "transport" leaf as where the decision is 
made.  I suppose that is the case now, but I always viewed the leaf as 
a somewhat artificial "anchor" that was added only to support the "when"
expression to assert homogeneity.  The 

On that, note that I merely said that I was sympathetic to the POV; I'm
not convinced that there is a problem allowing heterogeneity, as what's
been posted thus far for why it might be a [performance?] problem was 
conjecture.

A fully cooked example would be helpful here, but I think you want:

  <receivers>
    <receiver>
      <name>foo</name>
      <ex:param1>...</ex:param1>
      <ex:param2>...</ex:param2>
      <ex:param3>...</ex:param3>
    </receiver>
  </receivers>

whereas I was thinking that there would be a container, e.g.

  <receivers>
    <receiver>
      <name>foo</name>
      <ex:udp-pub-sub>
        <param1>...</param1>
        <param2>...</param2>
        <param3>...</param3>
      </ex:udp-pub-sub>
    </receiver>
  </receivers>

which acts as the transport-selector, and hence homogeneity (if needed),
could be via a "must" expression that ensures that there is only one
such descendent, other than "name", across the receivers.  This is what
that "must" expression I proffered last week was trying to do.  If we 
can do this, I think the model simplifies, as then the [artificial?] 
"transport" and "encoding" leaves, and the "when" expressions, wouldn't
be needed to still assert the homogeneity.

Thoughts?

Kent // contributor

   leaf type { ... }

     container ethernet {
       leaf duplex {
         ...
       }
     }
   }

  leaf transport { ... }

  ...

  

    leaf address {
      mandatory true;
      ...
    }
    leaf port {
      ...
    }
  }

/martin

> >>          <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nvlGbzwaLflz8fPtIV-iMrmk_M-b_KUsBI5XkyR6OQA&s=HOUalUJdAOVqj49diEzGM-Z-35a5rPmj2Y4NfhsdovQ&e=
> >>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nvlGbzwaLflz8fPtIV-iMrmk_M-b_KUsBI5XkyR6OQA&s=HOUalUJdAOVqj49diEzGM-Z-35a5rPmj2Y4NfhsdovQ&e=>>
> >>
> >>
> >>
> >>
> >>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nvlGbzwaLflz8fPtIV-iMrmk_M-b_KUsBI5XkyR6OQA&s=O67dhIVon_08t5AfSaVuRD1q-v2D8tAoezbECOsGoHY&e=
> >>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nvlGbzwaLflz8fPtIV-iMrmk_M-b_KUsBI5XkyR6OQA&s=O67dhIVon_08t5AfSaVuRD1q-v2D8tAoezbECOsGoHY&e=>
> >
> >
> 
_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nvlGbzwaLflz8fPtIV-iMrmk_M-b_KUsBI5XkyR6OQA&s=8uwYVApwY6kkzVSQBhp7pYLX9cex7YQ35Dyymf1wK2o&e=

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Aug 2018 20:00:27 +0200 (CEST)

> be needed to still assert the homogeneity.

Well, I don' think you can do what you want to do with a must
expression like that.

Also, I think the design w/ selecting a transport with an identity is
fine.  IMO both designs work; either use a discriminating leaf
(transport) and use augment with a "when" expression, or use a
mandatory choice where each case denotes which transport is used.

With the design choice that all receivers must use the same transport
+ encoding, the current design actually works better than a choice,
imo.

/martin

---

From: tom petch <[email-masked]>
Date: Tue, 7 Aug 2018 08:47:42 +0000

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
Sent: Sunday, August 05, 2018 10:11 AM
Robert Wilton <rwilton=[email-masked]> wrote:
> > On Wed, Aug 1, 2018 at 9:01 AM, Robert Wilton
<mailto:[email-masked]>> wrote:
> >>     On Tue, Jul 31, 2018 at 12:39 PM, Eric Voit (evoit) wrote:

<snip>

<tp>
which I think it the key point.  Look at the discussion that has been
generated on this list, where there is more YANG expertise than almost
anywhere else, and wonder how the average implementer will cope with a
mandatory, empty choice.  Clever, yes, good idea, err no, not for an
RFC.

Tom Petch

/martin

<snip>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 9 Aug 2018 14:38:33 +0000

> mandatory, empty choice.  Clever, yes, good idea, err no, not for an

Martin makes an interesting point about how to model augmented in can
assert which nodes are mandatory, which we assume will always happen,
but it's not really our problem if they don't.

Also, regarding the idea of using distinct-values(), I don't think
we can, because it's only in XPath 2.0.  Besides, the intermediate
containers didn't look nice.

I am okay with removing the choice statement.

[as chair: Any other comments?]

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Tue, 14 Aug 2018 19:50:35 +0000

No further comments are coming, so it seems that we've reached in end.
I'm glad we had the discussion.

Eric, please post an updated SN draft without the mandatory choice.

Kent

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 14 Aug 2018 21:17:48 +0000

Hi Kent,

Before I post the change, there is the question of whether SN Appendix A should be totally dropped, or whether it should be tweaked and inserted into NETCONF-Notif.   

Moving it to NETCONF-Notif would allow SN section 2.5.7 to retain a reference to a non-normative example augmentation without SN becoming dependent on a document split of RESTCONF-Notif.

Eric

> https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 14 Aug 2018 23:54:47 +0200 (CEST)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> Hi Kent,
> 
> Before I post the change, there is the question of whether SN Appendix
> A should be totally dropped, or whether it should be tweaked and
> inserted into NETCONF-Notif.

I think an example of what a transport-specific module looks like
should be in this document.  Adding an example tranport module to the
netconf transport draft (that eventually already defines a real
transport module) doesn't make much sense.

However, the example in this draft should be made for an example
transport, rather than for NETCONF.  And the module should be named as
such.  Specifically, it must not be called
"ietf-netconf-subscribed-notifications", but instead
"example-something...".

/martin

> 
> Moving it to NETCONF-Notif would allow SN section 2.5.7 to retain a
> reference to a non-normative example augmentation without SN becoming
> dependent on a document split of RESTCONF-Notif.
> 
> Eric
>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 14 Aug 2018 22:03:41 +0000

Hi Eric,

I think it's okay to leave that appendix section and associated reference
in Section 2.5.7, for the purpose of the Last Calls.  I do not think that
the section should be moved to the netconf-notif draft, as it is unclear
if the WG will ever standardize *configured* NETCONF notifications.

Kent

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

Hi Kent,

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 15 Aug 2018 20:57:43 +0000

Hi Kent,
Hi Martin,

I posted -v16.   This version:

(1) Removes the empty mandatory choice "transport"

(2) Updates non-normative Appendix A so the example configured transport is no longer "NETCONF".  Instead it is now of transport "Foo".  Note: to stop automated inclusion in IETF model catalogs, I removed the <CODE BEGINS> and <CODE ENDS> for the augmentation example in Appendix A.  If instead either of you prefer renaming the YANG model to "example-transport-foo", and this renaming would also exclude the model from IETF processes, I am happy to make such a change.

Beyond this, I am not aware of other open issues.

Eric

> From: Martin Bjorklund, August 14, 2018 5:55 PM
> 
> Hi,
> 
> I think an example of what a transport-specific module looks like should be in
> this document.  Adding an example tranport module to the netconf transport
> draft (that eventually already defines a real transport module) doesn't make
> much sense.
> 
> However, the example in this draft should be made for an example transport,
> rather than for NETCONF.  And the module should be named as such.
> Specifically, it must not be called "ietf-netconf-subscribed-notifications", but
> instead "example-something...".
> 
> 
> 
> /martin
> 
> 
> 
> 
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 Aug 2018 23:03:16 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> (2) Updates non-normative Appendix A so the example configured
> transport is no longer "NETCONF".  Instead it is now of transport
> "Foo".  Note: to stop automated inclusion in IETF model catalogs, I
> removed the <CODE BEGINS> and <CODE ENDS> for the augmentation example
> in Appendix A.  If instead either of you prefer renaming the YANG
> model to "example-transport-foo", and this renaming would also exclude
> the model from IETF processes, I am happy to make such a change.

Yes, all example modules that we put into rfcs should be called
example-...  See section 4.1 in 6087bis.

I think Kent had some suggestion for how to name the transport
modules, so we should follow that also for this example module.

/martin

> > should be in
> > transport,
> > Specifically, it must not be called
> > "ietf-netconf-subscribed-notifications", but