syslog@conference.ietf.jabber.com - 2003/03/18
[09:09] %% logger has arrived.
[14:03] %% mark.ellison has arrived.
[15:09] %% wcw has arrived.
[15:28] %% mrose has arrived.
[15:30] * mrose has changed the subject to: ietf56 / hilton / continental 8-9
[15:34] %% smb has arrived.
[15:37] <mrose> Chris: Agenda
Agenda Bashing - no changes
Review of Charter and Status Update
Review of Syslog MIB
Wrap Up
Chris: Review of Charter
- Recall that our focus is about reliable delivery and authentication
- RFC 3164: How syslog works
- RFC 3195: Reliable Delivery
- draft-ietf-syslog-sign-09: looking solid, still lacking "Security"
and "IANA" considerations
- draft-ietf-syslog-mib-02: to be discussed today
[15:37] %% leg has arrived.
[15:38] <mrose> glenn masfield keeni now at mic
[15:42] <mrose> Glenn: draft-ietf-syslog-mib
- Questions to ask:
1. Are the right knobs there?
2. Are the knobs adequately defined?
- Purpose of the MIB
- monitoring syslog operation (stats on messages in/out)
- system-wide parameters: read-write
- process run-time parameters: read-write
- process rules for message selection and actions: read-write
[15:52] <mrose>
- MIB Design mimics this architecture
- system group: models generic information for the service
- parameters group: models processes that implement the daemon
- control group: models the syslog.conf file
[15:58] <mrose> question to the jabber room: i can't find any mention of a mib in the wg charter? did i miss it?
[15:59] <leg> i agree. i see no discussion of a syslog mib.
[16:00] <mrose> Glenn:
- Security Considerations
- insecure access can allow mis-configuration, start/stop it, etc.
(e.g., a bad idea given that syslog logs things like intruder
detection...)
[16:01] <leg> a bunch of this also seems pretty specific to bsd syslogd.
[16:01] %% carlalf has arrived.
[16:01] <mrose> certainly the modelling is focused on bsd syslog
[16:02] <leg> it would be nice to see someone show applicability to the windows log implementation.
[16:02] <mrose> leg - are you physically in the room? (if not, i'll raise this; if so, it's up to you)
[16:03] <leg> i'm in the room but i'm just reading the draft now
[16:03] <mrose> ok.
[16:04] <mrose> glenn: - Security Considerations
- insecure access can allow mis-configuration, start/stop it, etc.
(e.g., a bad idea given that syslog logs things like intruder
detection...)
- mis-configuring tables may result in loss/flood of messages,
console spamming, attacking collectors, remove shell
invocation, etc.
- even R/O access is sensitive, e.g., reading counters.
Mic: Security considerations can be addressed by access control in SNMPv3
David: Even with v3, only certain personnel should have access
[16:06] <mrose> mrose: when you say "SET requirements" are you referring to a "requirements" document or generic SNMP consistency
[16:06] <mrose> glenn: the latter
[16:09] <leg> "we're standardizing the bsd syslogd because there's more light on this corner
[16:10] <mrose>
Mike: There may be a lot of duplication with the Host Resources MIB?
Also, what about SNMP notifications?
Glenn: I've tried to avoid duplicating HR MIB functionality in the
SYSLOG MIB module. I need to document this more.
[16:12] <leg> mrose: 90% of the document is the configuration, where perhaps the real benefit is the statistics
[16:16] <mrose> Mic: Often times, simply having the MIB modelling is useful
independent of actual SNMP implementation (e.g., encouraging
syslog implementors to have the same feature set, independent
of the management).
Glenn: Even having just R/O access to the configuration information is
good. The design still remains consistent, regardless.
Mic: Many of the objects can probably be implemented without an
intrusive approach. We should take note of this in the
conformance statements.
[16:18] %% carlalf has left.
[16:19] <mrose>
Bert: Many operators aren't comfortable doing configuration via
SNMP, and there's interest in doing configuration other ways
(cf., netconf). So, there's a risk that even if you define the
objects, they won't get implemented for setting....
[16:20] <mrose>
Mic: Well, it may be used outside the operator community.
[16:20] <mrose>
David: I'm familiar with SNMP-manageable syslog stuff.
[16:23] <mrose>
Chris: How many people think we should be doing configurable stuff?
many hands
How many people think we should be doing monitoring stuff?
one hand
Glenn: is there an impact on the MIB module if we just make
everything R/O?
Bert: well, you can remove RowStatus objects, etc.,
[16:25] <mrose> , so it would make
things simpler. but, we'll still review the mib in case
someone chooses to implement objects read-write.
Steve: i look for what needs to be protected for both a read-only
for privacy, and read-write for other threats.
[16:27] <mrose>
Mic: i haven't had any customers ask for syslog configuration, they
want to use cli... so, i'd rather see a simpler mib, that's
faster to implement.
Mic: it's important that standard protocols have standard knobs
[16:28] <mrose>
Steve: netconf uses 3195 for notifications, and we're interested in
finding out what interest there is in opening up 3195 for our
needs. is there interest in this wg?
[16:29] <mrose> some hands go up, none opposed
[16:29] %% smb has left.
[16:31] <mrose>
Chris: Wrapup
Internationalization? Characters are currently us-ascii
syslog-sign needs review
- using rfc 3164 (timestamp, hostname, etc.)
- need to update rfc3195 to reflect this
continue work on syslog-mib
[16:34] %% mrose has left.
[16:43] %% leg has left.
[16:54] %% wcw has left.
[17:02] %% leg has arrived.
[17:02] %% leg has left.
[17:38] %% mark.ellison has left.
[19:19] %% leg has arrived.
[19:20] %% leg has left.