Expand mount-point/state/type to union of string and enum

[mrevang]

Change Scope

• This change is being made to add more structure to the content of mount-point/state/type. This will enable more predictable content for programming against.
• This change is backwards compatible.

Platform Implementations

• Before mount-point/state/type was added to the standard, it was a Google specific augment.

[dplore]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit 3d01ba9

[dplore]

/gcbrun

[earies]

Few overall comments:

• Depending how this is looked at, it is a backwards incompatible change as you are ultimately changing the underlying YANG type which can have other effects outside of the encoded value representation
• I would propose if doing this to take the enum declaration out into a reusable typedef or better yet a set of expansible identities (and use an identityref rather)
• Reference to /proc/filesystems is useful here and there is also an implicit assumption of underlying OS in doing this (this already exists in other spots too)
• IMO drop the union - just keep an identityref then and implementations can augment in expanded identities to the base if necessary. If you order the union as such then the rule of thumb is that the value matches the string as first match everytime as both are encoded identically

But if this is looked at as a mapping of the first column of something like df output (Filesystem) then you have a mish-mash of what can be represented here (This is likely what each implemtation is doing today) meaning alot of different string values (or expanded identities which then don't make as much sense imo)

If this is to be the type from something like the output of mounts then corresponds directly w/ the list you might see from /proc/filesystems

[rgwilton]

Wouldn't we also need the enumeration to be listed above the string in the union definition (I appreciate that you are suggesting that the union isn't needed at all), otherwise everything would always match against the string, regardless of the enum values?

[dplore]

Thanks for the comments. We reviewed in the Dec 3 operators meeting and there is some rough consensus that making this change to this very new leaf as an indentify-ref like @earies suggests is cleaner and still supports the operational use case. We have good precedence of adding more identity refs as needed in areas like transceiver types.

@mrevang could you revise this remove the string entirely and become an identity-ref?