On 06/04/2021 09:04, Ladislav Lhotka wrote:
>> I see. Okay, thanks for the clarification and yes, if this was explicitly
>> mentioned in the RFC it would be great. Although, the validity of your
>> example was not in question. Rather something like:
>>
>> container foo {
>> if-feature X;
>> container bar;
>> }
>>
>> augment /foo/bar {
>> container Y;
>> }
>>
>> I am just going to assume this is what you meant and simply that the
>> requirement is that any schema path must point to an existing schema node,
>> ignoring any "if-feature" statements.
> I think it also depends on whether features are set before or after
> processing the modules. In the former case, an augment statement with an
> effectively missing target node can IMO be silently ignored, without even
> parsing its contents.This very case has been discussed here: https://mailarchive.ietf.org/arch/msg/netmod/Icd5c8J27P3UKjloNG8VC9fApoM/ FTR the original request for OpenDaylight lives here: https://jira.opendaylight.org/browse/YANGTOOLS-859 and it provides some additional context. As an implementation author, I certainly did not like the implications of the request, but Andy brought up a very important point in that thread: > The modules are valid. > The conformance decision (i.e., which features are advertised and which are > not by a server implementation) > does not change the compile-time validity of the YANG modules i.e. even if the YANG modules are being interpreted as part of assembling a server implementation, if-feature processing phase comes only after cross-statement relationships have been established and therefore the augment is valid, but 'container Y' disappears just as 'container bar' does. This is further reinforced by Martin's response in this (related) thread: https://mailarchive.ietf.org/arch/msg/netmod/9JgPZphOdim-wLZA3NrSe3I1un4/ Regards, Robert
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
