Subject: [sip-clf] draft-ietf-sipclf-problem-statement-01

From: Peter Musgrave <[email-masked]>
Date: Sun, 30 May 2010 08:43:32 -0400

Hi all,

Here are my "as individual" comments...

3.
transaction
Do we mean transaction or message. I asked in Anaheim about logging
retransmits and the response was these will be logged. This makes me
think we are not logging the transaction but the messages. (e.g.
RFC3261 talks about the 'transaction' resending the 'request' message
- so my understanding is a single transaction can result in multiple
messages).

4.
"is a standardized method of producing a text file"
- this statement precludes INFIX - remove "text" ?

8. Data model
- do we want to include the Content-Type and Content-Length? I can see
value is knowing e.g. where in the flow the offer/answer was - which I
can get if I can see the content-type.
(This list appears to exclude logging of content - which seems ok to
me since this will greatly increase the logging value)

Some of the earlier list discussion talked about binary content (if we
log Content?). Do we see content logging as a requirement for the
datamodel, a likely extension or something that should be prohibited
due to the log volume impact?

9. Examples are TBD
- do we need examples if this doc is not describing a specific format?
- do we want to include a typical volume analysis such as discussed in
http://www.ietf.org/mail-archive/web/sip-clf/current/msg00123.html

10. Security
There was a discussion of threat models and it was agreed this should
go in the next draft.
(http://www.ietf.org/mail-archive/web/sip-clf/current/msg00153.html)

Thanks,

Peter Musgrave

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 30 May 2010 14:39:49 -0500

> Here are my "as individual" comments...

Hello Peter: Please see inline.

> - so my understanding is a single transaction can result in multiple

The intent is to log a message.  In SIP, transactions can pend for
a certain time until a response is delivered.  In early versions of
the work, I tried to make it so that if a response is delivered
soon enough (200ms), a transaction is logged (i.e., a request +
the response it elicits).  But this gets fairly complex and requires
the sipclf logging system to now be aware of timing issues.  So
it seems reasonable to say that we deal in terms of messages,
where a message is a request or a response processed by the SIP
entity.

> - this statement precludes INFIX - remove "text" ?

What would we put instead?  Any suggestions?

> me since this will greatly increase the logging value)

I think we can include these but not in the mandatory set of fields.

> due to the log volume impact?

An extension.

> - do we need examples if this doc is not describing a specific format?

In the version I am working on, I have included examples just to make
the idea more concrete.  In the draft, I do say that the examples
are included for illustration purposes only and not as a
representation of any specific logging means (indexed-ASCII or IPFIX).

> http://www.ietf.org/mail-archive/web/sip-clf/current/msg00123.html

That is upto the WG to decide.  I do not have this analysis at
present in the problem-statement, but am happy to put it in if people
think it helps.

> (http://www.ietf.org/mail-archive/web/sip-clf/current/msg00153.html)

Yes, it is already there in my working copy.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Peter Musgrave <[email-masked]>
Date: Sun, 30 May 2010 19:04:30 -0400

Hi Vijay,

Thanks for the quick response.

A few clarifications inline. (Some items removed to save space)

> What would we put instead?  Any suggestions?
I meant that it should read "producing a file". Really just a nit.

.
> representation of any specific logging means (indexed-ASCII or IPFIX).

Ok.

> present in the problem-statement, but am happy to put it in if people

In my opinion I think sizes of typical and extreme messages are useful
- but I think the implementor will need to figure out their own rates
(since there is a huge difference between a carrier server and a
mobile device....)