[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Syslog] Syslog-mib-12



Hi,

[speaking as co-chair]

I think these comments from Tom have not been addressed in mib-12.

Does the WG agree that Figure 1 and discussion of facilities and hosts
and so on should be removed in mib-xx?

Does the WG agree that Diagram 1 from protocol-19 should be duplicated
in mib-xx, as a way to bring the language used in the mib module
closer to the "standard terminology" proposed by this WG?

Does the WG agree that Diagram 1 represents all likely deployment
scenarios (most notably those encountered on dumb-device, *NIX and
Windows environments)?

Would it be adequate to simply **reference** Diagram 1 in [RFCPROT],
and the Terminology of Section 3 of [RFCPROT], and then explain how
the terminology in the mib module relates to the [RFCPROT] terminology
and diagram?

David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net
co-chair, Syslog WG 


> -----Original Message-----
> From: tom.petch [mailto:cfinss@dial.pipex.com] 
> Sent: Friday, December 15, 2006 9:35 AM
> To: David Harrington; 'Rainer Gerhards'
> Cc: syslog@ietf.org
> Subject: Re: [Syslog] Syslog-mib-11
> 
> mmmmmm
> 
> Rainer's explanation shows me why I have not encountered 
> this; it is only
> present in Windows servers and then only, if I read it 
> aright, because Windows
> has not done a satisfactory implementation yet.  The question 
> then is, how much
> do we adapt to this behaviour of Windows?
> 
> I find your remedy insufficient.  Look at the diagram at the 
> start of -mib and
> compare it with the diagram at the start of -protocol.  
> Seeing those two
> diagrams convinced me that the two I-Ds came from different 
> planets and that,
> until that was resolved - and only now, months later, do I 
> begin to see a
> resolution - it was not worth expending much effort on -mib.
> 
> I think this will be the reaction of others and that we MUST 
> include the diagram
> in -mib that appears in all the others and then -mib must 
> explain how the terms
> it chooses relates to those in the diagram and why.  
> Simplying saying this I-D
> is different because we are on planet Microsoft is not 
> sufficient for me.
> 
> I agree that there must also be a brief explanation in the 
> DESCRIPTION clause.
> 
> Another problem I have with -mib is the statement that
> "The syslog entities may be on the same host or on different hosts."
> If on different hosts, what is the protocol used to 
> communicate between the two
> hosts?  If this is syslog, then how is the MIB information 
> communicated from
> syslog sender to the entity with the SNMP agent?   This is not a new
> question:-(.
> 
> 
> Tom Petch
> 
> 
> ----- Original Message -----
> From: "David Harrington" <ietfdbh@comcast.net>
> To: "'Rainer Gerhards'" <rgerhards@hq.adiscon.com>
> Cc: <syslog@ietf.org>
> Sent: Thursday, December 14, 2006 11:23 PM
> Subject: RE: [Syslog] Syslog-mib-11
> 
> 
> > Hi,
> >
> > [speaking as a contributor]
> >
> > Thank you Rainer for such a clear response.
> >
> > I recommend that text similar to Rainer's response be 
> included in the
> > DESCRIPTION clause for the syslogEntityControlTable, to explain
why
> > multiple syslog entities are modeled in the MIB module.
> >
> > I recommend capturing the discussion within the MIB module 
> definition
> > rather than in the document introductory sections, because 
> MIB modules
> > are often distributed already-extracted from the 
> surrounding document,
> > and NMS help screens are often fashioned from the 
> DESCRIPTION clauses.
> > So putting this info in the table description clause will get the
> > explanation to the users. I would not object to **also** having it
> > discussed in the introductory text sections.
> >
> > David Harrington
> > dharrington@huawei.com
> > dbharrington@comcast.net
> > ietfdbh@comcast.net
> >
> > https://www1.ietf.org/mailman/listinfo/syslog
> 
> 



_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog