These are brief notes from my first reading of
draft-dawes-sipping-debug-{event,id}-01. Once these are clairified,
we will be in a better position to properly evaluate this proposal.
Probably better to combine the two drafts into one, as neither one
alone defines a usable mechanism.
Organization of the documents could use some improvement. In
particular, it would help to place near the beginning a complete
example, so that the reader knows how all the parts of the mechanism
interact before reading the details of each part.
While it is true that we want to capture traces from every SIP element
on the entire path from UAC to UAS, doing so is likely to be
complicated in the general case. If the call does not fork, all
elements are within one administrative domain, and we can predict in
advance which elements will handle the call, this mechanism seems to
be adequate. But in more complex situations it might not suffice. In
particular, I would expect the case of a call handled by different
service providers at each end to be commercially important, and yet it
seems simple enough that a workable solution should be possible. But
in such a case, the single *operational* point of control that
activates tracing differs from the multiple *administrative* points of
control of the two networks, which might require more complex
mechanisms. A number of these cases should be examined and described
to show that the mechanism works well in realistic situations.
The draft is conflicted about the debug-id values. In some places it
is described as 3 hex digits, and in some places as 6 hex digits. But
it seems that it should be "token" or some broader syntax category.
Is there any reason to constrict values so narrowly?
Using subscriptions to deliver debugging events (which are the
specifications for what logging should be done) assumes that every
relevant element maintains a subscription to the debug event server
(or that it can be instructed to establish a subscription by some
other means). This seems inefficient, as the subscription would
rarely return an event. Instead, why not "push" the events, say using
PUBLISH? That reduces the overhead to zero at any time the mechanism
is not being actively used. Or perhaps have the debugging-controller
send a SUBSCRIBE to the element, where the SUBSCRIBE carries the
debugging specification, and the element returns debugging status
information in the NOTIFYs.
To work in a practical network, the mechanism must allow multiple
debugging actions to proceed simultaneously and independently. This
mechanism allows multiple AORs to be debugged at one time, but it
seems to intend that each element have one "master" for debugging
purposes. Is this adequate for complex situations?
Section 4: RFC 3265 forgets to specify that the definition of an
event package must specify the request-URIs to which SUBSCRIBEs for
the event package can be directed, and how the information returned in
the NOTIFYs is determined by the request-URIs. This draft should
include that information, but (like most others) does not. The
structure of the draft (e.g., last item of section 4.3) suggests that
the request-URI is an AOR which might be subject to debug tracing, but
that is operationally inconvenient. (How is a proxy to guess which
AORs to subscribe to?) Perhaps the request-URI contains only a domain
name, and returns debug information about all AORs that an element
"owned by the domain" should trace? To some degree this question is
addressed in section 5.1 ("Note that the document format explicitly
allows for conveying information on multiple addresses-of-record.
This enables subscriptions to groups of debug configurations, where
such a group is identified by some kind of URI.") but it should be
specified clearly as a datum about the event package, both for
completeness and to ensure the reader is not confused.
Section 4.7.1: The description of the state machine seems excessively
complicated. All that needs to be stated is: For every AOR, the
notifier (debug state server) either has a debug configuration for
that AOR or it does not, and it can transition between these
conditions. Whenever the debug configuration changes (or is created
or destroyed), the server sends a NOTIFY.
Section 4.7.1, last paragraph: The term "registrar" is used here
instead of "debug state server". It is not clear why, as there is no
intrinsic connection between being a SIP registrar and being a debug
state server.
Section 5.1: "a 32 bit integer" does not specify whether the integer
is signed or unsigned.
Section 5.2: Terminology should be more consistent. The value which
is called "debug-id" in section 5.1 is referred to as both "unique id"
and "id" in section 5.2: 'Each row is indexed by the unique id for
that session. It is conveyed in the "id" attribute of the "session"
element.' If the XML element is named 'debug-id', that value should
always be referred to as "a debug-id", as that makes reading the
document much easier.
Section 5.2: The draft assumes that a subscriber may have several
subscriptions, each of which may provide information about several
AORs. What if two subscriptions provide information about the same
AOR?
Section 5.2: "registration" is used where "AOR" should be used.
Section 5.4: The <debug-id> element is a child of the <start-trigger>
element, but it is not clear why, since the parent <session> has an
'id' attribute which is also unique (within an appropriate scope).
Why not promote debug-id to an attribute of <session>? (Note the
description in 3.1 ("the minimum set of debugging configuration is a
"aor" attribute and a <debug-id> element.") but the schema doesn't
make <debug-id> required. It seems the uses of 'id' could be
simplified considerably. At the least, in some one place the
hierarchy of subscriptions/AORs/sessions needs to be laid out clearly.
Section 5.4: There seems to be no description of the meanings of any
of the elements of <session>. What is to be logged, when? How is
this controlled by the elements of <session>?
How is the logged information to be retrieved?
Section 9: Since this mechanism could have serious effects on
security and privacy, a real discussion of these needs to be included.
Dale
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
