BEHAVE minutes, IETF84, Vancouver, August 2, 2012 Chairs: Dave Thaler, dthaler@microsoft.com, Dan Wing, dwing@cisco.com minutes by Paul Selkirk and Philip Matthews audio: http://www.ietf.org/audio/ietf84/ietf84-regencyc-20120802-1730-pm3.mp3 Chair Slides ------------ Two documents in RFC editor queue: behave-learn-analysis, behave-64-analysis WGLC completed: behave-lsn-requirements Simon: draft-ietf-behave-lsn-requirements needs a clarification of whether to mandate PCP by name maybe MUST implement PCP, MAY use another mechanism Milestones Discussion about NAT MIB for CGNS. Will this move to Sunset4? Dave T thought yes, but Wes (chair of Sunset4) said "Don't assume so, yet. Keep working on it in Behave for now" Discovery Heuristic, Teemu Savolainen ------------------------------------- Presented slides. No discussion. draft-ietf-behave-nat64-discovery-heuristic Dave: If no objections, will start second WGLC FTP46, Simon Perreault ---------------------- Philip: Slide 4, is this stateless or stateful NAT64? Simon: Could be either Philip: If stateful, how does client initiate connection? Simon: Using NAT traversal Dave: As this is "v4 internet to v6 network", we can discuss it, but can't add any new milestones without rechartering. Philip: Haven't read doc, but if it is really a small enhancement to existing RFC, then shouldn't we just rev existing RFC? Dave: We need more people to read this before we can have an intelligent conversation. Please read and give feedback. LSN MIB, Simon Perreault ------------------------ Reinaldo: add mapping type volunteers to review: Dave Thaler, Reinaldo Penno, Julia Renouard SYSLOG NAT LOGGING, Cathy Zhou ------------------------------ Long discussion of what data should be logged, not specific to SYSLOG. Simon: in the CGN requirements document, we don't require specific information to be logged, and will remove from the next rev Tom Taylor: maybe cgn requirements should specify an information model, and leave data model for the another document Simon: cgn requirements is the wrong place for this Alain: there are cgns that don't log; also, not aware of syslog format docs for routers, etc Tom: there's a syslog document for PCN, but only that. Philip: Logging is a big thing that can slow down NATs. We do a lot in our implementation to give efficient logging. Worried about standardizing this. Not sure we need to standardize what is logged. Alain: customers have different requirements and regulations, so serious reservations about standardizing anything Reinaldo: "logging" means different things to different people Chris Donley: also need to consider amount of data to store; 33K connections per user per day is a lot of data to log, and syslog may be the wrong tool Tom: if someone does log, they need a vocabulary, and the document defines the vocabulary, so this is a toolkit for operators Doug Otis: we're a small company, and still generating terabytes of data per day, don't know who would use this or how Alain: 6302 says we must support law enforcement, so must store some data Reinaldo: I see value in standardizing the information model, then operators can plug them together Julia: different investigators request information in different formats, e.g. syslog, ipfix. We could have a doc that specifies general information requirements. Tiru: dime working group already has a way of polling the log (syslog, ipfix, radius), so can't standardize here Philip: agree that there should be a way to log this, but leave it up to vendors and operators to specify requirements. One can also use Radius for logging. I think we should say "A CGN should log", but not specify how. IPFIX, Reinaldo Penno --------------------- Presenter: Originally, we did an IPFIX specific doc. Then we created a general model. But the WG asked us to go back to IPFix specific. Cathy Zhou: If IPFIX is in charter, why is syslog not in charter? Dave Thaler: right now the charter says ipfix is in, but we're having a discussion about whether some charter items belong in other groups Dan: sunset4 chairs and behave chairs have not gotten together to hash things out Dave T: Good question. We need to figure out what will happen with these documents? Tina Tsao: ipfix and syslog need to get same priority Philip: Does IPFIX want to capture everything, or just s subset? Presenter: All mappings Philip: Then how are you handling the data volume? Presenter: IPFIX does not have to sample; it can log all data.