[netconf] issue #2 draft-ietf-netconf-https-notif (discover capabilities)

[Martin Bjorklund <[e-mail]>]

Hi,

For the encoding I think we have four options:

1)  define one fixed encoding

2)  support multiple encodings and let the identity https derive from
    sn:configurable-encoding.  this ties into the mechanism defined in
    RFC 8529.  requires a "default encoding".

3)  support multiple encodings and do not derive from
    sn:configurable-encoding.  define a discovery mechanism that must
    be used to dynamically figure out which encoding to use.

4)  combination of 2+3; make it configurable, but let the default
    encoding be dynamic


I think it is quite clear that we don't want to do 1.  People have
expressed requirements for both text-based and binary encodings.

To discover the encoding, isn't this possible with standard HTTP?
Googling a bit showed an old I-D for an Accept-Post header that the
server could return in response to OPTIONS; this could have been
useful.  (Hmm, it seems it is actually
defined:https://www.iana.org/assignments/message-headers/message-headers.xhtml)
Perhaps someone with HTTP knowledge can recommend a solution?

As for the format of capabilities in general, I think a normal config
false YANG model will work.  If we use OPTIONS (or GET on some related
uri) the client can send an Accept header to indicate which format it
prefers for this config false data as usual
("application/yang-data+xml" or "application/yang-data+json" or some
other media type for binary formats)


/martin