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