Hi Robert,
I've adopted all your suggestion.
Thanks for the review!
Chris.
> On Feb 13, 2019, at 7:04 AM, Robert Wilton wrote:
>
> Reviewer: Robert Wilton
> Review result: Ready with Nits
>
> I have reviewed this document as part of the YANG doctors directorate's
> ongoing effort to review a
> On Feb 13, 2019, at 6:04 AM, Rohit R Ranade wrote:
>
> Editorial Comments:
> 1. Section 1, refers to RFC6020 for Yang Module, but since this document
> uses Yang Version 1.1, I feel it should refer to RFC7950
> 2. Section 4.3, " removed with using normal configuration", can use "removed
>
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.
Title : YANG Module Tags
Authors : Christan Hopps
Lou Berger
Dea
Hi Rob,
Thank you very much for your fast reply, for proposing a mitigation, and for
'reducing' our set of YANG modules to pin-point the cause of the issue.
I am aligned with you. It is indeed a corner case. We will forward your
feedback to OpenDaylight as well.
Thank you,
Yves
On 15-02-19 1
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 eas
Hi,
We are working with a submodule in which we are augmenting a container of the
same module with a mandatory node. There is a small catch though.
Our YANG modules are actually supporting two augmentations - I have copied a
trimmed down version of our modules at the end of this mail -:
* From
