Re: [netconf] ?==?utf-8?q? edit-config leaf without value

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Radek,

Let's consider the "remove" case because that one is simpler:

I don't think that it makes sense to require the client to specify a value for a leaf that is being removed.  I read the semantics of "remove" to be best effort, i.e. remove the leaf if you can, and ignore it silently if you cannot (e.g. the leaf does not exist).

If a client also provides a value for the leaf being removed, and it matches what the server holds, then that would seem fine but unnecessary, but the leaf should be deleted.

If a client provides a value that doesn’t type check during a remove, then the behaviour is probably undefined.  Some servers might reject the request because it doesn't type check, others might be graceful in what they receive and delete the leaf anyway.  However, I'm not sure that I regard not providing a value as a type check failure when considering a remove or a delete operation.

Having looked at both the NETCONF and YANG specs, it is unclear to me what behaviour is expected if the value type checks but differs from what the server holds.  E.g. is the request "remove leaf foo if it exists", or is the request "remove leaf foo if it exists with value 5"?  My understanding of Juergen's interpretation is that it is only meant to be the former, which does seem to be backed up by section 7.6.7 of RFC 7950, given that it only mentions existence and not checking values.


Considering the "delete" operation, I think that the behaviour should be the same as "remove", except that the request must be failed if the target node doesn’t exist.

I suspect that it is better if clients don't provide values in either "remove" or "delete" requests.  Whatever is decided by the WG, raising an issue on the NETCONF github issue tracker would seem to be a good idea.

Regards,
Rob





> -----Original Message-----
> From: Radek Krejčí <[e-mail]>
> Sent: 09 March 2020 12:57
> To: Michal Vaško <[e-mail]>; Rob Wilton (rwilton)
> <[e-mail]>
> Cc: netconf <[e-mail]>
> Subject: Re: [netconf] ?==?utf-8?q? edit-config leaf without value
> 
> Hi Rob,
> 
> I agree with Michal, it is actually not clear what the "value not
> provided" mean. Because I understand <l operation="delete"/> to have a
> value which is invalid for the uint32 type, but valid for for example in
> case of string. By checking for the type, we would have types without
> possibility to have "value not provided". So I believe that we can a)
> always check the value or b) never check the value in case of
> delete/remove operation. Acting according to the type seems confusing.
> When involving unions, with the possibility to change type according to
> some external data, it would be hell.
> 
> Regards,
> Radek
> 
> 
> Dne 09. 03. 20 v 8:18 Michal Vaško napsal(a):
> > Hi Rob,
> > thank you for answers even though they are quite different from what I
> expected. I tried to understand the behavior from the RFC having always
> referenced the specific sections and I found nothing about invalid values
> being allowed although there is no explicit prohibition. I would make sure
> explicit rules are included in whatever next YANG document is released.
> >
> > Also, you are saying "delete" on a uint32 leaf can occur without a value
> (meaning it can never match a valid value) but in the next answer you are
> saying you would check the value and return an error if it did not match,
> which is an obvious inconsistency, so please clarify what you meant. As
> for the "remove" operation and not checking the value, what exactly would
> be the behavior? An error is never returned, that is written in the RFC,
> but would the leaf actually be removed only if the value matches or even
> when it does not?
> >
> > Regards,
> > Michal
> >
> > On Friday, March 6, 2020 21:06 CET, "Rob Wilton (rwilton)"
> <[e-mail]> wrote:
> >
> >> [As a contributor]
> >>
> >> Hi Michal,
> >>
> >> Please see inline ...
> >>
> >>> -----Original Message-----
> >>> From: netconf <[e-mail]> On Behalf Of Michal Vaško
> >>> Sent: 06 March 2020 15:10
> >>> To: netconf <[e-mail]>
> >>> Subject: [netconf] edit-config leaf without value
> >>>
> >>> Hello,
> >>> we would like some input on a problem that was discussed several
> >>> times based on our search of the mailing list archive but we are
> >>> still not sure what the exact rules are.
> >>>
> >>> So, let's say we have YANG snippet
> >>>
> >>> leaf l {
> >>>     type uint32;
> >>> }
> >>>
> >>> and edit-config config (assume correct namespaces)
> >>>
> >>> <l operation="delete"/>
> >>>
> >>> a) Is the example allowed? Meaning can the leaf "l" be without a
> >>> value (have an invalid value)? Based on the YANG 1.1 RFC [1] I would
> >>> say it cannot.
> >> [RW]
> >> Yes, a value does not need to be provided, but the leaf must previously
> exist in the configuration, or an error is returned.
> >>
> >> I think that this would be the normal way this operation is expressed.
> >>
> >>
> >>> b) If it can be without a value, is it only in the case of "delete"
> >>> operation, otherwise it is an error?
> >> [RW]
> >> "remove" would be similar but would not error if the node doesn't
> exist.
> >>
> >>> c) If the leaf "l" had a string type, for example, and there was an
> >>> instance with value "string" in the datastore, would the edit-config
> >>> succeed and the leaf be deleted? In other words, when deleting a
> >>> leaf, do the values have to match for a successful delete or not? In
> >>> this case, I would say the values do not have to match [2].
> >> [RW]
> >> For a delete operation, if a value was provided, then I would check it
> or return an error if it did not match.
> >>
> >> For a remove operation, I wouldn't perform the check, and just remove
> the node if it exists.
> >>
> >>> d) I am assuming none of this can work for a leaf-list [3] or list
> >>> [4], which must always have the exact value/keys no matter what the
> >>> operation on them is.
> >> [RW]
> >> Agreed.
> >>
> >> Thanks,
> >> Rob
> >>
> >>
> >>> Thank you for any clarification.
> >>>
> >>> Regards,
> >>> Michal
> >>>
> >>> [1] https://tools.ietf.org/html/rfc7950#section-7.6.6
> >>> [2] https://tools.ietf.org/html/rfc7950#section-7.6.7
> >>> [3] https://tools.ietf.org/html/rfc7950#section-7.7.9
> >>> [4] https://tools.ietf.org/html/rfc7950#section-7.8.6
> >>>
> >>> _______________________________________________
> >>> netconf mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/netconf
> >
> >
> >
> > _______________________________________________
> > netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> --
> Radek Krejci
> mobile  : [phone]
> office  : [phone]
> e-mail  : [e-mail]
> LinkedIn: http://www.linkedin.com/in/radekkrejci
> 
> CESNET, Association of Legal Entities
> Zikova 4                                      Office: Bozetechova 1
> 160 00 Praha 6                                        612 66 Brno
> Czech Republic                                        Czech Republic
>