Re: [netmod] rib-data-model and routing-cfg

[Ladislav Lhotka]

> On 21 Oct 2015, at 15:26, Rob Shakir  wrote:
> 
> On 15 October 2015 at 15:13:38, Acee Lindem (acee) (a...@cisco.com) wrote:
>> 
>> Do we really see associating the same interface with different 
>> routing-instances for IPv4 and IPv6? I can seem to remember the use case 
>> and it does add complexity forever. 
>> 
> 
> At least two of the operators for whom I have worked utilise this 
> functionality (providing separate L3VPNs for IPv6 and IPv4) - so in my 
> experience, it is not possible to make this simplification.

One option would be to create two virtual interfaces - one for IPv4 VPN and 
another for IPv6 VPN, and define routing-instance and addresses separately for 
each.

Lada

> 
> r.

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] open-source yang-explorer application

[Benoit Claise]

Great. Thanks Pravin.

Regards, Benoit

Hi All,

As demonstrated in IETE 93 hackthon and Bits & Byte Session, Yang 
Explorer (beta) a open source web based yang browser and RPC 
builder/Tester(w/ncclient)  is now available on github.


https://github.com/CiscoDevNet/yang-explorer

Please let me know if you have any question/comments regarding it. You 
are welcome to contribute to the project.


Thanks,
Pravin
. 


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Martin Bjorklund]

Andy Bierman  wrote:

[...]

> But the "when-stmt" never causes an error for application within
> a datastore.
> 
> The text in sec. 8 does not apply because the when-stmt is not
> on any object in the RPC being processed.
> 
> Only this text applies:
> 
>The "when" statement makes its parent data definition statement
>conditional.  The node defined by the parent data definition
>statement is only valid when the condition specified by the "when"
>statement is satisfied.
> 
> 
> The NETCONF specific text needs to change.
> Simply putting , "For example, NETCONF ..." might be enough.

Can you be more specific - exactly where do you suggest this change?


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Andy Bierman]

On Wed, Oct 21, 2015 at 11:15 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
>
> [...]
>
> > But the "when-stmt" never causes an error for application within
> > a datastore.
> >
> > The text in sec. 8 does not apply because the when-stmt is not
> > on any object in the RPC being processed.
> >
> > Only this text applies:
> >
> >The "when" statement makes its parent data definition statement
> >conditional.  The node defined by the parent data definition
> >statement is only valid when the condition specified by the "when"
> >statement is satisfied.
> >
> >
> > The NETCONF specific text needs to change.
> > Simply putting , "For example, NETCONF ..." might be enough.
>
> Can you be more specific - exactly where do you suggest this change?
>
>
Not really -- there are way too many places the draft refers to
NETCONF operations, where it could just be referring to a configuration
datastore.

The draft does not even cover proprietary access RPCs.
If somebody defined  the same datastore validation
procedures should apply to the conceptual configuration datastore.




>
> /martin
>

Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] open-source yang-explorer application

[Pravin Gohite (prgohite)]

Hi All,

As demonstrated in IETE 93 hackthon and Bits & Byte Session, Yang Explorer 
(beta) a open source web based yang browser and RPC builder/Tester(w/ncclient)  
is now available on github.

https://github.com/CiscoDevNet/yang-explorer

Please let me know if you have any question/comments regarding it. You are 
welcome to contribute to the project.

Thanks,
Pravin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Andy Bierman]

On Wed, Oct 21, 2015 at 6:22 AM, Ladislav Lhotka  wrote:

>
> > On 21 Oct 2015, at 15:07, Andy Bierman  wrote:
> >
> >
> >
> > On Wed, Oct 21, 2015 at 5:46 AM, Ladislav Lhotka  wrote:
> >
> > > On 21 Oct 2015, at 14:33, Andy Bierman  wrote:
> > >
> > > Hi,
> > >
> > > IMO we do not need lots of rules for when-stmt.
> > > They are harder to enforce than just implementing the auto-deletion.
> > >
> > > Note that auto-deletion also applies to nodes already in candidate or
> running.
> > > It is just a derivative case to have a newly-created node deleted
> right away.
> > > If you add node /foo it may cause node /bar and node /baz to get
> deleted.
> > >
> > > I strongly object to treating a false when-stmt in a datastore
> validation
> > > as an error.  This is not how YANG 1.0 works, and this is not
> > > backward-compatible.
> >
> > I think it has nothing to do with YANG (1.0 or whatever), and RFC 6020
> correctly describes this auto-deletion behaviour for "choice" in sec. 7.9.6
> NETCONF  Operations. It is indeed protocol business - YANG
> spec should just define what's valid and what isn't.
> >
> > IMO RESTCONF spec doesn't require auto-deletion.
> >
> >
> >
> > Our server uses the same validation engine for both protocols.
> > RESTCONF does not change the behavior of YANG in any way.
> > I don't see how YANG validation procedures would not apply to RESTCONF.
>
> The validation procedure does apply (the notion of a valid data tree has
> to be the same) but auto-deletion doesn't because it is specified in
> "NETCONF  ..." sections (7.9.6 and 8.3.2), and RESTCONF
> doesn't use .
>
> >
> > YANG says that the node semantics apply IFF the when-stmt evaluates to
> true.
> > It is up to the implementation to enforce that.  It applies to
> server-created
> > nodes or nodes created via some protocol.
>
> Yes, but it can be enforced either by auto-deleting offending nodes, or by
> refusing to accept changes that lead to an invalid configuration.
>
>

But the "when-stmt" never causes an error for application within
a datastore.

The text in sec. 8 does not apply because the when-stmt is not
on any object in the RPC being processed.

Only this text applies:

   The "when" statement makes its parent data definition statement
   conditional.  The node defined by the parent data definition
   statement is only valid when the condition specified by the "when"
   statement is satisfied.


The NETCONF specific text needs to change.
Simply putting , "For example, NETCONF ..." might be enough.





> Lada
>
>
Andy


> >
> >
> > Lada
> >
> > Andy
> >
> >
> > >
> > >
> > > Andy
> > >
> > >
> > > On Wed, Oct 21, 2015 at 5:16 AM, Balazs Lengyel <
> balazs.leng...@ericsson.com> wrote:
> > > Hello Martin,
> > > I would want to codify this. My earlier proposal was:
> > >
> > > - when MUST NOT be dependent on a data node controlled by a when or
> choice statement
> > >
> > > Notice the strong MUST NOT statement. This would simplify life greatly.
> > > regards Balazs
> > >
> > > On 2015-10-20 10:09, Martin Bjorklund wrote:
> > > I have never seen anyone trying to refer to the conditional nodes in a
> > > when expression - simply b/c it doesn't make any sense.
> > >
> > > --
> > > Balazs Lengyel   Ericsson Hungary Ltd.
> > > Senior Specialist
> > > ECN: 831 7320
> > > Mobile: +36-70-330-7909  email:
> balazs.leng...@ericsson.com
> > >
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Andy Bierman]

On Wed, Oct 21, 2015 at 5:46 AM, Ladislav Lhotka  wrote:

>
> > On 21 Oct 2015, at 14:33, Andy Bierman  wrote:
> >
> > Hi,
> >
> > IMO we do not need lots of rules for when-stmt.
> > They are harder to enforce than just implementing the auto-deletion.
> >
> > Note that auto-deletion also applies to nodes already in candidate or
> running.
> > It is just a derivative case to have a newly-created node deleted right
> away.
> > If you add node /foo it may cause node /bar and node /baz to get deleted.
> >
> > I strongly object to treating a false when-stmt in a datastore validation
> > as an error.  This is not how YANG 1.0 works, and this is not
> > backward-compatible.
>
> I think it has nothing to do with YANG (1.0 or whatever), and RFC 6020
> correctly describes this auto-deletion behaviour for "choice" in sec. 7.9.6
> NETCONF  Operations. It is indeed protocol business - YANG
> spec should just define what's valid and what isn't.
>
> IMO RESTCONF spec doesn't require auto-deletion.
>
>

Our server uses the same validation engine for both protocols.
RESTCONF does not change the behavior of YANG in any way.
I don't see how YANG validation procedures would not apply to RESTCONF.

YANG says that the node semantics apply IFF the when-stmt evaluates to true.
It is up to the implementation to enforce that.  It applies to
server-created
nodes or nodes created via some protocol.


Lada
>

Andy


>
> >
> >
> > Andy
> >
> >
> > On Wed, Oct 21, 2015 at 5:16 AM, Balazs Lengyel <
> balazs.leng...@ericsson.com> wrote:
> > Hello Martin,
> > I would want to codify this. My earlier proposal was:
> >
> > - when MUST NOT be dependent on a data node controlled by a when or
> choice statement
> >
> > Notice the strong MUST NOT statement. This would simplify life greatly.
> > regards Balazs
> >
> > On 2015-10-20 10:09, Martin Bjorklund wrote:
> > I have never seen anyone trying to refer to the conditional nodes in a
> > when expression - simply b/c it doesn't make any sense.
> >
> > --
> > Balazs Lengyel   Ericsson Hungary Ltd.
> > Senior Specialist
> > ECN: 831 7320
> > Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Ladislav Lhotka]

> On 21 Oct 2015, at 15:07, Andy Bierman  wrote:
> 
> 
> 
> On Wed, Oct 21, 2015 at 5:46 AM, Ladislav Lhotka  wrote:
> 
> > On 21 Oct 2015, at 14:33, Andy Bierman  wrote:
> >
> > Hi,
> >
> > IMO we do not need lots of rules for when-stmt.
> > They are harder to enforce than just implementing the auto-deletion.
> >
> > Note that auto-deletion also applies to nodes already in candidate or 
> > running.
> > It is just a derivative case to have a newly-created node deleted right 
> > away.
> > If you add node /foo it may cause node /bar and node /baz to get deleted.
> >
> > I strongly object to treating a false when-stmt in a datastore validation
> > as an error.  This is not how YANG 1.0 works, and this is not
> > backward-compatible.
> 
> I think it has nothing to do with YANG (1.0 or whatever), and RFC 6020 
> correctly describes this auto-deletion behaviour for "choice" in sec. 7.9.6 
> NETCONF  Operations. It is indeed protocol business - YANG spec 
> should just define what's valid and what isn't.
> 
> IMO RESTCONF spec doesn't require auto-deletion.
> 
> 
> 
> Our server uses the same validation engine for both protocols.
> RESTCONF does not change the behavior of YANG in any way.
> I don't see how YANG validation procedures would not apply to RESTCONF.

The validation procedure does apply (the notion of a valid data tree has to be 
the same) but auto-deletion doesn't because it is specified in "NETCONF 
 ..." sections (7.9.6 and 8.3.2), and RESTCONF doesn't use 
.

> 
> YANG says that the node semantics apply IFF the when-stmt evaluates to true.
> It is up to the implementation to enforce that.  It applies to server-created
> nodes or nodes created via some protocol.

Yes, but it can be enforced either by auto-deleting offending nodes, or by 
refusing to accept changes that lead to an invalid configuration.

Lada

> 
> 
> Lada
> 
> Andy
>  
> 
> >
> >
> > Andy
> >
> >
> > On Wed, Oct 21, 2015 at 5:16 AM, Balazs Lengyel 
> >  wrote:
> > Hello Martin,
> > I would want to codify this. My earlier proposal was:
> >
> > - when MUST NOT be dependent on a data node controlled by a when or choice 
> > statement
> >
> > Notice the strong MUST NOT statement. This would simplify life greatly.
> > regards Balazs
> >
> > On 2015-10-20 10:09, Martin Bjorklund wrote:
> > I have never seen anyone trying to refer to the conditional nodes in a
> > when expression - simply b/c it doesn't make any sense.
> >
> > --
> > Balazs Lengyel   Ericsson Hungary Ltd.
> > Senior Specialist
> > ECN: 831 7320
> > Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Andy Bierman  wrote:
>> Hi,
>> 
>> I updated the YANG guidelines draft.
>
> I have a couple of comments.
>
> --
>
> Section 5.14 says:
>
> The "choice" statement is allowed to be directly present within a
> "case" statement in YANG 1.1.
>
> It is allowed in YANG 1 as well.
>
> This needs to be considered
> carefully.  Consider simply including the nested "choice" as
> additional "case" statements within the parent "choice" statement.
>
> Ok, but I don't think people use nested choice by accident.  I have
> seen it used a handful of times, and there was always a good reason
> for doing it.  If you think some warning text like this is needed, I

But isn't it that in these legitimate cases the inner choice is always
accompanied by other nodes within the same case? The solution to Y29
enables choice as a short-hand case, and this can always be
flattened. Do I miss something?

Lada

> suggest something along the lines of:
>
> If a "case" statement contains a single "choice" statement,
> consider simply including ...
>
> --
>
> Section 5.1 says:
>
>Normative modules contained in Standards Track documents
>  MUST be named according to the guidelines in the IANA
>  Considerations section of [I-D.ietf-netmod-rfc6020bis].
>
>
> Note that since 6020bis doesn't obsolete 6020, the IANA Considerations
> text is not copied to 6020bis.  So either reference 6020, or copy the
> rule (use "ietf-" prefix).
>
>
>
>
> /martin
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Andy Bierman  wrote:
> >> Hi,
> >> 
> >> I updated the YANG guidelines draft.
> >
> > I have a couple of comments.
> >
> > --
> >
> > Section 5.14 says:
> >
> > The "choice" statement is allowed to be directly present within a
> > "case" statement in YANG 1.1.
> >
> > It is allowed in YANG 1 as well.
> >
> > This needs to be considered
> > carefully.  Consider simply including the nested "choice" as
> > additional "case" statements within the parent "choice" statement.
> >
> > Ok, but I don't think people use nested choice by accident.  I have
> > seen it used a handful of times, and there was always a good reason
> > for doing it.  If you think some warning text like this is needed, I
> 
> But isn't it that in these legitimate cases the inner choice is always
> accompanied by other nodes within the same case? The solution to Y29
> enables choice as a short-hand case, and this can always be
> flattened. Do I miss something?

No you're right.  It should also be noted that an implementation can
choose to flatten such nested choices.


/martin



> 
> Lada
> 
> > suggest something along the lines of:
> >
> > If a "case" statement contains a single "choice" statement,
> > consider simply including ...
> >
> > --
> >
> > Section 5.1 says:
> >
> >Normative modules contained in Standards Track documents
> >MUST be named according to the guidelines in the IANA
> >Considerations section of [I-D.ietf-netmod-rfc6020bis].
> >
> >
> > Note that since 6020bis doesn't obsolete 6020, the IANA Considerations
> > text is not copied to 6020bis.  So either reference 6020, or copy the
> > rule (use "ietf-" prefix).
> >
> >
> >
> >
> > /martin
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt

[Jernej Tuljak]

Andy Bierman je 20.10.2015 ob 3:41 napisal:

Hi,

I updated the YANG guidelines draft.
All open issues have been addressed in this version.

https://github.com/netmod-wg/rfc6087bis/issues


You missed this: 
https://www.ietf.org/mail-archive/web/netmod/current/msg13593.html


Applies to both YANG 1.0 and current 1.1 text.

Jernej




Andy



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt

[Ladislav Lhotka]

> On 21 Oct 2015, at 09:17, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> Martin Bjorklund  writes:
>> 
>>> Andy Bierman  wrote:
 Hi,
 
 I updated the YANG guidelines draft.
>>> 
>>> I have a couple of comments.
>>> 
>>> --
>>> 
>>> Section 5.14 says:
>>> 
>>>The "choice" statement is allowed to be directly present within a
>>>"case" statement in YANG 1.1.
>>> 
>>> It is allowed in YANG 1 as well.
>>> 
>>>This needs to be considered
>>>carefully.  Consider simply including the nested "choice" as
>>>additional "case" statements within the parent "choice" statement.
>>> 
>>> Ok, but I don't think people use nested choice by accident.  I have
>>> seen it used a handful of times, and there was always a good reason
>>> for doing it.  If you think some warning text like this is needed, I
>> 
>> But isn't it that in these legitimate cases the inner choice is always
>> accompanied by other nodes within the same case? The solution to Y29
>> enables choice as a short-hand case, and this can always be
>> flattened. Do I miss something?
> 
> No you're right.  It should also be noted that an implementation can
> choose to flatten such nested choices.

So maybe this was the reason for not allowing choice as a short-hand case. I 
wonder, is Y29-01 a good idea after all? We are encouraging people to do 
convoluted things that have a simpler alternative.

Lada

> 
> 
> /martin
> 
> 
> 
>> 
>> Lada
>> 
>>> suggest something along the lines of:
>>> 
>>>If a "case" statement contains a single "choice" statement,
>>>consider simply including ...
>>> 
>>> --
>>> 
>>> Section 5.1 says:
>>> 
>>>   Normative modules contained in Standards Track documents
>>>MUST be named according to the guidelines in the IANA
>>>Considerations section of [I-D.ietf-netmod-rfc6020bis].
>>> 
>>> 
>>> Note that since 6020bis doesn't obsolete 6020, the IANA Considerations
>>> text is not copied to 6020bis.  So either reference 6020, or copy the
>>> rule (use "ietf-" prefix).
>>> 
>>> 
>>> 
>>> 
>>> /martin
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> -- 
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Balazs Lengyel]

Hello Martin,
I would want to codify this. My earlier proposal was:

- when MUST NOT be dependent on a data node controlled by a when or 
choice statement


Notice the strong MUST NOT statement. This would simplify life greatly.
regards Balazs

On 2015-10-20 10:09, Martin Bjorklund wrote:

I have never seen anyone trying to refer to the conditional nodes in a
when expression - simply b/c it doesn't make any sense.


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Ladislav Lhotka]

> On 21 Oct 2015, at 14:33, Andy Bierman  wrote:
> 
> Hi,
> 
> IMO we do not need lots of rules for when-stmt.
> They are harder to enforce than just implementing the auto-deletion.
> 
> Note that auto-deletion also applies to nodes already in candidate or running.
> It is just a derivative case to have a newly-created node deleted right away.
> If you add node /foo it may cause node /bar and node /baz to get deleted.
> 
> I strongly object to treating a false when-stmt in a datastore validation
> as an error.  This is not how YANG 1.0 works, and this is not
> backward-compatible.

I think it has nothing to do with YANG (1.0 or whatever), and RFC 6020 
correctly describes this auto-deletion behaviour for "choice" in sec. 7.9.6 
NETCONF  Operations. It is indeed protocol business - YANG spec 
should just define what's valid and what isn't.

IMO RESTCONF spec doesn't require auto-deletion.

Lada

> 
> 
> Andy
> 
> 
> On Wed, Oct 21, 2015 at 5:16 AM, Balazs Lengyel  
> wrote:
> Hello Martin,
> I would want to codify this. My earlier proposal was:
> 
> - when MUST NOT be dependent on a data node controlled by a when or choice 
> statement
> 
> Notice the strong MUST NOT statement. This would simplify life greatly.
> regards Balazs
> 
> On 2015-10-20 10:09, Martin Bjorklund wrote:
> I have never seen anyone trying to refer to the conditional nodes in a
> when expression - simply b/c it doesn't make any sense.
> 
> -- 
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Balazs Lengyel]

I would love to get rid of the autodelete feature. It really complicates 
things.

regards Balazs

On 2015-10-18 16:43, Ladislav Lhotka wrote:

On 18 Oct 2015, at 11:52, Juergen Schoenwaelder 
 wrote:

On Thu, Oct 15, 2015 at 06:03:57PM +0200, Martin Bjorklund wrote:

Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
rephrase the intro text in 8.2) But I think Balazs is also right.
Suppose you have:

  leaf a {
when "../b = 42";
type int32;
  }
  leaf b {
type int32;
  }

and the db contains b=10.

Suppose I send an edit-config with a=2.  What is the result?

  1)  you get an error back
  2)  you get ok; the request to set a to 2 is silently dropped
  3)  something else


Isn't the simplest to always make the changes that were requested in
the rpc/action (e.g. edit-config) and then to validate the result and
if it fails to validate to return an error? No magic addition or
removal of nodes while trying to guess what the client wanted to
achieve. I am likely missing details since I never implemented this

That would be the type of behaviour I'd prefer. The auto-deletion feature also 
goes against the principle of least embarrassement - a trivial error can 
inadvertently erase substantial parts of a data tree.

Lada


but having a processing logic that is simple to understand would be
good and I think it is fair to expect that clients send edits that
do not require the server to guess what should happen.

/js

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> 
> > On 21 Oct 2015, at 09:17, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> Martin Bjorklund  writes:
> >> 
> >>> Andy Bierman  wrote:
>  Hi,
>  
>  I updated the YANG guidelines draft.
> >>> 
> >>> I have a couple of comments.
> >>> 
> >>> --
> >>> 
> >>> Section 5.14 says:
> >>> 
> >>>The "choice" statement is allowed to be directly present within a
> >>>"case" statement in YANG 1.1.
> >>> 
> >>> It is allowed in YANG 1 as well.
> >>> 
> >>>This needs to be considered
> >>>carefully.  Consider simply including the nested "choice" as
> >>>additional "case" statements within the parent "choice" statement.
> >>> 
> >>> Ok, but I don't think people use nested choice by accident.  I have
> >>> seen it used a handful of times, and there was always a good reason
> >>> for doing it.  If you think some warning text like this is needed, I
> >> 
> >> But isn't it that in these legitimate cases the inner choice is always
> >> accompanied by other nodes within the same case? The solution to Y29
> >> enables choice as a short-hand case, and this can always be
> >> flattened. Do I miss something?
> > 
> > No you're right.  It should also be noted that an implementation can
> > choose to flatten such nested choices.
> 
> So maybe this was the reason for not allowing choice as a short-hand
> case. I wonder, is Y29-01 a good idea after all? We are encouraging
> people to do convoluted things that have a simpler alternative.

IMO Y29 is about having consistent rules in the language.  Allowing
short hand cases for just a subset of the nodes seems like a CLR.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> 
> > On 21 Oct 2015, at 09:50, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> 
> >>> On 21 Oct 2015, at 09:17, Martin Bjorklund  wrote:
> >>> 
> >>> Ladislav Lhotka  wrote:
>  Martin Bjorklund  writes:
>  
> > Andy Bierman  wrote:
> >> Hi,
> >> 
> >> I updated the YANG guidelines draft.
> > 
> > I have a couple of comments.
> > 
> > --
> > 
> > Section 5.14 says:
> > 
> >   The "choice" statement is allowed to be directly present within a
> >   "case" statement in YANG 1.1.
> > 
> > It is allowed in YANG 1 as well.
> > 
> >   This needs to be considered
> >   carefully.  Consider simply including the nested "choice" as
> >   additional "case" statements within the parent "choice" statement.
> > 
> > Ok, but I don't think people use nested choice by accident.  I have
> > seen it used a handful of times, and there was always a good reason
> > for doing it.  If you think some warning text like this is needed, I
>  
>  But isn't it that in these legitimate cases the inner choice is always
>  accompanied by other nodes within the same case? The solution to Y29
>  enables choice as a short-hand case, and this can always be
>  flattened. Do I miss something?
> >>> 
> >>> No you're right.  It should also be noted that an implementation can
> >>> choose to flatten such nested choices.
> >> 
> >> So maybe this was the reason for not allowing choice as a short-hand
> >> case. I wonder, is Y29-01 a good idea after all? We are encouraging
> >> people to do convoluted things that have a simpler alternative.
> > 
> > IMO Y29 is about having consistent rules in the language.  Allowing
> > short hand cases for just a subset of the nodes seems like a CLR.
> 
> It would be practically useful in cases like this:
> 
> grouping foo {
>   choice foo {
> ...
>   }
> }
> 
> choice foobar {
>   uses foo;
>   leaf bar;
> }
> 
> However, this is not possible because of another CLR that doesn't
> allow "uses" as a substatment of "choice". So if we want consistency,
> we should simply remove short-case-stmt from the ABNF and use
> data-def-stmt instead.

The problem with allowing uses as a shorthand is that it is not
directly obvious what it means.  For example:

  grouping foo {
leaf a { ... }
leaf b { ... }
  }

  choice x {
uses foo;
  }


could be equivalent to:

A:

 choice x {
   leaf a { ... }
   leaf b { ... }
 }

or

B:

 choice x {
   case foo {
 leaf a { ... }
 leaf b { ... }
   }
 }



/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6020bis more than one revision of a module

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Tue, Oct 20, 2015 at 05:28:20PM -0400, David Reid wrote:
> > 
> > Why does yang 1.1 add the new requirement that a server MUST NOT implement
> > more than 1 revision? If there is an e-mail thread, you can point me at that
> > rather than re-hash the arguements here.
> >
> 
> How do you implement multiple revisions at the same time? There is
> only one path in a namespace. How do you combine must/when constraints
> if you implement multiple revisions of a module? I think the one
> revision requirement has already been part of YANG 1.

+1

Another example is if the value space for a leaf has been expanded in
the new revision.  What does it mean if you advertise both revisions?


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt

[Ladislav Lhotka]

> On 21 Oct 2015, at 09:50, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> 
>>> On 21 Oct 2015, at 09:17, Martin Bjorklund  wrote:
>>> 
>>> Ladislav Lhotka  wrote:
 Martin Bjorklund  writes:
 
> Andy Bierman  wrote:
>> Hi,
>> 
>> I updated the YANG guidelines draft.
> 
> I have a couple of comments.
> 
> --
> 
> Section 5.14 says:
> 
>   The "choice" statement is allowed to be directly present within a
>   "case" statement in YANG 1.1.
> 
> It is allowed in YANG 1 as well.
> 
>   This needs to be considered
>   carefully.  Consider simply including the nested "choice" as
>   additional "case" statements within the parent "choice" statement.
> 
> Ok, but I don't think people use nested choice by accident.  I have
> seen it used a handful of times, and there was always a good reason
> for doing it.  If you think some warning text like this is needed, I
 
 But isn't it that in these legitimate cases the inner choice is always
 accompanied by other nodes within the same case? The solution to Y29
 enables choice as a short-hand case, and this can always be
 flattened. Do I miss something?
>>> 
>>> No you're right.  It should also be noted that an implementation can
>>> choose to flatten such nested choices.
>> 
>> So maybe this was the reason for not allowing choice as a short-hand
>> case. I wonder, is Y29-01 a good idea after all? We are encouraging
>> people to do convoluted things that have a simpler alternative.
> 
> IMO Y29 is about having consistent rules in the language.  Allowing
> short hand cases for just a subset of the nodes seems like a CLR.

It would be practically useful in cases like this:

grouping foo {
  choice foo {
...
  }
}

choice foobar {
  uses foo;
  leaf bar;
}

However, this is not possible because of another CLR that doesn't allow "uses" 
as a substatment of "choice". So if we want consistency, we should simply 
remove short-case-stmt from the ABNF and use data-def-stmt instead.

Lada

> 
> 
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-rfc6087bis-05.txt

[Ladislav Lhotka]

> On 21 Oct 2015, at 10:13, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> 
>>> On 21 Oct 2015, at 09:50, Martin Bjorklund  wrote:
>>> 
>>> Ladislav Lhotka  wrote:
 
> On 21 Oct 2015, at 09:17, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> Martin Bjorklund  writes:
>> 
>>> Andy Bierman  wrote:
 Hi,
 
 I updated the YANG guidelines draft.
>>> 
>>> I have a couple of comments.
>>> 
>>> --
>>> 
>>> Section 5.14 says:
>>> 
>>>  The "choice" statement is allowed to be directly present within a
>>>  "case" statement in YANG 1.1.
>>> 
>>> It is allowed in YANG 1 as well.
>>> 
>>>  This needs to be considered
>>>  carefully.  Consider simply including the nested "choice" as
>>>  additional "case" statements within the parent "choice" statement.
>>> 
>>> Ok, but I don't think people use nested choice by accident.  I have
>>> seen it used a handful of times, and there was always a good reason
>>> for doing it.  If you think some warning text like this is needed, I
>> 
>> But isn't it that in these legitimate cases the inner choice is always
>> accompanied by other nodes within the same case? The solution to Y29
>> enables choice as a short-hand case, and this can always be
>> flattened. Do I miss something?
> 
> No you're right.  It should also be noted that an implementation can
> choose to flatten such nested choices.
 
 So maybe this was the reason for not allowing choice as a short-hand
 case. I wonder, is Y29-01 a good idea after all? We are encouraging
 people to do convoluted things that have a simpler alternative.
>>> 
>>> IMO Y29 is about having consistent rules in the language.  Allowing
>>> short hand cases for just a subset of the nodes seems like a CLR.
>> 
>> It would be practically useful in cases like this:
>> 
>> grouping foo {
>>  choice foo {
>>...
>>  }
>> }
>> 
>> choice foobar {
>>  uses foo;
>>  leaf bar;
>> }
>> 
>> However, this is not possible because of another CLR that doesn't
>> allow "uses" as a substatment of "choice". So if we want consistency,
>> we should simply remove short-case-stmt from the ABNF and use
>> data-def-stmt instead.
> 
> The problem with allowing uses as a shorthand is that it is not
> directly obvious what it means.  For example:
> 
>  grouping foo {
>leaf a { ... }
>leaf b { ... }
>  }
> 
>  choice x {
>uses foo;
>  }
> 
> 
> could be equivalent to:
> 
> A:
> 
> choice x {
>   leaf a { ... }
>   leaf b { ... }
> }
> 
> or
> 
> B:
> 
> choice x {
>   case foo {
> leaf a { ... }
> leaf b { ... }
>   }
> }
> 

The text in sec. 7.13 makes it quite clear that it would be A (The effect of a 
"uses" reference to a grouping is that the nodes defined by the grouping are 
copied into the current schema tree, … ).

Moreover, you have a similar dilemma if you augment a choice:

augment x {
  leaf a { ... }
  leaf b { ... }
}

But my point is different: choice as a short-hand case is only possible 
directly, not via "uses":

choice foo {
  choice bar { ... }
  ...
}

However, this really begs the question "Why don't you simply make the cases of 
'bar' into cases of 'foo'?" I can't see any reasonable answer.

Balazs wanted to add CLRs to ban "complex" choices. I don't know how to do it 
in general but here we are removing one obstacle for defining choices that are 
*needlessly* complex.

Lada

> 
> 
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod