Skip to content

openconfig keychain send-and-receive description update.#1499

Open
ishwarbnaik wants to merge 3 commits into
openconfig:masterfrom
ishwarbnaik:oc-keychain-send-and-receive
Open

openconfig keychain send-and-receive description update.#1499
ishwarbnaik wants to merge 3 commits into
openconfig:masterfrom
ishwarbnaik:oc-keychain-send-and-receive

Conversation

@ishwarbnaik

Copy link
Copy Markdown

Change Scope

  • The current description of this leaf does not clearly state that the configuration to receive-lifetime should be rejected when send-and-receive is set to "True". This description should be updated to clearly state that when this leaf is set to "True", configuration of a distinct receive-lifetime is not valid and the server should reject it as an invalid configuration. ( keychain model send-and-receive expected behaviour #1476 ).
  • This change is backward compatible.

Related Issues
Fixes #1476

Platform Implementations
NA

Tree View
No changes to tree view

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the openconfig-keychain YANG model to version 0.6.0, adding a new revision and clarifying the behavior of the send-and-receive leaf in its description. The reviewer identified inconsistent indentation in the updated description and recommended adding a must statement to programmatically enforce the constraint that a distinct receive-lifetime should not be configured when send-and-receive is true.

Comment on lines +116 to +123
description
"When this is set to true (the default value), the specified send-lifetime
is also used in the receive direction; configuration of a distinct
receive-lifetime is not valid in that case and the server should reject it
as an invalid configuration. When set to false, the device uses the
configured receive-lifetime for the receive direction (asymmetric mode).
If send-and-receive is false and the device does not support asymmetric
configuration, the server should reject the config as unsupported.";

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The indentation of the description text is inconsistent; lines 118-123 have an extra leading space compared to line 117.

Additionally, while the updated description clarifies that configuring a distinct receive-lifetime is invalid when send-and-receive is true, this constraint should be enforced programmatically using a must statement. This ensures that the server correctly rejects invalid configurations as stated in the description and the PR objectives.

      description
        "When this is set to true (the default value), the specified send-lifetime
        is also used in the receive direction; configuration of a distinct
        receive-lifetime is not valid in that case and the server should reject it
        as an invalid configuration. When set to false, the device uses the
        configured receive-lifetime for the receive direction (asymmetric mode).
        If send-and-receive is false and the device does not support asymmetric
        configuration, the server should reject the config as unsupported.";
      must "not(.) or not(../../../receive-lifetime/config/start-time or ../../../receive-lifetime/config/end-time)" {
        error-message "Distinct receive-lifetime cannot be configured when send-and-receive is true";
      }

@dplore

dplore commented May 26, 2026

Copy link
Copy Markdown
Member

/gcbrun

@OpenConfigBot

Copy link
Copy Markdown

No major YANG version changes in commit e1b5c83

@dplore dplore moved this to Ready to discuss in OC Operator Review Jun 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Ready to discuss

Development

Successfully merging this pull request may close these issues.

keychain model send-and-receive expected behaviour

3 participants