Operating System: Linux
Platform: PC

Below mentioned gerrit changes can be used to fix these issues.

https://git.opendaylight.org/gerrit/#/c/9112/

https://git.opendaylight.org/gerrit/#/c/9135/

Hi Ankit,
would you rework your controller patch
https://git.opendaylight.org/gerrit/#/c/9135/
to not require this change in YANGTools?

Would you abandon your YANGTools patch
https://git.opendaylight.org/gerrit/#/c/9112/
since it starts allowing Null values in places, where they were not allowed
and has potential to introduce NPE based regression at various places (parser, codecs...).

Hi Tony,

I have submitted a new patch on

https://git.opendaylight.org/gerrit/#/c/9135/
and

https://git.opendaylight.org/gerrit/#/c/9112/
But both the changes are required to fix the Bug.

In 9112 now only YangModelDependencyInfo class has changes which is a caller for the parsing method.

Regarding this bug, there is plenty of evidence in RFC 6020 that the first revision of a YANG module does not need to have a "revision" statement, and hence not needed in the <hello> message, but section 5.6.4.1 says:

"A server MUST advertise all revisions of all modules it implements."

Which seems contradictory. Discussing with the NETMOD WG, it is agreed that the sentence should have been written:

"A server MUST advertise all known revisions of all modules it implements."

Thus providing the necessary leeway.

FWIW, the only time it is envisioned a YANG module not wanting to have an initial revision date is when the module itself is already version-specific (e.g., http://xml.juniper.net/netconf/junos/14.2R2.4), which clearly will have one and only one revision. In all other cases, it seems the module is expected to be versioned over time and therefore SHOULD have a revision statement. For this reason, the NETMOD WG may also add a clarifying statement into section 7.1.9.

Thanks,
Kent