2.1.34 Universal Logging Protocol (ulp) BOF

Minutes of the Uniform Logging Protocol (ulp)BOF

Chair: Erik Guttman <erik.guttman@eng.sun.com>

Reported by Jerome Abela <Jerome.Abela@hsc.fr>

Edited by Erik Guttman <Erik.Guttman@eng.sun.com>

Mailing list:

To subscribe: send "subscribe" to gulp-request@hsc.fr
To post: send mail to gulp@hsc.fr
Archives: http://www.hsc.fr/gulp/archives/
Web site for information on universal logging work (ULP): http://www.hsc.fr/gulp

The published agenda for this BOF was:

10 Minutes:
Presentation: Universal structured logging is a good thing

30 Minutes:
Discussion: A successful Universal Logging Protocol's requirements might include the following. We won't decide on the problems, just consider if they are hard or easy, within scope or outside of it.

10 Minutes
Is ULP really a good thing? Is it a well specified project? Who wants to work on it? Who would follow the work? Who would use it?

10 Minutes
Draft a charter, get volunteers

ULM (tag/value log format) was presented by Jerome Abela

Erik explained how the global logging problem could be broken into pieces, mainly:

Q: What is in the scope and what is not. Are we really talking about universal ?
A: We only provide a structure for logging
A: The kind of universal we are seeking is the minimal set of tags.

Q: why use tags ?
A: The idea is to build a minimum set of semantics, whether it's based on tags or position dependant fields or any other scheme may still be discussed.

Q: What are the problems with syslog ?
A: No semantics, no authentication, no integrity, no structure...
A: We need a way to standardize semantics.
Q: But do we really want authentication ? Signatures ?

Q: Who is concerned ? Which application? The system? (some company) is already using a multi-vendor standard.
A: ULP should not break anything. It should take this into account.
A: It can be an elective standard, coexisting with current logging but offering more. Vendors could migrate toward using it without breaking existing logging infrastructure. Interoperation with existing logging technology would have to be a work item for the ULP WG.

Q: What is the minimum set of attributes/values ?
A: Currently, it's suggested it should be the HOST, DATE, APPLICATION and PROCESS ID fields.

Q: What are the security requirements?
A: Suggestion: Mutual authentication of client and server should be possible. Message integrity is important. Confidentiality might be important.

Q: SASL solve none of the requirements. IPsec doesn't either.

Erik read a proposed charter to bash:

Q: It's not true that there is no standard. A logging system already exist: syslogd.
A: But syslog IS the problem.
A: There is an existing successful format. It should not be broken by ULP. (Consider sendmail, etc. which create structured syslog messages.)

Q: Shouldn't architecture and semantics should be differentiated?
A: An architecture should be provided so that message semantics are possible.

There are already successful schemes. The new mechanism should bridge the different formats, map them into ULP.

ULP would encourage more logging.

There are people doing audit trails, but their are not to be standardized here. We only provide a mechanism so their could be standardized.

Q: Syslog IS a standard. It should be specified by this group.

Q: Is it in the scope of an IETF WG to standardize an API?
A: Yes. But we are probably not interested in pursuing a standard API. An informational API would be quite useful.

Q: If we start with authentication, we will need certificates, then certificate distribution.
A: We won't invent a new security scheme. We only address the problem, and find which protocol can achieve which level of security for ULP.

Q: How is it better than syslog ?

Security, when ? Someone asked when we would come up with security. Maybe ipsec will be there before we do ? Is ipsec at the right level ?

Q: Are there enough people here who think we are solving things?

Regarding the security part of the charter, "we will do this" should be "we will take care of this, we will look at it." We won't invent new mechanisms, if at all possible.

It was strongly suggested by the Keith Moore that the Correct Way to Proceed is:

I. Answer the question: "What do we need?"
II. Seek Solutions.

We should not try to build our solutions before having find our needs.

How many people are interested in working on it: 10
Take responsibilities: 4 (more approached the podium after the BOF)
Read and comment: 20

In answer to Keith, what the WG is willing to do is:

What about syslog which is not documented ?

Action Item: Add a gulp-request@hsc.fr alias so that mail administration can be done in the standard way. Currently one subscribes by sending "sub gulp" to sympa@hsc.fr [done]


None Received

Attendees List

go to list

Previous PageNext Page