Re: [netmod] Using an empty type in a list key

[Ladislav Lhotka]

> On 09 Sep 2016, at 16:07, Andy Bierman  wrote:
> 
> 
> 
> On Fri, Sep 9, 2016 at 6:44 AM, Ladislav Lhotka  wrote:
> "Dale R. Worley"  writes:
> 
> > 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 ordinary rules can't work.  Indeed,
> > specifically banning them increases the complexity of the
> > specification.
> 
> +1
> 
> There is no need to ban keys with type "empty", XPath and everything
> works fine if other YANG rules are followed.
> 
> 
> 
> Why should YANG Doctors approve a YANG module that uses type empty as a key?
> The guidelines say SHOULD NOT use empty as a key.  Come up with a use-case.
> (You can't). If you can, I will remove the guideline from the draft.

This is all fine, my point (and I think Dale's as well) is that it should be 
permitted in YANG the language, so it is a good thing that this 6020 CLR is no 
more present in 7950:

   A leaf that is part of the key can be of any built-in or derived
   type, except it MUST NOT be the built-in type "empty".

Earlier in this thread you said that we had it right in YANG 1.0, and I don't 
agree with that.

Lada

> 
> The YANG Guidelines draft restricts YANG usage for IETF standards track 
> modules.
> Use lots of empty keys in your data model if you want.
> 
> 
>  
> Lada
> 
> 
> Andy
> 
>  
> >
> > The reason for this is that the code (in this case, the module
> > definition) may be generated by an automatic process, and those
> > processes are easier to construct if the rules contain fewer
> > irregularities.  E.g., multiplying a number by zero is pointless, in
> > that the result is always zero, and one might ask, Why not just write 0
> > instead of the multiplication?  But everyone agrees that the statement
> >
> > a = 0 * b;
> >
> > is *valid*, and can easily imagine situations where a process might
> > generate it as an output.
> >
> >>> Unless I'm off, the line should be fixed to avoid the string
> >>> conversion:
> >>>
> >>>  /ex:system/ex:service[ex:name='foo'][ex:enabled]
> >>>
> >>> and a negation should be:
> >>>
> >>>  /ex:system/ex:service[ex:name='foo'][not(ex:enabled)]
> >>
> >> There is only one value provided by type empty.  The 2nd instance
> >> identifier is invalid.
> >> There is no instance possible that does not include the 'enabled' leaf.
> >
> > The 2nd instance identifier is (should be) *valid* even if it always
> > returns the empty set.  (Assuming it is used in contexts where a set can
> > be returned.)
> >
> > Dale
> >
> > ___
> > 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] Using an empty type in a list key

[Andy Bierman]

On Fri, Sep 9, 2016 at 6:44 AM, Ladislav Lhotka  wrote:

> "Dale R. Worley"  writes:
>
> > 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 ordinary rules can't work.  Indeed,
> > specifically banning them increases the complexity of the
> > specification.
>
> +1
>
> There is no need to ban keys with type "empty", XPath and everything
> works fine if other YANG rules are followed.
>
>

Why should YANG Doctors approve a YANG module that uses type empty as a key?
The guidelines say SHOULD NOT use empty as a key.  Come up with a use-case.
(You can't). If you can, I will remove the guideline from the draft.

The YANG Guidelines draft restricts YANG usage for IETF standards track
modules.
Use lots of empty keys in your data model if you want.




> Lada
>
>
Andy



> >
> > The reason for this is that the code (in this case, the module
> > definition) may be generated by an automatic process, and those
> > processes are easier to construct if the rules contain fewer
> > irregularities.  E.g., multiplying a number by zero is pointless, in
> > that the result is always zero, and one might ask, Why not just write 0
> > instead of the multiplication?  But everyone agrees that the statement
> >
> > a = 0 * b;
> >
> > is *valid*, and can easily imagine situations where a process might
> > generate it as an output.
> >
> >>> Unless I'm off, the line should be fixed to avoid the string
> >>> conversion:
> >>>
> >>>  /ex:system/ex:service[ex:name='foo'][ex:enabled]
> >>>
> >>> and a negation should be:
> >>>
> >>>  /ex:system/ex:service[ex:name='foo'][not(ex:enabled)]
> >>
> >> There is only one value provided by type empty.  The 2nd instance
> >> identifier is invalid.
> >> There is no instance possible that does not include the 'enabled' leaf.
> >
> > The 2nd instance identifier is (should be) *valid* even if it always
> > returns the empty set.  (Assuming it is used in contexts where a set can
> > be returned.)
> >
> > Dale
> >
> > ___
> > 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] Using an empty type in a list key

[Ladislav Lhotka]

"Dale R. Worley"  writes:

> 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 ordinary rules can't work.  Indeed,
> specifically banning them increases the complexity of the
> specification.

+1

There is no need to ban keys with type "empty", XPath and everything
works fine if other YANG rules are followed.

Lada

>
> The reason for this is that the code (in this case, the module
> definition) may be generated by an automatic process, and those
> processes are easier to construct if the rules contain fewer
> irregularities.  E.g., multiplying a number by zero is pointless, in
> that the result is always zero, and one might ask, Why not just write 0
> instead of the multiplication?  But everyone agrees that the statement
>
> a = 0 * b;
>
> is *valid*, and can easily imagine situations where a process might
> generate it as an output.
>
>>> Unless I'm off, the line should be fixed to avoid the string
>>> conversion:
>>>
>>>  /ex:system/ex:service[ex:name='foo'][ex:enabled]
>>>
>>> and a negation should be:
>>>
>>>  /ex:system/ex:service[ex:name='foo'][not(ex:enabled)]
>>
>> There is only one value provided by type empty.  The 2nd instance
>> identifier is invalid.
>> There is no instance possible that does not include the 'enabled' leaf.
>
> The 2nd instance identifier is (should be) *valid* even if it always
> returns the empty set.  (Assuming it is used in contexts where a set can
> be returned.)
>
> Dale
>
> ___
> 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] How to constrain a leaf to a read-only list of supported values?

[Ladislav Lhotka]

"Dale R. Worley"  writes:

> Balazs Lengyel  writes:
>> Problem: how do you restrict values for (3) - file-compression so that 
>> it is one of the nodes-supported-compression-types. The natural solution 
>> would be to use a must expression or a leaf-ref, but as 
>> nodes-supported-compression-types is config-false data, it is not 
>> allowed to constrain the config=true leaf, file-compression, with it.
>
> I'm no expert at this, but it seems to me that the way to do it is to
> have the overall data structure be config-true but make the contained
> supported-compression-types be config-false.  You can nest config-false
> nodes in a config-true structure.  The Yang would be something like
> this:
>
> typedef Compression-Method {
>   ...
> }
>
> list node {
>   config true;
>   key name;
>
>   string name;
>
>   leaf-list supported-compression-methods {
> type Compression-Method;
> config false;
>   }
>
>   Compression-Method compression-method;
>   must "compression-method ... supported-compression-methods";
> }

I think this is a good idea. It would have to be done on ad hoc basis
but, on the other hand, not all enumerations permit implementations to
choose a subset of enums.

The only technical problem with your mock-up is that "must" expressions
on config nodes cannot refer to state data.

Lada

>
> Dale
>
> ___
> 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] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Ladislav Lhotka]

Kent Watsen  writes:

>>Then you probably already know what the solution is going to be. I don't.
>
> It’s not that I know the exact solution.  It’s that I see this
> approach offering good options for graceful migration to an opstate
> compliant solution (for which I’m on the design team alias), without
> incurring any modelling cost, other than there being an additional
> module.  I additionally see this approach as more flexible in that, as
> you said, it would allow one module to be updated without disturbing
> the other.

The data modelling cost of splitting config and state data into
separate modules IMO is that it weakens the concept of system- and
user-controlled objects. I understand that some folks don't like it but
I am still not convinced that anything better is readily available.

And then of course another cost is that all modules depending on
ietf-routing need to be updated accordingly. So IMO we should think
twice before making this change. I would appreciate more opinions on it.

Lada

>
>
>> Anyway, if the consensus was to split config and state data into separate 
>> modules, we would have to tell all module developers who build upon the core 
>> routing model to split their augments into config and state parts as well, 
>> because otherwise the change to ietf-routing would be useless.  
>
> Yes, indeed, this would be the primary consequence.
>
>
>>Lada
>
> Kent
>
>

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

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