The Ops Area Working Group met between 1520 and 1720 on July 24, 2007 minutes by Al Morton and George Jones with help from the jabber log 1. welcome & agenda bashing Chairs 10 min 2. introduction to WG ADs 15 min Ron's take on the purpose for the WG: deals with work items too small to be a working group, work that touches multiple working groups and it's a catch-all for all area work may emerge that there's support for and needs a home. 3. Quality Measurement Requirements for Tunneling Protocols: Kikuchi Yutaka (total: 20 min.) draft-kikuchi-tunnel-measure-req-01.txt Presentation covered the background on why this is needed and response to comments from the previous meeting. There was also a new draft: definition of the parameters that IPPM was alerted to. Lots of animated examples Al Morten: It looks like loss count is incremented/double counting/mis-classifying packets that arrive late. Some applications are more forgiving than others of late arriving packets. Look at RFC4737 Scott Bradner: RFC2119 added to this version (MUST, SHOULD....). It may not be a good idea to use 2119 language in this document. It's aimed at interoperability. IPPM has defined a number of these metrics. You might want consider pointing at those definitions instead of defining your own. We should have more discussion. You should look at it again. Ron Bonica: How do you see this being deployed in an ISPs network? Once in a while or all tunnels all the time? - Will send to list Scott Bradner - you are inserting sequence numbers, this isn't strictly passive, be careful with the word choice. - Will send to list 3. Guidelines for Considering Operations and Management of New Protocols - David Harrington draft-harrington-operations-and-management-01.txt Moving away from SNMP & MIB modules as "the" management protocol, and looking into what else is needed in the Long Term. Harald Alvestrand: Do you define management in your document? David Harrington: No. Harald Alvestrand: I probably won't be able to understand your document then. Dave Myer: add ops section ? David Harrington: The draft will give documentation guidelines to address manageability, but not a new "Considerations" section - IESG does not want that now "An SNMP MIB is not always the right answer". A lot of what this document is about is getting people to think about the problem rather than just writing a MIB because they have to." Still trying to organize the document. I haven't defined "operations" or "management". There is a lot of redundancy. There have been requests to eliminate. Requests for strong recommendations about what not to use. "SNMP MIBs are a casually designed relational database" "We need to make sure this doesn't become something that causes every protocol to take two years to finish" RFC 3535 .... lots cut and pasted into this document. Volunteers to help. Sharon, Alan, ???, David Kessins Scott Bradner: This document is in the WG charter. Sharon Chisholm: I think this document covers two different topics and needs to be divided. Changing paradigm and designing protocols are very different. 10 people or so have read document. Wes Hardaker: I will agree to send in comments. Topic seems somewhat nebulous. Try hard not to lock yourself into the current moment....stick to more generic advice. Different protocols work well for different layers, you have to consider how they will be deployed...COPS-PR is good for situations where it is used. Sharon Chisholm channeling David Perkins: There were some items not included in 4181 due to cut off for publication. Where will these go? Some of the things that went in were too nebulous. Dan : This document is not a revision of 4181. Not guidelines for management protocol design. Not new network management framework for IETF. Role of the document is to provide guidelines for people who design management protocols or work in other IETF areas on how a protocol will be managed. Example, need to consider transition between 2 versions of a protocol. I see many documents that seem to have given no thought to deployment, version transition, etc. Other simple questions: how will this affect traffic in the Internet. Harald Alvestrand: Read the document during the meeting, very useful BUT IETF has only been successful in management of devices, ITU-T has a broader definition of mamangement - Service management. DH: could you send me suggestions? Andy - agrees with Sharon to split the draft. Move docs through IETF faster. He's in favor of the checklist approach to verifying manageability. 4. RadSec Version 2 - A Secure and Reliable Transport for the RADIUS Protocol: Stefan Winter (total: 15 min.) draft-winter-radsec-00.txt RadSec on one slide (2) Two implementations exist and interoperate (slide 3) Made a case for Shared Secret independence (5) All the things they are trying to do are done by DIAMETER, but no implementation meets their needs. Plan is to submit this as INFO on individual submission track. Questions: What do we think? Does it fit in OPS and Mgmt Area WG? Dan Romanescu: This will be an independent submission FYI document? Stefan Winter: yes. Dan Romanescu: Are you submitting this document to the WG for consideration? Stefan Winter: Yes, if possible. Dan Romanescu: Will you be presenting this ID at the radext WG also? Stefan Winter: yes ?? - Course of Action (Independent submission or other?) Would you prefer standards track? - Stefan Winter: yes ?? - This clearly constitutes an Experimental RFC. Scott Bradner: Please let the list know what happens at radext, it is too early to tell if this topic is one that this WG should take up. 5. ADDITIONAL Talk by Sharon Chisholm: Alarms in Syslog. draft-gerhards-chisholm-syslog-alarm-00.txt Proposes to add Structured Data (SD) parameters, severity mapping to syslog. Introducing an optional SD-alarm - Motivation is Severity Mapping, need to map between ITU Severity and Syslog. There are some outstanding issues. This falls outside the existing Syslog effort's charter. Andy - Syslog WG looked at this and did some work on it, but won't complete it? Dave Harrington: The syslog WG is in the Security Area and was created to deal with security issues in network logging, it was not designed to do data molding. Security needed standard message format. This is one that many but not all agreed was useful. After 5 years of work, we're trying to get things published. This was one of many areas that were not directly related security. Therefore decided to remove from the document so we could move it forward. WG had real tendency to loose focus. Request to take this up - Scott Bradner: How many feel that this would be a good topic for this working group? There was general support that this was in scope and no opposition. Dave Harrington: The Syslog WG does believe that this is useful work. If you're going to take up syslog data modeling here, you need to get the syslog implementers to participate here. After 5 years, we finally agreed on what was common in syslog: the first 8 bits. There are people interested in doing syslog data modeling, extending SDs. There are lots of WGs groups dealing with logging. Might be worth starting a logging WG. ?? There might be interactions with the "notifications" and or "biff BOF" work in the APPS area Dan Romanescu: People feel unsure about charter. You (WG) have to decide if you want the work. The poll was quite obviously in favor of accepting, but needs to be validated by mailing list. SOB: I'm reluctant to evaluate support for something people have not read. Lets discuss it on the list