Subject: [Netconf] Kathleen Moriarty's Discuss on draft-ietf-netconf-yang-patch-12: (with DISCUSS and COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 31 Oct 2016 08:28:43 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-netconf-yang-patch-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be easy to resolve through discussion or some text tweaks. 
In the security considerations section, I see some text that hints at my
questions below, but isn't clear enough, so I'd like to discuss it to see
if these things are covered, or why they are not, and to see if we can
tweak the text a bit.

The following text is helpful, is PATCH described in
[I-D.ietf-netconf-restconf]?
   This document defines edit processing
   instructions for a variant of the PATCH method, as used within the
   RESTCONF protocol.

I see section 2.7 discusses error handling and validating the YANG
module, but is there a way that the hash (or some other mechanism) of the
patch could be validated to ensure the patch was not altered.  Is that
already described for PATCH?

I also see this text in the security considerations section:
   It is important for RESTCONF server implementations to carefully
   validate all the edit request parameters in some manner. 

Is the source of the patch authenticated?  Can the client receiving the
patch be authenticated?  Is this handled through RESTCONF?  Since YANG
modules could add in write capabilities, unauthenticated patches could
result in opening backdoors or revealing information that was not
intended.  You are covering it with that statement, but it's not clear if
both ends can be authenticated and there are attacks if they are not
authenticated.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Nit: In section 2.2

   YANG Patch does not provide any access to specific datastores.  It is
   am implementation detail

s/am/an/