Use union type with empty type to enable "[null]" correct answer in case a mandatory data is not available

[EstherLerouzic]

If mandatory data are not present in the topology instance (for example due to a not responding server which makes the value unavailable), a yang-driven sofware will probably generate an "inconsitent" value based on the implementer or the attribute. eg fiber length is mandatory, and if not present the instance may contain an inconsistant data (eg -99999.99 or 0.00, or -1234 or ....) to satisfy the mandatoty requirement still conveying the information that data is not there.
In order to avoid these unspecified behaviour, I propose to explicitly use the empty type, so that if a mandatory data is not found the response should be of the empty type eg "[null]" for json case [RFC7951].
This means that all our types should be union with the empty type.

[EstherLerouzic]

To complete this issue, using empty type may also be useful for optional parameters when they are required for use cases.

For example, let's consider an amplifier element to represent a Raman pump. In this case tilt-target is not applicable. so in the yang tilt target can be put as optional to cover this use case. Then extracting an EDFA amplifier information with tilt-target = [null] has not the same meaning as not reporting the attribute at all: in one case it means that the value was required but not found (wrongly reported, issues with the server..., so needs some corrective action), in the other case, it means that this attribute is not applicable, so no error in the data or during the extraction.

[sergiobelotti]

AP @sergio,Italo and Esther: to provide text clarification about the usage of "empty" type for optional" attribute

[sergiobelotti]

AP @sergio,Italo and Esther: to provide text clarification about the usage of "empty" type for optional" attribute

This is the text proposed for AP above:

"If an optional attribute is not applicable to an entity it MUST be omitted (not be present in the datastore).
If an optional/mandatory attribute is applicable but its value is unknown, it MUST be reported using the "empty" type. "

The proposal would be to add this text clarification in the description field of the YANG module.

[ju7ien]

The following sentences seem easy to agree on:
"If an optional attribute is not applicable to an entity it MUST be omitted (not be present in the datastore).
If a the value of a mandatory attribute is unknown, it MUST be reported using the "empty" type."

I'm less sure about the "optional but applicable" case. It suggests it's a conditional attribute while the module doesn't express the associated criteria. Besides, there could be some situation where, for example, 2 among 3 attributes are enough: why would we mandate an implementation to include the 3rd one as null whereas there's no "missing value" to express?

How about: "If an optional attribute is applicable but its value is unknown, it SHOULD be reported using the "empty" type."?

[sergiobelotti]

The following sentences seem easy to agree on: "If an optional attribute is not applicable to an entity it MUST be omitted (not be present in the datastore). If a the value of a mandatory attribute is unknown, it MUST be reported using the "empty" type."

I'm less sure about the "optional but applicable" case. It suggests it's a conditional attribute while the module doesn't express the associated criteria. Besides, there could be some situation where, for example, 2 among 3 attributes are enough: why would we mandate an implementation to include the 3rd one as null whereas there's no "missing value" to express?

How about: "If an optional attribute is applicable but its value is unknown, it SHOULD be reported using the "empty" type."?

@ju7ien : I would be fine with your modified text. @EstherLerouzic @italobusi @dieterbeller : what is your opinion?

[EstherLerouzic]

OK for me!

[dieterbeller]

OK for me too

[italobusi]

The following sentences seem easy to agree on: "If an optional attribute is not applicable to an entity it MUST be omitted (not be present in the datastore). If a the value of a mandatory attribute is unknown, it MUST be reported using the "empty" type."

I'm less sure about the "optional but applicable" case. It suggests it's a conditional attribute while the module doesn't express the associated criteria. Besides, there could be some situation where, for example, 2 among 3 attributes are enough: why would we mandate an implementation to include the 3rd one as null whereas there's no "missing value" to express?

How about: "If an optional attribute is applicable but its value is unknown, it SHOULD be reported using the "empty" type."?

I think that the SHOULD will bring back the ambiguity between the attribute not being present and being reported using the "empty" type

IMHO, there is no value to add the "empty" type in the YANG model if we allow an implementation to decide whether to omit the attribute or to report it using the "empty" type

In the example above, if 2 among 3 attributes are enough, IMHO the third attribute MUST be omitted. I think that the third attribute can be considered as "not applicable". Maybe we can find a better wording for "not applicable" ...

[sergiobelotti]

This is the final text agreed during the meeting of January 25 th:
"If the value of a mandatory attribute is unknown, it MUST be reported using the "empty" type.
If an optional attribute is applicable but its value is unknown it MUST be reported using the "empty" type.
If an optional attribute is not applicable to an entity it MUST be omitted (not be present in the datastore)."
This text will be added in the description of the module in the YANG .