[Syslog] Dbh re-Review of -mib-11, part 1

"David Harrington" <ietfdbh@comcast.net> Wed, 06 December 2006 22:54 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5ea-0004Jg-7t; Wed, 06 Dec 2006 17:54:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5eZ-0004Jb-E8 for syslog@ietf.org; Wed, 06 Dec 2006 17:54:15 -0500
Received: from alnrmhc13.comcast.net ([204.127.225.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs5eY-0000EX-Ut for syslog@ietf.org; Wed, 06 Dec 2006 17:54:15 -0500
Received: from harrington73653 (failure[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20061206225414b1300c4fp7e>; Wed, 6 Dec 2006 22:54:14 +0000
From: David Harrington <ietfdbh@comcast.net>
To: syslog@ietf.org
Date: Wed, 06 Dec 2006 17:50:33 -0500
Message-ID: <0d5401c71989$086d1910$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acb2LLQKXZaxt/eyS/2isochxRKHIAjQ4DbQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
In-Reply-To: <057501c6f62d$5b7e8fa0$b07557c0@china.huawei.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb
Cc:
Subject: [Syslog] Dbh re-Review of -mib-11, part 1
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Hi,

This is a check that my comments of 10/22 have been addressed in
mib-11. 

> 1) There are multiple pages that exceed the maximum allowed lines
per
> page. 
Fixed.

> 
> 2) The headers and footers do not appear to be standard. There
should
> an abbreviated title for easch page after the first.
Fixed.

> 
> 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.

> 
> 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.

> 
> 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.

> 
> 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.

> 
> 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.

> 
> 8) Section 3 has a number of lists. You should decide if the list
> should contain sentences, or makes up one complete sentence. If it
is
> one sentence, then each listed clause should end with a comma, and
be
> consistent in style. If each item is a sentence, then the
introductory
> phrase needs to be a sentence. I recommend making each item a
> sentence, so we  can eliminate the "which" conrstructs.
Fixed.

> 
> 9) "asynchronously monitor" s/b "asynchronously report"
Fixed.
> 

> 10) the name of SyslogMIB or syslogMIB should be consistent in the
> text. I recommend using SYSLOG-MIB, which is the correct name for
the
> MIB module.
Fixed.
> 

> 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,
and
> shows that 99 (other) is also used. Why do we need 99? Are other
> values valid?
Partially fixed. When is "other" used?

> 
> 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.

> 
> 13) For consistency with most other MIB modules being developed, I
> suggest defining a top-level breakdown of syslogNotifications (0),
> syslogObjects (1), and syslogConformance (2). Then put syslogSystem
> and syslogDevice under syslogObjects. See RFC4181 appendix D. 
Fixed.

> 
> 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?

> 
> 15) some objects are named xxxSeverity, but the description uses
> priority. We need to be consistent with the other documents about
what
> this is called.
Fixed.

> 
> 16) the syslogDefaultMaxMessageSize description really needs work -
> 480 is the minimum maximum size, not the recommended maximum size,
so
> it should not be the default. The maximum message size also may
depend
> on the transport protocol and the target system, so I'm not sure a
> default is a useful object. Who is the user of this default? The
local
> system? If so, then it is an implementation detail and does not need
> to exposed in a mIB object. If it is for use by the remote system,
> then it shouldn't be a default value, but the actual value supported
> by the implementation.
Fixed (removed).

> 
> 17) syslEntOpsTable uses abbreviated elements in the name. I don't
see
> why they need to be abbreviated, or what the name actually means.
The
> description does not mention "ops".
Fixed.

> 
> 18) object prefixes should be consistent for the whole module. The
> DefaultXXX uses syslog as the prefix, but here we use sysl. Why? See
> RFC4181 appendix C for naming guidelines.
Fixed.
> 
> 19) syslEntCtlTable contains static info; does that imply that
> syslEntOpsTable contains dynamci info? Or is syslEntOpsTable about
the
> operational environment, and syslEntCtlTable about control info? The
> descritions should kae the purpose of the table unambiguous.
Fixed.

> 
> 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, the
> SnmpAdminString can always be "1", "2", etc.
Not fixed.

> 
> 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? 

> 
> 22) syslEntOpsMsgsDropped counts messages that could not be relayed.
> What about messages that cannot be queued for transmission for an
> original sender?
Fixed.

> 
> 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?

> 
> 24) syslEntOpsLastMsgDeliveredTime - the system does not know when
the
> message was delivered, only when it was transmitted or received. 
Fixed.

> 
> 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? 

> 
> 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". 

> 
> 27) what is the persistence of the syslEntOpsReference across
reboots
> of the OS? Across reboots of the SNMP system? If it is not
persistent,
> but the table is, what should the SNMP agent do - delete the
> references? Change the references to match the new SWRunIndex? 

> 
> 
> David Harrington
> dharrington@huawei.com 
> dbharrington@comcast.net
> ietfdbh@comcast.net
> 
> 
> 
> _______________________________________________
> 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