YANG Patch Media Type
draft-ietf-netconf-yang-patch-14

Update: I've cleared my discuss bases on the authors' intent to clarify that yang-patch is intended to be atomic regardless of the underlying protocol.

-2, 2nd paragraph, last sentence: is the message body mentioned in the last sentence the same as the one described by the media type in the previous sentence? That is, are we talking about one body part, or two? If one, the ordering of the 2nd and 3rd sentence is a bit confusing to me.

-2.2, tree diagram:
If edit-id is optional, how are errors identified if it is not present?

-2.6, first paragraph: "...RESTCONF server SHOULD return a "yang-patch-status" message."

What if it doesn't? (I.e. Why not MUST?)

-2.7, 2nd paragraph: "... SHOULD return a "yang-patch-status" message."

What if it doesn't?

Editorial:
-2, first bullet: s/at within/within

-2, Accept-Patch example: The example seems misplaced, as it seems to apply to the text two paragraphs back, not the immediately proceeding paragraph.

Thanks for addressing my prior discuss question.

This document may have the clearest terminology section I've ever seen in a draft. Thank you all for that!

I have the same question as Ben did in his Discuss, about just how atomic a patch operation is. I'll watch the discussion in that thread.

- section 2: I'm not clear what that example of Accept-Patch is
telling me. (And if that's meant to be a figure then a caption
and figure number would be good.)

- 2.2: How do you ensure a patch-id is unique? In what scope?
Random idea: you could specify a way to make these unique if you
hashed a representation of the current resource and the patch
data and the date/resource URI or something. And that might have
nice properties for auditing. Think of "git blame" etc.:-) It
might be possible to do a similar thing for edit-id too I guess.
(Note that I'm only suggesting this as an informative bit of
spec, i.e. as a "here's a good way to do it" kind of thing.)

- section 5: you very reasonably say that a server SHOULD
"prevent system disruption due to excessive resource
consumption" but you don't say how to do that. Is that ok?  At
least some references would help implementers not go so wrong I
think. (Sorry, I don't have such references to hand.)