Add deviate(not-supported) support for identities

[abierman]

There is no way for a server vendor to tell the YANG client that a specific identity in a YANG module is not supported. This is critical for vendors who use YANG modules defined by an SDO (all of them)

YANG conformance for identities is particularly awful at this time because it mandates that every identity in a supported module be implemented. Yet YANG modules are designed with the intent that a vendor can choose a subset of the identities to support (e.g. iana-if-type)

There must be a mechanism in YANG for the server to convey the exact subset of identities that are supported by the server

Deviations are probably unacceptable because they imply the server implementation is deficient and flawed because the deviation exists. This is not the case with identities. YANG has no support (except description-stmt) to identify if a server MUST, SHOULD, or MAY support an identity for a specific identityref leaf or leaf-list.

[kwatsen]

We struggled with this problem too when we were trying to define the algorithm identities in the crypto-types drafts. Before abandoning the "key generation" effort, the last idea was to define opstate lists or RPCs to return the subset of identities supported.

Sometimes I put an if-feature statement under identities to enable implementations to toggle support that way. One limitation to this approach is that features are global and, e,g,, it might be the case that a server supports an identity in one part of its config but not an another. The general fix for when a global if-feature is in a grouping is to augment-in additional application-specific if-feature statements, but this is not possible with identities as they're not an allowed target for augments. We could possibly allow identities be augmentable, but it won't support path-specific identities as identities are global (unlike groupings).

[lllyfeng]

I suggest add restriction to type identity-ref, for example: type identity-ref { base interface-type { except iana-interface-type; } }

or type identity-ref { base iana-interface-type { accept iso88023Csmacd | fastEther | gigabitEthernet ; } }

I think use if-feature is useful but in some scenario sever do support this identity but one leaf maybe only support a subset of a identity.

deviation/deviate should be used to indicate some changes of data node's attribute server supported.

[troglobit]

For future readers, here's what we did for Infix:

 // relevant snippet from infix-interfaces@yang
 deviation "/if:interfaces/if:interface/if:type" {
    deviate add {
      must "self::if:type = 'ianaift:bridge' or"
         + "self::if:type = 'ianaift:ethernetCsmacd' or"
         + "self::if:type = 'ianaift:ilan' or"
         + "self::if:type = 'ianaift:l2vlan' or"
         + "self::if:type = 'ianaift:other' or"
         + "self::if:type = 'ianaift:softwareLoopback'" {
    error-message "Invalid interface type for this interface.";
      }
    }
  }

When using netopeer2-cli to connect to Infix and attempt to change the if:type to, e.g., ianaift:vdsl, we now get the following response:

> edit-config --target running --config
ERROR
    type:     application
    tag:      operation-failed
    severity: error
    message:  Invalid interface type for this interface. (Data location "/ietf-interfaces:interfaces/interface[name='e0']/type".)

[rgwilton]

Also see #40, #80 and #124

[abierman]

Part of the conformance issue for identities

Support a new statement like 'accept-list' Need to clarify if it means:

• A) accept only these values
• B) accept at a minimum these values

Must Do