[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
- [Syslog] Dbh Review of -mib-09, part 1 David Harrington
- [Syslog] Dbh re-Review of -mib-11, part 1 David Harrington
- Re: [Syslog] Dbh re-Review of -mib-11, part 1,2,3 Glenn M. Keeni
- Re: [Syslog] Dbh re-Review of -mib-11, part 1,2,3 Glenn M. Keeni
- [Syslog] Notification compliance David Harrington
- Re: [Syslog] Dbh re-Review of -mib-11, part 1 Glenn M. Keeni
- RE: [Syslog] Dbh re-Review of -mib-11, part 1 Rainer Gerhards
- [Syslog] severity David Harrington
- RE: [Syslog] severity Rainer Gerhards
- Re: [Syslog] severity tom.petch
- [Syslog] Mib terminology and MIB design David Harrington
- [Syslog] transportDomain and transportAddress David Harrington
- [Syslog] SyslogService David Harrington
- [Syslog] allowed David Harrington
- [Syslog] syslEntCtlConfFileName David Harrington
- RE: [Syslog] Dbh re-Review of -mib-11, part 1,2,3 David Harrington
- RE: [Syslog] severity Rainer Gerhards
- RE: [Syslog] severity Chris Lonvick
- Re: [Syslog] Mib terminology and MIB design tom.petch
- RE: [Syslog] Mib terminology and MIB design David Harrington
- syslog architecture Re: [Syslog] Mib terminology … tom.petch