Skip to content

Latest commit

 

History

History
55 lines (40 loc) · 4.34 KB

README.md

File metadata and controls

55 lines (40 loc) · 4.34 KB
Raw

Go netconf client library

WARNING: This is still pre-1.0 and the API may still change however this library is being use at scale in production with good results.

Go Reference Report Card stability-unstable Validate coverage

This library is used to create client applications for connecting to network devices via NETCONF.

Like Go itself, only the latest two Go versions are tested and supported (Go 1.22 or Go 1.21).

RFC Support

RFC Support
RFC6241 Network Configuration Protocol (NETCONF) 🚧 inprogress
RFC6242 Using the NETCONF Protocol over Secure Shell (SSH) ✅ supported
RFC7589 Using the NETCONF Protocol over Transport Layer Security (TLS) ✅ beta
RFC5277 NETCONF Event Notifications 💡 planned
RFC5717 Partial Lock Remote Procedure Call (RPC) for NETCONF 💡 planned
RFC8071 NETCONF Call Home and RESTCONF Call Home 💡 planned
RFC6243 With-defaults Capability for NETCONF 💡 planned
RFC4743 Using NETCONF over the Simple Object Access Protocol (SOAP) ❌ not planned
RFC4744 Using the NETCONF Protocol over the BEEP ❌ not planned

There are other RFC around YANG integration that will be looked at later.

See TODO.md for a list of what is left to implement these features.

Comparison

Differences from github.com/juniper/go-netconf/netconf

  • Much cleaner, idomatic API, less dumb I, @nemith, was the original creator of the netconf package and it was my very first Go project and it shows. There are number of questionable API design, code, and a lot of odd un tested bugs. Really this rewrite was created to fix this.
  • No impled vendor ownership Moving the project out of the Juniper organization allowes better control over the project, less implied support (or lack there of), and hopefully more contributions.
  • Transports are implemented in their own packages. This means if you are not using SSH or TLS you don't need to bring in the underlying depdendencies into your binary.
  • Stream based transports. Should mean less memory usage and much less allocation bringing overall performance higher.

Differences from github.com/scrapli/scrapligo/driver/netconf

Scrapligo driver is quite good and way better than the original juniper project. However this new package concentrates more on RFC correctness and implementing some of the more advanced RFC features like call-home and event notifications. If there is a desire there could be some callaboration with scrapligo in the future.