Confirm and Ack are identical in this respect and they must be called on instance nodes, never on the type. This sentence just clarifies this particular case of Invalid NodeID.

CMPWG Jun-26-2014:

Thanks for the feedback. We wanted to clarify that Confirm should actually be called against a type definition, kind of... the opening paragraph in 5.7.4 (Confirm Method) states:

"However, some Servers do not expose Condition instances in the AddressSpace. Therefore all Servers shall allow Clients to call the Confirm Method by specifying ConditionId as the ObjectId and the well known NodeId of the Method declaration on the AcknowledgeableConditionType as the MethodId. The Method cannot be called on the AcknowledgeableConditionType Node."

However, we still think that BadNodeIdUnknown is the wrong choice of code here. The Node is known. But we wonder if another problem we found may have accidentally resulted in BadNodeIdUnknown being used:

Part 4 Table 63 (Call Operation Level Result Codes) shows:

• Bad_NodeIdInvalid See Table 166 for the description of this result code.
  Used to indicate that the specified object is not valid.
• Bad_NodeIdUnknown See Table 166 for the description of this result code.
  Used to indicate that the specified object is not valid.

Note: two different codes showing the exact same description.

Based on the description of BadNodeIdInvalid, it seems to be the best fit for this situation.

2014-07-29: UA meeting

We agreed that the error description should be improved.
Proposal: Change error description into "Used to indicate that the specified ObjectId does not refer to a valid Condition"

Reviewed all error codes and fix description and the actual error codes as needed (made all methods more consistent)

Agreed to changes in telecon.