Note to editors: Please style the question as "Heading 3" and answer as normal "Paragraph" (see an existing question). Please simply add to the end of the list of existing questions.
The UML model provides clarity on which attributes are intended to be mandatory. The Yang (derived from the UML using tooling) is somewhat looser. Most attributes are optional in the Yang. We do aim to tighten this up a little.
Where you cannot map an attribute, e.g., because the feature or aspect of technology is not present in the device or in the controller, the attribute can either be omitted (i.e., can be considered as not mandatory) or, if available in the definition, set to a relevant default value or null value.
You can choose to not support node-rule-group in which case all potential connection opportunities in the node are assumed to be allowed. If you choose to support node-rule-group, then you can model to whatever depth you consider appropriate for your application. Clearly, the deeper and more precise the model, the more often a client based path computation capability will choose valid routes without requiring supplementary information.
The intention is that there is sufficient detail to allow an understanding of which connectors and, where relevant, pins the signal passes through. The pin is only relevant if the connector carries several modeled signals. This is to help diagnostics where the cable/connector may be faulty and to clarify how the signal traverses in a complex wiring environment (recognizing that we are intentionally not covering outside plant). The specific identification ought to be that that would be meaningful to a person standing at the equipment. But you can choose to be less precise if the application would not benefit from this detail. Where the pin detail is not relevant it can be omitted.
The aim is to not use RPC but to instead use standard Restconf/OAS operations. We are intending to remove the RPCs in a later release. We suggest that you explore the Restconf approach or the OAS approach.