Subject: RE: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 14 Oct 2003 09:08:13 -0400

Hi

Might I suggest then that providing a MIB way of doing the same thing might
just be noise? As for more detailed configuration, why can't this be done in
the protocol? A monitoring MIB would be useful though if you can keep it
nice and simple - i.e. no superfluous configuration.

Sharon

-----Original Message-----
From: Wes Hardaker [mailto:[email-masked]] 
Sent: Tuesday, October 14, 2003 1:02 AM
To: Chisholm, Sharon [CAR:0S00:EXCH]
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt

>>>>> On Mon, 13 Oct 2003 19:31:24 -0400, "Sharon Chisholm" 
>>>>> <[email-masked]> said:

Sharon> I've only skimmed the draft, but I suspect a MIB to do cleanup 
Sharon> may not be the best approach. If things are setup using non-SNMP 
Sharon> means, shouldn't tear down be done that way?

The MIB is more for super-management.  The draft already supports either
side randomly dropping the session, and will support (IE, its not there now)
a notification mechanism to the other side that one side intentionally
dropped a connection.  This will all be "within-SBSM-messages".  Greater
ability may be controlled by the accompanying MIB module, but the details
haven't been worked out.

Thanks for the comments!

Sharon> If I understood things from my quick skim, I think I like the 
Sharon> approach of not using SNMP to set up the session since it avoids 
Sharon> all the bootstrap issues and is easier to sell to people who 
Sharon> don't think they want to use SNMP for configuration.

That was the primary goal; reuse of existing authentication mechanisms.
Things like password databases, radius, ... are all heavily used and there
is no reason they can't be used within SNMP as well.

-- 
Wes Hardaker
Sparta

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 14 Oct 2003 09:01:03 -0700

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: <[email-masked]>
> Cc: "Wes Hardaker" <[email-masked]>
> Sent: Tuesday, October 14, 2003 6:08 AM
> Subject: RE: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt
...
> nice and simple - i.e. no superfluous configuration.
...

I agree that *superluous* configuration should be avoided, but I think that
some very basic configuration / control capabilities are essential, such as
permitting a security administrator to kill a session in progress (getting back
to the issues Gene originally raised much earlier in this thread).

As to the basic question "why can't this be done in the protocol", I think
the answer centers around the question of *who* should have the
rights to do such configuration.  My intuition is that it would normally be
a security administrator, rather than the session user, who would set
things up, kill sessions, and so on.  If this is correct, then building it
into the protocol would not make sense, since the wrong user would
be behind the protocol operations requesting the configuration change.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 15 Oct 2003 15:26:48 -0700

>>>>> On Tue, 14 Oct 2003 09:08:13 -0400, "Sharon Chisholm" <[email-masked]> said:

Sharon> Might I suggest then that providing a MIB way of doing the
Sharon> same thing might just be noise? As for more detailed
Sharon> configuration, why can't this be done in the protocol? A
Sharon> monitoring MIB would be useful though if you can keep it nice
Sharon> and simple - i.e. no superfluous configuration.

Because the complexity of the protocol would get pretty nasty.  We
already *have* a management protocol and it doesn't make much sense
not to use it to self-manage ;-)

-- 
Wes Hardaker
Sparta