Re: Proposed Update to Netconf Charter

[Wes Hardaker <wjhns1@hardakers.net>]

>>>>> On Tue, 5 Jul 2005 23:52:50 +0200, Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> said:

Juergen> I wanted to make the configuration such that users who have
Juergen> authenticated using a cleartext channel will be treated
Juergen> differently from users who have authenticated over an
Juergen> encrypted channel.

I agree this is actually a nice thing about SNMP.  Users of mine
actually do just this because they have different avenues of security
coming in.  Most system administrators would probably even like to do
something like this for telnet vs ssh, but can't, so they do the only
other acceptable thing which is to turn off telnet instead because
doing anything else would be completely insecure.

Juergen> If we do netconf access control, we should investigate how
Juergen> command line interfaces typically deal with access
Juergen> control. We should not constrain ourself by the VACM design
Juergen> since the number of non-default VACM tables I have seen on
Juergen> production systems is close to zero. If someone has different
Juergen> experiences with deployed VACM configurations, please speak
Juergen> up.

I have described before in front of microphones that I think in an
ideal world we need some sort of pseudo-API in our RFCs that describe
*how* you need to use the data.  IE, setup_new_user(username,
securitylevel, ...) would be described to perform these particular
SETs in SNMP to the mib objects.  This is totally independent of the
protocol.  Netconf needs something as well, IMHO, because if you think
just having the data in XML will let you magically stuff it in with
one command you're missing the very big light on the front of the
train that is about to run you over.  Unfortunately, it's not that
easy, because you need to worry about testing for existence of user
names that already exist, do an replace if they do and you actually
wanted this, or abort if you didn't.  Then ...  Anyway, high level "to
do this frequent task, follow these steps" would be a great boon to
application writers and would potentially convince them to design
decent infrastructure in their agents and managers.

I normally try to shy away from talking about a particular project of
mine, but sometimes it serves as an example so I'm going to break my
personal rule this time.  In Net-SNMP we had issues with the
complexity of the VACM for a long time as well.  Having said that, we
have users that are using probably every aspect of its complexity in
their environments.  The problem wasn't that it isn't useful, it was
that it's hard to understand and more importantly isn't needed for the
95% case.  So, to fix this we added a ton of documentation about how
to set it up and added a few very simple configuration wrappers for
the 95% case that are easy to understand.  The majority of our users
probably have lines similar to this in their snmp agent configuration
files:

  rocommunity public
  rwuser      wes

And they're done.  In 2 lines they've added like 8 rows to the VACM
tables without knowing anything about it.  It's this sort of simple,
common-case API that the RFCs need to offer readers.  With the advent
of the above "wrapping" configuration items and with the documentation
we get very few questions now, and if we do its frequently from people
trying to understand the more complex scenarios because they actually
need it.  (as an aside the above configuration tokens actually have
additional parameters that add a single oid-tree restriction, add
minimum security level (default is authNoPriv, etc)).

Visualizing how the whole ball of wax works is hard.  Unfortunately,
in any system where you have a high degree of variation in how
something needs to work you're not going to get away from that.  The
best you can do is to try and offer *both* a simple case and a hard
case.  The problem with our RFCs is that 99% of the time because we
need the hard cases to exist, that's all we offer rather than offering
both.


(ok, as long as I'm breaking rules...  pet project 2 for the day is
visualizing SNMPv3 VACM configuration from live data pulled from the network:

  http://net-policy.sourceforge.net/screenshots-2004-07-28/viz_snmpv3.png
)
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>