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

[Kent Watsen <[e-mail]>]

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?



>> 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?

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).



>> 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...


Kent // as co-author