Skip to main content

Network Configuration Protocol (NETCONF) Access Control Model
draft-ietf-netconf-access-control-07

Yes

(Dan Romascanu)
(Jari Arkko)

No Objection

(Adrian Farrel)
(Gonzalo Camarillo)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Wesley Eddy)

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

Dan Romascanu Former IESG member
Yes
Yes () Unknown

                            
David Harrington Former IESG member
(was Discuss) Yes
Yes (2011-12-01) Unknown
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.
Jari Arkko Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Peter Saint-Andre Former IESG member
No Objection
No Objection (2011-11-29) Unknown
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 Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2011-11-30) Unknown
#1) I agree with Stephen & Peter.

#2)

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
  session.

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.
Stephen Farrell Former IESG member
No Objection
No Objection (2011-11-28) Unknown
- 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
ideally.)

- 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,/
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection () Unknown