search

Juniper / go-netconf

NETCONF implementation in Go.
Other
254 stars 110 forks source link

add optional XML header parameter for HelloMessage #60

Closed s3rj1k closed 1 year ago

s3rj1k commented 6 years ago

This is needed for some HP switches for example HP 5940.

This box does not expect XML header in hello message.

New Boolean optionally disables this header.

nemith commented 6 years ago

Looks like we shouldn't include this at all.

https://tools.ietf.org/html/rfc6241#section-3.2

nemith commented 6 years ago

Never mind that is for DOCTYPES. A message MAY have xml declaration. Which means HP is actually violating the RFC by refusing it.

A NETCONF message MAY begin with an XML declaration (see Section 2.8 of [W3C.REC-xml-20001006]).

https://tools.ietf.org/html/rfc6241#section-3

s3rj1k commented 6 years ago

@nemith Hi, did a little research on this subject

indeed RFC6241 states that

A NETCONF message MAY begin with an XML declaration (see Section 2.8 of [W3C.REC-xml-20001006]).

It also states that one can lookup that MAY actually mean in RFC2119

https://tools.ietf.org/html/rfc6241#section-1

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

So looking into how MAY is defined in RFC2119:

  1. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

And just in case what MUST mean:

  1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

So I agree that HP breaks compatibility with RFC by refusing to accept xml headers.

But also, by refusing to implement vendor agnostic functionality, is this case, accepting pull request, Juniner breaks RFC.

Still in readme you position this library as basic netconf RFC implementation, can you comment on this?

nemith commented 6 years ago

But also, by refusing to implement vendor agnostic functionality, is this case, accepting pull request, Juniner breaks RFC.

No one is refusing anything I just want to make sure nothing else breaks by merging this change and I want the API to be solid so I am trying to take some time to make sure it is implemented right. I also don't work for Juniper anymore.

Still in readme you position this library as basic netconf RFC implementation, can you comment on this?

nemith commented 2 years ago

This will break the API and callers. Need to find a a better way.

I'll make this optional in the v2 API. Either way HP should fix their implementation as well.

nemith commented 1 year ago

Closing as this is a breaking API change. Ideally we just don't ever send this header.

github.com/nemith/netconf won't be sending this header which should be more compatible.