Hi,
The following starts the discussion on the points
raised in Dbh re-Review of -mib-11, part 1. There is
a basic issue about terminology (points 1.1,1.2,1.3,
1.4) and another 1.9 about the nature and usage of
indices on which the WG definitely needs to provide
input.
Cheers
Glenn
+---------------------------------------------------+
1.1 > > 3) the terminology is not consistent with the
other WG documents.
Not fixed. Still a problem. The WG consensus was
to use sender,
receiver, relay, and collector. Other document were
required to change
to match this terminology. The MIB document uses entity,
which is a term not found in the protocol draft.
I find this change in terminology makes it difficult
to interpret some objects in the mib module.
Response:
We have a single MIB module for all the roles of a syslog
"entity" - sender, receiver, relay and collector.
I do not see any problem with this generic nature of the
MIB, as yet.
Let me know about the specific objects that are difficult
to interpret. We may try the following:
Use the generic "syslog entity" when the discussion
applies to all the roles
Use the role(s) explicitly "syslog sender", "syslog
receiver", etc. when the discussion does not apply to
all the roles.
Add a statement to that effect in the early part of
the text.
Any other suggestions?
1.2 > > 4) "roles a syslog entity maybe in" would be better as "roles of a
> > syslog entity" (although then entity should be changed according to
> > #3.
See #3.
Response:
See #1.
1.3 > > 5) I concur with Bert that the citations in section 2 seem
> > inappropriate.
I suggest rewriting the introduction to use the same terminology as
the protocol draft. See #3.
Response:
See #1.
1.4 > > 6) I find the references to SA-Li, RA-Rj confusing since these are
not
> > used in the diagram.
Fixed, but replaced by "entity" which is a problem. See #3.
Response:
See #1.
1.5 > > 7) "The MIB comprises of four groups" would be better as
> > "The MIB
> > contains four groups"
Fixed. However, "group" is a reserved keyword in SMIv2 referring to
compliance, so it should be replaced by "subtree" where that is its
meaning.
Response.
Done.
1.6 > > 11) in SyslogSeverity, I recommend removing the second sentnece
> > in the
> > description "The syslog protocol uses the values 0 (emergency)
> > to 7 (debug)." since this is already spelled out in the SYNTAX
> > clause,andshows that 99 (other) is also used. Why do we
> > need 99? Are other
> > values valid?
Partially fixed. When is "other" used?
Response.
"other" will be used to count messages that do not have severity in
the range 0-7. The syslog protocol specs (-19.txt) does not disallow
such messages.
1.7 > > 12) SyslogService - can we make this just a service name. The
> > port semantics are really ambiguous. How do distinguish a UDP
> >port# from a TCP port#?
Not fixed.
Response.
The syslogEntityControlTransportDomain specifies the transport e.g.
transportDomainUdpIpv4.
1.8 > > 14) transportAddressType is designed to be used with specific
> > types of
> > transportAddress. The syslogDefaultTransport object should
> > probably be
> > syslogDefaultTransportType. A transportAddressType
> > seems inappropriate
> > for use with syslogDefaultService, which does not necessarily
> > resolve
> > to one of the enumerated options. We should have a
> > syslogDefaultTransport that is a transport address. If we want a
> > Default service, that should probably be a separate object.
Partially fixed.
How will the syslog/TLS transport address be specified in this
object?
Response.
A syslog TLS transport domain will be defined. E.g. something like
SyslogTLSTransportDomain. We will specify that as the
syslogEntityControlTransportDomain.
Thus, we will have something like:
syslogEntityControlTransportDomain : SyslogTLSTransportDomain
syslogEntityControlService: SyslogTLSPort
1.9 > > 20) In the SNMPv2 effort, we found that using integer indices
> > made using the tabels more difficut for human readers. It would
> > be much easier for a human to interpret the statistics here is
> > it is easy to tell what the systlog entity is. So I recommend
> > using an SnmpAdminString as the index. For systems that cannot,
> > for whatever reason, determine a human-readable identifier for
> > the index, theSnmpAdminString can always be "1", "2", etc.
Not fixed.
Response.
The human readable identifier/description is there in
syslogEntityControlDescr. I think that any NMS can easily handle
this and make the table nicely "readable" to the user.
I accept that the primitive snmpget/snmpwalk type applications
which show OIDs will be difficult to "read".
I will not recommend mixing indices and descriptions - that may
lead to constraints on or, inappropriate usage of both indices and
descriptions.
If the working group wants descriptive indices, that is not a big
deal.
1.10> > 21) what is the persistence of the index? If syslog entities
> > happen to
> > start in a different order, will the index# refer to the same
> > entity
> > after a reboot? If the MIB says they must be persistent across
> > reboots, how difficult will that be for the OS that starts the
> > applications? What value will the system keep to match up to the
> > integer indicies to make sure they remain the same?
Partially fixed.
Is it important for interoperability to be able to correlate
messages
from before a system reboot and after a system reboot? If so, what
object can be used to do this correlation since integer index can
change across reboots?
I suspect the ControlDescr object might be able to be used, but the
description for ControlDescr does not specify the persistence of
that object.
All objects in the syslogEntityControlTable should probably persist
across reboots if you want the syslog entity to be configured the
same way across reboots.
You have a problem, however. You are using an integer index that
does
not persist across reboots. How does the SNMP agent correlate the
persistent configuration parameters with the appropriate application
index after a reboot? How does a remote manager read this table and
understand which row of configuration and monitoring info (like
statistics) refers to which application?
Response.
The syslogEntityControlDescr will be used by the application/NMS
to correlate the index and the target syslog application. It is
the user/admin responsibility to use appropriate
syslogEntityControlDescr.
1.11> > 23) syslEntOpsMsgsIgnored - where are the "allowed
> > specifications"
> > defined? We don't want a value that can be interpreted
> > differently by
> > different entities, because then the values canot be compared
> > across
> > systems, or have consistent baselines for comparison across
> > products,
> > etc. Objects shoud be defined to be interoperable and
> > unambiguous.
Partially fixed. This is still ambiguous, and could be interpreted
in different ways by different implemnenters resulting in
non-interoperability. This needs to be unambiguous as to what gets
counted.
This object counts things outside the "allowed specifications" -
again
I ask where are the allowed specfications defined so an implementer
knows what they are?
Response.
The allowed specifications are in the protocol document. There are
several MUST clauses. Some clauses explicitly mention that if the
MUST condition is not met the message MAY be discarded, some don't.
E.g. Sec. 6.1 Message length, Sec. 6.2 HEADER.
1.12> > 25) syslEntOpsLastError talks about "this process". Is this the
> > syslog
> > entity? This needs to be clear and unambiguous, and consistent
> > with
> > the terminology in the other WG documents.
I'm confused. Is an entity an application, such as login, or is the
entity the thing that sends syslog messages, such as a syslog
daemon, that sends messages for multiple applications?
Does the last error refer to the last error seen by the login
process, or by the syslog sender process (e.g. daemon)?
Since entity refers to all the different roles - senders, receivers,
relays, and collectors, does that mean we are keeping "last error"
info at the receiver as well as at the sender, and at the relays as
well?
Response.
Let me try it this way. The MIB is about syslog entities- syslog
senders, syslog receivers, syslog relays etc. We do not need to care
whether the Sender is a syslog daemon or a mail application as long
as it is sending and/or receiving syslog messages.
Having said that, I agree that the description of the lastError is
difficult to interpret.
Will the following help?
"A description of the last error related to sending, receiving
or processing a syslog message that was encountered by this
syslog entity.
"
1.13> > 26) syslEntOpsLastError talks about the last error this process
> > "encountered". The definition of encountered needs to be made
> > unclear
> > and unambiguous.
Not fixed. What does "encountered" mean?
Sent/received/relayed/collected?
While we're at it, what exactly does error mean? How do I know when
I am encountering an error? Can I encounter other things, like
warnings? I see that Error is a type of severity. Is that what we
ar ecounting? Do we also want to count criticals, and alerts, and
emergencies, etc.
Or is that not what you mean by "encounter an error".
Response.
see #12 above.
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
