[10:45:47] --- gmj has joined
[12:15:23] --- gmj has left
[14:16:09] --- wesh has joined
[15:03:36] --- wesh has left: Disconnected
[15:04:52] --- dperkins has joined
[15:21:18] --- LOGGING STARTED
[17:22:16] --- smb has joined
[17:30:20] --- gmj has joined
[17:30:28] <gmj> hey
[17:50:23] --- smb has left: Disconnected
[17:52:53] --- smb has joined
[17:54:41] --- SAH has joined
[17:54:53] --- SAH has left: Replaced by new connection
[17:54:54] --- SAH has joined
[17:58:45] --- bert has joined
[17:58:48] <smb> ross does introductions, agenda bashing, eliot lear is scribe (through smb's keyboard)
[17:59:01] <gmj> ok
[17:59:02] <smb> smb:
[17:59:19] <smb> unusual type of bof. draft-jones-opsec-03.txt
[17:59:31] <smb> origin is uunet security requirements doc
[17:59:54] <smb> randy and steve watched jones presentation at nanog, and decided the document would make a useful ietf doc
[18:00:00] <smb> went to the saag
[18:00:17] <smb> went through various reviews, and got to the iesg where it got 7 discuss votes and one abstention
[18:00:29] <smb> very bad sign.
[18:00:37] <smb> formed a panel to review the doc.
[18:00:40] <smb> they will present here
[18:00:46] <smb> then there will be comment
[18:00:55] --- ludomp has joined
[18:00:57] <smb> ross
[18:01:16] <smb> callon:
[18:01:36] <smb> "is there a problem?" are we in agreement that there is a need for such a doc?
[18:01:55] <smb> callon: should this document advance, perhaps with corrections?
[18:01:58] --- Bill has joined
[18:02:09] <smb> callon: what status should the document have?
[18:02:29] <smb> callon: -- if published roughly as is, or if published after substantial vetting by the ietf?
[18:02:48] <smb> callon: and how long do we think it would take to get the doc into a form appropriate to a BCP?
[18:03:11] --- admcd has joined
[18:03:16] <smb> callon: implication being that if published today it would probably go out as an individual informational
[18:03:35] <smb> callon: and one outcome is the informational followed by a BCP
[18:03:48] <smb> callon: based on amount of time estimated to complete
[18:03:54] --- dmm has joined
[18:04:00] <smb> callon: what about existing work?
[18:04:25] <smb> callon: is it obvious how to make use of the requirements, or do we need a framework doc as well?
[18:04:51] <smb> callon: is there a need for other documents based on different communities, such as SOHO or web service communities?
[18:05:16] <smb> callon: which returns us to what is the right venue to work on these documents?
[18:05:29] <smb> callon: is the ietf the right place? can we get operators to participate in the IETF?
[18:05:48] <smb> callon: mailing list is opsec@ops.ietf.org
[18:06:04] <smb> subscribe opsec-request@ops.ietf.org
[18:06:19] <smb> callon: we'll start with panelists
[18:06:28] <smb> fred baker
[18:06:53] <smb> fred: my take is that it addresses something rather different from what the ietf has called security
[18:07:08] <smb> fred: it doesn't talk about how to configure or set up ipsec, for instance
[18:07:35] <smb> fred: it comes to the ietf as a recommendation from uunet on how routers can be more useful from a security perspective to isps
[18:07:43] <smb> fred: i would like to see something along this line,
[18:07:54] <smb> fred: it provides good guidance to router vendors
[18:08:02] <smb> fred: i don't care whether it's a bcp or an informaitonal doc
[18:08:21] <smb> fred: i see fairly practical suggestions
[18:08:32] <smb> fred: by whatever means i'm interested in the suggestions
[18:08:53] <smb> pekka savola
[18:09:06] <smb> pekka: we operate a national and research document, and i've reviewed the doc several times
[18:09:20] <smb> pekka: this document presents very good ideas, and it should go forward in some form
[18:09:42] <smb> pekka: there is concern about using MUSTs and SHOULDs in a BCP, about what an inventor MUST and SHOULD do
[18:09:55] <smb> pekka: i don't see many problems there myself
[18:11:38] <smb> pekka: perhaps the doc should be more of a list of features that operators should ask for, as opposed to a specification to vendors
[18:12:36] <smb> pekka: vendors could then indicate what sections could be implemented
[18:12:47] <smb> dave meyer (at mike): agrees with pekka
[18:13:02] --- azinin has joined
[18:13:10] <smb> dmm: doc has several instances in which the document reduces to "one MUST not write bugs"
[18:13:19] <gmj> gmj on jabber notes the profiles mechanism is intended to facilitate that.
[18:13:42] <smb> steve bellovin: counters are accurate from a security perspective
[18:14:08] --- tomphelan has joined
[18:14:27] <smb> correction: smb: counters are IMPORTANT from a security perspective
[18:14:41] <dmm> definitely
[18:14:41] <smb> Eliot: george jones says on jabber...
[18:14:58] <smb> pekka: responding to george, there are two problems with profiles...
[18:15:10] <dmm> the question was more around whether the 2119 language is the right way to express this
[18:15:23] --- sommerfeld has joined
[18:15:44] <smb> first, when you say you do sections 1,2,3 whatever, it's a matter of what is conforant behavior as to what the vendor has actually been implemented between MUSTs and SHOULDs
[18:16:12] <smb> pekka: second, there has been some pushback about having IETF-blessed minimum secure routers.
[18:16:42] <smb> pekka: perhaps two documents are appropriate, one with default profiles or discussion of tradeoffs
[18:17:00] <smb> smb: one informational, and a set of BCPs for profiles??
[18:17:08] <smb> pekka: yes
[18:17:58] <gmj> I think my fundemental position/goal is alligned with Fred. I'm not into quibbling about form, but into getting the ideas into a form where they can be used/requested/implmented.
[18:18:09] <smb> pekka: notes the community pushback about whether appropriate for ietf to do this...
[18:18:20] <smb> ross: we did this in the ietf some time ago
[18:18:37] <smb> ross: resulted in a lot of gray hair based on lots of negotiation
[18:18:43] <smb> ross: but there is precedence for the ietf to do this
[18:19:13] <smb> pekka: critical is whether MUSTs and SHOULDs will cause excessive amount of time in negotiations
[18:19:35] <smb> pekka: so creating feature lists would provide a simple way forward
[18:19:50] <smb> Dan Romanescau
[18:19:57] <smb> dr: document badly needed
[18:20:14] <smb> dr: we have customers already referring to this document
[18:20:28] <smb> dr: this proves that such a reference from the IETF is both needed and taken quite seriously
[18:20:45] <smb> dr: i've made comments, some of which have been addressed by the author of the document
[18:21:21] <smb> dr: we need to be careful about making a distinction between service provider and enterprises
[18:21:31] <smb> dr: don't try to put everything in one document
[18:21:38] <smb> dr: create a separate doc for enterprise networks
[18:22:00] <smb> dr: second point
[18:22:19] <smb> dr: the document in its form right now sometimes says too much, and in some cases it says less than it should
[18:22:34] <smb> dr: says too much about op reqs not connected to security
[18:22:37] <gmj> gmj notes that at one point the scope was expanded beyond large ISP networks...it became unmanagably large.
[18:22:50] <smb> dr: requirements for rs 232, for instance
[18:23:12] <smb> dr: doc should be more focused
[18:23:57] <smb> eliot: interjects george's comments
[18:24:11] <smb> dr: the more focused, the more chances of success
[18:24:19] --- jhutz has joined
[18:24:31] <smb> dr: not sure about format
[18:24:41] <smb> dr: would like a focused fast track process
[18:24:56] <smb> dr: host requirements and router requirements are valuable documents in the industry
[18:25:05] <smb> dr: this is an opportunity for a long lived process
[18:25:35] <smb> dr: editing line by line is a very valuable process, but a good focused document shipped earlier would be fine too
[18:25:54] <smb> dr: it would be wiser to start with an informational document earlier and perhaps do a bcp later
[18:26:09] <gmj> gmj agrees with DR. This should be a process, the start of a discussion.
[18:26:33] <smb> dr: coming directly as a bcp originated by one author might in fact have less impact
[18:26:48] <smb> dave harrington
[18:26:56] <smb> dh: i come from the management area
[18:27:05] <smb> dh: my impression is that this is a very valuable document
[18:27:17] <smb> dh: had to hold my engineers back because it wasn't ready yet
[18:27:31] <smb> dh: very valuable doc, but the doc requires thorough review
[18:27:45] <gmj> One idea that was floating earlier was that the entire doc could be a "shopping list" which *each customer* could pick items from.
[18:27:45] <smb> dh: publish sooner as an informational, and then follow it up as a bcp
[18:28:07] <smb> dh: concerned about language and use of RFC 2119 MUSTs and sHOULDs
[18:28:48] <smb> eliot: george says
[18:28:59] <gmj> *everything* would be a SHOULD or MAY with each customer filling in the MUSTS.
[18:29:08] <gmj> not very strong
[18:29:13] <smb> dh: i would be very concerned about customers cherry picking feature sets
[18:29:25] <gmj> lots of responsibility on each customer to do lots of thinking.
[18:30:10] <smb> dmm: agrees with what has been said by others
[18:30:19] <smb> eliot: george says...
[18:30:31] <smb> ross callon
[18:30:58] <smb> ross: agrees with fred that this document covers areas that need to be covered to make internet infrastructure more robust against attack
[18:31:11] <smb> ross: this is a useful direction
[18:31:35] <smb> ross: if it's published as is, it should be informational. lots of good points, but a few things one could question. not quite ready for BCP.
[18:32:11] <smb> ross: i've changed my opinion in this session that it might actually take as long as a year to make a BCP based of concerns raised
[18:32:30] <smb> ross: nobody answered how these capabilities would be used. i agree with separation of enterprise and service providers
[18:32:40] <smb> ross: i don't know if we need a framework to show how these features would be useful.
[18:33:01] <smb> ross: i'm not sure about SOHO or servers. if nobody volunteers to do the work it won't happen.
[18:33:06] --- ludomp has left: Lost connection
[18:33:06] --- admcd has left: Disconnected
[18:33:20] --- kenh has joined
[18:33:31] <smb> ross: a better job longer term seems to indicate a working group
[18:33:34] <smb> open mike
[18:33:43] <smb> paul hoffman
[18:34:10] <smb> ph: it's always terrible in the ietf that if we don't do it someone else will. someone else is doing this work. there was a national summit by beurocrats.
[18:34:26] <smb> ph: it will not be of the quality of what we do when it comes out later
[18:34:50] <smb> ph: we should be concerned if we let folks whose job it is to sell but not implement write this doc
[18:35:00] <smb> ph: this is what is happening elsewhere
[18:35:17] <smb> ph: we shouldn't do anything lower level than enterprise, and even enterprise is questionable
[18:35:27] <smb> ph: we do a poor job on SOHO advice
[18:35:42] <smb> ph: we do somewhat reasonably with very intelligent enterprise operators, but that's about it.
[18:36:01] <smb> ph: so i vote for one document that is aimed at core operators
[18:36:02] <gmj> gmj notes that getting active operator involvement has been one of the biggest goals and biggest frustrations at this process. Half seriously: if you want operator involvment, hold the WG @ NANOG.
[18:36:06] --- dperkins has joined
[18:36:20] <smb> ph: vendors tell customers how to read these sorts of doc
[18:36:27] --- AWGY has joined
[18:36:52] <smb> eliot: george says...
[18:36:54] <smb> chris lonvick
[18:37:19] <smb> cl: t1.276 has gone out of the t1 ANSI commitee, and is now in the ITU SG3.
[18:37:30] <smb> cl: it has different roles, including requirements OF operators
[18:37:35] <smb> cl: very serious telco slant
[18:37:50] <smb> cl: i would like to see this document used to balance that document as a contribution to that process
[18:38:07] <smb> cl: i think that overall a working group effort to look at the "punch list" would be a good thing.
[18:38:27] <smb> smb: are the ANSI/ITU concerned with procedures as well as features?
[18:38:31] <smb> cl: yes
[18:38:38] <smb> smb: should the ietf go there as well?
[18:38:49] <smb> cl: haven't really formed an opinion yet, but probably not
[18:39:13] <smb> cl: but it would be good for ietf and nanog participants looking at the work going on in ANSI/ITU
[18:39:15] --- ludomp has joined
[18:39:23] <smb> eric gray
[18:39:53] <smb> eg: it's open ended if we ask that requirements are well understood, but i don't get the sense that we have consensus
[18:40:17] <smb> eg: rfc 2119 doesn't apply to informational drafts
[18:40:24] <smb> bill sommerfeld
[18:41:03] <smb> wesommer: clarifying question to ph: don't target to enterprises/SOHO, i think it would be useful for vendors to have something building boxes for that space so that they get the defaults right
[18:41:18] <smb> ph: yes it would. it is not clear it should come from the ietf or from this group
[18:41:28] --- david has joined
[18:41:29] <smb> ph: if we had a working group we could add this to the charter...
[18:41:53] <smb> ph: vendors would like something that is very very simple, but that's not what this is and that's a good thing because core routers are not simple
[18:41:59] <smb> scott hollenbeck
[18:42:20] <smb> sh: needs a history section discussing document's origin, and it should be an infomrational document
[18:42:24] <smb> david blakc
[18:42:29] <smb> correction: david black
[18:42:46] <smb> db: with suitable disclaimers it's okay to use RFC 2119.
[18:42:55] <smb> db: with a little more soak time this could be a BCP
[18:43:17] <smb> db: on RFC 2119, add some words to get an informational out, and then remove them when it goes BCP
[18:43:33] <smb> smb: i would like to poll this room on a few questions
[18:43:47] <smb> smb: should this document be published?
[18:44:10] <azinin> pseudo-mice: If we (the IETF) want to take a stance on this (rather than simply collect ideas floating around), it has to be a BCP, IMO
[18:44:19] <smb> correction should the document be published in substantially its current form?
[18:44:23] <azinin> correction: pseudo-mic
[18:44:24] <smb> consensus: yes
[18:44:34] <smb> smb: who wants it to be BCP?
[18:44:41] <azinin> count me in
[18:44:48] <smb> smb: strong consensus for informational
[18:44:48] <david> I would prefer INFO
[18:45:21] <smb> dh: george wrote two docs. you could pull out controversial issues and make one a bcp
[18:45:27] <smb> jonathon rosenberg
[18:45:55] <smb> jr: would there be confusion in the industry if we did an informational and then go to BCP?
[18:45:57] --- jhutz has left: Lost connection
[18:45:59] <smb> smb: i don't think so
[18:46:03] <smb> jr: forget i asked
[18:46:25] <smb> smb: next question: do we want follow-on docs?
[18:46:31] <smb> smb: strong consensus for yes
[18:46:38] <smb> smb: do we want a working group?
[18:46:43] <azinin> yes
[18:46:44] <smb> smb: strong consensus for yes
[18:46:53] <smb> smb: what sort of docs do we want to deliver?
[18:47:26] <smb> smb: do we want general strategy to be list of features in one doc and a separate set of profile docs?
[18:47:41] <smb> smb: not a lot of opinion, and only a small majority
[18:47:44] <smb> fred baker
[18:48:16] --- dinakar has joined
[18:48:31] <dperkins> You need "forward looking" documents in addition to setting up existing devices.
[18:48:32] <smb> fb: as rfc 1812 as that started out, jim forster got 300-400 experts in the room and got some fairly large amount of text that took a long time for others and fred to make it readable
[18:48:54] <smb> fb: if we were to do it again, it would take 10-20 docs., and not one.
[18:49:06] <smb> db: keep it on focused statements on focused issues
[18:49:19] <gmj> gmj suggests framework, series of reqs docs (what's needed), companion how-to-now-BCPs for each platform
[18:49:26] <smb> smb: so you're suggesting much smaller chunks
[18:50:02] <smb> fred: yes
[18:50:06] <smb> fred: !!
[18:50:31] <smb> cl: network reliability and interoperability council work may prove interesting
[18:50:37] <smb> smb: who likes fred's idea?
[18:50:52] <smb> smb: strong consensus from a small number of people
[18:50:56] <smb> pekka
[18:51:23] <smb> pekka: not sure we could find reasonable scenarios, so that might be a considerable task. we should analyse this question more first
[18:51:32] <smb> smb: yes, it is indeed a hard questions
[18:52:01] <smb> smb: it was premature to have a room full of people try and draft a charter. we need to discuss this more on the mailing list but...
[18:52:30] <smb> smb: i hear that this is improtant, and that we need to get involved, and we need to work with other documents, but it's not going to be easy.
[18:52:48] --- tomphelan has left: Disconnected.
[18:52:53] <smb> dave harrington: i have one concerned about fred's approach
[18:53:12] <smb> dh: we need to make sure that the pieces fit together properly, so a framework is appropriate
[18:53:16] <smb> fred: i agree
[18:53:22] <smb> richard gravemen
[18:53:29] <gmj> gmj agrees.
[18:53:53] <smb> rg: how far away are we?
[18:54:39] <smb> smb: all iesg evaluations are on line in the public tracker, and look for the web ballot. this will provide you with concerns iesg members have
[18:54:59] <dperkins> Have people seen the document from Juniper: http://www.juniper.net/solutions/literature/app_note/350013.pdf
[18:55:27] <Bill> https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1200&filename=draft-jones-opsec
[18:55:41] <smb> eliot: ross is now navigating to that site. people online should go to http://datatracker.ietf.org/dpublic/pidtracker.cgi
[18:55:51] <smb> search draft-jones
[18:56:06] <smb> click on detail for first one, which is bcp
[18:56:08] <Bill> my url gets you directly to where steve is navigating to
[18:56:18] <smb> click iesg "available"
[18:56:34] <smb> Here are the votes
[18:57:16] <smb> eliot: do you want to ask ads here to discuss their comments?
[18:57:33] <smb> smb: many of the comments have already been addressed and there will be a new version out
[18:57:48] <smb> that's it. we're adjourned. operators please provide input!
[18:57:50] --- dmm has left
[18:58:00] --- SAH has left
[18:58:01] --- AWGY has left
[18:58:51] --- kenh has left
[18:58:54] --- david has left
[18:59:11] --- ludomp has left
[19:00:37] --- azinin has left
[19:02:17] <smb> Eliot, thank you for acting as scribe.
[19:02:48] <gmj> smb, plz chat
[19:03:33] <smb> hang on -- give me a few minutes. I sent you a private note.
[19:03:41] --- sleinen has joined
[19:03:58] --- Bill has left
[19:04:36] --- dinakar has left
[19:05:02] --- smb has left
[19:05:44] --- bert has left: Disconnected
[19:06:14] <dperkins> Why is the meeting over at 10 instead of 11:30?
[19:06:33] <gmj> people were done ?
[19:11:12] --- AWGY has joined
[19:32:30] --- gmj has left: Logged out
[19:33:30] --- sleinen has left
[19:55:05] --- alexeymelnikov has joined
[19:57:01] --- alexeymelnikov has left
[20:00:52] --- ludomp has joined
[20:02:59] --- ludomp has left
[20:05:10] --- JACK has joined
[20:05:44] --- JACK has left
[20:07:49] --- AWGY has left
[20:38:17] --- dperkins has left