Last Call Review of draft-ietf-netconf-access-control-

Request Review of draft-ietf-netconf-access-control
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-11-29
Requested 2011-11-08
Draft last updated 2011-12-04
Completed reviews Secdir Last Call review of -?? by Carl Wallace
Assignment Reviewer Carl Wallace
State Completed
Review review-ietf-netconf-access-control-secdir-lc-wallace-2011-12-04
Review completed: 2011-12-04


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.