Hi,
Dbh> If the intention is to leave out the notification, I would like
to
know why this is desirable.
Glenn> The reason is to retain the possibility of a compliant
implementation that does not support notifications.
This still does not explain why this is desirable. Who wants this
feature?
It may be desirable to implementers who have not chosen to implement
notifications, so they can market their products as being
IETF-compliant, but we are NOT here to help marketing departments
claim compliance for their implementations by lowering the standards
to match their implementations.
The majority of snmp agents are based on either the commerical toolkit
from SNMP research (or other commercial snmp toolkits), or the
NET-SNMP (nee CMU-SNMP) toolkit. These already support notifications,
and the objects carried in the notification are required for
compliance, so I think it should be pretty simple to support the one
notification. So I don't see a strong benefit for an implementer to
not support the notification.
I especially do not see the benefit of making this optional in the
standard. Keep in mind that our job here is NOT to define a
specification that allows as many incompatible implementations to
claim compliance as possible. Our job here is to set some standards -
a minimum level of support for a common set of features to provide
multi-vendor and vendor-neutral interoperability. Having some
implementations support notfications and others not support
notifications negatively impacts interoperability.
Non-interoperability is NOT a desirable feature.
So I STRONGLY question the need for a compliance level to allow the
lack of support for the notification.
-- Let me approach the question from a different angle.
Does the WG believe that this notification is so useless that most
implementers will not implement it? Is this a nice-to-have but not
really necessary feature in the standard? If so, then we should simply
remove it from the standard.
My personal opinion is that this would be a useful feature, and should
not be optional. It should be part of the mandatory compliance, and an
implementation without it should NOT be allowed to claim compliance to
the standard.
dbh
> -----Original Message-----
> From: Glenn M. Keeni [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 13, 2006 6:45 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 1,2,3
>
> Hi,
> I have pruned the list of comments and renumbered them.
> The following starts the discussion on the points raised
> in Dbh re-Review of -mib-11, part 2.
>
> Cheers
>
> Glenn
>
> +---------------------------------------------------------------+
> 2.1 > > 5) is there a mismatch between transportaddresstype and
> > > syslEntCtlService? Is there a transportAddressType for this
> > > type of
> > > "address"?
> Not fixed.
> I think you are using an enumeration to identify the
> format of the
> value in the next object, and then using a format in the
> next object
> that does not match any of the enumerated choices. This
> is obviously
> wrong.
>
> Response:
> That is not what we are doing.
>
> syslogEntityControlTransportDomain maps onto a transport
domain.
> e.g. transportDomainUdpIpv4
> syslogEntityControlService maps onto a port number
> e.g. 512
>
> Let me know if I got this wrong.
>
>
> 2.2 > > 6) syslEntCtlConfFileName - using lots of abbreviations in
> > > the name
> > > makes it hard for people to remember how the words were
> > > abbreviated.
> > > It would be better to use something like
> syslogEntCtlFilename.
> > > Why do
> > > we need Ent in the name? we never deal with anything
> other than
> > > entities, do we? syslogControlFile would be much easier to
> > > remember
> > > than syslEntCtlConfFileName.
> Fixed (mostly).
>
> Response:
> What is the remaining problem?
>
> 2.3 > > 9) syslEntCtlStorageType - is this definition exactly the
> > > same as the
> > > StorageType T-C?
> I am not sure this is the same semantics as StorageType T-C.
> Your text is somewhat unclear when it says "backed up by
> non-volatile (permanent)"
>
> Response:
> Will the following help:
> syslogEntityControlStorageType OBJECT-TYPE
> SYNTAX StorageType
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "This object defines whether the parameters defined
in
> this row are kept in volatile storage and lost upon
> reboot or are backed up by non-volatile or permanent
> storage.
> Conceptual rows having the value 'permanent' need
not
> allow write-access to any columnar objects in the
row.
> "
>
> That mimics the DESCRIPTION used in DISMAN-MIB e.g.
> smLaunchStorageType
>
>
> 2.4 > > 11) syslEntStarted and syslEntStopped - spell out MO. I
don't
> > > understand the second sentence; how does the manager
> know what
> > > syslEntOpsIndex is used?
> Partially fixed. I still do not understand the second
> sentence. Can
> you reword this sentence?
>
> Response:
> When a trap is received, the NMS/Operator needs to
> figure out which
> syslog "entity" the trap is about. This is done by using the
> syslogEntityOperationsIndex instance identifier of the objects
in
> the notification.
>
> Will the following help?
>
> "The syslog entity corresponding to the notification will be
> identified by the syslogEntityOperationsIndex
> instance identifier
> of the objects in the notification."
>
> 2.5 > > 13) why are notifications not mandatory for compliance?
> syslogFullCompliance2 says this means support for writable
> objects and
> notifications, but th enotification group has been left out
> of the manadatory-groups.
>
> If the intention is to leave out the notification, I
> would like to
> know why this is desirable.
>
> Response:
> The intention is to leave out the notification.
>
> syslogFullCompliance2 MODULE-COMPLIANCE
> STATUS current
> DESCRIPTION
> "The compliance statement for SNMP entities which
> implement the SYSLOG-MIB with support for writable
> objects. Such an implementation can
> be both monitored and configured via SNMP.
> "
> MODULE -- this module
> MANDATORY-GROUPS {
> syslogDefaultGroup,
> syslogEntityOperationsGroup,
> syslogEntityControlGroup
> }
> ::= { syslogCompliances 2 }
>
> The reason is to retain the possibility of a compliant
> implementation that does not support notifications.
>
> 2.6 > > 14) The MIB module exposes some info from syslog, such as
> > > last error.
> > > The security considerations talk about securing snmp, but
> > > that does
> > > not make sense if you do not also secure the syslog
> transport.
> > > The
> > > security considerations should recommend securing syslog to
> > > match the
> > > snmp security.
> Not fixed.
>
> Response:
> To me that appeared to be out of scope. That seems to be a
matter
> for the "security considerations" for syslog transport. No?
>
> Will something like the following suffice:
>
> "Under some circumstances securing SNMP will not make sense
if
> the syslog transport is not secured. It is
> recommended that the
> syslog transport be secured to match the security
> level of SNMP."
>
> 2.7 > > 17) I suspect you are not usinng xml2rfc. If not, you need
to
> > > make
> > > sure all the boilerplates are up-to-date. Please check the
> > > funding
> > > statement and the intellectual property clauses.
> Partially fixed. Needs updated boilerplates.
>
> Response:
> Updated the boilerplate for the Copyright notice.
> http://tools.ietf.org/tools/idnits/
> shows zero errors now.
>
>
>
>
>
> Glenn M. Keeni wrote:
> > Dave,
> > Thanks for the detailed review. I count a total of
> > 13 + 7 + 4 = 24 issues raised in the three mails. Let
> > me go through these and try to figure out how to address
> > the issues, hopefully by 18/12/2006.
> >
> > Cheers
> >
> > Glenn
> >
> >
> > _______________________________________________
> > Syslog mailing list
> > Syslog@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/syslog
>
>
>
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
