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

From: "Glenn M. Keeni" <[email-masked]>
Date: Thu, 09 Nov 2006 07:55:37 +0900

Bert,
    I have revised and submitted draft-ietf-syslog-device-mib-11.txt.
The actions taken for each of the points raised are given in the
attached document. Please let me know if any of the points have not
been addressed adequately.
    Cheers

    Glenn

Wijnen, Bert (Bert) wrote:
> 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

1. First some SMICng error messages resulting from syntax checking:
=>   
=>     C:\bwijnen\smicng\work>smicng syslog.inc
=>1a   W: f(syslog.mi2), (47,17) REVISION value "200609R04000Z" is not
=>        a valid extended UTC time
=>1b   E: f(syslog.mi2), (97,15) Name of "auth" duplicates an existing one
=>1c   E: f(syslog.mi2), (102,15) Name of "cron" duplicates an existing one
=>1d   E: f(syslog.mi2), (54,20) Sub-Id for item "syslogMIB" must be
=>       "number" or "name(number)" format
=>1e   W: f(syslog.mi2), (245,4) Sequence "SyslDevOpsEntry" and Row
=>       "syslEntOpsEntry" should have related names
=>1f   W: f(syslog.mi2), (418,4) Sequence "SyslDevCtlEntry" and Row
=>       "syslEntCtlEntry" should have related names
=>1g   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
=>   
Action. Fixed 1a-1f 
   changed the duplicate instances of auth and cron to
               auth1, auth2, cron1, cron2
   changed: SyslDevOpsEntry -> SyslogEntityOperationsEntry 
            syslEntOpsEntry -> syslogEntityOperationsEntry
            SyslDevCtlEntry -> SyslogEntityControlEntry 
            syslEntCtlEntry -> syslogEntityControlEntry

+------------------------------------------------------------+
2  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?
Action. Response:
  The entity that handles syslog messages is called an "application" in 
  [RFCPROT] and a device in [RFC3164]. That is what the text above intends
  to say. 
  Looks OK to me.   Let me know if you want to change the wordings. 
 
+------------------------------------------------------------+
3  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.
=>
Action. Fixed.
      Added TRANSPORT-ADDRESS-MIB[RFC3419] to the text on section 3
      (and 7.1 Normative References).
   
+------------------------------------------------------------+
4  Page 6:
=>   
=>         LAST-UPDATED "200511250000Z"  -- 25th November, 2005
=>   
=>4a While in the DESCRIPTION clause you have a copyright of 2006!!??
=>   
=>4b 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.
=>
Action. Fixed 4a-4b.
+------------------------------------------------------------+
   
5  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
=>   
=>5a I think the "RFC yyyy" should read "RFC XXXX" in order to bein sync 
=>   with the RFCEd. note.
=>5b 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."
=>   
Action. Fixed 5a-5b.   
+------------------------------------------------------------+

6  The read-write objects under syslogSystem MUST add text to the 
   DESCRIPTION clauses that state the expected persistency behaviour.
  
Action. Fixed.   
   Added text 
       "The value of this object SHOULD remain unchanged
        across reboots of the managed entity."
    to the DESCRIPTION clauses for all the read-write objects under 
    syslogSystem.
+------------------------------------------------------------+

7  For
      syslogDefaultTransport OBJECT-TYPE
          SYNTAX      TransportAddressType
=>7a
=>   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?
=>   
=>7b
=>   Same question of course for syslEntCtlTransport object.
Action. Fixed 7a, 7b
   replaced 
      syslogDefaultTransport OBJECT-TYPE
          SYNTAX      TransportAddressType
      and
      syslEntCtlTransport OBJECT-TYPE
          SYNTAX      TransportAddressType
   by 
      syslogDefaultTransportDomain OBJECT-TYPE
          SYNTAX      TransportDomain
      and
      syslogEntityControlTransportDomain OBJECT-TYPE
          SYNTAX      TransportDomain
+------------------------------------------------------------+ 

8  >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.
Action. Fixed. 
   Changed "Ops" to "Operations". 
   The table name is changed to syslogEntityOperationsTable.
   There are two tables syslogEntityControlTable and 
                        syslogEntityOperationsTable 
   one is for control and the other for operations
   statistics and information.
   
+------------------------------------------------------------+   
=>9  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 }
=>   
=>9a I think that in the description clause I would state that this table
=>   is to have control over the configuration of syslog Entities.
=>
=>9b I think I would name it
=>   
=>      syslogEntityCtlTable or syslogEntityControlTable
=>   
=>   
=>9c 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.
=>
Action. Fixed 9a-9c   
   revised DESCRIPTION of syslogEntityControlTable.
   changed syslEntCtlTable -> syslogEntityControlTable 
   fixed   SyslDevCtlEntry -> SyslogEntityControlEntry
+------------------------------------------------------------+

10 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
=>Action. Fixed.
=>   changed: SyslDevOpsEntry -> SyslogEntityOpsEntry
=>            syslEntOpsEntry -> syslogEntityOpsEntry
=>                                      ^^^
=>11 Same story for: 
=>      syslEntCtlTable OBJECT-TYPE
=>          SYNTAX      SEQUENCE OF SyslDevCtlEntry
Action. Fixed.   
   changed: SyslDevCtlEntry -> SyslogEntityControlEntry
            syslEntCtlEntry -> syslogEntityControlEntry
+------------------------------------------------------------+

12 For
=>      syslEntCtlEntry OBJECT-TYPE
=>          SYNTAX      SyslDevCtlEntry
=>          MAX-ACCESS  not-accessible
=>          STATUS      current
=>          DESCRIPTION
=>              "The parameters pertaining to a syslog process."
=>          INDEX  { syslEntOpsIndex }
=>          ::= { syslEntCtlTable 1 }
=>   
=>12a 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).
=>   
=>12b 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.
=>
Action. Fixed 12a, 12b
   a. syslogEntityOperationsTable AUGMENTS syslogEntityControlTable 
   b. added syslogEntityOperationsCounterDiscontinuityTime object
      added text to the Counter32 objects about the discontinuities
+------------------------------------------------------------+

13 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?
Action. Fixed.
   renamed the object 
      from syslEntOpsLastMsgDeliveredTime
      to   syslogEntityOperationsLastMsgTransmittedTime.
   revised the DESCRIPTION of the object
+------------------------------------------------------------+

14 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?
=>
Action. Fixed. 
   Revised the DESCRIPTION. process-> entity
+------------------------------------------------------------+
     
=>15 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,
=>              "
=>   
=>15a
=>   First, I would change "is serviced" into "is instantiated" or "is supportted".
=>15b
=>   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.
=>              "
Action. Fixed.
   a. Revised the DESCRIPTION.
   b. Revised the SYNTAX to Integer32 (0..2147483647) 
+------------------------------------------------------------+

16 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.
=>              "
=>   
=>16a
=>   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.
=>   
=>16b
=>   For syslEntCtlProcDescr I wonder if this value is/can be used 
=>   anywhere else. If yes, pls say something about it.
Action. Fixed.
   Revised the DESCRIPTION clause 
+------------------------------------------------------------+
   
17 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 }
=>   
=>17a
=>   I am not sure what "if a hostname is specified..." means.
=>   If it is a FQDN, then the InetAddressType would be 'dns'
=>17b
=>   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.
=>   
=>17c
=>   You MUST also add some text that states that the format of this address
=>   is controlled by the value of the corresponding syslEntCtlBindAddrType
=>   object.
Action. Fixed 17a, 17b, 17c.
   Revised the DESCRIPTION clause. 
+------------------------------------------------------------+
   
18 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 }
=>   
=>18a
=>   I wonder where is/are the syslogCtlSelectionTable and the
=>   syslogCtlLogActionTable tables defined? I cannot find them
=>   so I am not sure what this means.
=>18b
=>   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. 
Action. Fixed 18a, 18b.
   Revised DESCRIPTION clause. 
   Removed references to syslogCtlSelectionTable and 
   syslogCtlLogActionTable. 
+------------------------------------------------------------+   
19
=>   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 }
=>   
=>19a
=>   What is "the process" ??
=>19b
=>   I think I would add a DEFVAL for syslEntCtlStorageType
=>   Any value that the WG feels appropriate is fine.
=>
Action. Fixed.
   a. Changed process -> entity.
   b. added   DEFVAL { nonVolatile } to syslEntCtlStorageType 
+------------------------------------------------------------+

20 For syslEntCtlRowStatus
=>20a
=>   - s/iff/if/
=>20b
=>   - 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.
Action. Fixed 20a, 20b.
    a. changed iff->if. 
    b. added text in the DESCRIPTION about objects that 
        be changed when this object is in state ''active'' or in
       ''notInService''.
+------------------------------------------------------------+

21
=>   The two NOTIFICATIONs could easily be combined into a
=>      syslogEntitySTatusChanged NOTIFICATION-TYPE
=>   Just a minor optimization I guess
Action. Fixed.
+------------------------------------------------------------+

22 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?
Action. Fixed.
   Revised the DESCRIPTION clauses of the Objects in syslogEntityControlGroup
+------------------------------------------------------------+

23 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.
=>              "
Action. Fixed.
    The Compliance section has been revised.
+------------------------------------------------------------+
   
24 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.
Action. Fixed.
     The Compliance section has been revised.
     Full compliance can be claimed with syslogFullCompliance1 now. 
+------------------------------------------------------------+
   
25 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.
Action. Fixed. 
+------------------------------------------------------------+
   
=>26 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.
Action. Fixed. 
+------------------------------------------------------------+
_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog