Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ability to retrieve both op-state types together #8

Open
kwatsen opened this issue Oct 5, 2015 · 4 comments
Open

ability to retrieve both op-state types together #8

kwatsen opened this issue Oct 5, 2015 · 4 comments
Labels

Comments

@kwatsen
Copy link
Contributor

kwatsen commented Oct 5, 2015

On the interim call, Rob made in interesting point about config+operational, using BGP as an example.

Do we need to amend point 4 to allow for a method to retrieve these in a single operation?

OLD:

   4.  Separation of configuration and operational state data; ability
       to retrieve them independently
       A.  Be able to retrieve only the derived state aspects of
           operational state
       B.  Be able to retrieve only the non-derived state aspects of
           operational state

NEW:

   4.  Separation of configuration and operational state data; ability
       to retrieve them both together and independently
       A.  Be able to retrieve only the derived state aspects of
           operational state
       B.  Be able to retrieve only the non-derived state aspects of
           operational state
       C.  Be able to retrieve both the derived and non-derived state
           aspects of operational state together
@rgwilton
Copy link

Yes, I think that this is a requirement, and hence support this proposed change.

For asynchronous servers, I expect that it is more useful to return applied config + derived state together in a single request than it is to return intended cfg + derived state since the client is likely to already know what the intended config is.

I'm not sure whether section 4 of openconfig-netmod-opstate-01 makes this requirement completely clear, but I think that it is because it assumes that the applied-cfg is part of the operational state and hence naturally returned as part of a get request. Section 5.1.also implies that the would be returned together.

Rob

@kwatsen
Copy link
Contributor Author

kwatsen commented Oct 15, 2015

This proposal was accepted on today's interim call

@kwatsen kwatsen added the EDIT label Oct 15, 2015
@kwatsen
Copy link
Contributor Author

kwatsen commented Oct 19, 2015

Change applied to draft - moving to REVIEW state

@kwatsen kwatsen added REVIEW and removed EDIT labels Oct 19, 2015
@kwatsen kwatsen added DONE and removed REVIEW labels Dec 15, 2015
@kwatsen
Copy link
Contributor Author

kwatsen commented Dec 15, 2015

4-C was accepted in -00 draft (moving to DONE)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants