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

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 protected]] 
Sent: Tuesday, October 14, 2003 1:02 AM
To: Chisholm, Sharon [CAR:0S00:EXCH]
Cc: [email protected]
Subject: Re: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt


>>>>> On Mon, 13 Oct 2003 19:31:24 -0400, "Sharon Chisholm" 
>>>>> <[email protected]> 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