[Syslog] Submission of Shepherding Documents
Hi Folks, David and I are pleased to announce that the shepherding documents for the following IDs have been submitted to the IESG. - draft-ietf-syslog-protocol-19.txt - draft-ietf-syslog-transport-tls-06.txt - draft-ietf-syslog-transport-udp-08.txt Our thanks go to the authors and the Working Group for putting in the time and effort to develop and review these documents. We now need to focus on getting syslog-device-mib and syslog-sign out the door. Many thanks, Chris David ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Dbh re-Review of -mib-11, part 1
Hi, This is a check that my comments of 10/22 have been addressed in mib-11. 1) There are multiple pages that exceed the maximum allowed lines per page. Fixed. 2) The headers and footers do not appear to be standard. There should an abbreviated title for easch page after the first. Fixed. 3) the terminology is not consistent with the other WG documents. Not fixed. Still a problem. The WG consensus was to use sender, receiver, relay, and collector. Other document were required to change to match this terminology. The MIB document uses entity, which is a term not found in the protocol draft. I find this change in terminology makes it difficult to interpret some objects in the mib module. 4) roles a syslog entity maybe in would be better as roles of a syslog entity (although then entity should be changed according to #3. See #3. 5) I concur with Bert that the citations in section 2 seem inappropriate. I suggest rewriting the introduction to use the same terminology as the protocol draft. See #3. 6) I find the references to SA-Li, RA-Rj confusing since these are not used in the diagram. Fixed, but replaced by entity which is a problem. See #3. 7) The MIB comprises of four groups would be better as The MIB contains four groups Fixed. However, group is a reserved keyword in SMIv2 referring to compliance, so it should be replaced by subtree where that is its meaning. 8) Section 3 has a number of lists. You should decide if the list should contain sentences, or makes up one complete sentence. If it is one sentence, then each listed clause should end with a comma, and be consistent in style. If each item is a sentence, then the introductory phrase needs to be a sentence. I recommend making each item a sentence, so we can eliminate the which conrstructs. Fixed. 9) asynchronously monitor s/b asynchronously report Fixed. 10) the name of SyslogMIB or syslogMIB should be consistent in the text. I recommend using SYSLOG-MIB, which is the correct name for the MIB module. Fixed. 11) in SyslogSeverity, I recommend removing the second sentnece in the description The syslog protocol uses the values 0 (emergency) to 7 (debug). since this is already spelled out in the SYNTAX clause, and shows that 99 (other) is also used. Why do we need 99? Are other values valid? Partially fixed. When is other used? 12) SyslogService - can we make this just a service name. The port semantics are really ambiguous. How do distinguish a UDP port# from a TCP port#? Not fixed. 13) For consistency with most other MIB modules being developed, I suggest defining a top-level breakdown of syslogNotifications (0), syslogObjects (1), and syslogConformance (2). Then put syslogSystem and syslogDevice under syslogObjects. See RFC4181 appendix D. Fixed. 14) transportAddressType is designed to be used with specific types of transportAddress. The syslogDefaultTransport object should probably be syslogDefaultTransportType. A transportAddressType seems inappropriate for use with syslogDefaultService, which does not necessarily resolve to one of the enumerated options. We should have a syslogDefaultTransport that is a transport address. If we want a Default service, that should probably be a separate object. Partially fixed. How will the syslog/TLS transport address be specified in this object? 15) some objects are named xxxSeverity, but the description uses priority. We need to be consistent with the other documents about what this is called. Fixed. 16) the syslogDefaultMaxMessageSize description really needs work - 480 is the minimum maximum size, not the recommended maximum size, so it should not be the default. The maximum message size also may depend on the transport protocol and the target system, so I'm not sure a default is a useful object. Who is the user of this default? The local system? If so, then it is an implementation detail and does not need to exposed in a mIB object. If it is for use by the remote system, then it shouldn't be a default value, but the actual value supported by the implementation. Fixed (removed). 17) syslEntOpsTable uses abbreviated elements in the name. I don't see why they need to be abbreviated, or what the name actually means. The description does not mention ops. Fixed. 18) object prefixes should be consistent for the whole module. The DefaultXXX uses syslog as the prefix, but here we use sysl. Why? See RFC4181 appendix C for naming guidelines. Fixed. 19) syslEntCtlTable contains static info; does that imply that syslEntOpsTable contains dynamci info? Or is syslEntOpsTable about the operational environment, and syslEntCtlTable about control info? The descritions should kae the purpose of the table unambiguous. Fixed. 20) In the SNMPv2 effort, we found that using integer indices made using the tabels more difficut for human readers. It would be much easier for a human to interpret the
[Syslog] Dbh re-review of Mib-11-, part 2
Hi this is a review of the requested changes from part 2 of my earlier review. -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 4:25 AM To: [EMAIL PROTECTED] Subject: Mib-09- review, part 2 Continued ... 1) syslEntCtlTable should describe what type of information is stored in the table, and the description should be more than static info. Fixed. 2) syslEntCtlEnty - what type of parameters? What process? 3) syslEntCtlBindAddress - does this field contain an address or a hostname? What does the seond sentence mean? Partially fixed. When a manager application reads the addrtype an dfinds dns, and then reads the address object, will the agent a hostname or the IPv4 or IPv6 address in the varbind? If it returns, say, an IPv4 address, does it change the AddrType field to match? Or do you intend it to return the dns hostname along with the dns addrtype? I cannot tell what is intended, and I expect other implementer swill have trouble knowing which is the right interpretation of the very ambiguous description. 4) syslEntCtlTransport - why is this default transport instead of just transport? Fixed. 5) is there a mismatch between transportaddresstype and syslEntCtlService? Is there a transportAddressType for this type of address? Not fixed. I think you are using an enumeration to identify the format of the value in the next object, and then using a format in the next object that does not match any of the enumerated choices. This is obviously wrong. 6) 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. Fixed (mostly). 7) syslEntCtlConfFileName refers to syslogCtlSelectionTable and syslogCtlActionTable - where are these defined? Fixed. 8) syslEntCtlStatus - again, what process? Fixed. 9) syslEntCtlStorageType - is this definition exactly the same as the StorageType T-C? I am not sure this is the same semantics as StorageType T-C. Your text is somewhat unclear when it says backed up by non-volatile (permanent) 10) ...RowStatus - spelling iff Fixed. 11) syslEntStarted and syslEntStopped - spell out MO. I don't understand the second sentence; how does the manager know what syslEntOpsIndex is used? Partially fixed. I still do not understand the second sentence. Can you reword this sentence? 12) 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. Fixed. Much better. 13) why are notifications not mandatory for compliance? syslogFullCompliance2 says this means support for writable objects and notifications, but th enotification group has been left out of the manadatory-groups. If the intention is to leave out the notification, I would like to know why this is desirable. 14) 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. Not fixed. 15) iana considerations talks about a base arc; this would be better reworded. Fixed. 16) I thik rfc3164 is informative, no tnormative. Fixed. 17) 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. Partially fixed. Needs updated boilerplates. 18) the change log is most effective if you track the chnages from published version to published version, not by MIB revision dates. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Review of mib-11, part 3
Hi, 1) The idnits checker reports the use of the old copyright and disclaimer boilerplates rather than the new copyright and disclaimer boilerplates. These need to be updated. 2) syslogEntityOperationsReference uses a lower case should. Is it nto important for interoperability that this be done? If so, then this should be a SHOULD. If not for interoperability, why are we saying it should be done? 3) I still have difficulty understanding why default parameters are listed in the MIB module. What is the use case that requires these objects in the MIB module? Who decides what the default values should be? Since they are read-write objects, I assume the purpose is to allow an NMS to set the default values they want the sender to use. What happens if there are multiple NMSs talking to the same sender? Then who decides? If each NMS gets to decide, than you need a table in which each row is owned by a particular NMS. I still don't see why this would be needed however. If the sender decides, and the objects exist only so the receivers can check and see what the sender will use for defaults, then why are the objects read-write? Once an NMS checks the defaults, what are they supposed to do with this information? I question whether this deserves to be in the MIB module at all, but if it kept, then at least the MIB module should include a description of why it is there and how it should be used. 4) RFCPROT is a reference in syslogDefaultTransportDomain; it probably shoul dbe shown as [RFCPROT] or the RFC editor may overlook it. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
