Remove default value for gRPC transport-security

[earies]

• (M) release/models/system/openconfig-system-grpc.yang
  • Remove default value for gRPC transport-security since an implementation cannot enable by default without other mandatory TLS attributes

Change Scope

• Remove default=true for gRPC transport-security. While it is recommended/preferred to enable transport-security, a YANG default here implies that the listening server has the ability to enable TLS without other mandatory parameters such as a certificate-id, mutual-authentication (and other future attributes for mutual-authentication that do not yet exist)

Platform Implementations

• N/A

[OpenConfigBot]

Major YANG version changes in commit f5788df4a0d0c24fe1dd153878b11e62fbbdf4d9:

[OpenConfigBot]

Compatibility Report for commit f5788df4a0d0c24fe1dd153878b11e62fbbdf4d9: ✅ pyangbind@6b85c2b

[dplore]

Today managing certificate-id, mutual-authentication is done out of band/outside of openconfig.

With the introduction of gNSI certz and authz and bootz, this moves to explicitly defined interfaces.

With this momentum, I think the time has past to change this default.

[earies]

Today managing certificate-id, mutual-authentication is done out of band/outside of openconfig.

With the introduction of gNSI certz and authz and bootz, this moves to explicitly defined interfaces.

With this momentum, I think the time has past to change this default.

I'm afraid you're missing the point that all of these projects are not going to be used by everyone concurrently but there is still a desire for only a subset - mainly YANG schemas and this node being a default=true is problematic for many reasons assuming some prior bootstrapping took place completely out-of-band. gNSI is not fully baked or adopted but there are real world deployments of this model set already for provisioning gRPC endpoints.

Also note that the nodes mentioned above still do exist in the schema set and there is no signal to the community or implementors that they are going away.

In addition, the other projects you mention are complementary to and possibly mutually exclusive to alternate methods of management. If there is a hard-set charter that gNSI is a must have for these provisions, I'm afraid this is going to gate adoption of these projects as it is then looking through a narrow lense.

The fact that it is default=true poses an issue for honoring defaults upon a plain server instance creation w/o other parameters.

[dplore]

Hi, thinking about this some more, I would like to understand the problem better. Let's discuss in more detail what is missing which makes having this enabled by default problematic. Then it can be more clear if these changes should be made or if the changes are so large in scope or infeasible such that transport-security should be disabled by default until the changes can be made.

Is the trouble with enabled by default is an issue regarding bootstrapping / initial configuration state of the device and where gRPC is enabled by default?