certz default profiles

[LimeHat]

1. Does the default profile have to be named "gNxI"? The spec implies so, but is there a reason to require a specific profile name to be used by all implementations? Usually, openconfig is not opinionated on the naming schemes. Also, this is not a new feature - there are existing implementations that support default profiles for grpc-based services, so the renaming will introduce an NBC change for all customers and deployments.

2. .proto and the readme have slightly different definitions of the rotate request behavior with an absent ssl_profile_id field: proto says to rotate the current profile https://github.com/openconfig/gnsi/blob/a80d61cd116210b0dfcac021ecd74906f3bbf4fa/certz/certz.proto#L287-L291 and the readme refers to the GnXi profile by name https://github.com/openconfig/gnsi/blob/a80d61cd116210b0dfcac021ecd74906f3bbf4fa/certz/README.md?plain=1#L44-L46

3. is it required to support certz rotation for the default profile? can the cert rotation be supported only for profiles added via certZ? e.g. in situations where the default profile uses idevID/IAK, it may not be trivial to implement the said rotation

[morrowc]

For 1: NBC - National Broadcast Company - probably that's not what you mean... what did you mean? :) I really don't know why there's a spec'd name for the default profile, that does seem very implementation specific.

For 2: I believe that the wording in the proto means: "Rotate the profile used by gNSI if there's not a specified profile_id." I think this is to accommodate cases where there maybe a different ssl profile for the various gN*I services in existence on the remote device.

as to the Readme content.. oh, I bet I wrote that and I bet I meant: 'gNxI' == 'gN*I' == 'gNI'

so there may be a:

• gNMI
• gNOI
• gNSI profile(s) defined on the device, not that a single profile would be named: "gNxI", in retrospect that sure looks/sounds confusing :(

Got replacement text you like?

[morrowc]

(Oh, that text may be Tomek's text, not mine... I'm sure I read/etc it though, ouch)

[LimeHat]

NBC - National Broadcast Company - probably that's not what you mean... what did you mean? :)

Apologies for the confusion, I meant "not backward-compatible" change :)

I believe that the wording in the proto means: "Rotate the profile used by gNSI if there's not a specified profile_id." I think this is to accommodate cases where there maybe a different ssl profile for the various gN*I services in existence on the remote device.

That part is actually fine, I understand the .proto definition (rotate the currently used profile); in fact, I don't expect different profiles used by different gNxI services since gNMI/gNOI/gNSI are using the same port number/socket. [^1][^2]

The scenario I have in mind is, for instance, if gNSI is configured with a custom profile (let's say test1). It makes sense to rotate test1, as implied by .proto, but the README suggests that gNxI profile should be rotated instead (despite the fact that it is not used anymore, at least by the current server instance).
So it's more about correcting the text in README (e.g. we can just copy the .proto definition, Leaving this field blank means that this stream will rotate the SSL profile which is currently being used by the gNSI service.)

[^1]: technically, gNSI is not in IANA registry yet; only gNMI and gNOI are. we raised this question earlier in b/287497407, and have been told to use the same port. [^2]: the only exception that comes to my mind is if an operator has multiple VRFs. Each instance can have a unique tls profile/grpc server instance. I assume we want to limit the rotation to the profile used by the gNSI server that received the request, not all profiles used by all servers (if they are different).

[morrowc]

I agree that the text in the README could have be better :( I think the text in question is already cleaned up though.