Rules in https://tools.ietf.org/html/rfc7950#section-7.6.5 apply, in this case bullet 1 because mm:first-augment is not a presence container: the augmentation is adding a mandatory node and it is not directly guarded by a when statement. The augmentation introducing 'mm:first-augment' is guarded, though, and this should probably cascade. This feels like another aspect of YANGTOOLS-859.

verthezpw would you mind talking to netmod@ietf about perhaps clarifying section 7.17?

OK, we'll let BBF (Broadband Forum) do this discussion, since this came ultimately from a model that they are standardizing (but working texts are not made public there). I'll keep you informed.

In the end somebody of our team initiated the netmod discussion, instead of pushing this to BBF. See the following thread:
https://mailarchive.ietf.org/arch/msg/netmod/unhiYU1AWcoFMKzUeTh50h4nrSo

Reply from the netmod mailing list indicates that this should indeed be allowed:

Re: [netmod] Augmentation with a mandatory leaf in a submodule - Is the following legal?

Robert Wilton <rwilton@cisco.com> Fri, 15 February 2019 10:08 UTC

Hi Yves,

My interpretation of the spirit of the RFC is that this should be
allowed, and I don't think that any text in 7.17 specifically prevents this.

However, this seems like a corner case, and I am also not surprised that
a YANG compiler would fail on this. This issue could perhaps be easily
mitigated by making the second augmentation also conditional on the same
when statement.

Note that the use of sub-modules doesn't really matter, in that a
compiler can treat them as one module. So, I think that the problem is
equivalent to:

module module-a {
  yang-version 1.1;
  namespace "http://www.example.com/anothermodule";
  prefix am;
  container top {
    leaf type {
      type string; mandatory true;
    }
  }
}

module module-b {
  yang-version 1.1;
  namespace "http://www.example.com/module-b";
  prefix mm;
  augment '/am:top' {
    when "am:type = 'test'";
    container first-augment {
    }
  }
  augment '/am:top/mm:first-augment' {
    leaf mandatory-leaf {
      type string; mandatory true;
    }
  }
}

Thanks,
Rob

Thanks for confirming, I'll take a look at what we need to do to catch this correctly.

Hi, what is the timeline for fixing this? We are getting some pressure from device teams on this because this is occurring in a standardized model from Broadband Forum and devices are integrating that. We have provided a workaround (i.e. doing a temporary patch to the YANG model), but still they want to know when ODL will support this so that this workaround would not be needed.

Sorry, I am busy with other parts of the system. There is a candidate patch, but has a relatively-high risk, so it won't be integrated before mid-July, I suspect.

OK, thanks for the update.

The fix breaks with OFP models and will need to be reworked.

The reason for the failure is that targetCtx.getOriginalCtx() ends up not returning the immediate copy predecessor, but rather the source-level-original definition.

The basic approach is sound, but we need the ability to walk backwards through the copy history.