Subject: [Syslog] RE: Request for Reviewers - draft-ietf-syslog-device-mib-09.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 10 Oct 2006 11:23:32 +0200

David Harrington (co-chair of the Syslog WG) specifically asked me 
for a review of documents in WG Last Call.

I am not subscribed to the SYSLOG WG mailing list, so pls copy
me explicitly on any reactions that you want me to see.

Bert

----- draft-ietf-syslog-device-mib-09.txt

First some SMICng error messages resulting from syntax checking:

  C:\bwijnen\smicng\work>smicng syslog.inc
  W: f(syslog.mi2), (47,17) REVISION value "200609R04000Z" is not
     a valid extended UTC time
  E: f(syslog.mi2), (97,15) Name of "auth" duplicates an existing one
  E: f(syslog.mi2), (102,15) Name of "cron" duplicates an existing one
  E: f(syslog.mi2), (54,20) Sub-Id for item "syslogMIB" must be
    "number" or "name(number)" format
  W: f(syslog.mi2), (245,4) Sequence "SyslDevOpsEntry" and Row
    "syslEntOpsEntry" should have related names
  W: f(syslog.mi2), (418,4) Sequence "SyslDevCtlEntry" and Row
    "syslEntCtlEntry" should have related names
  E: f(syslog.mi2), (418,4) Row "syslEntCtlEntry" may not have
     columns with MAX-ACCESS of read-write if any column is read-create

  *** 4 errors and 3 warnings in parsing

I see on page 3, sect 2:

   status or the occurence of events. These messages are handled by what
   has come to be known as the syslog application[RFCPROT] or device
   [RFC3164]. In this document we refer to a syslog application or

Mmm RFCPROT and RFC3164 are both a protocol spec, not an "application"
or a "devie", are they?

I see on page 5:

   The SyslogMIB module uses textual conventions defined in INET-
   ADDRESS-MIB[RFC4001], TRANSPORT-ADDRESS-MIB[RFC4001] and SNMP-
   FRAMEWORK-MIB[RFC3411].

I believe that the TRANSPORT-ADDRESS-MIB is described in RFC3419
and not in RFC4001.

Page 6:

      LAST-UPDATED "200511250000Z"  -- 25th November, 2005

While in the DESCRIPTION clause you have a copyright of 2006!!??

Further it is in conflict with the latest revision clause
       REVISION "200609R04000Z"  --  9th September, 2006
AND... that one has an R in there that is not valid either.

Page 6:
           Copyright (C) The Internet Society (2006). The initial
           version of this MIB module was published in RFC yyyy;
           for full legal notices see the RFC itself.  Supplementary
           information may be available at:
           http://www.ietf.org/copyrights/ianamib.html.
          "
     -- RFC Ed.: replace XXXX with the actual RFC number & remove this
     -- note

I think the "RFC yyyy" should read "RFC XXXX" in order to bein sync 
with the RFCEd. note.
Further, I do NOT think that the copyrights for iana maintained MIB 
modules is applicable here. I think you picked up the incorrect
template for MIB copyright. So probably you need to use:

        Copyright (C) The Internet Society (2006). This version of this
        MIB module is part of RFC XXXX; see the RFC itself for full
        legal notices."

The read-write objects under syslogSystem MUST add text to the 
DESCRIPTION clauses that state the expected persistency behaviour.

For
   syslogDefaultTransport OBJECT-TYPE
       SYNTAX      TransportAddressType
I wonder how you represent syslog-transport over tls.
I guess you could use "unknown" but that seems not very satisfactory.
You could use one of the tcp transports I guess, but you would loose
the info about the fact that it is over tls, no?

Same question of course for syslEntCtlTransport object.

>From the DESCRIPTION clause of 
   syslEntOpsTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslDevOpsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table containing information about the syslog entities
            serviced by an SNMP agent.

I cannot see why the "Ops" string is in the name???
It is OK if that is what the WG wants, but personally, I would
rather name it 
   syslogEntityTable
which seems a much more meaningfull name.

For 
   syslEntCtlTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslDevCtlEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table containing static information about
           the syslog entity.
           "
       ::= { syslogDevice 2 }

I think that in the description clause I would state that this table
is to have control over the configuration of syslog Entities.
I think I would name it

   syslogEntityCtlTable or syslogEntityControlTable

I further note that I find it a naming inconsistency to use "sysl"
as the prefix here instead of "syslog". This happens in the above
2 tables only. The rest of the MIB module nicely has syslog as 
prefix.

I see:

   syslEntOpsTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslDevOpsEntry
       MAX-ACCESS  not-accessible

Normal practice is that the SEQUENCE OF would in tis case be:
   syslEntOpsTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslEntOpsEntry
                                   ^^^
Same story for: 
   syslEntCtlTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslDevCtlEntry

For
   syslEntCtlEntry OBJECT-TYPE
       SYNTAX      SyslDevCtlEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The parameters pertaining to a syslog process."
       INDEX  { syslEntOpsIndex }
       ::= { syslEntCtlTable 1 }

I wonder if this is a sparse augmentation (it seems so because
otherwise it might have been an AUGMENTs).
I wonder though if this is intentional or accidental.
I personally think I would have made this the base table
and maybe used an AUGMENTS for the read-only (syslEntOpsTable).

The Counter32 object in the syslEntOpsTable MUST specify if/when
a discontinuity can occur and which timer indicates such discontinuity.
Probably the only discontinuity is when the SNMP agent restarts,
but I am not sure. If so it would be sysUptime that serves as the
discontinuity timer.

For:
   syslEntOpsLastMsgDeliveredTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The local time when the last message was delivered
            by the syslog process.
           "

I would think it is better to say "was relayed or sent"?
Because you do not actually know (in many cases) if the
message indeed does get delivered to the other end, do you?

For:
   syslEntOpsLastError OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "A description of the last error that was encountered
            by this process.
           "

I am not sure I understand what "this process" is?
Is it the agent (I guess not)? Is it the syslog entity?
Or is it something else?

For:
   syslEntOpsReference OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "If the Host resource MIB is serviced on the host then
            this entry will have the value of the hrSWRunIndex
            of the corresponding entry in the hrSWRunTable.
            Otherwise this object will be inaccessible,
           "

First, I would change "is serviced" into "is instantiated" or "is supportted".
Further I see that hrSWRunIndex is defined as:
   hrSWOSIndex OBJECT-TYPE
       SYNTAX     Integer32 (1..2147483647)
So I would expect the SYNTAX for syslEntOpsReference to also be
       SYNTAX     Integer32 (1..2147483647)
But... The last sentence of the DESCRIPTION clause says:
            Otherwise this object will be inaccessible,
(should have a period at the end instead of a comma by theway)
and that is also something that is VERY UNCLEAR.
Maybe a "nosuchInstance" exception would be better.
Maybe the best is to define the object as:
   syslEntOpsReference OBJECT-TYPE
       SYNTAX     Integer32 (0..2147483647)
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "If the Host resource MIB is instantiated on the host then
            this entry will have the value of the hrSWRunIndex
            of the corresponding entry in the hrSWRunTable.
            The special value of zero indicates that the Host resource
            MIB is not instantiated.
           "

I see:
   syslEntCtlTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslDevCtlEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table containing static information about
           the syslog entity.
           "

First I am not sure it is really static, because it allows to change
the values. But in any event, I would describe that this table is
intended to configure syslogEntities.

For syslEntCtlProcDescr I wonder if this value is/can be used 
anywhere else. If yes, pls say something about it.

For:
  syslEntCtlBindAddr OBJECT-TYPE
      SYNTAX      InetAddress
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "The specific IP address or hostname the syslog process
           will bind to. If a hostname is specified, the IPv4 or
           IPv6 address corresponding to the hostname will be used.
          "
      ::= { syslEntCtlEntry 3 }

I am not sure what "if a hostname is specified..." means.
If it is a FQDN, then the InetAddressType would be 'dns'
And yoiu MUST specify when that name is resolved into an IP address.
But probably you mean that if it is just some local hostname, that
in that case an IPv4 or IPv6 address shoudl be specified. That is not
100% clear to me though. So pls clarify.

You MUST also add some text that states that the format of this address
is controlled by the value of the corresponding syslEntCtlBindAddrType
object.

For:
   syslEntCtlConfFileName OBJECT-TYPE
       SYNTAX       SnmpAdminString
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
         "The fullpath name of the configuration file where the
          syslog entity's message selection and corresponding
          action rules will be read from.
          Data is loaded from this file into the
          syslogCtlSelectionTable and the syslogCtlLogActionTable.
          If the objects loaded from the file specified by this
          object have an access level of read-create, this file MUST
          be writable so that modifications to the corresponding
          objects, if any, will be effected in this file.
          If the system does not support the specification of a
          configuration file, this field will not be accessible.
         "
       DEFVAL { "/etc/syslog.conf" }
       ::= { syslEntCtlEntry 7 }

I wonder where is/are the syslogCtlSelectionTable and the
syslogCtlLogActionTable tables defined? I cannot find them
so I am not sure what this means.
I think that instead of
          If the system does not support the specification of a
          configuration file, this field will not be accessible.
I would make this object a zero-length string. Much cleaner
and much easier on both agent and NMS. 

For:
   syslEntCtlStatus OBJECT-TYPE
       SYNTAX       INTEGER  {
                         unknown  (1),
                         started  (2),
                         suspended(3),
                         stopped  (4)
                       }
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION
           "The status of the process.
           "
       DEFVAL      { unknown }

What is "the process" ??

I think I would add a DEFVAL for syslEntCtlStorageType
Any value that the WG feels appropriate is fine.

For syslEntCtlRowStatus
- s/iff/if/
- I am surprised to see that one needs to go to notInService
  state in order to change any column in the row. There are 
  various that could very well be changed (maybe even all)
  while in active state. And such is much easier on both
  agent and manager.

The two NOTIFICATIONs could easily be combined into a
   syslogEntitySTatusChanged NOTIFICATION-TYPE
Just a minor optimization I guess

I would think/hope that there is some relation between theobjects in the
syslogSystemGroup and those in the syslogDevCtlGroup.
For example, if no maxMessage size is specified in syslEntCtlMaxMessageSize,
then the maxmessagesize from syslogDefaultMaxMessageSize is used?
But the DESCRIPTION clauses of the OBJCTS say nothing about this,
so I am not sure how to determine which value to use when?

I think I would change
   syslogCompliance MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
           "The compliance statement for SNMP entities
            which implement the SYSLOG-MIB.
           "
Into something like:
   syslogFullCompliance MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
           "The compliance statement for SNMP entities which implement
            the SYSLOG-MIB with support for writable objects. Such an
            implentation can be both monitored and configured via SNMP.
           "

I am not sure I completely understand the intent of
syslogNotificationCompliance. Is it the idea that an implementation
can claim compliance to just send notifications and nothing else?
If so, you may want to make that clear.

Even then, I think I would include the syslogNotificationGroup in
both the other two MODULE-COMPLIANCE statements, so that if you
support it all, you only have to claim compliance with a single
MODULE-COMPLIANCE statement.

On page 27 I see:

   Even if the network itself is secure (for example by using IPSec),

I know that at least one of the SECURITY ADs will want you to
s/IPSec/IPsec/.
The latest MIB security template has the fix already in it.

I see quite a few places where you use "MIB" while I think what you
mean is the/a "MIB Module". I know this is a nit. Nevertheless,
it seems you need to do a revision to at least fix the syntax errors,
so might as well addres this.

Bert

----------- original review message:
> >
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt
> > > 
> > > Transmission of syslog messages over UDP
> > > 
> >
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07
> > > .txt
> > > 
> > > TLS Transport Mapping for SYSLOG
> > > 
> >
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03
> > > .txt
> > > 
> > > Syslog Management Information Base
> > > 
> >
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx
> > > t
> > > 
> > > Signed syslog Messages
> > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt
> > > (We expect this document to be updated this week.)
> > > 
> > > David Harrington
> > > [email-masked] 
> > > [email-masked]
> > > [email-masked]
> > > 
> > 
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Thu, 12 Oct 2006 21:43:14 +0900

Bert,
     Thanks for the detailed review. Let me go through these
and post a revised draft. I hope to make it before the 23rd
cutoff.

     Cheers

     Glenn