Re: [netmod] VRFY :Y09: introduce optional keys

Hi,

I do not think this is a minor change to YANG so it is
inappropriate for a minor update.

Solutions which alter the instance-identifier data type will
break NACM and this is also not a minor update change.

I do not know of any real use-cases in which a value
cannot be selected that means not-in-use.  The "union"
data-type can almost always be used to create a typedef
for this purpose.

There is no real operational need to suppress sending
a few key leafs during a "create" operation.  NETCONF
is not optimized for small message size in any way.

I do not think that lack of optional keys is a bug in YANG
and therefore it should not be part of YANG 1.1 at all.

Andy

On Fri, Jan 9, 2015 at 2:29 AM, Peyman Owladi -X (powladi - Ensoft Ltd
at Cisco) <powladi@cisco.com> wrote:
>
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman
>> Sent: 08 January 2015 15:20
>> To: Ladislav Lhotka
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] VRFY :Y09: introduce optional keys
>>
>> On Thu, Jan 8, 2015 at 2:22 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>> >
>> >> On 08 Jan 2015, at 10:21, Martin Bjorklund <mbj@tail-f.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>> >>> The 2014-12-03 virtual interim meeting proposal is to adopt Y09-03.
>> >>
>> >> The reasons for proposing Y09-03 (instead of Y09-02) were:
>> >>
>> >>  1. The instance-identifier syntax proposed in Y09-02 doesn't work,
>> >>     b/c empty strings and 0-values integers would also return "true"
>> >>     in the expression "not(key)".
>> >>
>> >>  But this turned out to be a false claim; the syntax proposed in
>> >>  Y09-02 is correct.
>> >>
>> >>  2. Y09-02 is tricky to implement in "common databases", since they
>> >>     require values for all keys.
>> >
>> > In some common databases (e.g. mongodb) a declaration of a key is just
>> an instruction for the server to generate an index. I think it is more a
>> limitation of NETCONF’s edit-config design.
>> >
>> > An implication for both Y09-02 and Y09-03 is that if a key is not set
>> at the time a list entry is created, it cannot be set afterwards.
>> >
>> >>
>> >>  But the idea for how to handle Y09-03 in these databases was to
>> >>  store additional info that the default value is set.  The same
>> >>  technique can be used to handle purely optional keys.
>> >>
>> >> Thus, I prefer Y09-02.
>> >
>> > Me too, Lada
>
> I think that as well as not having any downsides, Y09-02 actually addresses the set of issues better than Y09-03; sometimes there isn't a default that makes sense, in which case adding absence to the value space of a key is important.
>
>> Neither solution works.
>> I agree with David that they should not be added at all to YANG.
>
> Is the key concern here the handling of default values?
>
>> Please answer the questions below wrt/ how lists with default keys work:
>>
>> What if the designer does not want a list to automatically instantiate
>> entries?
>> How is this accomplished?
>
> If we do have defaults, I would have thought that having a default value for a key shouldn't mean a list entry is automatically instantiated -- i.e. there should still be no list entries until they are explicitly created.
>
> Perhaps this could be made explicit by requiring that at least one key has no default value?
>
>>   typedef X {
>>      type int32;
>>      default 42;
>>   }
>>
>>   list broken {
>>      key x;
>>      leaf x { type X; }
>>      leaf y { type string; mandatory true; }
>>   }
>>
>> Does the server automatically create a default entry for x=42?
>> If so, then isn't the mandatory-stmt violated immediately?
>> Are must-stmts in the default key leaf evaluated?
>>
>> Are <edit-config> requests for list "broken" allowed to omit the <x>
>> leaf?  Is the server supposed to fill in x=42 in such cases?
>
> Per RFC6020 section 7.6.1:
>
>    "... if the leaf's type has
>    a default value, and the leaf is not mandatory, then the leaf's
>    default value is the type's default value.  In all other cases, the
>    leaf does not have a default value."
>
> So in this example, since the leaf is mandatory, the default value is ignored, and the client must specify a value. (Otherwise this same problem would apply to any leaf in the list.)
>
> Cheers,
> Peyman
>
>> >>
>> >> /martin
>>
>>
>> Andy
>>
>>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod