ip-address was the last node that was read so it's not the problem. The problem occurs on the next DataTreeCandidatePayload which appears to contain a standalone LeafSetEntryNode w/o the parent LeafSetNode. In this case only the entry's value is outputted to the stream as the NormalizedNodeWriter doesn't pass NodeIdentifier in the leafSetEntryNode method. Presumably this was done for efficiency so the NodeIdentifier QName isn't duplicated for each entry when writing out a leaf set. However it assumes the parent LeafSetNode was previously written to the stream. The NormalizedNodeInputStreamReader makes the same assumption. In order to create a LeafSetEntryNode it needs the leaf set QName. This is obtained when the parent LeafSetNode is parsed and it's cached when the child LeafSetEntryNode's are parsed. However if the stream contains only a LeafSetEntryNode then the leaf set QName isn't available which leads to the NPE.
I'm not familiar with the OF data model and which leaf set is causing the issue and which component is writing it.
It seems the the NormalizedNodeWriter needs to detect that a standalone/parentless LeafSetEntryNode is being written and pass the NodeIdentifier to the stream writer, either as a @Nullable param to the existing method or a new method.
Submitted https://git.opendaylight.org/gerrit/#/c/33192 which adds a unit test that reproduces the NPE in NormalizedNodeInputStreamReader.
Looks like a change to NormalizedNodeStreamWriter's methods will be required to expose the QName.
Yes unfortunately - I don't see any other way around it. Adding QName (or NodeWithValue) to leafSetEntryNode would be enough on the yangtools side. The CDS NormalizedNodeOutputStreamWriter already keeps track of whether the parent was seen.
(In reply to Robert Varga from comment #3)
> Looks like a change to NormalizedNodeStreamWriter's methods will be required
> to expose the QName.
Submitted yangtools patch https://git.opendaylight.org/gerrit/#/c/33222/ to add the QName param.
Do we need an API waiver?
I'm working on the controller side patch.
I don't know if any other projects need changes.
Yes we do. I am actually working on a patch to add NodeWithValue, which is consistent with the rest of the API. I will go through the projects – it has not been two weeks since last waiver 
I added a QName param with my patch. I didn't know you were working on it. NodeWithValue is fine too - we can go with your patch - either way - I'll leave it up to you.
I have the controller side patch https://git.opendaylight.org/gerrit/#/c/33228/ working (it's a draft right now since it won't build in jenkins) with changes to AbstractNormalizedNodeDataOutput and NormalizedNodePruner. Added more unit tests to DataTreeCandidatePayloadTest to cover standalone leaf node and ordered leaf set (recently added - I fixed an issue with it).
Note that AnyXML doesn't work at all with the CDS streaming (it doesn't know how to serialize a DOMSource) but that's a separate issue.
(In reply to Robert Varga from comment #6)
> Yes we do. I am actually working on a patch to add NodeWithValue, which is
> consistent with the rest of the API. I will go through the projects – it
> has not been two weeks since last waiver
mdsal: https://git.opendaylight.org/gerrit/33231
controller: https://git.opendaylight.org/gerrit/33230
netconf: https://git.opendaylight.org/gerrit/33229
Waiting for initial review, will send out an API freeze waiver once initial review has been done.
I already submitted controller patch https://git.opendaylight.org/gerrit/#/c/33228/ which fixes the issue so https://git.opendaylight.org/gerrit/#/c/33230/ isn't needed.
(In reply to Robert Varga from comment #8)
> mdsal: https://git.opendaylight.org/gerrit/33231
> controller: https://git.opendaylight.org/gerrit/33230
> netconf: https://git.opendaylight.org/gerrit/33229
>
> Waiting for initial review, will send out an API freeze waiver once initial
> review has been done.
Boron has been merged, still working on the API waiver for Beryllium.
Tom/Robert,
I believe all the relevant patches are merged for this bug, or do we have any pending patches that needs to be merged ?
Beryllium/Boron are fixed, but this needs to backported to Lithium, too.
If the bug is a blocker, has it been fixed for Lithium SR4? If this bug is NOT a blocker, can we downgrade the severity to “critical”?
Lithium does not have all the dependencies need to fix this.