I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines such an access control model to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. I am not familiar with NETCONF or YANG so my review may be off-base. I found the frequent references to "recovery sessions" and "non-recovery sessions" unnecessary and somewhat confusing. Couldn't this concept be described once and omitted from the various lists of steps? There are probably some inconsistencies in the RFC 2119 language around the "recovery session" concept. For example, section 3.4.4 provides a bulleted list of steps that MUST be followed. Included in this list is an exception for recovery sessions. Section 3.3.1 says a "server MAY support a "recovery session" mechanism". Should 3.3.1 be a MUST? Section 3.1.1 references both "recovery session" and the ability to disable the entire access control model "during operation, in order to debug operational problems". What does the latter bullet that mentions debugging refer to in the model? Is this bullet just a second reference to recovery session? In section 3.2.4, copy operations may be partially performed while "nodes to which the client does not have read access are silently omitted". Why is this OK? It seems inconsistent with section 3.1.3, which says "If the user is authorized to perform the requested access operation on the requested data, then processing continues", implying that processing does not continue otherwise. The same silent skipping of items appears elsewhere as well, including edit config. At a minimum, some rationale describing why these silent omissions are acceptable should be provided.