Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change

[Andy Bierman <[e-mail]>]

Hi,

I updated the draft with these changes on github.
There is a draft-pre-09.txt file now for you to review.


Andy


On Tue, Nov 14, 2017 at 5:05 PM, Mahesh Jethanandani <
[e-mail]> wrote:

> Andy,
>
> I assume you will incorporate these changes in the -09 version of the
> draft.
>
> However, I am unable to review the changes in github. Can you post the
> diffs of the draft w.r.t. -08 version.
>
> That still leaves us with one issue, and that has to do with the what
> permission to give edit-operation. I am assuming the WG agrees that making
> the change from ‘none’ to ‘read’ for edit operations makes maintenance more
> difficult and makes the operation more vulnerable, unless all the deny
> rules are in place.
>
> We will need to update the security considerations section to address
> Eric’s concerns. How about this update?
>
> OLD:
>
> Therefore, a server MUST NOT vary their OPTIONS responses
> based on the existence of the underlying resource, which would
> indicate the presence or absence of resource instances.
>
>
> NEW:
>
> Therefore, a server MUST NOT vary their OPTIONS responses
> based on the existence of the underlying resource, which would
> indicate the presence or absence of resource instances. In particular
>
> servers should not expose instance information before validating field
>
> information.
>
>
> Cheers.
>
> On Nov 13, 2017, at 11:28 PM, Martin Bjorklund <[e-mail]> wrote:
>
> Hi,
>
> I just read this thread, and I agree with the changes, but see below
> for a comment.
>
>
> Andy Bierman <[e-mail]> wrote:
>
> Hi,
>
> Here are some proposed edits to make the data rule consistent with the
> examples.
> Note that this issue is not related to the edit in the original 1-week
> change.
>
>
> sec. 3.3.5:
>
> OLD:
>
>
>      data node rule:  controls access for a specific data node, identified
>      by its path location within the conceptual XML document for the
>      data node.
>
>
> NEW:
>
>      data node rule:  controls access for a specific data node and its
> descendants,
>      identified by its path location within the conceptual XML document
> for the
>      data node.
>
>
> sec 3.4.5, step 6, bullet 2:
>
>
> OLD:
>
>        *  The rule does not have a "rule-type" defined or the "rule-
>           type" is "data-node" and the "path" matches the requested
>           data node, action node, or notification node.
>
>
> NEW:
>
>
>        *  The rule does not have a "rule-type" defined or the "rule-
>           type" is "data-node" and the "path" matches the requested
>           data node, action node, or notification node. A path is
>           considered to match if the current data node is the data node
>           specified by the path, or is a descendant data node of this
>           data node.
>
>
> I propose:
>
>             The rule does not have a "rule-type" defined or the
>             "rule-type" is "data-node" and the "path" matches the
>             requested data node, action node, or notification node.
>             A path is considered to match if the requested node
>             is the node specified by the path, or is a
>             descendant node of the path.
>
> Note:  s/current node/requested node/ which is the term used in the
> first sentence.  And then s/data node/node/ since the first sentence
> refer to data-, action-, and notification node.
>
> I have checked in this fix in the repo.
>
>
> /martin
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> Mahesh Jethanandani
> [e-mail]
>
>