Subject: [Netconf] AD review of draft-ietf-netconf-access-control-06

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 7 Nov 2011 14:13:07 +0100

I have performed the AD review of draft-ietf-netconf-access-control-06.
There are no show-stoppers in this document, so I am sending it to IETF
Last Call. However, because of the timing conflict with the IETF meeting
which will keep busy many IETF contributors I will ask for the Last Call
period to be one week longer than usual (three weeks instead of the
usual two weeks). 

Please consider the questions and comments below together with the other
Last Call comments. The Technical comments are marked T and the
Editorial comments are marked E. 

T1. In Section 2.5: 
   It is necessary that the user-to-group mapping can be delegated to a
   central server, such as a RADIUS server [RFC2865] [RFC5607].  Since
   authentication is performed by the NETCONF transport layer, and
   RADIUS performs authentication and service authorization at the same
   time, the underlying NETCONF transport needs to be able to report a
   set of group names associated with the user to the server.

How does this requirement reflect in the rest of the document or maybe
does it need future work in RADEXT or in the YANG module for the
reporting part? 

T2. In Section 3.1.1: 

o  The entire ACM can be disabled during operation, in order to debug
      operational problems.

I think that the Security Considerations section needs to deal with this
case - at a minimum draw the attention of operators and implementers on
the existence of this mode, maybe make recommendations about how the
option of disabling the ACM can be prevented from becoming a potential
source of security attack. Just establishing enable as default mode is
not sufficient IMO. 

T3. Should not the default values of the four global enforcement control
switches defined in section 3.3.3 be specified? If no, why? 

E1. In Section 2.7: 

   Access control rules to restrict access operations on specific
   subtrees within the configuration datastore needs to be supported.

s/needs/need/

E2. Why is the following paragraph part of sub-section 3.3.1 Users? 

   The server MAY support a "recovery session" mechanism, which will
   bypass all access control enforcement.  This is useful for
   restricting initial access and repairing a broken access control
   configuration.

E3. I am questioning whether the capitalization of SHOULD in the first
paragraph of 3.7.3 is needed. If I understood correctly the logic of
using capitalized keywords in the rest of the document, the scarce usage
is restricted to the instances where clear requirements are made on
server to allow interoperable definitions of NACM. This seems to be an
exception.