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: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Dale.Worley@xxxxxxxxxxx Sent: 12 November 2008 20:48 To: sipping@xxxxxxxx Subject: 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. 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 _______________________________________________ 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
