Subject: Re: [Syslog] Mib -10-, part 2

From: "Glenn M. Keeni" <[email-masked]>
Date: Thu, 09 Nov 2006 08:00:25 +0900

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

    Glenn

David Harrington wrote:
> Hi Glenn,
> 
> I want to remind you of some outstanding issues to resolve:
> 
>>From tom petch, 8-16:
> "I still have trouble with the mib document, not for any mibby reason
> but simply
> because, as I commented on the previous version, it seems to be
> written in a
> different language to the other I-D and, insofar as I understand that
> language,
> seems to be describing a different set of concepts to the other
> documents."
> 
> And 9-28:
> "I have looked at this I-D and appreciate the increased explanation at
> the
> beginning.  It leaves me clearer, but still thinking that this
> document steers a
> different course to the other syslog ones, in its focus on a group of
> syslog
> entities.  It's not that there cannot be more than one syslog entity
> running in
> a given host, just that bundling them together into a table seems an
> artificial
> complication; other syslog MIB modules I see are scalar in approach."
> 
> I am less concerned about the table of entities versus modeling a
> single entity. Having this in a table makes it easier than forcing the
> use of contexts to get at multiple instances of the MIB module on a
> host, and is consistent with the hrSwRunTable of the Host Resources
> MIB. Unless the WG raises objections, I believe the table approach is
> acceptable.
> 
> Consistent concepts and terminology is important. WG consensus is that
> all the documents should be consistent. The other document editors
> aligned their terminology, and you must do so for this document as
> well. It is especially important that terminology used in the
> management interface be consistent with the technology being managed.
> 
> Please plan on submitting another official revision before Nov 12,
> with all outstanding change requests addressed, so we can finish
> another 2-week WGLC and still meet our November deadline. If you
> question some of the change requests, please consult the chairs and we
> will make a determination.
> 
> Thanks,
> 
> David Harrington
> [email-masked] 
> [email-masked]
> [email-masked]
> 
> 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog

   The following comments relate to mail with subject 
   [Syslog] Mib-09- review, part 1
+------------------------------------------------------------+
1) There are multiple pages that exceed the maximum allowed lines per
=>page. 
Action. Fixed
+------------------------------------------------------------+

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

=>3) the terminology is not consistent with the other WG documents. 
=>
Action. Response.
     I think this is fixed. The MIB deals with an syslog entity. 
     The other documents refer to a syslog receiver, relay, collector
     etc. depending on the context.
     I do not see any inconsistency or conflict.
     Please let me know if there are any specific inconsistencies. 
+------------------------------------------------------------+

=>
=>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.
=>
Action. Fixed. 
  "syslog entity" remains. 
  I do not think that is a problem. Let me know if it is.)
+------------------------------------------------------------+

5) I concur with Bert that the citations in section 2 seem
=>inappropriate.
=>
Action. Fixed.
+------------------------------------------------------------+

=>6) I find the references to SA-Li, RA-Rj confusing since these are not
=>used in the diagram.
=>
Action. Fixed.
     The labels and caption are changed. 
+------------------------------------------------------------+

=>7) "The MIB comprises of four groups" would be better as "The MIB
=>contains four groups"
=>
Action. Fixed.
+------------------------------------------------------------+

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.
Action. Fixed.
+------------------------------------------------------------+

9) "asynchronously monitor" s/b "asynchronously report"
=>
Action. 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.
Action. 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?
Action. Fixed.
     If there is consensus in removing 99 (other), I will remove it.
+------------------------------------------------------------+

=>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#?
Action. Response.
     We do not distinguish between TCP ports and UDP ports. The 
     syslogEntityControlTransportDomain will tell whether TCP is used or 
     UDP is used. 
+------------------------------------------------------------+

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. 
Action. 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.
=>
Action. Response.
   We are now using syslogDefaultTransportDomain. And in the 
   SyslogEntityControlEntry we have 
        syslogEntityControlBindAddrType
             InetAddressType,
        syslogEntityControlBindAddr
             InetAddress,
        syslogEntityControlTransportDomain
             TransportDomain,
        syslogEntityControlService
             SyslogService,

   The syslogEntityControlTransportDomain ( by default 
   syslogDefaultTransportDomain) specifes the domain to which the 
   syslogEntityControlBindAddrType,syslogEntityControlBindAddr and 
   syslogEntityControlService apply. 
+------------------------------------------------------------+
   
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.

Action. Fixed.
   The xxxFacility and xxxSeverity will be used to compute the
   Severity.
   The DESCRIPTION clauses are revised to clarify the above.
+------------------------------------------------------------+

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.

Action. Fixed.
    syslogDefaultMaxMessageSize is deleted. 
    revised the DESCRIPTION of syslogEntityControlMaxMessageSize
+------------------------------------------------------------+

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".
=>
Action. Fixed. 
   DESCRIPTION of syslogEntityOperationsTable is revised.
+------------------------------------------------------------+

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.
Action. Fixed.
   The namings have been revised. syslog is used uniformly. 
+------------------------------------------------------------+

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.
Action. Fixed. 
    The DESCRIPTION clauses for the tables have been revised. 
+------------------------------------------------------------+

=>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.
Action. Response.
     I agree with you. But I have adopted the simpler approach. 
     Applications will match the indices with the corresponsding 
     syslogEntityControlProcDescr to obtain the user specified
     description of the entity. 
     That way I can leave the syslogEntityControlProcDescr with the 
     default size restrictions of SnmpAdminString.  
+------------------------------------------------------------+

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?

Action. Response.
   The indices are not required to be persistent across system reboots. 
   Users and applications are required to determine the index of each 
   entity after a reboot.
+------------------------------------------------------------+

22) syslEntOpsMsgsDropped counts messages that could not be relayed.
=>What about messages that cannot be queued for transmission for an
=>original sender?
Action. Fixed.
    The DESCRIPTION clause is revised  
        "The number of messages that could not be queued
         for transmission by the syslog entity."
+------------------------------------------------------------+
   
=>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.
Action. Fixed.
   The DESCRIPTION clause is revised to 
        "The number of messages that were not processed by the
         syslog entity because the messages did not meet
         the allowed specifications. This will include
         messages that are not accepted as the message size was
         greater than the systems maximum message size and will
         exclude messages that are rejected because they are 
         malformed. 
+------------------------------------------------------------+

24) syslEntOpsLastMsgDeliveredTime - the system does not know when the
=>message was delivered, only when it was transmitted or received. 
Action. Fixed.
    The Object name is changed to syslogEntityOperationsLastMsgTransmittedTime
    and DESCRIPTION has been revised to
        "The local time when the last message was transmitted
         by the syslog entity.
        "
+------------------------------------------------------------+    

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.
Action. Fixed.
    The description has been revised to 
        "A description of the last error that was encountered
         by this syslog entity.
        "
+------------------------------------------------------------+

26) syslEntOpsLastError talks about the last error this process
=>"encountered". The definition of encountered needs to be made unclear
=>and unambiguous.
Action. Response.
   Can you tell more about the ambiguity. I cannot figure out 
   what needs to be clarified and disambiguated.
+------------------------------------------------------------+

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? 
Action. Fixed.
   Revised the DESCRIPTION of syslogEntityOperationsReference to

        "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.
         Note that the hrSWRunIndex is not persistent
         across system reboots or software restarts. The
         value of syslogEntityOperationsReference should
         reference the latest 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.
        "
+------------------------------------------------------------+

   The following comments relate to mail with subject 
   [Syslog] Mib-09- review, part 2
  [The sequence numbers have been Prefixed by 2.]
+------------------------------------------------------------+
201) syslEntCtlTable should describe what type of information is stored
=>in the table, and the description should be more than "static info".
Action. Fixed.
     The DESCRIPTION of syslogEntityControlTable has been revised.
+------------------------------------------------------------+

202) syslEntCtlEnty - what type of parameters? What process?

Action. Fixed. 
    The DESCRIPTION of syslogEntityControlEntry is revised.
+------------------------------------------------------------+

203) syslEntCtlBindAddress - does this field contain an address or a
=>hostname? What does the seond sentence mean?
Action. Fixed. 
    The DESCRIPTION clause for syslogEntityControlBindAddr has been 
    revised.
=>
+------------------------------------------------------------+

204) syslEntCtlTransport - why is this "default" transport instead of
=>just transport?
Action. Fixed.
   The DESCRIPTION of syslogEntityControlTransportDomain has been
   revised.
+------------------------------------------------------------+

205) is there a mismatch between transportaddresstype and
=>syslEntCtlService? Is there a transportAddressType for this type of
=>"address"?
Action. Response.
   I did not get the question. 
+------------------------------------------------------------+

206) syslEntCtlConfFileName - using lots of abbreviations in the name
=>makes it hard for people to remember how the words were abbreviated.
=>It would be better to use something like syslogEntCtlFilename. Why do
=>we need Ent in the name? we never deal with anything other than
=>entities, do we? syslogControlFile would be much easier to remember
=>than syslEntCtlConfFileName.
Action. Fixed.
   The object names have been revised. 
+------------------------------------------------------------+

207) syslEntCtlConfFileName refers to syslogCtlSelectionTable and
=>syslogCtlActionTable - where are these defined?
Action. Fixed. 
   The DESCRIPTION of syslogEntityControlConfFileName has been
   revised.
=>
+------------------------------------------------------------+

208) syslEntCtlStatus - again, what process?
Action. Fixed.
   Changed process-> entity.
=>
+------------------------------------------------------------+

209) syslEntCtlStorageType - is this definition exactly the same as the
=>StorageType T-C?
Action. Response.
    Does it need to be exactly the same ? 
    Let me know if there is a problem with the definiton. 
=>
+------------------------------------------------------------+

210) ...RowStatus - spelling "iff"
Action. Fixed. 
    "iff" is not a spelling mistake. Its usage is intentional.
    But we can do with a simpler less precise "if".
=>
+------------------------------------------------------------+

211) syslEntStarted and syslEntStopped - spell out MO. I don't
=>understand the second sentence; how does the manager know what
=>syslEntOpsIndex is used?
Action. Fixed. 
     Changed MO-> Object.
     The manager will know the syslogEntityOperationsIndex from
     the instance identifiers in the trap/inform.
     Did I miss something ?
+------------------------------------------------------------+

212) It would be much better to use consistent naming between the
=>objects/tables and the conformance clauses. The table refers to
=>syslEnt, but conformance is for syslogDev; the objects are
=>syslogDefault but the conformance is syslogSystem. Let'e make it easy
=>to work with by being more consistent.
=>
Action. Fixed. 
     The names have been revised. 
+------------------------------------------------------------+

213) why are notifications not mandatory for compliance?
Action. Fixed. 
     The compliance statements have been revised.
+------------------------------------------------------------+

214) The MIB module exposes some info from syslog, such as last error.
=>The security considerations talk about securing snmp, but that does
=>not make sense if you do not also secure the syslog transport. The
=>security considerations should recommend securing syslog to match the
=>snmp security.
=>
Action. Response.
      I think that would be out of the scope of the MIB document's
      Security Considerations section.  
      It is something that the Protocol document should deal with.
      Let me know if I am wrong. 
+------------------------------------------------------------+

215) iana considerations talks about a base arc; this would be better
=>reworded.
Action. Fixed. 
      The text has been revised.
+------------------------------------------------------------+

216) I thik rfc3164 is informative, no tnormative.
=>
Action. Fixed.
+------------------------------------------------------------+

217) I suspect you are not usinng xml2rfc. If not, you need to make
=>sure all the boilerplates are up-to-date. Please check the funding
=>statement and the intellectual property clauses.
=>
Action. Response.
     I am relying ID-nits checks. 
+------------------------------------------------------------+

218) the change log is most effective if you track the chnages from
=>published version to published version, not by MIB revision dates.
Action. Noted.
+------------------------------------------------------------+

The following comments relate to mail with subject
   [Syslog] Mib-10- review, part 2
  [The sequence numbers have been Prefixed by 3.]

+------------------------------------------------------------+
301) syslEntCtlEntry should be changed to match the other prefixes
=>(syslogEntityControlEntry)
=>
Action. Fixed.
    Names have been revised.
+------------------------------------------------------------+

302) the same for syslEntOpsEntry, syslEntStarted, syslEntStopped, etc.
=>
Action. Fixed.
    Names have been revised.
+------------------------------------------------------------+

303) I recommend chaging "operations related information" to "operations
=>information"
=>
Action. Fixed.
+------------------------------------------------------------+

304) I recommend changing syslogSystemGroup to syslogDefaultGroup if
=>that's the prefix you keep on all the "Default" variables.
=>
Action. Fixed.
      Changed syslogSystemGroup -> syslogDefaultGroup
+------------------------------------------------------------+

305) I recommend changing syslDevOpsGroup to syslogEntityOpsGroup, and
=>syslDevCtlGroup to syslogEntityControlGroup. Why do we need two
=>groups? Can you implement Ops without the Control table, now that one
=>augments the other?
=>
Action. Fixed.
      The namings for the conformance groups have been revised.
+------------------------------------------------------------+

306) /implememt/implement/
=>
Action. Fixed.
+------------------------------------------------------------+

307) Is it possible to support notifications only, since the
=>notifications contain data from the tables not implemented? Where do
=>the values come from?
=>
Action. Response.
     Yes as far as external appearances are concerned the 
     agent may not show any signs that the objects are 
     implemented. (No Get/Set)
     But it can still send notifications. 
+------------------------------------------------------------+

308) did you run the document through the idnits checker at
=>http://tools.ietf.org/tools/idnits/?
=>It still reports this problem:
=> The page length should not exceed 58 lines per page, but there was 38
=>    longer pages, the longest (page 2) being 60 lines
=>
Action. Fixed.
        The only thing that idnits complains is about the 
        Security Considerations section. That is very much there.
+------------------------------------------------------------+

309) did you run the MIB module through the smilint utility?
=>Instructions can be found at
=>http://www.ibr.cs.tu-bs.de/projects/libsmi/mailrobot.html?lang=de
=>
Action. Response.
   Yes. I am running it through 
        smilint -m -s -e -l 9 -i namelength-32 syslogMIB
        there are zero errors.
        
+------------------------------------------------------------+

310) Can you add "Intended status: Standards Track" to the header (see
=>syslog-sign for an example).
Action.Fixed 
+------------------------------------------------------------+
   The following comments relate to mail with subject
   [Syslog] Mib-10- , part 2
  [The sequence numbers have been Prefixed by 4.]
+------------------------------------------------------------+
401 From tom petch, 8-16:
=>"I still have trouble with the mib document, not for any mibby 
=>reason but simply because, as I commented on the previous version, 
=>it seems to be written in a different language to the other I-D 
=>and, insofar as I understand that language, seems to be describing 
=>a different set of concepts to the other documents."
=>
Action.Response. 
        The terminology has been brought in line. In the 
        MIB document the reference is to a syslog entity. 
        That encompasses a collector, relay and sender
+------------------------------------------------------------+

402 And 9-28:
=>"I have looked at this I-D and appreciate the increased explanation 
=> at the beginning.  It leaves me clearer, but still thinking that this
=>document steers a different course to the other syslog ones, in its 
=>focus on a group of syslog entities.  It's not that there cannot be 
=>more than one syslog entity running in a given host, just that 
=>bundling them together into a table seems an artificial
=>complication; other syslog MIB modules I see are scalar in approach."
Action. Response.
        In one scenario there may be more than one Syslog daemons 
        running on different ports/network addresses. The MIB will 
        handle this nicely. The grouping is a feature not a necessity. 
        It provides flexibility that is useful in many scenarios.
+------------------------------------------------------------+
_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog