Subject: [Sipping] Some initial issues regarding draft-dawes-sipping-debug-event-01

From: [email-masked]
Date: Wed, 12 Nov 2008 15:48:02 -0500 (EST)

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Tue, 18 Nov 2008 16:35:45 +0100

Hello Dale,
Thanks very much for providing such a thorough review and for uncovering
the important areas that the draft(s) must  include. It will take me a
little while to look into everything you found, but I think it's best to
start by combining the  drafts into one and giving the examples you
suggest. In particular, example(s) of how the whole mechanism works,
example(s) of a call handled by two or more service providers, and
example(s) of how multiple events are debugged simultaneously. 
I agreee with your concern that every relevant element will have to
maintain a subscription to the debug event server and I have a proposal
for how that can be avoided which I will also show in an example. I have
not thought much about the best way to retrieve the logged information,
perhaps a PUBLISH to the 'debug event server' is a way to do it. Also, I
agree that  security and privacy will need to be fully discussed. 

My preference for combining the drafts is to put everything in the event
package draft. Is it viable to define a new SIP header field in an event
package description, or would it be clearer to have a completely new
draft with a new title? 

Regards,
Peter 

http://www.ietf.org/internet-drafts/draft-dawes-sipping-debug-event-01.t
xt
http://www.ietf.org/internet-drafts/draft-dawes-sipping-debug-id-01.txt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: 12 November 2008 20:48
To: [email-masked]
Subject: [Sipping] Some initial issues
regardingdraft-dawes-sipping-debug-event-01

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.

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 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.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>?

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
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP