Hi this is a review of the requested changes from part 2 of my earlier
review.

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh@comcast.net] 
> Sent: Wednesday, October 25, 2006 4:25 AM
> To: syslog@ietf.org
> 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
> dharrington@huawei.com 
> dbharrington@comcast.net
> ietfdbh@comcast.net
> 
> 
> 



_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog