On Wed, Sep 7, 2016 at 7:02 PM, Dale R. Worley wrote:
> Andy Bierman writes:
> > Using a key of type empty is utterly pointless unless the point
> > is to make the instance identifier longer.
>
> IMO using a key of type empty (or any type with only one value) is
> *pointless* but should be *vali
Andy Bierman writes:
> Using a key of type empty is utterly pointless unless the point
> is to make the instance identifier longer.
IMO using a key of type empty (or any type with only one value) is
*pointless* but should be *valid*. Things should be valid unless
processing them according to the
On Wed, Sep 7, 2016 at 11:21 AM, Ladislav Lhotka wrote:
>
> > On 07 Sep 2016, at 19:44, Vladimir Vassilev
> wrote:
> >
> > On 09/07/2016 02:18 PM, Martin Bjorklund wrote:
> >> Hi,
> >>
> >> Your example is not circular, and it is legal. However, the 'when'
> >> expression refers to the node in
> On 07 Sep 2016, at 19:44, Vladimir Vassilev wrote:
>
> On 09/07/2016 02:18 PM, Martin Bjorklund wrote:
>> Hi,
>>
>> Your example is not circular, and it is legal. However, the 'when'
>> expression refers to the node in which the when expression is defined.
>> Note that this expression will a
On 09/07/2016 02:18 PM, Martin Bjorklund wrote:
Hi,
Your example is not circular, and it is legal. However, the 'when'
expression refers to the node in which the when expression is defined.
Note that this expression will always evaluates to 'false' (see the
third bullet in 7.21.5 in RFC 7950).
Hi,
Your example is not circular, and it is legal. However, the 'when'
expression refers to the node in which the when expression is defined.
Note that this expression will always evaluates to 'false' (see the
third bullet in 7.21.5 in RFC 7950).
Take a step back and consider what the 'when' sta
Hi,
Is there any practical value of 'when' statements with circular
dependency to the value of the parent (in case it is a leaf) or any
children of the parent?
container circular-dependency-when {
leaf a {
when "(. + ../b) = 100";
type uint16 {
range
Hi,
[Copying NETMOD, but suggest all discussions are held on OPSAWG list]
We updated our document to (hopefully) make some stuff clearer...
- We are not trying to piss on draft-ietf-netmod-yang-model-classification!
Actually, that is an important reference, but its approach is slightly
di
