· Chapter 2.5, page 2-33. The paragraph of the second bullet point can also contain the TypedRecordIterator.

· Chapter 2.3.1, page 2-26. It is more correct if it is said that BasicLogFactory creates BasicLog but not Log (similar to that EventLogFactory creates EventLog).

· Chapter 2.2.7.2, page 2-25. destroy operation is not only inherited from CosEventChannelAdmin::EventChannel but also defined in BasicLog interface. It is worth to mention it, since destroy operation can also be invoked on BasicLog objects.

· Chapter 2.4.1, page 2-29. Definition of the ObjectCreation struct contains logref field. This is different from the same definition in appendix 1 on page A-7. I think the correct version is on page 2-29. Then ObjectDeletion struct (page 2-30) does not have logref field. Is it OK? If yes, then "NOTE" in appendix 1 on page A-7 is wrong and not needed at all. If not, then the definition of that struct both on page 2-30 and in the appendix 1 should be modified.

· Chapter 2.4. Within the whole chapter in the description of every generated event "the log field" is used instead of "the logref field". Should be changed in every occurrence.

· Chapter 2.2.4.4, page 2-11. To have one style in the document and make it more readable I propose to change ulong to unsigned long.

3. Appendix 1, page A-5 has missing definition of write_recordlist method in the Log interface and has doubled definition of write_records method.

All these issues are applied to version 1.0 as well (formal/2000-01-04).

· Chapter 2.2.7.1, page 2-24. What is so resource consuming in the copy and copy_with_id operations? Why it can raise NoResources exception and any factory cannot? Factories also create logs and the log server also can have not enough resources to do it, but according to the specification factories do not raise NoResources exception. If NoResources should leave there then appendix 1 should be corrected since definitions of these copy operations do not contain NoResources exception in the list of raised exceptions and appendix 1 does not have definition of NoResources exception at all (should be put in DsLogAdmin module). Or if NoResources can be omitted then description of those copy operations should be modified

· Chapter 2.2.6, page 2-24. It is not clear for reader what is DAG topology. I propose to explain this. At least write what it stands for, like "DAG (directed acyclic graph)".

· Chapter 2.2.5.5, page 2-22. set_record_attribute operation does not raise InvalidGrammar and InvalidConstraint exceptions. These exceptions should be deleted from the description of the operation

2. Page 2-19. Description of write_recordlist says "In this case, only the "info" field (event content) of the RecordData struct is written to the log, the LogRecord id and logging time will be assigned by the log." Why doesn't it say anything about attr_list field of RecordData struct? Seems to me that this field (list of name/value pairs) can also be modified and written to the log.

1. Page 2-19 has missing LogOffDuty exception in the signatures of write_records and write_recordlist methods.

Currently there is:
void write_records(in Anys records)
raises(LogFull, LogLocked, LogDisabled);
void write_recordlist(in RecordList list)
raises(LogFull, LogLocked, LogDisabled);

Should be:
void write_records(in Anys records)
raises(LogFull, LogOffDuty, LogLocked, LogDisabled);
void write_recordlist(in RecordList list)
raises(LogFull, LogOffDuty, LogLocked, LogDisabled);

· Chapter 2.2.5.4, page 2-21. delete_records operation does not raise InvalidAttribute exception. This exception should be deleted from the description of the operation.

· Chapter 2.2.5.1, page 2-19. What are the values for minor codes: LOGFULL, LOGOFFDUTY, LOGLOCKED, and LOGDISABLED? Should those be defined in IDL?

The text for the copy() and copy_with_id() operations defined on the DsLogAdmin::Log
interface should specify that a DsLogNotification::ObjectCreation notification will
be generated as a result of the copy operation.

I think the OMG Telecom Log Service IDL (DsLogAdmin and DsNotifyLogAdmin
modules) isn't in accordance with the CORBA 2.6 "OMG IDL Syntax and
Semantics" specification.

Indeed the DsNotifyLogAdmin::NotifyLog interface inherits from both
DsLogAdmin::Log.get_qos and CosNotification::QoSAdmin.get_qos
operations, this is illegal according to section 3.7.5 (page 3-20) of
the CORBA 2.6 specification.

I've tried to compile the OMG Telecom Log Service with 2 differents ORBs
(ORBacus 4.0.5 and JacORB 1.4beta2) without success.

There is a typo on the first sentence on page 2-13. The words "enabled lock" should be "enabled log" in the following sentence : The stop field indicates the date and time at which an unlocked and enabled lock stops functioning.

The Notification Service defines:

module CosNotification {
// ...
interface QoSAdmin

;
// ...
};

module CosNotifyChannelAdmin {
// ...
interface EventChannel :
CosNotification::QoSAdmin,
CosNotification::AdminPropertiesAdmin,
CosEventChannelAdmin::EventChannel

;
};

The net result is that DsNotifyLogAdmin::NotifyLog inherits get_qos()
and set_qos() twice, once from QoSNotification::QoSAdmin, and once from
DSLogAdmin::Log, which is illegal. This makes the Logging Service
unimplementable right now.

Looks like the operations in DSLogAdmin::Log will have to be renamed or
the inheritance structure will have to change.

Assuming a log is persistent, how does one access the logged data after the system has been shut down? It seems important to be able to view this data after the system shuts down to determine if there were any glitches while the system ran or to troubleshoot any problems that occured.

The Log Service spec doesn't state how a client gets access to the
intial references for the service (namely, the various factories).

This issue concerns the Telecom Log Service as described in
the dtc/99-07-02 document.

I think the following statements in the spec are not compatible
together:

"Log forwarding is determined solely by forwarding state, it is not
affected by the log's administrative state, availability state, log
duration, scheduling, or log full action."

"A log may be not be able to create any new log records because it is
full, locked, or disabled. If a log cannot create new log records when
a push operation is invoked, then the push operation should fail and a
SystemException should be raised."

If the log records are forwarded, then throwing system exceptions to
the supplier doesn't make sense.