Subject: [netconf] edit-config leaf without value

From: Michal Vaško <[email-masked]>
Date: Fri, 06 Mar 2020 16:10:00 +0100

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.
b) If it can be without a value, is it only in the case of "delete" operation, otherwise it is an error?
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].
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.

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 6 Mar 2020 20:06:01 +0000

[As a contributor]

Hi Michal,

Please see inline ...

> -----Original Message-----
> From: netconf <[email-masked]> On Behalf Of Michal Vaško
> Sent: 06 March 2020 15:10
> To: netconf <[email-masked]>
> 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.
> 
> 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.

> 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

> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Michal Vaško <[email-masked]>
Date: Mon, 09 Mar 2020 08:18:17 +0100

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Mar 2020 08:40:31 +0100

Dear Michal,

the text in section 7.2 of RFC 6241 repeatedly uses the phrase "the
configuration data identified by the element containing this
attribute". I read this as the match is purely structural and not
involving a comparison of the value of the element to be deleted or
removed.

/js

PS: This is a NETCONF question, not a YANG question, hence any
    clarification necessary needs to go into a NETCONF document.

-- 
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/>

---

From: Radek Krejčí <[email-masked]>
Date: Mon, 9 Mar 2020 13:57:05 +0100

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

-- 
Radek Krejci
mobile  : +420 732 212 714
office  : +420 234 680 256
e-mail  : [email-masked]
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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Mar 2020 14:01:08 +0100

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

---

From: Radek Krejčí <[email-masked]>
Date: Mon, 9 Mar 2020 15:00:46 +0100

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 9 Mar 2020 14:33:26 +0000

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

> From: Radek Krejčí <[email-masked]>
> Sent: 09 March 2020 12:57
> To: Michal Vaško <[email-masked]>; Rob Wilton (rwilton)
> <[email-masked]>
> Cc: netconf <[email-masked]>
> 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
> 
> 
> > 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
> >
> >>> 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.
> >>>
> >>> 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.
> >>
> >>> 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]
> >>> 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
> >>
> >>

---

From: Radek Krejčí <[email-masked]>
Date: Mon, 9 Mar 2020 15:58:03 +0100

Thanks Rob,

> 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, an…

agreed

> 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 f…

ok, agreed. We are going this way and handle the edit-config data more like a filter with some additional attributes than a standard data.

Regards,
Radek

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Mar 2020 17:02:52 +0100

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