[09:56:49] --- bruce has joined
[17:35:39] --- ohm has joined
[17:37:27] --- andreas-b has joined
[17:38:32] --- SharonChisholm has joined
[17:38:44] <SharonChisholm> We are currently looking at the charter
[17:39:03] <SharonChisholm> Chairs - TBD, but there will be two
[17:39:26] <SharonChisholm> This will be in the ops area
[17:40:15] <SharonChisholm> same mailing list
[17:40:45] <SharonChisholm> changed text 'the data link and IP Layers"
[17:41:37] <SharonChisholm> want to dicuss milestone dates
[17:43:02] <SharonChisholm> hoping to get a charter approved in a month or so. certainly by the next ietf
[17:43:34] <SharonChisholm> there is a nanog coming up. might want to get charter approved by then so it can be discussed with the operators
[17:43:59] <SharonChisholm> comment - I like the charter ... it looks good
[17:44:11] <SharonChisholm> Next item ... framework document
[17:45:07] <SharonChisholm> www.port11.com/opsec/wg/framework-discussion.txt
[17:46:35] <SharonChisholm> (I don't know if that will work)
[17:46:54] <SharonChisholm> Major issues
[17:47:11] <SharonChisholm> BCP - rfc2026 sec 5, rfc 1818
[17:47:25] <SharonChisholm> definition of 'requirement'
[17:47:34] <SharonChisholm> review specific documents
[17:47:41] <andreas-b> above link seems to be dead
[17:48:15] <SharonChisholm> (link was more where he was picking up his stuff than somewhere he was advertising)
[17:48:34] <SharonChisholm> (there seems to be some security)
[17:49:20] --- Tom Phelan has joined
[17:49:50] <SharonChisholm> barbara - one comment ... examples of ingress/egress filtering. products had those capability, but practice might not have been used
[17:50:12] <SharonChisholm> barbara - differentiate ... used versus available
[17:50:21] --- sommerfeld has joined
[17:50:42] <SharonChisholm> answer - we will keep this in mind
[17:51:16] <SharonChisholm> barbara - need to understand when talking about stuff, which is it, does it exist widely in products today or does it not. It shouldn't become a stew of things
[17:51:42] <SharonChisholm> answer - we have a requiremetns section and an example section. We also have a warning section. That could give warnings when solutions are not available
[17:52:32] <SharonChisholm> pat - concerned with terminology. requirements are mostly 'you do this'. at the same time BCP has some specific terms. whether it is defined in my router is not a BPC. Whether there is a large group of operators using it ...
[17:53:53] <SharonChisholm> answer - in prep for this I did some reading on the term BCP ... section 5 of 2026 has some great text. there is a big of vagueness ... that is probably good so we can apply some common sense. we have some flexibility. if a wide range of service providers say we need to do 'x', maybe that is all it will take so long as it is possible, rather than if it is currently used.
[17:54:15] <SharonChisholm> someone - will the scope of consideration consider <something> security issues
[17:54:27] <SharonChisholm> answer - if you have specific issues you would like considered ,,, send them to the list
[17:54:45] <SharonChisholm> (jerry wilson was the person)
[17:55:33] <SharonChisholm> answer - the question was on requirements. what are the logging, aaa, in the next iteration these will be more like shopping lists. Document features that in some context will be essential for a secure operation
[17:56:19] <SharonChisholm> eliot lear - <discussion about internet standards> it is difficult to change a standard, so doing a BCP is the right thing
[17:56:29] <SharonChisholm> eliot lear - <something> hope you were not indending
[17:57:11] <SharonChisholm> answer - indending something similar as is in the draft - breaking out feature sets ... not as musts ... for large isp this is relevant ... for enterprise this is the relevant ... we received feedback that we didn't have enough profiels
[17:57:28] <SharonChisholm> eliot - service providers will want to pick and choose their requirements.
[17:58:14] <SharonChisholm> comment - when I read the initial version .. there is a collection of requiremnts. some are backed by reasoning ... from an understanding point of view it would be better to start with the problem, rather than the solution
[17:58:46] <SharonChisholm> comment - also looking at the threats ... I did not find much in yourdocument ... what do we need to do maintain continuity of service during an attack
[17:59:19] <SharonChisholm> comment - if we had somehow guiding document on what we want to acheive, what we want to guard against ... it would be much easier to understand which requirements we need
[17:59:37] <SharonChisholm> answer - there is somet of that in the header material as well as the framework ... let us know where we need more.
[18:00:09] <SharonChisholm> comment (new) - what is the definition of a secure network is defined in the document ... let us know what else is needed
[18:00:57] <SharonChisholm> comment (another new) - I was just skimming the document. from what I see, there are operational requiremnets for an operator. there is also requirements for a network element,. I don't know if these need to be in the same place.
[18:01:41] <SharonChisholm> comment - the other thing I wanted to ask ... if you come up with requiremnts are you going for a certified secure network or is it just recommendations
[18:02:09] <SharonChisholm> answer - the goal is to collect the wisdom of the operator community ... that can be input to other operators as well as to vendors.
[18:02:24] <SharonChisholm> comment - these operators are not tier 1 operators but also those below them
[18:02:33] <SharonChisholm> comment - those are up to date on this stuff
[18:02:44] <SharonChisholm> answer - this came out of a tier 1 operator ....
[18:03:19] <SharonChisholm> answer - we had been trying to list feature sets ... knob you might want to tune. not to give advice to operators (refering to his other point I think)
[18:03:39] <SharonChisholm> comment - suggest moving some of the network element requirements into routing groups
[18:04:05] <SharonChisholm> answer - that has been suggested ... consensus that this stuff is parallel ... going to be its own work
[18:04:28] <SharonChisholm> for those have read the framework ... are we covering the right areas
[18:05:08] <SharonChisholm> comment - we put into the framework a warning that it is not appropriate to mandate this stuff. it seems to me that we might want that same warning in our other documents
[18:05:45] <SharonChisholm> comment - the whole issue of will this be mandated by law ... it's a collection of knowledge ... that is what it is ... it's not the same as a set of requirements
[18:06:07] <SharonChisholm> answer - i agree .. the moment you say this is what you need there will be a case where it doesn't apply and people will ignore it
[18:06:55] <SharonChisholm> answer - a question i had ... a definition of what <> needs to be logged ... snmp poll ... sometime it needs to be logged. The question of how to you log. The question of what do you log needs some standardization ... that is something beyond what we have that we will want to add
[18:07:43] <SharonChisholm> comment (new) - not a big difference between small and large isps ... <examples> in the framework there is too much distinction ... backbone routers ... access ... might be a more useful distinction
[18:08:00] <SharonChisholm> answer - note your point ...
[18:08:16] <SharonChisholm> comment - log management might have different requirement for that
[18:09:06] <SharonChisholm> show of hands from people that when we become a working group, would we accept this as a working group document ... proceed with how many people have read this document
[18:09:26] <SharonChisholm> hands up - <smallish percentage>
[18:09:45] <SharonChisholm> of those we have read it ... if we have a working group soon ... would it be appropriate for this doc to be a wg document
[18:09:56] <SharonChisholm> <reasonable perscentage of that smallish percentage>
[18:10:06] <SharonChisholm> Next Agenda Item --------------------------------
[18:10:25] <SharonChisholm> Liaison and Other Efforts (Chris Lonvick)
[18:11:08] <SharonChisholm> IETF Liaisons http://www.iab.org/liaisons/index.html
[18:11:45] <SharonChisholm> workin in progress draft-baker-liaisons-statements-01.txt
[18:12:24] <SharonChisholm> other SDOs are very formal. they have these mechanisms already worked out
[18:12:39] <SharonChisholm> could call them denial of service attacks waiting to happen ... send lots of stuff
[18:13:22] <SharonChisholm> what does this mean for us? we should not ask for any liaisons until we are a working group
[18:14:02] <SharonChisholm> things we need to do before we ask for liaison statements wither other sdos
[18:14:12] <SharonChisholm> - identify specific efforts elsewhere
[18:14:24] <SharonChisholm> - if we send a liaison statement, need to be prepared for feedback
[18:14:35] <SharonChisholm> other operational security efforts
[18:14:49] <SharonChisholm> draft-lonvick-sec-efforts-00.txt
[18:15:37] <SharonChisholm> glossaries, SDOs, SDO efforts
[18:16:29] <SharonChisholm> feedback is appreciated
[18:16:54] <SharonChisholm> id intent - awareness
[18:17:16] <SharonChisholm> multiple opsec standards may result in - vendors not sure what to follow;
[18:17:26] <SharonChisholm> - purchasers unsure which best apply
[18:17:29] --- sakai has joined
[18:17:38] <SharonChisholm> - operators unsure which to follow
[18:17:52] <SharonChisholm> T1M1.5 sec effort
[18:18:03] <SharonChisholm> http://www.t1.org
[18:18:47] <SharonChisholm> look at proceedings from last meeting for his preso for more details
[18:19:25] <SharonChisholm> 3M150074
[18:19:52] <SharonChisholm> http://www.ansi.org (ANSI T1.276-2003)
[18:20:13] <SharonChisholm> The spec started in T1M1 and was published as an ANSI standard. ANSI has more power
[18:20:35] <SharonChisholm> T1 are US service providers, vendors and telcos
[18:21:13] <SharonChisholm> ... going into ITU-T -> into ITU-T SG4 Q 18
[18:21:27] <SharonChisholm> M.3016.0 TMN security overview
[18:21:45] <SharonChisholm> M.3016.1 security overview - Requirements
[18:22:03] <SharonChisholm> M.3016.2 TMN security overview - Services
[18:22:15] --- swb has joined
[18:22:23] <SharonChisholm> M.3016.3 - TMN security overview - Mechanisms
[18:22:35] <SharonChisholm> M.3016.4 - TMN security overview - Profiles
[18:24:08] <SharonChisholm> This stuff could get influenced by contributions from other member states since this is an internation organization and the previous versions were only the US
[18:24:25] <SharonChisholm> ...going back into ATIS (the parent body for T1)
[18:25:04] <SharonChisholm> stuff left over from ANSI T1.276-2003 -> alliance for telecommunications information solutions ->
[18:25:42] <SharonChisholm> ->work plan to achieve interop, implementable, end-to-end standards and solutions -> liaison statement to other SDOs
[18:27:11] <SharonChisholm> T1M1.5 (Security) ftp://ftp.t1.org/T1M1/ (missed rest of url)
[18:27:20] <SharonChisholm> security management system
[18:27:47] <SharonChisholm> ftp://ftp.t1.org/T1M1/NEW-T1M1.5/ (and more url that I didn't get)
[18:28:02] <SharonChisholm> packet filtering to prevent unwanted traffic
[18:28:17] <SharonChisholm> wrap up
[18:28:34] <SharonChisholm> previously sent email to the list with pointers to papers
[18:28:43] <SharonChisholm> working group should be aware of all this work
[18:29:28] <SharonChisholm> Dave Sidor (SG 4 Chair) if you participate in SG 4 he will make a lot of these specifications available to for the Q18/4. His email is in the stuff that chris had previously sent out
[18:30:06] <SharonChisholm> we all need to work together to collaborate
[18:30:09] <SharonChisholm> ------------
[18:30:23] <SharonChisholm> Outreach to Operator Communities
[18:30:39] <SharonChisholm> We had talked about speaking at NANOG
[18:30:50] <SharonChisholm> hoping to get that up at the upcoming nanog.
[18:31:20] <SharonChisholm> as far as other forms of outreach ... nanog is NA. We need similar organizations for the rest of the world
[18:31:44] <SharonChisholm> question to operators ... what would motivate people to get involved. come up afterwards and talk to me.
[18:31:54] <SharonChisholm> ----
[18:31:58] <SharonChisholm> Call for Volunteers
[18:32:13] <SharonChisholm> Look at the list of documents to be produced. Some have volunteers. Some Don't
[18:32:25] <SharonChisholm> In particular, network operators would be very valuable
[18:32:51] <SharonChisholm> we have draft of framework and something else ... comments would be great .... other bits of text would be good
[18:33:22] <SharonChisholm> barb - unfortable with us barreling down the road . interesting comments ... the comment of starting with the problem to solve rather than the laundry list
[18:33:37] --- swb has left
[18:34:19] <SharonChisholm> barb - another comment I've heard I liked ... I think it is important to separate out the features you want to impose on the devices (router requirements, for example, but applies to other types of equipment).
[18:34:36] --- Tom Phelan has left
[18:34:52] --- sakai has left
[18:34:56] <SharonChisholm> barb - it is important to understand what we are after. We have this document and we seem to be looking for a way to fast track them into an RFC. I don't think this is the right way to do this.
[18:35:14] <SharonChisholm> If there are practices ... how would you use these in an operational environment
[18:35:38] <SharonChisholm> answer - collect wisdom from operator community .. whether they want them in RFPs or just talking to their vendors ...
[18:35:56] <SharonChisholm> barb - that would be an informational RFC ... not a BCP
[18:36:18] <SharonChisholm> answer - you don't want to document the way to break a network
[18:36:23] <SharonChisholm> comment - oh yes you do
[18:37:07] <SharonChisholm> answer - people in general have a really good idea of what can be done when routers are compromised because we have done it by mistake. I don't know if you want to write a document that says how to take down the netork when you have compromised a router
[18:37:23] <SharonChisholm> answer - we have things that need to be deployed and implemented
[18:38:11] <SharonChisholm> barb - I am all for anything we can do to improve security in the networks. I'm just saying ... this is a BOF .. exploring what this is about and whether this should eb a working group. The framework document says to take the information documetn and break it into chunks
[18:38:43] <SharonChisholm> barb - are we listing requiremnts for internet devices and on the other side practices on how you would use these features, some of which exist. Need to ensure it is clear to the community.
[18:39:09] <SharonChisholm> barb - currently we have a soup or stew. It is not clean. It does not make it easy for the community to review
[18:39:24] <SharonChisholm> answer - the word requirement. it is not clear whether this should be called that or capability.
[18:39:36] <SharonChisholm> answer - it could just be a good idea to use it
[18:40:14] <SharonChisholm> comment - want to comment on the point of not documenting threats. if you don't documjent the threat you are not stopping the enemy.
[18:40:30] <SharonChisholm> answer - not saying we should not document it, but (not here)
[18:40:43] <SharonChisholm> steve B - we have a long history in this organization of documenting threats
[18:40:54] <SharonChisholm> steve b - the bad guys already understand all this
[18:41:09] <SharonChisholm> answer - we are listing why the requirement was put somewhere.
[18:41:49] <SharonChisholm> comment - we saw a listing of ISO organizxation working on security. organziation tends to have a mixed agenda. Tends to use this to push something else
[18:42:21] <SharonChisholm> comment - increasing robustness of the network ....
[18:42:42] <SharonChisholm> (that ISO was probably something else - SDO?)
[18:43:34] <SharonChisholm> comment - if we want to be precise in how we protect the network ... have to go into attack vectors. Many people use strawmans ... 'I know what we need to do'. Not doing the threat analysis - we will miss something
[18:43:42] <SharonChisholm> comment - <examples of requirements>
[18:44:06] <SharonChisholm> answer - those are important - it was decided that if we went that way the document would be too big.
[18:44:28] <SharonChisholm> answer - are you proposing additional stuff be put in the charter
[18:44:32] <SharonChisholm> comment - yes
[18:44:44] <SharonChisholm> answer - then write something up that we should also do threat analysis
[18:45:25] <SharonChisholm> comment (new) - we were trying to accomplish two things... have a BCP for operator and requirements for vendors. this has been a contensious point for a while. I don't think we have solved this. I think the group needs to decide
[18:45:56] <SharonChisholm> comment - my second comment is on threats analysis. the problem I have is creating yet another threats model document. It takes a long time and people lose interest.
[18:46:09] <SharonChisholm> comment- people wonder why we lose operators - they understand the threats
[18:46:29] <SharonChisholm> comment - <alternative to threat model definition>
[18:47:18] <SharonChisholm> comment (new) - we have a mix up between a couple things ... threats and best practice .... then comes vendor requirements. Three steps
[18:47:51] <SharonChisholm> answer - in operators who have worked on this document. They had specific threats in mind
[18:48:09] <SharonChisholm> answer - or they saw bad equipment in the lab that lacked basic features
[18:48:09] --- bruce has left: Disconnected
[18:48:33] <SharonChisholm> comment (new) - we do need to be careful about theoretical threat documents
[18:49:06] <SharonChisholm> barb - procedural question ... framework document question earlier ... I can't answer that question as the scope of the working group has not really been agreed upon.
[18:49:14] <SharonChisholm> barb - are we doing requirements for devices
[18:50:03] <SharonChisholm> steve b - yes. we had a meeting this afternoon ... the question of whether it was device requirements was raised by me. at some points in the charter this had been ambiguous. we changed the wording to make it clear it was devices in those places.
[18:50:57] <SharonChisholm> comment - then why don't we call it device security requirements bof? I thought the point was to clarify the operational securtity requirements. I think if we don't do that, we are missing an opportunity
[18:51:57] <SharonChisholm> answer - there seems to be three thigns that various people could do 1) Threat models; 2) Requirements for Devices; 3) If threat models and capabilities in devices, how would operators make use of these to mitigate against those threats
[18:52:36] <SharonChisholm> answer - I'm perfectly happy to work on 2) ... if people want to do 1) and 3) I'm willing to discuss
[18:52:54] <SharonChisholm> comment - we have an opportunity to get feedback on operational security considerations
[18:53:18] <SharonChisholm> answer - one question I have ... should we do anything about using these cabalities
[18:53:34] <SharonChisholm> answer - would changing requiremetns to capabilites .. does that help
[18:54:16] <SharonChisholm> barb - it's kind of the same thing. I want us to be clear to the community as to what we are doing. I think we should change the title. Be clear that what we are talking about is what you said. And be very clear
[18:54:38] <SharonChisholm> steve b - there is precident for IESG to request change in name before chartering
[18:55:08] <andreas-b> yo
[18:55:20] <SharonChisholm> comment (new) - I've heard the comment that we all know the threats. Actually, you all know some threats. It is precicely beccause it is hard that we need to do it.
[18:56:00] --- Tom Phelan has joined
[18:56:05] <SharonChisholm> answer - deliverying a device in 2004 without logging is broken ... < other examples> we need to capture that sort of thing
[18:56:52] <SharonChisholm> answer - my understand of Best Current Practice is that the current part matters. Current will change.l Same with threats, although those would be worst current practices. I would be afraid that we would send all that time on threats and then they would change
[18:57:12] <SharonChisholm> comment - we can set a limit to how much brainstorming we do
[18:57:26] <SharonChisholm> comment - there is always a bennefit to doing that brainstorming.
[18:57:35] <SharonChisholm> comment - you end up with insight that you did not have before
[18:58:32] <SharonChisholm> answer - speaking as individual .. if doing a threat model would not slow down the other work, then I would think it would be interesting to do. Or even if it only slowed it down a little bit. Is someone else already doing this? Otherwise we would not want to add it to the charter
[18:58:41] --- mallman has joined
[18:58:51] --- jis has joined
[18:58:51] --- mallman has left
[18:59:23] <SharonChisholm> comment (new) - if we do a threat model, propose we get started on that my defining what decide is a trusted <something>. Is the operating system on the router trusted for example?
[18:59:32] <SharonChisholm> comment - if we trying to look at too much. It is years of work
[18:59:45] <SharonChisholm> comment - what are our assumptions?
[18:59:57] --- Tom Phelan has left: Disconnected.
[19:00:18] <SharonChisholm> answer - time for polls. The way the charter is currently written - capabilities on devices ... how many thin resonable
[19:00:29] <SharonChisholm> yes - smallish percentage ; no a couple of people
[19:00:37] <SharonChisholm> if threat model
[19:00:58] <SharonChisholm> yes - smallish percentage ; no half the size of the previous bunch
[19:01:36] <SharonChisholm> barb - <comment around the poll>
[19:02:02] <SharonChisholm> elliot - my mother told me not to propose additional charter items without volunteers to work on items
[19:02:13] <SharonChisholm> <there were a few hands to agree to work on threat model
[19:02:28] <SharonChisholm> comment (new) - the threat model for what?
[19:03:11] <SharonChisholm> if we were to charter as a working group - how many people think we would have to add the advice to operatos - you must use these features
[19:03:22] <SharonChisholm> <small numbers, but more NOs)
[19:04:22] <SharonChisholm> comment - having difficulty with requirement, capability and best practice. I think they are all different
[19:04:53] <SharonChisholm> comment - is the third part a BCP? operational security?
[19:05:34] <SharonChisholm> steve b - this is the thrid BOF with this name. Won't disagree that the name is misleading.
[19:06:06] <SharonChisholm> steve b - this was always going to be knobs for boxes. The question is in addition to that, should there be an additional document on how to use those knobs to secure a network
[19:06:23] <SharonChisholm> <a bigger small number yes; a smaller number no>
[19:06:45] <SharonChisholm> steve b - if you want to describe how to use knobs, you need to know what the knobs are
[19:07:25] <SharonChisholm> tony - we are here to solve an engineering problem. Don't care about threat. want a practicle list of threats. If you know some, please let me know. Send them to NANOG
[19:07:56] <SharonChisholm> tony - we could end up with vendor bashing here. Tell us what the threats are.. what knobs are. let us worry about getting the vendors to deal with the threats
[19:08:31] <SharonChisholm> mike - I think we are taking this the wrong way around ... requirements from backbone which results in features for routers
[19:08:36] <SharonChisholm> steve b - chicken and egg
[19:08:58] <SharonChisholm> comment - are knobs in the future subject to IETF standardization
[19:09:07] <SharonChisholm> answer - that is why it is a BCP
[19:09:41] <SharonChisholm> comment - feauture set will change ... faster than you can revice a BCP
[19:10:02] <SharonChisholm> answer - there are two sections - requirements and implementations. expect requiremetns to be more stable
[19:10:14] <SharonChisholm> barb - not aware of BCP that is about capabiliites of devices
[19:10:31] <SharonChisholm> barb - they are more the people side of it or use of a features. Not a BCP for router requirements
[19:10:58] <SharonChisholm> steve b - the router requirements itself is pretty close. It predates the definition of BCP (I think)
[19:11:34] <SharonChisholm> steve b - this is not proposed standard . capabilities is less of a check list. trying for more general
[19:12:11] <SharonChisholm> dave - don't see it as conflict. important that we focus on the issues at hand. limit set of <> and tools.
[19:12:56] <SharonChisholm> comment - to follow up on Dave's comment, we in the ietf we specify a lot of protocols that have many features with SHALL, MUST, Etc. I don't see much difference ...
[19:13:19] <SharonChisholm> comment - if we were to attack from the egg and not the chicken .... that might be better
[19:13:29] <SharonChisholm> answer - you would be in favour of the operational BCP?
[19:13:39] <SharonChisholm> comment - I"m not saying, but it is one approach.
[19:14:17] <SharonChisholm> comment (new) - keep saying we want the operator input and we do device, it will turn into vendor bashing. We will lose the operator input
[19:14:40] <SharonChisholm> answer - in my reading of george's document, it does not read like a bashing document. Stuff we would like vendors to use.
[19:15:03] <SharonChisholm> answer - it is nice to have a list with an explanation for a feature. all service providers can use this and it all sounds the same
[19:15:23] <SharonChisholm> answer - vendor bashing would be inappropriate
[19:15:51] <SharonChisholm> comment - my comment is will it get finanlized in the working group,
[19:16:11] <SharonChisholm> answer - it should be what the operators want. Sure it should be possible though.
[19:16:38] <SharonChisholm> comment (new) - possiblity of multiple possible answers to a problem
[19:17:32] <SharonChisholm> comment (new) - won't the network operators vote with their wallet? If they really want it.
[19:17:45] <SharonChisholm> answer - they will hear back that they are the only ones who want a particular feature
[19:18:05] <SharonChisholm> comment (new) - want to create a BCP to enable voting with wallet
[19:18:31] <SharonChisholm> answer - if people describe thing the same way, they will be less likely to be told they are the only one
[19:19:15] <SharonChisholm> comment (new) - this rfc will show up on RFPs . The people who put it there won't understand it. it will show up on RFPs long after it is useful. This is not useful
[19:19:29] <SharonChisholm> answer - we would just put disclaimers in the document on how it is to be used.
[19:20:25] <SharonChisholm> brian - i got involved ... what I was looking for ... we need to have three firewall products as a vendor ... do they do things the same way ... that is what I was hoping we would get to here. I was hoping we would get to what is important and why
[19:20:37] <SharonChisholm> answer - that is there in the justification section
[19:20:57] <SharonChisholm> brian - that is the bit that might be getting lost here. There is an opportunity to educate the next generation
[19:21:36] <SharonChisholm> answer - also think that if the why in certain cases why the capability, it will help educate whether that capability makes sense in their particular case.
[19:22:09] <SharonChisholm> answer - one example about ocean storms. It doesn't apply in Banf. It didn't apply
[19:22:40] <SharonChisholm> answer - in breaking the document into pieces, we will examine the justification sections
[19:23:31] <SharonChisholm> Dave - need to reach a bit of conclusion on this stuff. Can we get an agree whether people agree
[19:24:02] <SharonChisholm> Tony - Do you folks agree that the primary purpose of this working group is to educate operators
[19:24:23] <SharonChisholm> answer - no. The primary purpose is to collect the wisdom of operators to share with other operators as well as vendors
[19:24:49] <SharonChisholm> Dave - discussion is going in all sorts of directions.
[19:25:13] <SharonChisholm> Comment - quick question on the definition of operators - ISP or ISP or enterprises?
[19:25:15] <SharonChisholm> answer - the latter
[19:25:56] <SharonChisholm> Answer - it is possible that the collective knowlesge of ISPs contains stuff that enterprise people don't know
[19:26:32] <SharonChisholm> Dave - could you put the goals on the screen again and ask the question of whether you need to emphase the educational stuff more
[19:26:52] <SharonChisholm> Answer - people should look at this charter
[19:27:26] <SharonChisholm> How may people think that what is up there is necessary and sufficient to chater?
[19:27:58] <SharonChisholm> <yes - smallish number; no - none>
[19:28:40] <SharonChisholm> answer - there seems to be more peopel who voted for sufficient ... even those people, do you want a few more sentences
[19:29:04] <SharonChisholm> Dave - type something in
[19:29:55] <SharonChisholm> "The working group will strive to gather collective knowledge of network operators for the purpose of educating other network operators and vendors."
[19:30:06] <SharonChisholm> comment - for clarfiication - what problem are we trying to solve
[19:31:07] <SharonChisholm> answer - how man y people tink this woud be a good addition
[19:31:15] <SharonChisholm> <smaller votiing - more in favour>
[19:31:56] <SharonChisholm> how many people think what we have here .. charter and documents would be useful if we ut the effort
[19:32:02] <SharonChisholm> smallish number .. yes. None no
[19:32:56] <SharonChisholm> comment - i think clarity of purpose is useful ... would it be fair to summarize .. this working group is going to do market reserach for product requirements.
[19:33:14] <SharonChisholm> comment - getting this knowelse for what purpose?
[19:33:59] <SharonChisholm> comment - is the intended auduance vendors or operators
[19:34:01] <SharonChisholm> answer - both
[19:34:49] <SharonChisholm> comment (new) - I think we are getting close. I got invovlved because we wanted to educate ... I was more thinking smaller ISPs and enterprises. I think they need the most education.
[19:35:12] <SharonChisholm> comment - want to know the BCP from the experts. strugling with current feature sets.
[19:35:37] <SharonChisholm> comment - who audience, problem to solve, who are are trying to educate
[19:36:21] <SharonChisholm> answer - the only comment I have about smaller devices and shops ... it will be useful. the problem I had in the previous document when I tried to widen scope. became unmanageble
[19:37:07] <SharonChisholm> sue - hoping at NANOG to have a BOF. I hope we will do requirements for vendors
[19:37:33] <SharonChisholm> answer - if we are all talked out ...
[19:37:55] <SharonChisholm> answer - one more show of hands ... how many people think we should proceed with chartering a workoin group base don what we have
[19:38:01] <SharonChisholm> smallish yes ... one sort of no
[19:38:38] <SharonChisholm> Dave - most people do want a working group. No agreement on exact goals . Need more work. I don't know if we will be able to finish now. close to closing time. Move some of this to the list
[19:38:52] <SharonChisholm> Dave - We need to think more about the educational aspects.
[19:39:16] <SharonChisholm> Dave - talk in smaller group of us
[19:39:32] <SharonChisholm> Dave - to come up with some text. really diverse opinions. We are really stuck
[19:39:41] <SharonChisholm> Answer - thanks everyone for input. For coming.
[19:40:09] <SharonChisholm> End of Session
[19:42:06] --- andreas-b has left
[19:47:53] --- jis has left
[19:48:04] --- ohm has left
[20:02:56] --- SharonChisholm has left: Disconnected
[20:20:58] --- SharonChisholm has joined
[20:31:42] --- SharonChisholm has left: Disconnected