Subject: Re: [Sipping] Some initialissues regardingdraft-dawes-sipping-debug-event-01

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Fri, 9 Jan 2009 13:00:46 +0100

Hi,
Thanks Dale and to eveyone who made comments on the debug drafts in
Minneapolis and here on the sipping list. I was not aware of the SIP
config framework draft
(http://tools.ietf.org/html/draft-ietf-sipping-config-framework-15) that
Hadriel pointed out and, having read it, I agree that my debug proposal
can be thought of, in terms of the config framework draft, as a
temporary configuration of specific fields: namely SIP
debug-logging-related configuration. The debug drafts have additional
information in that they include detail of the syntax and meaning of the
configuration, and also procedures related to a new header field. 

Also, Krishna made a very good point that might not be clear in the
debug drafts. The mechanism might not be the best way to find a failure
of a single entity, but it will find an end-to-end problem when, for
example, a node returns an error response when it should not.

Security is rightly important when sending logs of signalling activity
between entities. The config framework draft deals with the same
concern, so in a revision of my drafts I have referenced
draft-ietf-sipping-config-framework (as a neater alternative to just
copying the solution into the new draft). I would be interested to know
if the security solution for config framework is considered adequate for
logs of debugging information.

I have uploaded a new, combined draft
http://tools.ietf.org/id/draft-dawes-sipping-debug-00.txt, which
includes changes in response to several of the points raised by Dale in
his mail of 12 November 2008 20:48. I have made a note of the more
detailed points, which can go into a later version. I have tried to
include enough examples to show how all parts of the mechanism work. The
example has two service providers, to show how this works, the 'debug
event server' is now mentioned as an entity separate from the registrar,
and the example shows multiple simultaneous debugging events. The draft
suggests sending a PUBLISH method to retrieve the logged information,
but a better method might be available. I have left out the detailed XML
schema and the debugging state machine for now to concentrate on the
principle of operation and on security.

Further views on this proposal are most welcome.

Regards,
Peter 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dale Worley
Sent: 08 December 2008 18:12
To: SIPPING
Subject: Re: [Sipping] Some initialissues
regardingdraft-dawes-sipping-debug-event-01

   From: "Dawes, Peter, VF-Group" <[email-masked]>

   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?

I see no reason why both definitions cannot be in one draft.  Which
draft name you use for it is probably not significant, since the name
will become irrelevant once the draft becomes an RFC.

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