[sip-clf] Rough notes

["Elwell, John" <[e-mail]>]

Problem statement (Peter):

Open issue 1 on 4K limit on mandatory headers. Peter suggests 4K per field - per message seems too constraining. Some support from others.
Brian - agrees each field.

Open issue 2 - IP address vs DNS name.
Hadriel: Round robin DNS is deployed, contrary to one of Vijays cons of IP address only.
Also no limitation to how many fields you can encoded in ASCII format. So prefers first.
Brian: IP address has advantage you know the IP address - DNS mapping may change in future so you can't get back the IP address. But depends where you are doing the logging - before or after DNS mapping.
Hadriel channelling Cullen: Agreeing with Hadriel. (missed the other point).
Peter: As individual, round robin argument clinches it. Seems to be all in favour of IP address, apart from one.

Suggestion from chair that it is ready for last call. Hadriel preferred to table it.


Indexed-ASCII format (Adam):
Open issue on logging of message bodies.
Hadriel: Should be optional, but we should define a format for them, e.g., name=value.
Hadriel: What was the 4K maximum per field - what is the solution if you have something longer?
Peter: Truncate.
Brian: If doing forensics, would have an alternative mechanism to log the raw bit stream as separate facility.
Hadriel channelling Cullen: Sounds nuts not to have SDP in log file.
Adam: Yes, that would be the consequence.
Hadriel: What we are really talking about is adding bodies to extension fields.

Missed some ????
Dan: Don't see why can't use multiple tags - if concerned about conflict, reserve subset of tags for future use.
Hadriel channelling Cullen: If can't put bodies in some standardized way in log file, can't see anyone using it.
Adam asked Cullen: Do we need a standardized tag?
Cullen: Yes.
Brian: What is application of including whole body with a subset of the header, versus just dumping the whole message?
Adam: For different kinds of message you have different sorts of information in bodies.
Hadriel: Agree with what Brian says, but what we are talking about here are vendor proprietary fields - why would we restrict this? Gave a couple of examples. But shouldn't restrict.
Keith Drage: So where would we go outside scope, e.g., if you had content indirection in SIP, would we include the HTTP exchange in there. Perhaps this because this is a separate protocol, that is outside scope. Need to say something about what not to do.
Hadriel: But it is silly to start restricting vendor specific stuff.
Keith: Allow to be vendor proprietary, but don't say how to use it.
Hadriel; Yes - point of syntax would be how to tag the information.
Adam: People seem to be saying we will allow vendors to define their own tags.
Hadriel channelling someone from Jabber room: Not sure why SDP needs to be a vendor extension.
Seems to be rough consensus in room, but some objections from Jabber room. Take to list.


IPFIX format - Brian Trammell
Noted that list consensus had been to use SIP escaping rules in log rather than binary.
Robert: Document needs to have text on this.
Brian: Next version will have this.
Robert: Still want to see worked examples (for torture tests).

How to encode method names- integer or name.
Adam: Unrecognised methods are not necessarily illegal - just something a proxy, say, has not implemented.
Brian: Would need a mechanism for logging weird methods.
Adam: Would need a configuration file to putting in new methods.
Brian: Planning to have IANA updatable XML file.
Robert: ????
Brian: Will need an IPFIX registry
Hadriel: Can we have ????
Hadriel: Add a string field for the name.

Have two independent implementations. Can fix issues if decide to proceed and get it finished quickly.


Wireshark plug-in implementation (Hadriel)
Noted that next release of Wireshark will have IPFIX support.
Chair will put some screenshots on Wiki for benefit of remote participants.


Implementation (Peter):
Hadriel: Surprised at code size difference. Did you work from template.
Peter: Yes
Hadriel: But you can just dump in correct format without using template.
Brian: What is size difference when compressed?
Peter: Haven't done it, but would still would expect similar size ratios.
Hadriel: Should end up being about the same size.
Brian: Difference between theoretical and practical compressibility. Need to talk off-line.


Pros and cons of the two approaches:
Do IPFIX advocate really want file format or stream format? Might be possible to base on non-binary file format?
Hadriel: IPFIX people were expecting to get the stream capability for free from this work. Could define in ASCII and define IPFIX tags as separate exercise.
Brian: IPFIX is trying to streamline its process, but basically need to bring draft along and have expert review. Would need to define in a SIP-like WG, not IPFIX. AS soon as adopted as work item here, go to IANA and get codepoints assigned.
Robert: Doesn't fit into DISPATCH, but if acceptable to stakeholders, could take to DISPATCH and let DISPATCH find a place for it.
Nobody in room seems to have a problem with this.
Will ask on mailing list whether people would be comfortable defining ASCII format for SIPCLF, and deriving IPFIX stream from that.
Hadriel: Likes compromise, but why is ASCII file format be so complicated - why can't we have one that is fully human readable?
Chair: Have that discussion on the list.
Adam: ????
Gonzalo: Should explain on list why we effectively are doing both.