Subject: Re: [Isms] proposal comparison I-D

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 15 Feb 2005 15:25:50 -0800

Hi,

Well I'm heartened that people seem to think that this WG
still has good prospects of success (smile).

About printers - CLI or embedded Web interfaces are NOT
sufficient.  The printer industry has experienced the
same crushing reduction in hardware profits that the
computer industry has experienced.  There are only two
areas of profit left, to whit, supplies (now under great 
competitive pressure) and fleet management.

Fleet management applications from printer vendors are
all currently proprietary - and the typical customers have
networks with thousands or tens-of-thousands of printers.
That is to say, printers are far more common than either
network servers or network infrastructure (routers and
hubs) in typical enterprise networks.  

I suggest that the SNMP standards community not focus
so exclusively on network infrastructure for their
management requirements.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: David B Harrington [mailto:[email-masked]]
Sent: Tuesday, February 15, 2005 3:00 PM
To: 'McDonald, Ira'; 'Juergen Quittek'; [email-masked]
Subject: RE: [Isms] proposal comparison I-D

Hi,

Regarding pronouncements that SNMP is dead - I've heard it so many
times in the IETF, but so seldom from buying customers, that I don't
put a lot of stock in such pronouncements. Which is not to say that
valid criticisms of SNMP shouldn't be paid attention to; SNMP has been
around for a long time and is used in ways it was not designed for,
and hasn't kept up with related advances in technology.

I think it is important to recognize that management interfaces for
printers are normally for element management, not network, service, or
business process management. Generally one does not need to compare
the status of the paper tray across printers. For monitoring a
specific device status, a CLI or web-based interface is typically
fine. SNMP isn't required for that use-case (although traps could
certainly be useful).

<...snip...> 

I look rather optimistically at what this WG has achieved so far, and
what we will yet achieve. 

David Harrington
[email-masked]

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 24 Feb 2005 09:14:25 -0500

Excellent points, Randy!  More inline.

-----Original Message-----
>> In section 3.5 of the proposal evaluation, a comparison between the
key
>> provisioning for an external authentication source (AAA server) and
the goal
>> of ISMS is made. It should be noted that the provisioning of a single
key
>> per device rather than a key per-user-per-device is of a
significantly
>> different complexity.
>
> During my discussions with non-SNMP people about USM and VACM,
> I've found that many had an important misconception about how key
> provisioning works, despite our best efforts in RFC 3415 appendix A
> and RFC 3414 Appendix A.  One needs to "manually" key exactly ONE
> user, known as "initial".  All other user creation and keying would be
> done in-band with SNMPv3.

I can only wonder what is missing from our documents to allow for such a
crucial misconception.

> If someone is manually setting keys for any users other than
"initial",
> they're not doing things the way the WG intended when the SNMPv3
> documents were developed.

>>                        Also, there are numerous solutions and
solutions in
>> progress to remove the need for this communication key provisioning
for
>> standard external authentication protocols (e.g. Kerberos, RADIUS),
and this
>> should appropriately be solved in the context of the AAA protocol and
not
>> SNMP, IMO.

No protocol can possibly remove the need for initial provisioning. But
once that one protocol itself has been provisioned - through it other
protocols can be "initialized". After that each of those protocols can
in turn perform its own user administration, or leave it to that first
protocol. Amount of work is likely to be the same.

> The point in the evaluation is that AAA provisioning, (currently)
requiring a
> key to be set in every device, needs the same amount of manual work as
> does using  SNMPv3 as it was designed to be used.  (Of course, some
> people seem intent on making more work for themselves.)  You're
absolutely
> right that *solving* that is AAA's problem, not SNMP's.  The only
thing I've
> seen in the SNMP space to address the problem is leap-of-faith
solutions
> like the kick-start in RFC 2786.

Precisely.

The only argument in favor of AAA is that some customers *already* have
AAA deployed, so they may find it attractive *not* to deploy a second
infrastructure for SNMP - but rather tie it to the existing AAA
infrastructure.

Starting from scratch - the amount of work to provision AAA keys or
SNMPv3 keys is absolutely the same. Starting from AAA infrastructure -
no extra keys are necessary, but a piece of software that would interact
with both SNMPv3 and AAA to perform key management for SNMPv3, plus a
standard defining how that piec of software should behave...

Pretty much what we're doing here anyway. :-)