Network Configuration Protocol (NETCONF) Access Control Model
RFC 6536

Note: This ballot was opened for revision 07 and is now closed.

(Jari Arkko) Yes

(David Harrington) (was Discuss) Yes

Comment (2011-12-01)
No email
send info
1) in section 3.5, the one sentence refers to section 3.5. I don't think the sentence adds anything, even if you meant to point to the YANG module in 3.5.2.

(Dan Romascanu) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2011-11-28 for -)
No email
send info
- I'd still be happier if there were more text advising developers
to be careful mapping from an authenticated identity to a NACM user
name and associated groups, and in particular calling out a pitfall
or two in doing that (e.g. i18n in names, null characters in
authenticated identity). That is there by reference (to RFC 6241 I
guess) but it'd be better to be explicit I think. (In section 3.3.1

- Its still not quite clear to me how the "transport layer" can
provide group memberships properly. RFC 6421 doesn't say and 2.5
just says that something "such as a RADIUS server" could be used.  I
think you could add a security consideration saying that unless you
have the same level of security in how you get the username and
group membership information, then you might be in trouble. E.g. if
SSH provides the username with fairly good security, but then RADIUS
is used for group memberships with less good security, then you may
have a problem.

- typo: 3.7.1 s/contents enabled,/contents is enabled,/

(Russ Housley) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-11-29 for -)
No email
send info
I concur with Stephen Farrell's comments about the incompleteness and vagueness of the text about derivation and handling of user names and group names.

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2011-11-30 for -)
No email
send info
#1) I agree with Stephen & Peter.


s2.6: It might be nice to clarify this somewhat:

 It ought to be possible to disable part or all of the access control
 model without deleting any access control rules.

s3.1.1: and here:

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

I agree it ought to be possible but it ought to be possible only by appropriately authorized users (i.e., the admin).

#3) s3.1.2: Contains the following:

  It is expected that the mandatory transport
  mapping NETCONF Over SSH [RFC6242] is also supported by the server,
  and that the server has access to the user name associated with each

Why isn't this a MUST/SHOULD kind of sentence:

  Servers MUST support the NETCONF Over SSH [RFC6242] It is expected that
  the mandatory transport mapping, and the server MUST have access to the
  user name associated with each session.