Subject: Re: [Netconf] NETCONF replace operation

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sat, 20 Feb 2010 00:00:29 +0100

I have learned from VACM two things:

- We should not over-engineer. We did that with VACM. Nodbody uses/wants it,
  It was mainly a theorethical exercise.
- Even though VACM can be configerd in a simple way (like just read and write acces),
  it is not being used in a simple way... mostly (I think) because we overengineered it and
  so it looks/feels compliated to do even the simple thing.

my 2 cents,
Bert
  ----- Original Message ----- 
  From: Andy Bierman 
  To: Phil Shafer 
  Cc: NETCONF 
  Sent: Friday, February 19, 2010 8:37 PM
  Subject: Re: [Netconf] NETCONF replace operation

  Phil Shafer wrote:
  > Andy Bierman writes:
  >> We should learn from VACM and move on.
  > 
  > IMHO we should learn this isn't a problem we will solve in the next
  > little while and our efforts will be better spent on other issues
  > where we can bear fruit that people will need and use.
  > 

  If NETCONF is going to be a real replacement/supplement to CLI
  then it needs at least some of the ACM features used in CLI.
  Some operators use Radius and TACACS+ for CLI access control.
  Some just use 2 types of passwords -- root user and everybody else.

  IMO, we should support these CLI access control modes in NETCONF standard.

  > Thanks,
  >  Phil

  Andy
  _______________________________________________
  Netconf mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/netconf

------------------------------------------------------------------------------

  Geen virus gevonden in het binnenkomende-bericht.
  Gecontroleerd door AVG - www.avg.com 
  Versie: 9.0.733 / Virusdatabase: 271.1.1/2697 - datum van uitgifte: 02/19/10 08:34:00

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 19 Feb 2010 16:42:22 -0800

Hi -

I think the "overengineered" aspects of VACM really have nothing at all
to do with formulating access control policy, but were instead thought
(at least by their proponents) to be ways to make things "easier" or
"more efficient" for particular uses cases.  But they just get in the
way of understanding the normal cases.  Two specific examples:
  - "prefix matching" for contexts
  - the vacmViewTreeFamilyMask

Both of these can dramatically reduce the number of entries needed
for complex policies, and the size of policies was a big concern when
VACM was developed.  The flip side is that these two features both
make the MIB harder to understand, and require substantial intelligence
on the part of the security administrator application to put to optimal
use.  Configuring these by hand is madness, but that appears to be
what at least some folks still try to do.

The lesson, I think, is that NETCONF should be explicit in its expectations
regarding how access control policy configurations will be created and
administered.

Randy

----- Original Message ----- 
From: "Bert Wijnen (IETF)" <[email-masked]>
To: "Phil Shafer" <[email-masked]>; "Andy Bierman" <[email-masked]>
Cc: "NETCONF" <[email-masked]>
Sent: Friday, February 19, 2010 3:00 PM
Subject: Re: [Netconf] NETCONF replace operation

my 2 cents,
Bert
  ----- Original Message ----- 
  From: Andy Bierman 
  To: Phil Shafer 
  Cc: NETCONF 
  Sent: Friday, February 19, 2010 8:37 PM
  Subject: Re: [Netconf] NETCONF replace operation

  Andy

--------------------------------------------------------------------------------

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 21 Feb 2010 10:58:11 +0100

I agree with Randy and Bert. I would add that the principal problem with
VACM was that the document or documents that describe it did not make a
good enough job in explaining how VACM is to be used in the simpler and
most common use cases, and what the complexity added for the special
cases brings and why it is special. I hope that we can learn and avoid
such mistakes with NETCONF access control. 

Dan
(speaking as contributor)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Saturday, February 20, 2010 2:42 AM
> To: NETCONF
> I think the "overengineered" aspects of VACM really have 
> nothing at all to do with formulating access control policy, 
> but were instead thought (at least by their proponents) to be 
> ways to make things "easier" or "more efficient" for 
> particular uses cases.  But they just get in the way of 
> understanding the normal cases.  Two specific examples:
> Both of these can dramatically reduce the number of entries 
> needed for complex policies, and the size of policies was a 
> big concern when VACM was developed.  The flip side is that 
> these two features both make the MIB harder to understand, 
> and require substantial intelligence on the part of the 
> security administrator application to put to optimal use.  
> Configuring these by hand is madness, but that appears to be 
> The lesson, I think, is that NETCONF should be explicit in 
> its expectations regarding how access control policy 
> configurations will be created and administered.
> 
> Randy
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 22 Feb 2010 07:19:39 -0800

>>>>> On Sat, 20 Feb 2010 00:00:29 +0100, "Bert Wijnen (IETF)" <[email-masked]> said:

BW> - We should not over-engineer. We did that with VACM. Nodbody uses/wants it,
BW> It was mainly a theorethical exercise.

Well, I'm not about to say that I've been happy with how the VACM is
defined, needs-to-be-implemented or needs-to-be-used.  I actually
started designing a different ACM years ago that I thought would better
meet the needs of what I found people wanted to do.

However, I will say that the comments surrounding "it has been deployed
or isn't being used" aren't anywhere near correct.  Based on the user
population I deal with, it's being used very very heavily.  And many do
use exclusion/inclusion trees to get what they want.  That being said,
they're often very confused when they start and that's definitely a problem.
-- 
Wes Hardaker
Cobham Analytic Solutions