Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> Hi Martin,
> 
> >> Firstly, while ietf-http-client defines HTTP "basic" authentication
> >> parameters, the example in the I-D didn't show them, even though the
> >> YANG module uses the ietf-http-client module.
> > 
> > I am not sure what this reply means exactly.  My comment about
> > authorization above was for outgoing notifications (section 3.4.6 in
> > RFC 8341).  I.e., the device needs a local username for the configured
> > subscription.
> 
> Do you mean to add to the draft a new section called something like
> "Authorization" that mimics what's in the SN draft regarding, e.g.,
> NACM?

No I mean that when the device generates a notification, NACM needs a
user name to find the access control rules.  What is the user name
with this new protocol?

> >> That said,
> >> ietf-http-client fails to define a "path" field, so that appears to be
> >> something that should be added to it
> > 
> > I don't think 'path' belongs in http-client; not all http client
> > configs require a 'path' (e.g. restconf uses it's own mechanism wih
> > ".well-known").
> 
> True, path isn't needed for RESTCONF clients.
> 
> This draft doesn't assume anything about the server (if this is a
> valid assumption is discussed below) and, presumably, this assumption
> may be a common.  So maybe ietf-http-client should also define a
> feature statement for the new "path" leaf, thus servers have an easy
> way to turn it on.  It would be mandatory false, with the description
> statement indicating that it is only needed for some protocols.
> Alternatively, this draft could augment in a "path" leaf into the
> "http-params" section, or define a new section for just the path.
> Thoughts?

I prefer the latter.  I think the 'path' leaf will not be very common
whe the http-client grouping is used.

> Regarding the validity of the assumption that this draft must also (in
> addition to http-client-server) assume nothing about the remote
> server.  It seems like the completion to that assumption is, why is it
> not a RESTCONF server.  The reason is that we don't want to burden the
> remote server with needing to implement a full RESTCONF server.  But,
> if the server were to implement only one module that implements only
> one RPC (e.g., receive-notifications) and otherwise has no protocol
> accessible nodes, then a fully-compliant server-implementation could
> be very small (e.g., returning either an HTTP error code or an empty
> response for datastore oriented HTTP/RESTCONF requests).  Just an
> idea, it may not be too much of a jump for this draft, and the
> benefits a questionable (ability to assume discovery and have
> well-defined URL construction (i.e.,
> {+restconf}/operations/receive-notifications).

I'm fine with this being a new "protocol", not RESTCONF.

> >> As for the HTTP operation and request body, POST-ing a stream of
> >> notifications seems right.
> > 
> > Yes POST seems right.  I'm not so sure about the streaming though.
> > Perhaps pipelining is the right mechanism.  For "bulk" sending, the
> > "bundled-message" defined in draft-ietf-netconf-notification-messages
> > seems right.
> 
> These sound like good conversations to have.
> 
> 
> > My point is that the document needs quite a lot of work, and I think
> > that the WG should spend its energy on getting the "client-server"
> > documents ready.   NOTE again that I do think that this is good work,
> > and we should work on it, the sooner the better (but after the
> > existing documents).
> 
> 
> We can slow-walk this draft.  As you say, we need to prioritize other
> drafts...

Ok.


/martin