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: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Dale Worley Sent: 08 December 2008 18:12 To: SIPPING Subject: Re: Some initialissues regardingdraft-dawes-sipping-debug-event-01 From: "Dawes, Peter, VF-Group" <Peter.Dawes@xxxxxxxxxxxx> 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
