multicast code has raised some open questions about the use of NS_DEBUG and possible interaction with the tracing system:

- whether NS_DEBUG should be used widely to perform function call tracing for debugging during model development

- whether traces such as function call tracing should be hooked into the tracing system rather than the debug system

- whether function call tracing is explicit or automated (bozo-profiler)

- format of function call tracing including whether parameters are included and also class namesaaa

- whether more granularity (per-node) is needed in filtering NS_DEBUGs printing out

- whether NS_DEBUG messages should print out simulation time and possibly node or object identifiers

- whether NS_DEBUG needs a few logging levels such as syslog warn, info, etc.  For instance:  1: function call/signature tracing, 2: return values, 3: internal high-level logic of a routine such as an algorithm, 4:  logic inside for loops, etc.

Quote from Craig:  "Assume for a moment that a debug trace facility is very useful.  We
currently have one based on macros with an on-off selector.  We also have a
very powerful low-level tracing subystem.  Does it make sense to integrate
the existing debug print / trace functionality into the tracing subsystem to
leverage some of the flexibility inherent in that system?"
"