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

Minor changes on NETCONF implementation #45

Closed
wants to merge 6 commits into from

Conversation

SCadilhac
Copy link
Contributor

  • No space after ampersand escaped characters
  • Add writable-running capability
  • Announce base:1.0 capability (because we support only legacy framing system)
  • No quotes around revision value

@olofhagsand
Copy link
Member

@SCadilhac thanks!!

I have cherry-picked and pushed into develop:

  • Add conformance-type to modules-state (Had to enhance test/test_feature.sh)
  • Allow new lines in prompts

But I have some comments on the others:
(1) No space after ampersand escaped characters -
I strictly followed https://www.w3.org/TR/2008/REC-xml-20081126/#syntax where it says eg:
single-quote character (') may be represented as " ' "
Note the space after the semi-colon. I am happy to remove the space, seems strange to me, but it is there in the W3C spec. Any comment?
2) Add writable-running capability. Announce base:1.0 capability
writable-running: OK, strictly speaking it is supported in the sense that you can write to the running config datastore. But there is no commit action associated if you write directly to running, ie no backend actions are triggered as when you write to candidate and then do commit. I don't see any discussion on that in RFC6241. I.e., what is the semantics of writable-running? But I would expect that you would want backend plugins to be triggered and they currently are not. So I question whether the "writable-running" capability is actually supported?
base:1.0 OK,
quotes around version number: OK
3) Add xmlns to the element in xml_merge
I agree to the error, but have some problems with the patch due to (my) style of programming using labels, I use ok: only as a positive exit from the function with no (or only minor) side-effects.
As this seems to be a global error,I think I may need to look at this generally.

@SCadilhac
Copy link
Contributor Author

For the follow up:
(1) See #52
(2) See #53
(3) See #49

@SCadilhac SCadilhac closed this Oct 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants