[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Syslog] Mib -10-, part 2
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
dharrington@huawei.com
dbharrington@comcast.net
ietfdbh@comcast.net
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
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
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog