RESTCONF Protocol
draft-ietf-netconf-restconf-18

Thanks for your work on this.

(1)
I'm curious how the WG settled on using Server-Sent Events. My understanding is that the SSE framework is somewhat brittle when used on its own and there can be problems when there are intermediaries in the path. Did the WG consider other options (e.g., H2 server push or long polling)?

(2)
I know the jukebox module is just an example, but it actually made me wonder if there would ever be cause for the server to return a 451 status code in response to a POST or GET request rather than a 401 or 403. Obviously there is no analog in the netconf status codes and the use for this would be pretty atypical, but figured I would mention this thought since it occurred to me.

(I would have balloted DISCUSS based on the major comment, but Alexey beat me to it:)

Major:
- 4.6:  The first patch says the sever MUST support PATCH, and also that implementation of PATCH is optional. Language in 4.1 seems to assume the latter.

Minor:

- 2.5: I'm a bit surprised to see basic authentication encouraged to the same degree as other options.

- 5.2:  Did the working group consider the interoperability impact of not making either encoding MTI?

- 12, paragraph 4: Please consider not repeating the 2119 language from other sections.

Editorial/Nits:

-1.4, 6th paragraph: "...then this commit will act as the
   confirming commit": Which commit is "this" commit?

- 5.3, first sentence: Missing word?

The draft is nicely written, thank you for that.  I have a point in the security consideration section that I think is important to clarify in the draft.

Authentication for RESTconf - The method for HTTP authentication vary and some are really bad (HTTP Basic, digest isn't too far behind it).  This draft just requires some method, but I think a warning to research the methods since they have widely varying security levels is important.  For the HTTP Authentication methods, the RFCs cover the pitfalls well.  Here is the sentence:

   Client
   authentication MUST be implemented using client certificates or MUST
   be implemented using an HTTP authentication scheme.

How about:
   Client
   authentication MUST be implemented using client certificates or MUST
   be implemented using an HTTP authentication scheme.  The strength of 
   these methods vary greatly and (certificates are recommended or HTTP basic is not recommended).

Digest isn't great either, but at least not recommending basic would be good.  There are also a few newer experimental HTTPAuth methods that improve things, but are experimental.  One gets rid of stored passwords (HOBA).

I'm not sure how PATCH is MUST support but optional to implement in 

   The RESTCONF server MUST support the PATCH method.  RESTCONF uses the
   HTTP PATCH method defined in [RFC5789] to provide an extensible
   framework for resource patching mechanisms.  It is optional to
   implement by the server.
   
Can you help me understand?

- What about tls1.3 0RTT/replayable-data? There may be a case
to be made to mention this here and e.g. to say that only
idempotent requests (or none) are allowed use 0RTT early data.
Equally you could argue to not say anything since tls1.3 isn't
yet finished. I'd argue that saying something here is better
(and that saying to not use 0RTT at all is best) since
RESTCONF will use standard https libraries, which will at some
point soon support 0RTT and that might even make that happen
more easily than they ought. (This isn't a discuss as tls1.3
isn't yet done so I'd not feel right blocking on this basis,
but were tls1.3 done, which it will be soon I hope, this
would be a definite discuss as RESTCONF differs enough from
a browser for this to be a cause of possibly really bad
security problems.)

1.4: "Note that there are no interactions at all between the
NETCONF protocol and RESTCONF protocol.  It is possible that
locks are in use on a RESTCONF server, even though RESTCONF
cannot manipulate locks.  In such a case, the RESTCONF
protocol will not be granted write access to data resources
within a datastore." What you mean is clear, but the text is,
I think, self-contradictory - what is described is an
interaction between the two protocols. (And so is the fact
that access controls need to be commensurate between the two
protocols.) 

- section 2: would it be useful to add a reference to BCP195
and say that adhering to that is a good idea?  I think you
could maybe actually lose some (but not all) of the text here
via that single reference. (That might help a bit with
Alexey's discuss, not sure.)

- 2.5: "MUST use tls-cilent-auth or MUST use any HTTP
authentication scheme" is (as Kathleen noted) wishy washy.
And that leaves out html-form-based client auth methods too it
seems. I think you could word this better. (Not that that's
likely to affect the reality that clients here will just use
web engines so there's probably no point in expecting that
RESTCONF can use anything out of the ordinary.) The same
comment applies to section 12 where the same wishy-washy
statement occurs.

- 12: "There are many patterns of attack..." that screams
out for references, please add some to give the reader
a chance to understand if they don't already know.