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

The NETCONF specification is largely silent about the details of the
processing of requests, other protocols are much more explicit.
Hence, it is often difficult to declare something 'right' or 'wrong';
all we can do is to recognize that for certain requests
implementations may be behave differently. Some may do the delete
without looking at the value at all, others may check types first and
return an error before they attempt to process the operation.

/js

On Mon, Mar 09, 2020 at 03:00:46PM +0100, Radek Krejčí wrote:
> So your answer is the option a)? So the value processing (and type violation reporting) must be always checked (no matter when). Maybe I'm just not getting your point.
> 
> What is the expected result of edit-config's <l operation="delete"/> in case
> 
> i) l is uint32 and node l is present with value "1"
> 
> ii) l is string and node l is present with value "x"
> 
> What is the "value not present" representation for string?
> 
> Regards,
> Radek
> 
> 
> Dne 09. 03. 20 v 14:01 Juergen Schoenwaelder napsal(a):
> > I think when and how type checking is done is rather implementation
> > specific. Some implementations may complain about a type violations
> > before processing the operation attributes, others may not look at the
> > type until they process values.
> >
> > /js
> >
> > On Mon, Mar 09, 2020 at 01:57:05PM +0100, Radek Krejčí wrote:
> >> 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)" <rwilton@cisco.com> wrote: 
> >>>  
> >>>> [As a contributor]
> >>>>
> >>>> Hi Michal,
> >>>>
> >>>> Please see inline ...
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: netconf <netconf-bounces@ietf.org> On Behalf Of Michal Vaško
> >>>>> Sent: 06 March 2020 15:10
> >>>>> To: netconf <netconf@ietf.org>
> >>>>> 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
> >>>>> netconf@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/netconf
> >>>  
> >>>  
> >>>
> >>> _______________________________________________
> >>> netconf mailing list
> >>> netconf@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netconf
> >> -- 
> >> Radek Krejci
> >> mobile  : +420 732 212 714
> >> office  : +420 234 680 256
> >> e-mail  : rkrejci@cesnet.cz
> >> 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
> >>
> >>
> >> _______________________________________________
> >> netconf mailing list
> >> netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netconf
> 
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>