I have just noticed a bug in the Telecom Log Service IDL. The
"Log" interface defined in the "DsLogAdmin" module defines "set_qos"
and "get_qos" operations. And, the DsNotifyLogAdmin::NotifyLog
interface inherits both the DsLogAdmin::Log interface (indirectly,
through inheritence of DsEventLogAdmin::EventLog) and the
CosNotifyChannelAdmin::EventChannel interface. Note that the
CosNotifyChannelAdmin::EventChannel interface inherits from
CosNotification::QoSAdmin, which also defines "set_qos" and "get_qos"
operations! This is invalid IDL inheritence as of CORBA 2.3!

The same problem exists for the DsTypedNotifyLogAdmin::TypedNotifyLog
interface. It indirectly inherits both DsLogAdmin::Log and
CosNotification::QoSAdmin, and thus two versions of "set_qos" and
"get_qos".

There are a couple of possible solutions to this problem, but perhaps
the easiest would be to simply rename the "set_qos" and "get_qos" operations
defined in the Log interface as "set_log_qos" and "get_log_qos",
respectively. If only there were an RTF that could do this...

see above

Summary: The specification text is unclear and should make a note in
section "3.4 Log Generated Events" to explain that the manner
in which logs send log generated events to their corresponding
log factories is an implementation detail.

The idea is that applications (log/LogFactory clients) are only consumers
of log emitted events, they do not send events to the factory. Therefore, the
LogFactory does not need to expose the SupplierAdmin interface. How the log
actually forwards events to the factory is left up to the implementation -
use a SupplierAdmin object, or other means.

resolved, see revised text below

Summary: In the specification text, the BasicLogFactory::create() and
BasicLogFactory::create_with_id() operations have an extra
argument, in CapacityAlarmThresholdList thresholds, which does
not appear in the specification IDL. The reference to thresholds
in the specification text should be removed from the definitions
of BasicLogFactory::create() and BasicLogFactory::create_with_id().

The paragraphs in the specification text that describe the create()
and create_with_id() operations for the other log factories
(ie. EventLogFactory) should explain that they have an additional
argument, thresholds, besides the ones defined in the BasicLogFactory.

resolved, see revised text

Summary: In the specification text, all references to "LogFactory" should be
changed to "BasicLogFactory" to match what is defined in
the specification IDL.

completed, see revised text

Summary: there are a few enums defined in the
IDL. Perhaps it would be a good idea to adopt the
current OMG style of using CONST declarations for
these values as this allows easy extension of the values (which
enums do not). It is also nice to define the const types
as signed and to reserve all positive values for OMG
use and leave the negative values for vendors.

The following are the enums defined in the Specification IDL and proposed changes:

There are various Typo's that need to be corrected:
Page 1-5 "Allows a log factory emits"
Page 1-5 "Allows multiple push or pull consumers can register"
Page 2-20 "An InvalidAttribute exception..." (delete_records does not raise Invalid exception)
Page 2-21 "interface Iterater"
Page 2-21 "When an invoking the get() operation..."
Page 2-22 "...initialized to the save values as the log..."
Page 2-26 "...TypedNotifyLogFactory interfaces create() new EventLog..." (no parens)

Correct typos.

Summary: The specification text is unclear to a log"s behavior when off_duty.
What should the log do when it"s not functioning due to being
outside the interval or shut down according to the weekmask? I assume it"s
still available for adjusting weekmask parameters, but does it just drop
log requests on the floor?

rersolved, see revised text below

Summary: The specification text is unclear to a log"s behavior when disabled.
If the log is disabled ("due to some run time catastrophy"), how should
the log respond to requests? Since it is active enough to respond to
"get_operational_state ()" requests, shouldn"t it throw exceptions? Is it
allowed to drop log requests on the floor in that case? It could throw a
LogLocked exception, but in that case, should the log lock when it enters
the disabled state?

resolved, see revised text

The specification does not define a StateChange or a ProcessingErrorAlarm event
which are referenced in X.735 section 11.2.3, "Notifications".

resolved, se revised text below

The specification is inconsisent in specifying which attributes generate
AttributeValueChange events. Currently AttributeValueChange events are
generated for:
capacityAlarmThreshold
logFullAction
maxLogSize
startTime
stopTime
weekMask
filter

An AttributeValueChange event should also be generated when the other
attributes of a log are changed:
administrativeState
maxRecordLife
qualityOfService
forwardingState

resolved, see below

Summary: Documents: telecom/98-12-04 (text)
telecom/99-01-05 (IDL)

In module DsLogNotification, the event to be sent on log deletion is
defined as

struct ObjectDeletion

;

Here, "logref" is a reference to the Log object that has just been deleted,
and hence cannot be used for anything – would it be better to abolish this
field? (Even though doing so would reduce the symmetry with ObjectCreation).

Remove logref from the ObjectDeletion struct.

Summary: There seems to be a slight conflict on pg 3-16: "New events delivered to a
halt log will simply be discarded, these events may still be forwarded if
the log forwarding state (described below) is on". How can events be
discarded and forwarded?

A log in the halt state only effect the logs ability to log new records.

Summary: Should the Log interface define the get_capacity_thresholdlist()
and set_capacity_thresholdlist() operations? The BasicLog interface
inherits from Log and yet thresholds are meaningless in the context
of the BasicLog Why are they defined in Log and not in event and
notify log? And should BasicLog even bother checking the parameters or
doing anything?

resolved , see text below

A clarification needs to be made when untyped events are inserted and retrieved
from a typed log.

A client can use the standard "push" operation with a TypedProxyPushConsumer as
well as the type event operations defined on the interface generating the event.
What happens if a client invokes the typed_query() operation where some of the events
that pass the constraint were "push"ed as untyped events? Are those records ignored?
Are the type related fields of the TypedEventRecord left empty? Should we raise an exception?

No action to be taken.

Summary: The description of the "in Anys records" parameter of the write_records()
operation on page 3-18 is unclear as to what the records should contain.

The specification text should state that each Any contains the event to be logged.

The AB raised an issue regarding an ambiguity on the proper value
for the availability status, when the log is in the wrap condition.
The FTF editor added the following sentence at the top of page 2-12
of to telecom/99-05-01, in an effort to clarify the AB issue:

"When a log is full its availability status will change to
indicate the log full condition. If a log's full action is set to
'wrap', it will never be in 'full' condition."

This same ambiguity was discussed the ITU-T group which
originally wrote the X.735 spec, and their proposed resolution
has the opposite affect:

Add the following explanation to the availability status value as a
separate para after the text discussing wrap event behaviour :

"The availability status indicates "logfull" when the capacity of
the log is exceeded. In the case where halt behaviour is
specified for the log the value implies no more records can be
added. If wrap behaviour is specified, the value continues to
remain as log full even though forthcoming records will be added
by overwriting existing records. The wrap mode combined with
logfull condition indicates that old records are lost as
overwriting takes place. If records are deleted from the log, the
logfull status value is removed from the availability status in
either halt or wrap mode."

The reason the ITU group has recommended "full" status is that it
gives the information that records are being overwritten. When
the log is full, records will be lost in response to forthcoming
events. In Halt mode new records are not logged (i.e., lost),
while in the wrap mode the oldest records are overwritten (i.e.,
lost). If a client comes and deletes records, then
availabilitystatus can be reset. Otherwise one needs to have a
different behaviour for halt and wrap in terms of the value for
availability status.

Accept the ITU-T proposal, when in wrap mode, the log is considered to be full.

would like to formally raise the following Issue for resolution
by the FTF (jointly with the ITU-T group responsible for X.735)

Location: section 2 : Log full action, page 2-12

The AB raised an issue regarding an ambiguity on the proper value for the
availability status. When the log is in the wrap condition. The FTF input text
added the following sentence:

This is a duplicate of Issue 2753 – closed

Summary: This behaviour does not seem correct. Under a wrap condition, a
capacity alarm gauge threshold should retrigger once in each
period between wraps, but if the counter resets every time it
crosses the thresold it will trigger more often. Thus the reset
of the gauge , under wrap conditions, needs to be reworded as
follows:

"
When a log object is created with the wrap option the capacity
threshold alarms are triggered as if coupled to a gauge that
counts from zero to the highest capacity of the log defined
(reached each time the log wraps) and then resets to zero.

If a log wraps, and no records are deleted to free space,
capacity threshold events shall be emitted only when all the
records in the log prior to the previous wrap occurance are
completely overwritten. In other words, the gauge threshold is
reset to zero each time the end of log marker is crossed by the
addition of a new log record. For example if a log has a capacity
of 2 Gigabytes a wrap event will occur only when every time 2
Gigabytes of data have been written to the log.
"

resolved, see revised text below