YANG Patch Media Type
RFC 8072

Note: This ballot was opened for revision 12 and is now closed.

(Benoît Claise) Yes

Alexey Melnikov Yes

Comment (2016-10-29 for -12)
No email
send info
Thank you for a well written document. A couple of small nits in your media type registration:

4.2.1.  Media Type application/yang-patch+xml

      Subtype name: yang-patch

Should be "yang-patch+xml"

      Encoding considerations: 8-bit
         Each conceptual YANG data node is encoded according to the
         XML Encoding Rules and Canonical Format for the specific
         YANG data node type defined in [RFC7950].
         In addition, the "yang-patch" YANG Patch template found
         in [RFCXXXX] defines the structure of a YANG Patch request.

If you are allowing any of UTF-16 encodings, then the above is not correct and should say "Binary".

      Fragment identifier considerations: Fragment identifiers
         for this type are not defined.

I suggest you just say "The same as for application/xml".

It would be good if you register a new file extension for this media type.

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2016-11-03 for -12)
No email
send info
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.

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Comment (2016-11-03 for -12)
No email
send info
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.

(Stephen Farrell) No Objection

Comment (2016-11-03 for -12)
No email
send info
- 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.)

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2016-12-02)
No email
send info
Thanks for addressing my prior discuss question.

Alvaro Retana No Objection