From inacio@cert.org Thu Aug 1 00:22:41 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6632C21F9D1E for ; Thu, 1 Aug 2013 00:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osCvimv4t7Bl for ; Thu, 1 Aug 2013 00:22:36 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5716421F9D65 for ; Thu, 1 Aug 2013 00:22:36 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r717MXdn016177; Thu, 1 Aug 2013 03:22:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1375341753; bh=NEptRMOlhgjL4ho8Pcu7NJtlbmsIXMboF82VleCQ248=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=RNryIerZ95vPR+PSuOkWLP3as/ga3LTtFOhTJB+G+vr5K7H/nFvXMmKZWYAqonT/b lLw6e/adF2vDJUuG39O28bdz7nT2zoFvxKeySQP0UEQMHmf8saeiirtzAE4cDSJI3B D/UuL8M/5ymIe3zlIKp2PtfBl5TDK5LxdlucHDFY= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r717Mfqx024606; Thu, 1 Aug 2013 03:22:42 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 03:22:31 -0400 From: Chris Inacio To: Adam Montville Thread-Topic: comments on draft-waltermire-sacm-use-cases-05 Thread-Index: AQHOjjqfNIe9Y1K/g0uKHDeCZjagz5l/jivwgAA+0eCAAGlhgA== Date: Thu, 1 Aug 2013 07:22:31 +0000 Message-ID: <4AE532C8B0B4B548AF47570D250D817414206BA4@marathon> References: <4AE532C8B0B4B548AF47570D250D8174142067DC@marathon> <05BCCEB107AF88469B9F99783D47C1D673B2CF@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D673B2CF@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.100.119] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] comments on draft-waltermire-sacm-use-cases-05 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:22:41 -0000 -- Chris Inacio inacio@cert.org On Aug 1, 2013, at 7:10 AM, Adam Montville = wrote: >=20 >=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Stephen Hanna >> Sent: Wednesday, July 31, 2013 6:38 PM >> To: Chris Inacio; sacm@ietf.org >> Subject: Re: [sacm] comments on draft-waltermire-sacm-use-cases-05 >>=20 >> Chris, >>=20 >> I hope you won't mind if I piggyback with a few comments of my own on th= is >> document and on your very good comments. >>=20 >>> Endpoint / Asset : we should either discuss or acknowledge virtual >>> machines (read virtual assets?) and how they should be handled here. >>=20 >> I agree. Virtual machines were intended to be included in the RFC 5209 >> definition of endpoint. However, that's not entirely clear from the text= of >> that definition. It was explained obliquely later in RFC 5209. I suggest= that we >> append the following sentence to the second paragraph in the endpoint >> definition in draft-waltermire-use-cases: >>=20 >> Virtual devices (e.g. VM images) are also considered to be endpoints. >=20 > Is this really needed? To me, a VM can have an IP address, and that's co= vered. I guess it doesn't matter either way, but if examples start becomin= g the spirit of the definition, then we're going to have a long list of thi= ngs as technologies evolve. Toasters? I think it matters, mostly because of use cases that include asset tracking= . There are a bunch of obvious other points where VM's need slightly speci= al consideration =96 but it isn't clear to me from various statements in va= rious documents that VM's are as top of mind as they might need to be. From david.waltermire@nist.gov Thu Aug 1 05:02:26 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F3321F9C59 for ; Thu, 1 Aug 2013 05:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNKyc94jiVB4 for ; Thu, 1 Aug 2013 05:02:17 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0195C21F85E3 for ; Thu, 1 Aug 2013 05:01:40 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 1 Aug 2013 08:00:42 -0400 Received: from wsget2.nist.gov (129.6.13.151) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 1 Aug 2013 08:01:12 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 1 Aug 2013 08:01:04 -0400 Received: from na01-by2-obe.outbound.protection.outlook.com (207.46.163.237) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 1 Aug 2013 08:01:11 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB037.namprd09.prod.outlook.com (10.255.211.139) with Microsoft SMTP Server (TLS) id 15.0.731.16; Thu, 1 Aug 2013 12:01:06 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.53]) with mapi id 15.00.0731.000; Thu, 1 Aug 2013 12:01:06 +0000 From: "Waltermire, David A." To: Chris Inacio , "sacm@ietf.org" Thread-Topic: [sacm] http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 comments Thread-Index: AQHOjh/BDH7WKqJPk0SCym8hNOZlj5mAFji4 Date: Thu, 1 Aug 2013 12:01:06 +0000 Message-ID: References: <4AE532C8B0B4B548AF47570D250D817414205186@marathon> In-Reply-To: <4AE532C8B0B4B548AF47570D250D817414205186@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:df8:0:16:68fd:15a3:d64b:2a96] x-forefront-prvs: 0925081676 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(51444003)(54356001)(47446002)(74876001)(33646001)(4396001)(16406001)(50986001)(76576001)(54316002)(83072001)(15202345003)(56776001)(56816003)(81342001)(19580385001)(69226001)(47976001)(63696002)(77982001)(74366001)(19580395003)(74316001)(80976001)(83322001)(76482001)(31966008)(80022001)(76796001)(51856001)(74706001)(74662001)(220493001)(65816001)(49866001)(79102001)(59766001)(74502001)(53806001)(19580405001)(46102001)(76786001)(77096001)(81542001)(47736001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB037; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:2001:df8:0:16:68fd:15a3:d64b:2a96; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 comments X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:02:27 -0000 Comments inline marked [daw].=0A= ________________________________________=0A= From: sacm-bounces@ietf.org on behalf of Chris Inac= io =0A= Sent: Wednesday, July 31, 2013 8:57 PM=0A= To: sacm@ietf.org=0A= Subject: [sacm] http://tools.ietf.org/html/draft-waltermire-sacm-architectu= re-00 comments=0A= =0A= I think the architecture draft would be helped TREMENDOUSLY by defining som= e terminology and using it to describe the intents of the architecture. By= having everything be defined as "DF #", it isn't very descriptive. It doe= sn't have to be named in any form that implies using any particular solutio= n (obviously, that would be bad) but by defining an architecture, you are e= ffectively splitting the problem into (hopefully) manageable components wit= h defined tasks.=0A= =0A= Maybe splitting terminology out of the use-case doc and into a separate doc= so that everything can use it (and for easier reference in the future.)=0A= =0A= [DAW: I see that adoption of the use case document as a WG document is on t= he agenda for a consensus call. If concesus is confirmed on the list, could= we use the use case document as this reference?]=0A= =0A= Additionally, since we are the IETF, maybe we want to call the DF's protoco= ls - it's kind of our bread and butter. :)=0A= =0A= [daw: +1. I'm happy to make that change if others agree. ;-)]=0A= =0A= Second general comment, I understand the goal of the document/architecture = being such that an we could use a passive/active separate evaluator to crea= te information about a - but I think that's hard to discern from the= architecture. Second, from the architecture, it's hard to discern that th= e goal is to evaluate a . I'm using , the charter uses endpoin= t. Can we identify what that is - because I'm not so sure. Does that incl= ude a manageable network switch? A printer? A laptop? What if the printe= r runs Windows?=0A= =0A= [daw: A few questions/comments:=0A= =0A= - That is the intention of the "sensor" component of the architecture. It = can make observations about posture using various mechaisms (e.g., remote A= PI calls, local API calls, passive analysis, network management protocols, = etc.). This is not very clear in the current draft. I'll address this in t= he next revision. Some of this confusion is centered around using the term = "sensor". Would "collector" be better? Any ideas for other terms to use ins= tead?=0A= - We need to address terminology. I can either reference a seperate termin= ology draft, the use case draft, or embed used terms. Any thoughts on what= would be best?]=0A= =0A= RFC5209 (NEA requirements) defines endpoint as:=0A= =0A= Endpoint - Any computing device that can be connected to a network.=0A= Such devices normally are associated with a particular link layer=0A= address before joining the network and potentially an IP address=0A= once on the network. This includes: laptops, desktops, servers,=0A= cell phones, or any device that may have an IP address.=0A= =0A= Is that the intended scope for SACM? (It's copied into the use cases, and = references 5209 there, that way.)=0A= =0A= [daw: yes. This is the intent of the draft. I'll address this in the next r= evision.]=0A= =0A= The Controller:=0A= =0A= The controller receives data collection tasks? From whom, where?=0A= =0A= [daw: The evaluator is intended to dispatch collection tasks for posture in= formation it needs for evaluation that cannot be retrieved from the data st= ore. This is used to collect up-to-date or ad-hoc data as needed.]=0A= =0A= In the LMAP working group, derived from the IPPM working group (mostly well= aligned to the broadband forum) the terminology in use is Instructions and= Reports. From that paragraph, I would be, I imagine the controller as an = intelligent MEDIATOR (stealing terminology from IPFIX) which can be inline = to sensors and understands the sensor & evaluator infrastructure such that = it can take complex tasks and allocate them appropriately - and then combin= e the results?=0A= =0A= Is that the intention?=0A= =0A= [daw: Yes. The controller is a request dispatcher for sensors (and potentia= lly other controllers). It knows what information can be collected from whi= ch sensors for a single or a collection of endpoints. Using this informatio= n it will parse out tasking to individual sensors and will combine the resu= lts. I'll add more detail to address this in the next revision.]=0A= =0A= If I turn that into reality, then I might have something like:=0A= =0A= And passive asset/vulnerability device at the border, and IDS at the border= , a active scanner inside the appropriate network segment, some host based = agents able to send back configuration status, and the software configurati= on system. (Product wise, if it helps people, think: passive inventory:Te= nnable PVS, active scanner: Nmap/metasploit, host agents: McAfee ePolicy Or= chestrator/End Point Protection, software config management: Windows AD.)= =0A= =0A= At some central console (no idea where / if that fits into the architecture= ) I send a task (n=E9e Instruction) to the Controller. The Controller, usi= ng something akin to a compiler, breaks the Instruction down into sub-Instr= uctions and sends those to the passive asset/vuln detector, active vuln sca= nner, host based config agent, and software config management system. Pres= umably, because this is about security, and we're not very trusting folks, = the Controller asks as MANY as possible the same question.=0A= =0A= Then the Controller receives the Reports, presumably it detects discrepanci= es.=0A= =0A= [daw: This is a good example of the intended functionality.]=0A= =0A= I'm nervous about what level of detail we dictate about the Controller, esp= ecially with respect to the Data Store. That's really an implementors choi= ce I think. Not that we don't acknowledge its existence, but I'm not sure = how detailed describing the iteration with data store should be. We need d= escribe the Controllers function, not how it gets it done.=0A= =0A= [daw: +1 We need to describe the protocol that enables tasking a controller= and the protocol(s) that the controller uses to communicate tasking to the= other components. The rest can be an implementation choice.]=0A= =0A= Can a Controller task another Controller? Or can a Controller pretend its = a sensor? Is there a trust system involved? Is the trust transitive?=0A= =0A= [daw: Controllers tasking other controllers was intended, but not documente= d in the current draft. Gunner has also proposed this concept. Trust is som= ething we need to discuss.]=0A= =0A= Content Repository:=0A= =0A= What are the security requirements for the Content Repository? Everything = accesses it, including potentially compromised endpoints. Is that really n= ecessary? It seems almost as if the glueing together of the system is via = the Content Repository.=0A= =0A= I'm not really clear, what the Content Repository really is. Is it a big O= racle system (or Postgres, CouchDB, MonetDB, MongoDB, or =85 for anyone who= has their favorite DB system) with 3 extra protocols on top that aren't SQ= L?=0A= =0A= [daw: The purpose of the content repository is to provide requested data se= ts on demand (e.g. vulnerability scores and characteristics, policy rules, = collection rules, etc) that make the system more dynamic and data driven. T= he sensor accesses it to get collection rules. This enables a collection ta= sk to reference a set of rules that can be retrieved by then sensor. The co= ntroller can retrieve rule sets that instruct or inform how to decompose re= quests into sub-tasks. The evaluator can retrieve analysis rules that can b= e used to parameterize or define analysis processes. In all cases, use of t= he content repository should be optional, but doing so would make an implem= entation less configurable and more static in functionality.=0A= =0A= Access to the content repository should be controlled to restrict unauthori= zed access. We need to work out how best to address this. If the endpoint i= s compromised, it may be possible to query the content repository. Behavio= rial analysis, provided by elements of the SACM system, can be used as a me= thod to detect this and restrict access. This might be one way to eat our o= wn dogfood? ;-) It is also likely in a compromise scenerio that much of the= information the component has retrieved will be accessable by the attacker= anyway.]=0A= =0A= --=0A= Chris Inacio=0A= inacio@cert.org=0A= =0A= =0A= =0A= _______________________________________________=0A= sacm mailing list=0A= sacm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sacm=0A= From david.waltermire@nist.gov Thu Aug 1 05:28:28 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A1411E81AC for ; Thu, 1 Aug 2013 05:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDw8iSQQnsiG for ; Thu, 1 Aug 2013 05:28:17 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5302921E83E4 for ; Thu, 1 Aug 2013 05:23:47 -0700 (PDT) Received: from WSGHUB2.xchange.nist.gov (129.6.16.197) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 1 Aug 2013 08:23:38 -0400 Received: from wsget1.nist.gov (129.6.13.150) by wsghub2.xchange.nist.gov (129.6.16.197) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 1 Aug 2013 08:23:45 -0400 Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 1 Aug 2013 08:23:15 -0400 Received: from na01-by2-obe.outbound.protection.outlook.com (207.46.163.241) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 1 Aug 2013 08:23:44 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB037.namprd09.prod.outlook.com (10.255.211.139) with Microsoft SMTP Server (TLS) id 15.0.731.16; Thu, 1 Aug 2013 12:23:42 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.53]) with mapi id 15.00.0731.000; Thu, 1 Aug 2013 12:23:42 +0000 From: "Waltermire, David A." To: Chris Inacio , "sacm@ietf.org" Thread-Topic: comments for draft-handt-sacm-alternate-architecture-01 Thread-Index: AQHOjiNH9f0+SbqN+EerSaMN8JnQMZmAQ0JX Date: Thu, 1 Aug 2013 12:23:42 +0000 Message-ID: <80697a6feca34dcfb9fde7de7a116251@BLUPR09MB038.namprd09.prod.outlook.com> References: <4AE532C8B0B4B548AF47570D250D8174142053CB@marathon> In-Reply-To: <4AE532C8B0B4B548AF47570D250D8174142053CB@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:df8:0:16:68fd:15a3:d64b:2a96] x-forefront-prvs: 0925081676 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(76796001)(74706001)(51856001)(80022001)(65816001)(74662001)(31966008)(74316001)(80976001)(83322001)(76482001)(76786001)(46102001)(47736001)(81542001)(77096001)(59766001)(74502001)(49866001)(79102001)(53806001)(19580405001)(54316002)(83072001)(47446002)(54356001)(76576001)(33646001)(74876001)(4396001)(50986001)(16406001)(63696002)(47976001)(69226001)(19580395003)(74366001)(77982001)(81342001)(56816003)(56776001)(19580385001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB037; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:2001:df8:0:16:68fd:15a3:d64b:2a96; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] comments for draft-handt-sacm-alternate-architecture-01 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:28:28 -0000 +1 on the concreteness. I like having a practical view into how the archite= cture can be used.=0A= =0A= My only concern is that a concrete architecture might be brittle in the fac= e of evolving technilogical approaches. I believe a hybrid approach brings = the best of both worlds. It might be better to present an abstract architec= ture that may be more broadly applicable and a number of concrete examples = to provide illustrations of how it can be used.=0A= =0A= Is this an acceptable way forward?=0A= =0A= Dave=0A= ________________________________________=0A= From: sacm-bounces@ietf.org on behalf of Chris Inac= io =0A= Sent: Wednesday, July 31, 2013 9:22 PM=0A= To: sacm@ietf.org=0A= Subject: [sacm] comments for draft-handt-sacm-alternate-architecture-01=0A= =0A= I really like the concreteness of the architecture, its easy to think about= . But I feel like this alternative isn't complete enough. From my comment= s in the review of the draft-waltermire-sacm-architecture-00 architecture, = I really feel like more than just BPD's (which I think is code for IDS/IPS)= should be considered to complete the situational awareness (SA) picture.= =0A= =0A= I believe that we need to include passive asset devices, active vuln scan c= apability, and machine config management (Windows AD, Red Hat Satellite Ser= ver, Puppet, CFEngine, MDM systems, =85). I don't think that is covered in= your model.=0A= =0A= =0A= So after we've done all of this evaluation - what are the protocols used to= reconfigure the network to isolate a compromised / at risk machine? Is th= at all NETCONF?=0A= =0A= =0A= --=0A= Chris Inacio=0A= inacio@cert.org=0A= =0A= =0A= =0A= _______________________________________________=0A= sacm mailing list=0A= sacm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sacm=0A= From dbharrington@comcast.net Thu Aug 1 05:36:53 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2577A21F92B8 for ; Thu, 1 Aug 2013 05:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLKSSH68Kw-B for ; Thu, 1 Aug 2013 05:36:48 -0700 (PDT) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by ietfa.amsl.com (Postfix) with ESMTP id C523711E80F0 for ; Thu, 1 Aug 2013 05:32:36 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta11.emeryville.ca.mail.comcast.net with comcast id 7Q7D1m0041u4NiLABQYZf8; Thu, 01 Aug 2013 12:32:33 +0000 Received: from [130.129.70.183] ([130.129.70.183]) by omta21.emeryville.ca.mail.comcast.net with comcast id 7QYC1m00E3xFRL28hQYJ6P; Thu, 01 Aug 2013 12:32:31 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 01 Aug 2013 14:32:11 +0200 From: David Harrington To: "Waltermire, David A." , Chris Inacio , "sacm@ietf.org" Message-ID: Thread-Topic: architecture terminology and data flows In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375360353; bh=VBpLBMW3FD9plvIQOg9rzMkn5GzzLJrCPMCxB6AlVoI=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=ezhRjsQX8aNSn7gYcER9qfl0p496i0ghOvnmBQOkPY3F5eFKzMmDUr0Z79lWe7i/3 V01KuYCwmHlpsWNoVnIXcTIiUCUG+rc87t3kwETYR47faFuC6HdO4itciimovWU0Zy Z1oxHGuNf0bbU8GTou1z1hsk+H9iPC1keFMZamyCGygnCGLUaeZfWUV3eHuEIk172m YqLwyXUOcdZ8k5W6MCHqpXj319BFu95LDIyidilOkEXtiJXivlaFeo/Um4glu0LpM5 chXQFbJ9OGW/WSTwcqDLvbmYdTzwYe5q+oOQG0rg7u632vR7PXtyNkHu9Po9RsTPh4 sLMr1IZVCvxyw== Subject: [sacm] architecture terminology and data flows X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:36:53 -0000 Comments inline as [dbh:] On 8/1/13 2:01 PM, "Waltermire, David A." wrote: >Comments inline marked [daw]. >________________________________________ >From: sacm-bounces@ietf.org on behalf of Chris >Inacio >Sent: Wednesday, July 31, 2013 8:57 PM >To: sacm@ietf.org >Subject: [sacm] >http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00 comments > >I think the architecture draft would be helped TREMENDOUSLY by defining >some terminology and using it to describe the intents of the >architecture. By having everything be defined as "DF #", it isn't very >descriptive. It doesn't have to be named in any form that implies using >any particular solution (obviously, that would be bad) but by defining an >architecture, you are effectively splitting the problem into (hopefully) >manageable components with defined tasks. > >Maybe splitting terminology out of the use-case doc and into a separate >doc so that everything can use it (and for easier reference in the >future.) > >[DAW: I see that adoption of the use case document as a WG document is on >the agenda for a consensus call. If concesus is confirmed on the list, >could we use the use case document as this reference?] [dbh: for now, as we start with use cases, having the terminology there makes things fairly simple. However, we might want to put terminology on standards-track, but not use cases, which are Informational. So I think we should assume that the terminology might move in the future. As we work in parallel on use cases, requirements, and architecture, we can probably duplicate terminology in each document (if I as use-cases author have to wait for David to add a term to his arch doc before I can use it, that will slow work a lot. We can reach consensus on terms and definitions as we go, and then extract them to a common location later or as we go.] > >Additionally, since we are the IETF, maybe we want to call the DF's >protocols - it's kind of our bread and butter. :) > >[daw: +1. I'm happy to make that change if others agree. ;-)] [dbh: the problem with the term protocols is that protocol might mean something different to you than to me, because we have different levels of experience with specific protocols that have certain inherent properties. DF is an obvious abstraction of the flow of data, which presumably flows over some yet-to-be-determined-set of protocols, with some yet-to-be-determined-set of properties. I prefer DF.] > >-- >David Harrington >ietfdbh@comcast.net > From Adam.Montville@cisecurity.org Thu Aug 1 07:19:31 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AC721E81A8 for ; Thu, 1 Aug 2013 07:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.778 X-Spam-Level: X-Spam-Status: No, score=-2.778 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ubxOxdLwzrv for ; Thu, 1 Aug 2013 07:19:24 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.194]) by ietfa.amsl.com (Postfix) with ESMTP id 51E5A21E81D0 for ; Thu, 1 Aug 2013 07:19:01 -0700 (PDT) Received: from [216.82.242.179:30601] by server-2.bemta-8.messagelabs.com id D4/67-07208-F4E6AF15; Thu, 01 Aug 2013 14:18:55 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-5.tower-86.messagelabs.com!1375366735!35357167!1 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 22286 invoked from network); 1 Aug 2013 14:18:55 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-5.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 1 Aug 2013 14:18:55 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Thu, 1 Aug 2013 10:18:54 -0400 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: TESTING Thread-Index: Ac6OwgOTy9jzYrzfRyGBsfWon1DFIQ== Date: Thu, 1 Aug 2013 14:18:54 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D673B5C1@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] TESTING X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:19:31 -0000 No need to reply. . . . From jclarke@cisco.com Fri Aug 2 17:27:56 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5D511E814B for ; Fri, 2 Aug 2013 17:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC9jIjluAd6j for ; Fri, 2 Aug 2013 17:27:51 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id DD0D811E8146 for ; Fri, 2 Aug 2013 17:27:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r730RoMS015951 for ; Fri, 2 Aug 2013 20:27:50 -0400 (EDT) Received: from rtp-vpn5-1164.cisco.com (rtp-vpn5-1164.cisco.com [10.82.236.144]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r730RnTK017908 for ; Fri, 2 Aug 2013 20:27:49 -0400 (EDT) Message-ID: <51FC4E85.8010501@cisco.com> Date: Fri, 02 Aug 2013 20:27:49 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: sacm@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 00:27:56 -0000 After talking with Eliot today after the WG meeting, I think my comments regarding vulnerability management were unclear. I'd like to clarify and still see if people think this is out of scope. I am not asking to standardize vulnerability assessment per se (meaning standardize IPS signatures). What I am asking is whether or not SACM needs to define a new (or standardize an existing) data model to describe a vulnerability for purposes of efficient interchange? My argument for "yes" is that if I am to learn about things like device type, hardware version, software version, place in network, configuration, etc. how can I effectively build a policy around security posture if I do not know what vulnerabilities exist? If we have a way to exchange descriptions of vulnerabilities, it would enable consistent communication to a vulnerability repository as described in the charter. To me, this directly goes towards posture assessment. I don't see this as being in scope for MILE, so I wonder if this is out of scope for SACM, would SACM disregard this type of model, point to an existing, non-IETF model, look to tackle this in a future re-charter, or ...? Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From ietf@meetecho.com Fri Aug 2 05:50:47 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E887011E8313 for ; Fri, 2 Aug 2013 05:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WE72sIjn9kX for ; Fri, 2 Aug 2013 05:50:34 -0700 (PDT) Received: from smtpdg7.aruba.it (smtpdg3.aruba.it [62.149.158.233]) by ietfa.amsl.com (Postfix) with ESMTP id B660621E8237 for ; Fri, 2 Aug 2013 05:48:49 -0700 (PDT) Received: from dell-tcastaldi ([89.246.150.136]) by smtpcmd03.ad.aruba.it with bizsmtp id 7oon1m00T2wpE7M01ooou4; Fri, 02 Aug 2013 14:48:48 +0200 Date: Fri, 2 Aug 2013 14:48:46 +0200 (CEST) From: Meetecho Team To: sacm@ietf.org Message-ID: <205491528.5.1375447726692.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4_449390461.1375447726690" X-Mailman-Approved-At: Sat, 03 Aug 2013 01:01:07 -0700 Subject: [sacm] SACM session recording available X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 12:50:47 -0000 ------=_Part_4_449390461.1375447726690 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the SACM WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#SACM For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_4_449390461.1375447726690-- From athiasjerome@gmail.com Sat Aug 3 02:13:12 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE5821F97C7 for ; Sat, 3 Aug 2013 02:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv8OzOpiCDO7 for ; Sat, 3 Aug 2013 02:13:11 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DB3BB11E8168 for ; Sat, 3 Aug 2013 02:13:10 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id r10so1018574lbi.1 for ; Sat, 03 Aug 2013 02:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1cmW7pSevmwjJxx2mQ4DfIi/OCJh0jOE6Zm/MbejqD0=; b=vbw2vT0DR2Dhy8U4igUZ/L8YBLDLU7b54sqfFF9dD9CxYAjeLGsV2McBuCbC95YoEh OUjZDuyyF1A4PWEMBvSwzdlCmutR7zj/4iulQPS3lzQhJBzOWPWaRTYF/sAXmTux3AAq IGjV85/h4TQXvcEMjdtESAKmmUQdhV4YodT6FO2jmOqV2pJveot/bLlcnbxXWMQxDoIq kR3uPSw/TKAtzQMRpOFHDkFDmrh82dMoPtqvKdC35i17rTX1zV9AusDTrG/Umy/HmECI cTKIKOwM493RqBl5cTEt3bP893Dr4yd2zGyz17sX3SRfTNjHIJGddTTsG6Eks59Sbw3E kcHA== MIME-Version: 1.0 X-Received: by 10.112.29.196 with SMTP id m4mr4873258lbh.66.1375521189744; Sat, 03 Aug 2013 02:13:09 -0700 (PDT) Received: by 10.114.92.2 with HTTP; Sat, 3 Aug 2013 02:13:09 -0700 (PDT) In-Reply-To: <51FC4E85.8010501@cisco.com> References: <51FC4E85.8010501@cisco.com> Date: Sat, 3 Aug 2013 11:13:09 +0200 Message-ID: From: Jerome Athias To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=001a1133a8f0e5546404e3077bcf Cc: "sacm@ietf.org" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 09:13:12 -0000 --001a1133a8f0e5546404e3077bcf Content-Type: text/plain; charset=ISO-8859-1 Hi, i am interested by this and would be happy to talk about it. So yes, we need an answer on if it is in the scope for SACM. 2013/8/3 Joe Marcus Clarke > After talking with Eliot today after the WG meeting, I think my comments > regarding vulnerability management were unclear. I'd like to clarify > and still see if people think this is out of scope. > > I am not asking to standardize vulnerability assessment per se (meaning > standardize IPS signatures). What I am asking is whether or not SACM > needs to define a new (or standardize an existing) data model to > describe a vulnerability for purposes of efficient interchange? > > My argument for "yes" is that if I am to learn about things like device > type, hardware version, software version, place in network, > configuration, etc. how can I effectively build a policy around security > posture if I do not know what vulnerabilities exist? If we have a way > to exchange descriptions of vulnerabilities, it would enable consistent > communication to a vulnerability repository as described in the charter. > To me, this directly goes towards posture assessment. > > I don't see this as being in scope for MILE, so I wonder if this is out > of scope for SACM, would SACM disregard this type of model, point to an > existing, non-IETF model, look to tackle this in a future re-charter, or > ...? > > Joe > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > > ---------------------------------------------------------------------------- > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --001a1133a8f0e5546404e3077bcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

i am interested by this and w= ould be happy to talk about it.
So yes, we need an answer o= n if it is in the scope for SACM.

2013/8/3 Joe Marcus Clarke <jclarke@cisco.c= om>
After talking with Eliot today after the WG meeting, I think my comments regarding vulnerability management were unclear. =A0I'd like to clarify=
and still see if people think this is out of scope.

I am not asking to standardize vulnerability assessment per se (meaning
standardize IPS signatures). =A0What I am asking is whether or not SACM
needs to define a new (or standardize an existing) data model to
describe a vulnerability for purposes of efficient interchange?

My argument for "yes" is that if I am to learn about things like = device
type, hardware version, software version, place in network,
configuration, etc. how can I effectively build a policy around security posture if I do not know what vulnerabilities exist? =A0If we have a way to exchange descriptions of vulnerabilities, it would enable consistent
communication to a vulnerability repository as described in the charter. =A0To me, this directly goes towards posture assessment.

I don't see this as being in scope for MILE, so I wonder if this is out=
of scope for SACM, would SACM disregard this type of model, point to an
existing, non-IETF model, look to tackle this in a future re-charter, or ...?

Joe

--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: += 1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t e m s
Email: jclarke@cisco.com

---------------------------------------------------------------------------= -
_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm

--001a1133a8f0e5546404e3077bcf-- From dromasca@avaya.com Sun Aug 4 06:17:57 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B4721F9A50 for ; Sun, 4 Aug 2013 06:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.447 X-Spam-Level: X-Spam-Status: No, score=-103.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StegISxKCKTt for ; Sun, 4 Aug 2013 06:17:51 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 277A621F9A10 for ; Sun, 4 Aug 2013 06:17:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFANxT/lHGmAcV/2dsb2JhbABXA4JCIyE1UL8VgRoWdIIkAQEBAQMBAQEPG0ELDgICAQgNBAQBAQsdBxsMCxQJCAIEAQ0FCBqHbgELmwCbAxMEBI5NgRcFHAwEBgERgwh0A4hylTaLB4MXgXE5 X-IronPort-AV: E=Sophos;i="4.89,812,1367985600"; d="scan'208,217";a="18848075" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Aug 2013 09:17:44 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Aug 2013 09:14:35 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Sun, 4 Aug 2013 15:17:43 +0200 From: "Romascanu, Dan (Dan)" To: Jerome Athias , Joe Marcus Clarke Thread-Topic: [sacm] Feedback on vulnerability management use case Thread-Index: AQHOj+BP4VmLse1r80mT6rjOx5Yui5mDEg+AgAH2TYA= Date: Sun, 4 Aug 2013 13:17:42 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1289E9D3@AZ-FFEXMB04.global.avaya.com> References: <51FC4E85.8010501@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA1289E9D3AZFFEXMB04globa_" MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 13:17:57 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA1289E9D3AZFFEXMB04globa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The charter talks about information on vulnerabilities and vulnerability ma= nagement. I agree that the system needs to be aware about existing vulnerab= ilities, I am not sure whether the description of vulnerabilities needs to = be defined in this working group. According to the wording in the charter =D8 content repositories are expected to store up-to-date dictionary of specific enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on. so it seems to be more about defining a format for vulnerability identifier= s rather than semantics for vulnerability descriptions. Regards, Dan From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Jer= ome Athias Sent: Saturday, August 03, 2013 12:13 PM To: Joe Marcus Clarke Cc: sacm@ietf.org Subject: Re: [sacm] Feedback on vulnerability management use case Hi, i am interested by this and would be happy to talk about it. So yes, we need an answer on if it is in the scope for SACM. 2013/8/3 Joe Marcus Clarke > After talking with Eliot today after the WG meeting, I think my comments regarding vulnerability management were unclear. I'd like to clarify and still see if people think this is out of scope. I am not asking to standardize vulnerability assessment per se (meaning standardize IPS signatures). What I am asking is whether or not SACM needs to define a new (or standardize an existing) data model to describe a vulnerability for purposes of efficient interchange? My argument for "yes" is that if I am to learn about things like device type, hardware version, software version, place in network, configuration, etc. how can I effectively build a policy around security posture if I do not know what vulnerabilities exist? If we have a way to exchange descriptions of vulnerabilities, it would enable consistent communication to a vulnerability repository as described in the charter. To me, this directly goes towards posture assessment. I don't see this as being in scope for MILE, so I wonder if this is out of scope for SACM, would SACM disregard this type of model, point to an existing, non-IETF model, look to tackle this in a future re-charter, or ...? Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o= S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------= - _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_9904FB1B0159DA42B0B887B7FA8119CA1289E9D3AZFFEXMB04globa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

The charter talks about i= nformation on vulnerabilities and vulnerability management. I agree that th= e system needs to be aware about existing vulnerabilities, I am not sure whether the description of vulnerabilities needs to be defin= ed in this working group. According to the wording in the charter

 <= /p>

<= span style=3D"mso-list:Ignore">=D8  content = repositories are expected
to store up-to-date dictionary of specific enumerations, such as those
used for configuration element identifiers, asset classifications,
vulnerability identifiers, and so on.

 <= /p>

so it seems to be more ab= out defining a format for vulnerability identifiers rather than semantics f= or vulnerability descriptions.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Jerome Athias
Sent: Saturday, August 03, 2013 12:13 PM
To: Joe Marcus Clarke
Cc: sacm@ietf.org
Subject: Re: [sacm] Feedback on vulnerability management use case

 

Hi,

 

i am interested by this and would be happy to talk a= bout it.

So yes, we need an answer on if it is in the scope f= or SACM.

 

2013/8/3 Joe Marcus Clarke <jclarke@cisco.com>

After talking with Eliot today after the WG meeting,= I think my comments
regarding vulnerability management were unclear.  I'd like to clarify<= br> and still see if people think this is out of scope.

I am not asking to standardize vulnerability assessment per se (meaning
standardize IPS signatures).  What I am asking is whether or not SACM<= br> needs to define a new (or standardize an existing) data model to
describe a vulnerability for purposes of efficient interchange?

My argument for "yes" is that if I am to learn about things like = device
type, hardware version, software version, place in network,
configuration, etc. how can I effectively build a policy around security posture if I do not know what vulnerabilities exist?  If we have a way=
to exchange descriptions of vulnerabilities, it would enable consistent
communication to a vulnerability repository as described in the charter.  To me, this directly goes towards posture assessment.

I don't see this as being in scope for MILE, so I wonder if this is out
of scope for SACM, would SACM disregard this type of model, point to an
existing, non-IETF model, look to tackle this in a future re-charter, or ...?

Joe

--
Joe Marcus Clarke, CCIE #5384,       =   |          |
SCJP, SCSA, SCNA, SCSECA, VCP       &= nbsp;|||||      |||||
Distinguished Services Engineer ..:|||||||||::||||||= |||:..
Phone: &= #43;1 (919) 392-2867         c i s c o  S y s = t e m s
Email: jclarke@= cisco.com

----------------------------------------------------= ------------------------
_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm<= /span>

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA1289E9D3AZFFEXMB04globa_-- From jclarke@cisco.com Sun Aug 4 10:20:13 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1934021F9CC7 for ; Sun, 4 Aug 2013 10:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0YcPqXWGYPd for ; Sun, 4 Aug 2013 10:20:08 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id A80E821F9D15 for ; Sun, 4 Aug 2013 10:20:03 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r74HJuSC027776; Sun, 4 Aug 2013 13:19:56 -0400 (EDT) Received: from rtp-vpn5-1932.cisco.com (rtp-vpn5-1932.cisco.com [10.82.239.147]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r74HJtvZ015234; Sun, 4 Aug 2013 13:19:55 -0400 (EDT) Message-ID: <51FE8D3A.8030109@cisco.com> Date: Sun, 04 Aug 2013 13:19:54 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <51FC4E85.8010501@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA1289E9D3@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1289E9D3@AZ-FFEXMB04.global.avaya.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Jerome Athias , "sacm@ietf.org" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 17:20:13 -0000 On 8/4/13 9:17 AM, Romascanu, Dan (Dan) wrote: > Hi, > > > > The charter talks about information on vulnerabilities and vulnerability > management. I agree that the system needs to be aware about existing > vulnerabilities, I am not sure whether the description of > vulnerabilities needs to be defined in this working group. According to > the wording in the charter > > > > Ø content repositories are expected > to store up-to-date dictionary of specific enumerations, such as those > used for configuration element identifiers, asset classifications, > vulnerability identifiers, and so on. > > > > so it seems to be more about defining a format for vulnerability > identifiers rather than semantics for vulnerability descriptions. Hmmm....Above what you quote (in the charter) it talks about interfacing with these repositories to store, update, and retrieve posture assessment content that may be used for vulnerability management (I paraphrased). While an identifier alone might be sufficient for retrieval, storing new data about a vulnerability would imply (to me anyway) a common data model for the vulnerability itself. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From Adam.Montville@cisecurity.org Sun Aug 4 11:06:16 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E075021F9D2B for ; Sun, 4 Aug 2013 11:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPS2L+CUq3eC for ; Sun, 4 Aug 2013 11:06:12 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.15]) by ietfa.amsl.com (Postfix) with ESMTP id E278421F9D9B for ; Sun, 4 Aug 2013 11:06:08 -0700 (PDT) Received: from [216.82.250.179:64971] by server-15.bemta-12.messagelabs.com id EB/02-29847-F089EF15; Sun, 04 Aug 2013 18:06:07 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-9.tower-210.messagelabs.com!1375639566!10903798!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 22355 invoked from network); 4 Aug 2013 18:06:07 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-9.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 4 Aug 2013 18:06:07 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Sun, 4 Aug 2013 14:05:57 -0400 From: Adam Montville To: Joe Marcus Clarke , "Romascanu, Dan (Dan)" Thread-Topic: [sacm] Feedback on vulnerability management use case Thread-Index: AQHOj+BNCA4qx6I6Hke8Ina7noa8/JmDdqWAgAHWqACAAEOrAP//yHeA Date: Sun, 4 Aug 2013 18:05:57 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D673BFEE@CISEXCHANGE1.msisac.org.local> References: <51FC4E85.8010501@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA1289E9D3@AZ-FFEXMB04.global.avaya.com> <51FE8D3A.8030109@cisco.com> In-Reply-To: <51FE8D3A.8030109@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jerome Athias , "sacm@ietf.org" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 18:06:17 -0000 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Joe Marcus Clarke > Sent: Sunday, August 04, 2013 10:20 AM > To: Romascanu, Dan (Dan) > Cc: Jerome Athias; sacm@ietf.org > Subject: Re: [sacm] Feedback on vulnerability management use case >=20 > On 8/4/13 9:17 AM, Romascanu, Dan (Dan) wrote: > > Hi, > > > > > > > > The charter talks about information on vulnerabilities and > > vulnerability management. I agree that the system needs to be aware > > about existing vulnerabilities, I am not sure whether the description > > of vulnerabilities needs to be defined in this working group. > > According to the wording in the charter > > > > > > > > =D8 content repositories are expected > > to store up-to-date dictionary of specific enumerations, such as those= > > used for configuration element identifiers, asset classifications, > > vulnerability identifiers, and so on. > > > > > > > > so it seems to be more about defining a format for vulnerability > > identifiers rather than semantics for vulnerability descriptions. >=20 > Hmmm....Above what you quote (in the charter) it talks about interfacing= > with these repositories to store, update, and retrieve posture assessmen= t > content that may be used for vulnerability management (I paraphrased). > While an identifier alone might be sufficient for retrieval, storing new= data > about a vulnerability would imply (to me > anyway) a common data model for the vulnerability itself. >=20 I think you both have valid points the working group may eventually need t= o consider. At this point, we need to get the use cases figured out, cons= ider which use cases we need to entertain, and then move forward from ther= e. =20 I'm sure the WG would consider a use case for updating/augmenting vulnerab= ility context for inclusion in this chartered work or to, at least, consid= er for later phases. Additionally, I'd like to call attention to the terminology of "vulnerabil= ity" and that we, typically, mean software vulnerability by it. It might = be more precise to call say so explicitly. There are many categories of v= ulnerabilities: Software, configuration, policy, process, etc. From my pe= rspective, it makes complete sense to be pedantic and state explicitly the= type of vulnerabilities we are interested in rather than assuming one typ= e over another. > Joe >=20 > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > ------------------------------------------------------------------------= ---- > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... . . . From jclarke@cisco.com Sun Aug 4 11:12:18 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED2C21F9DE9 for ; Sun, 4 Aug 2013 11:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xibqdo7EKor4 for ; Sun, 4 Aug 2013 11:12:13 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id EEB1521F9D21 for ; Sun, 4 Aug 2013 11:12:12 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r74IC8Nj002491; Sun, 4 Aug 2013 14:12:09 -0400 (EDT) Received: from rtp-vpn5-1932.cisco.com (rtp-vpn5-1932.cisco.com [10.82.239.147]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r74IC7Nk023185; Sun, 4 Aug 2013 14:12:08 -0400 (EDT) Message-ID: <51FE9977.4080600@cisco.com> Date: Sun, 04 Aug 2013 14:12:07 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Montville References: <51FC4E85.8010501@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA1289E9D3@AZ-FFEXMB04.global.avaya.com> <51FE8D3A.8030109@cisco.com> <05BCCEB107AF88469B9F99783D47C1D673BFEE@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D673BFEE@CISEXCHANGE1.msisac.org.local> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "Romascanu, Dan \(Dan\)" , Jerome Athias , "sacm@ietf.org" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 18:12:18 -0000 On 8/4/13 2:05 PM, Adam Montville wrote: > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Joe Marcus Clarke >> Sent: Sunday, August 04, 2013 10:20 AM >> To: Romascanu, Dan (Dan) >> Cc: Jerome Athias; sacm@ietf.org >> Subject: Re: [sacm] Feedback on vulnerability management use case >> >> On 8/4/13 9:17 AM, Romascanu, Dan (Dan) wrote: >>> Hi, >>> >>> >>> >>> The charter talks about information on vulnerabilities and >>> vulnerability management. I agree that the system needs to be aware >>> about existing vulnerabilities, I am not sure whether the description >>> of vulnerabilities needs to be defined in this working group. >>> According to the wording in the charter >>> >>> >>> >>> Ø content repositories are expected >>> to store up-to-date dictionary of specific enumerations, such as those >>> used for configuration element identifiers, asset classifications, >>> vulnerability identifiers, and so on. >>> >>> >>> >>> so it seems to be more about defining a format for vulnerability >>> identifiers rather than semantics for vulnerability descriptions. >> >> Hmmm....Above what you quote (in the charter) it talks about interfacing >> with these repositories to store, update, and retrieve posture assessment >> content that may be used for vulnerability management (I paraphrased). >> While an identifier alone might be sufficient for retrieval, storing new data >> about a vulnerability would imply (to me >> anyway) a common data model for the vulnerability itself. >> > > > I think you both have valid points the working group may eventually need to consider. At this point, we need to get the use cases figured out, consider which use cases we need to entertain, and then move forward from there. The reason I brought this up is that one use case for me in vulnerability management, as a vendor, is to be able to publish my vulnerabilities in a way that can be consumed by customers and potentially other vendors (I'm thinking of OEMs) and vice versa. > > I'm sure the WG would consider a use case for updating/augmenting vulnerability context for inclusion in this chartered work or to, at least, consider for later phases. > > Additionally, I'd like to call attention to the terminology of "vulnerability" and that we, typically, mean software vulnerability by it. It might be more precise to call say so explicitly. There are many categories of vulnerabilities: Software, configuration, policy, process, etc. From my perspective, it makes complete sense to be pedantic and state explicitly the type of vulnerabilities we are interested in rather than assuming one type over another. I think that's fair. I was operating under a similar understanding of vulnerability. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From gunnar.engelbach@threatguard.com Sun Aug 4 12:57:35 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0AC21F99C3 for ; Sun, 4 Aug 2013 12:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXObmBp4ryWt for ; Sun, 4 Aug 2013 12:57:27 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id C298C21F9980 for ; Sun, 4 Aug 2013 12:57:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=hT27167CkINzXRA7H8wAiL7lwkp99w2wUYvp1NW8oAgXKklC//i5W7Bw9CLfwT3T8jqGV4mKHhMh31KKnlsfVa+ZQYkhKUwBmcnkX8WbdqaEZuAuYuphOQ9Ff5Zos1Ee; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 23713 invoked from network); 4 Aug 2013 12:56:14 -0700 Received: from 97-125-26-97.eugn.qwest.net (HELO ?192.168.11.12?) (97.125.26.97) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 Aug 2013 12:56:13 -0700 Message-ID: <51FEB21C.2000208@ThreatGuard.com> Date: Sun, 04 Aug 2013 15:57:16 -0400 From: Gunnar Engelbach User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Marcus Clarke References: <51FC4E85.8010501@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA1289E9D3@AZ-FFEXMB04.global.avaya.com> <51FE8D3A.8030109@cisco.com> <05BCCEB107AF88469B9F99783D47C1D673BFEE@CISEXCHANGE1.msisac.org.local> <51FE9977.4080600@cisco.com> In-Reply-To: <51FE9977.4080600@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Romascanu, Dan \(Dan\)" , Jerome Athias , Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 19:57:35 -0000 As Adam says, we'll want to go through the use case/requirements process and determine exactly what this working group is going to focus on, but I'll mention for now that the initial focus is security automation, which is deliberately non-specific. It's hard to imagine we won't, at a bare minimum, allow for automated assessment of software vulnerabilities and configuration compliance, but I think the goal is more to create tools sets that have the possibility of being used for other purposes as well. --gun On 08/04/2013 02:12 PM, Joe Marcus Clarke wrote: > On 8/4/13 2:05 PM, Adam Montville wrote: >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>> Joe Marcus Clarke >>> Sent: Sunday, August 04, 2013 10:20 AM >>> To: Romascanu, Dan (Dan) >>> Cc: Jerome Athias; sacm@ietf.org >>> Subject: Re: [sacm] Feedback on vulnerability management use case >>> >>> On 8/4/13 9:17 AM, Romascanu, Dan (Dan) wrote: >>>> Hi, >>>> >>>> >>>> >>>> The charter talks about information on vulnerabilities and >>>> vulnerability management. I agree that the system needs to be aware >>>> about existing vulnerabilities, I am not sure whether the description >>>> of vulnerabilities needs to be defined in this working group. >>>> According to the wording in the charter >>>> >>>> >>>> >>>> Ø content repositories are expected >>>> to store up-to-date dictionary of specific enumerations, such as those >>>> used for configuration element identifiers, asset classifications, >>>> vulnerability identifiers, and so on. >>>> >>>> >>>> >>>> so it seems to be more about defining a format for vulnerability >>>> identifiers rather than semantics for vulnerability descriptions. >>> Hmmm....Above what you quote (in the charter) it talks about interfacing >>> with these repositories to store, update, and retrieve posture assessment >>> content that may be used for vulnerability management (I paraphrased). >>> While an identifier alone might be sufficient for retrieval, storing new data >>> about a vulnerability would imply (to me >>> anyway) a common data model for the vulnerability itself. >>> >> >> I think you both have valid points the working group may eventually need to consider. At this point, we need to get the use cases figured out, consider which use cases we need to entertain, and then move forward from there. > The reason I brought this up is that one use case for me in > vulnerability management, as a vendor, is to be able to publish my > vulnerabilities in a way that can be consumed by customers and > potentially other vendors (I'm thinking of OEMs) and vice versa. > >> I'm sure the WG would consider a use case for updating/augmenting vulnerability context for inclusion in this chartered work or to, at least, consider for later phases. >> >> Additionally, I'd like to call attention to the terminology of "vulnerability" and that we, typically, mean software vulnerability by it. It might be more precise to call say so explicitly. There are many categories of vulnerabilities: Software, configuration, policy, process, etc. From my perspective, it makes complete sense to be pedantic and state explicitly the type of vulnerabilities we are interested in rather than assuming one type over another. > I think that's fair. I was operating under a similar understanding of > vulnerability. > > Joe > From dromasca@avaya.com Mon Aug 5 08:47:53 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8B021F9EC2 for ; Mon, 5 Aug 2013 08:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.452 X-Spam-Level: X-Spam-Status: No, score=-103.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1U8bgt6oAvn for ; Mon, 5 Aug 2013 08:47:47 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 58F4B21E80E4 for ; Mon, 5 Aug 2013 08:47:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAE7I/1HGmAcV/2dsb2JhbABbgmUhgQW+dIEhFnSCJgEBAxIoUQEVBRAUQhcPAQQbGoduAZUAhESbZI5hgQeDUXQDniiLB4MXgXE5 X-IronPort-AV: E=Sophos;i="4.89,819,1367985600"; d="scan'208";a="22370113" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Aug 2013 11:47:27 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Aug 2013 11:44:14 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0146.000; Mon, 5 Aug 2013 11:47:26 -0400 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: SACM - consensus on 'Way Forward' Thread-Index: Ac6R8xTLkINV4Y/AQbKf7+Autmo1Nw== Date: Mon, 5 Aug 2013 15:47:26 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] SACM - consensus on 'Way Forward' X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:47:54 -0000 At the SACM WG meeting at IETF-88 the participants in the room did not rais= e any objection on the 'Way Forward' plan of action between now and IETF-88= presented by Adam Montville on behalf of the chairs. The plan included the= following: 8/16: Agreement on way forward on list 8/31: Adopt Use Case I-D as WG doc 9/13: Initial Requirements I-D submitted 9/30: Adopt Requirements I-D as WG doc 10/15: Initial Architecture I-Ds submitted IETF 88: Discuss architecture contributions and work for consensus We are asking the WG to confirm this consensus on the mail list. Please sen= d all comments, questions and concerns to the SACM WG mail list before 8/15= , so that the chairs can judge consensus on 8/16. Thanks and Regards, Adam and Dan From dromasca@avaya.com Mon Aug 5 08:51:02 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A379921F9C6F for ; Mon, 5 Aug 2013 08:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cm2qlOY0PCbS for ; Mon, 5 Aug 2013 08:50:56 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1C521F9DD6 for ; Mon, 5 Aug 2013 08:50:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAELJ/1GHCzI1/2dsb2JhbABbgmUhgQW9ZgGBDoEhFnSCJgEBAxIoUQEVFRQFPSYBBBsah24BlH2ERJtnjmGBB4NRdAOeKIsHgV6BOYFxOQ X-IronPort-AV: E=Sophos;i="4.89,819,1367985600"; d="scan'208";a="22924044" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 05 Aug 2013 11:50:53 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 05 Aug 2013 11:44:10 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Mon, 5 Aug 2013 17:50:52 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases Thread-Index: Ac6R849yIIsiER8oT9evwtziU7dGeQ== Date: Mon, 5 Aug 2013 15:50:51 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128A4113@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:51:02 -0000 At the SACM WG meeting at IETF-88 the participants in the room did not rais= e any objection on the proposal to adopt draft-waltermire-sacm-use-cases as= start point for WG I-D for use cases. We are asking the WG to confirm this= consensus on the mail list. Please send all comments, questions and concer= ns to the SACM WG mail list before 8/15. Thanks and Regards, Adam and Dan From shanna@juniper.net Mon Aug 5 09:01:33 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2320721F8C93 for ; Mon, 5 Aug 2013 09:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.467 X-Spam-Level: X-Spam-Status: No, score=-100.467 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tu4RlrlhmKx for ; Mon, 5 Aug 2013 09:01:25 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5893821F9FFB for ; Mon, 5 Aug 2013 09:00:41 -0700 (PDT) Received: from mail131-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE024.bigfish.com (10.243.66.87) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 16:00:40 +0000 Received: from mail131-co1 (localhost [127.0.0.1]) by mail131-co1-R.bigfish.com (Postfix) with ESMTP id 4B5CACE013C for ; Mon, 5 Aug 2013 16:00:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I542I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h683h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail131-co1: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=shanna@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail131-co1 (localhost.localdomain [127.0.0.1]) by mail131-co1 (MessageSwitch) id 1375718437646909_18019; Mon, 5 Aug 2013 16:00:37 +0000 (UTC) Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.228]) by mail131-co1.bigfish.com (Postfix) with ESMTP id 9AC2342004A for ; Mon, 5 Aug 2013 16:00:37 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.54) by CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 16:00:35 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Aug 2013 09:00:35 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Mon, 5 Aug 2013 09:00:35 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Aug 2013 09:05:30 -0700 Received: from mail199-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 16:00:33 +0000 Received: from mail199-ch1 (localhost [127.0.0.1]) by mail199-ch1-R.bigfish.com (Postfix) with ESMTP id 41B681800DB for ; Mon, 5 Aug 2013 16:00:33 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(164054003)(377454003)(189002)(13464003)(51704005)(51856001)(74366001)(80976001)(59766001)(77982001)(31966008)(47446002)(74502001)(74662001)(79102001)(54356001)(56816003)(46102001)(77096001)(76786001)(76576001)(53806001)(69226001)(56776001)(74706001)(81542001)(74876001)(80022001)(76796001)(16406001)(33646001)(65816001)(54316002)(74316001)(66066001)(83072001)(83322001)(19580405001)(19580385001)(19580395003)(63696002)(81342001)(50986001)(47976001)(76482001)(47736001)(49866001)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB054; H:BLUPR05MB053.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail199-ch1 (localhost.localdomain [127.0.0.1]) by mail199-ch1 (MessageSwitch) id 1375718430239694_28966; Mon, 5 Aug 2013 16:00:30 +0000 (UTC) Received: from CH1EHSMHS035.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail199-ch1.bigfish.com (Postfix) with ESMTP id 2D6D736005D; Mon, 5 Aug 2013 16:00:30 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS035.bigfish.com (10.43.70.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 16:00:19 +0000 Received: from BLUPR05MB054.namprd05.prod.outlook.com (10.255.210.149) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Mon, 5 Aug 2013 16:00:15 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) by BLUPR05MB054.namprd05.prod.outlook.com (10.255.210.149) with Microsoft SMTP Server (TLS) id 15.0.731.16; Mon, 5 Aug 2013 16:00:12 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.169]) by BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.223]) with mapi id 15.00.0731.000; Mon, 5 Aug 2013 16:00:12 +0000 From: Stephen Hanna To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: SACM - consensus on 'Way Forward' Thread-Index: Ac6R8xTLkINV4Y/AQbKf7+Autmo1NwAAbWpg Date: Mon, 5 Aug 2013 16:00:11 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0929F1BAED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%AVAYA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] SACM - consensus on 'Way Forward' X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:01:33 -0000 Yes, I agree with this plan. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Monday, August 05, 2013 11:47 AM > To: sacm@ietf.org > Subject: [sacm] SACM - consensus on 'Way Forward' >=20 > At the SACM WG meeting at IETF-88 the participants in the room did not > raise any objection on the 'Way Forward' plan of action between now and > IETF-88 presented by Adam Montville on behalf of the chairs. The plan > included the following: >=20 > 8/16: Agreement on way forward on list > 8/31: Adopt Use Case I-D as WG doc > 9/13: Initial Requirements I-D submitted > 9/30: Adopt Requirements I-D as WG doc > 10/15: Initial Architecture I-Ds submitted > IETF 88: Discuss architecture contributions and work for consensus >=20 > We are asking the WG to confirm this consensus on the mail list. Please > send all comments, questions and concerns to the SACM WG mail list > before 8/15, so that the chairs can judge consensus on 8/16. >=20 > Thanks and Regards, >=20 > Adam and Dan >=20 >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From shanna@juniper.net Mon Aug 5 09:02:29 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A81F21F9D1B for ; Mon, 5 Aug 2013 09:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.467 X-Spam-Level: X-Spam-Status: No, score=-100.467 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 094ntC97fVbN for ; Mon, 5 Aug 2013 09:02:23 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8B72621F9D05 for ; Mon, 5 Aug 2013 09:02:04 -0700 (PDT) Received: from mail52-co1-R.bigfish.com (10.243.78.234) by CO1EHSOBE041.bigfish.com (10.243.66.106) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 16:02:03 +0000 Received: from mail52-co1 (localhost [127.0.0.1]) by mail52-co1-R.bigfish.com (Postfix) with ESMTP id DEEAB740261 for ; Mon, 5 Aug 2013 16:02:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I542I1432I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h683h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail52-co1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=shanna@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail52-co1 (localhost.localdomain [127.0.0.1]) by mail52-co1 (MessageSwitch) id 1375718521543533_4205; Mon, 5 Aug 2013 16:02:01 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.235]) by mail52-co1.bigfish.com (Postfix) with ESMTP id 812D434004A for ; Mon, 5 Aug 2013 16:02:01 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.52) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 16:02:01 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Aug 2013 09:02:00 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Mon, 5 Aug 2013 09:02:00 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.181) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Aug 2013 09:06:36 -0700 Received: from mail115-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE022.bigfish.com (10.43.70.79) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 16:01:39 +0000 Received: from mail115-ch1 (localhost [127.0.0.1]) by mail115-ch1-R.bigfish.com (Postfix) with ESMTP id 5C4B9200216 for ; Mon, 5 Aug 2013 16:01:39 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(51704005)(199002)(189002)(13464003)(164054003)(74366001)(76576001)(76786001)(76796001)(56776001)(16406001)(77096001)(56816003)(46102001)(81342001)(81542001)(33646001)(83072001)(19580385001)(19580405001)(53806001)(83322001)(51856001)(74502001)(74662001)(47446002)(76482001)(19580395003)(54356001)(80976001)(31966008)(561944002)(59766001)(77982001)(54316002)(4396001)(79102001)(47976001)(50986001)(74876001)(49866001)(74706001)(69226001)(66066001)(80022001)(63696002)(65816001)(47736001)(74316001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB055; H:BLUPR05MB053.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail115-ch1 (localhost.localdomain [127.0.0.1]) by mail115-ch1 (MessageSwitch) id 1375718497532679_14805; Mon, 5 Aug 2013 16:01:37 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail115-ch1.bigfish.com (Postfix) with ESMTP id 735451E004D; Mon, 5 Aug 2013 16:01:37 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 16:01:36 +0000 Received: from BLUPR05MB055.namprd05.prod.outlook.com (10.255.210.150) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Mon, 5 Aug 2013 16:01:32 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) by BLUPR05MB055.namprd05.prod.outlook.com (10.255.210.150) with Microsoft SMTP Server (TLS) id 15.0.731.16; Mon, 5 Aug 2013 16:01:30 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.169]) by BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.223]) with mapi id 15.00.0731.000; Mon, 5 Aug 2013 16:01:30 +0000 From: Stephen Hanna To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases Thread-Index: Ac6R849yIIsiER8oT9evwtziU7dGeQAAWBkg Date: Mon, 5 Aug 2013 16:01:29 +0000 Message-ID: <250c25a43b3c470480ebd819688cf089@BLUPR05MB053.namprd05.prod.outlook.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128A4113@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4113@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0929F1BAED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%AVAYA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:02:29 -0000 Definitely yes! This document is a good start. Let's adopt it as a WG draft and work on the list to make it more complete and agreed-upon. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Monday, August 05, 2013 11:51 AM > To: sacm@ietf.org > Subject: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use- > cases as start point for WG I-D for use cases >=20 >=20 > At the SACM WG meeting at IETF-88 the participants in the room did not > raise any objection on the proposal to adopt draft-waltermire-sacm-use- > cases as start point for WG I-D for use cases. We are asking the WG to > confirm this consensus on the mail list. Please send all comments, > questions and concerns to the SACM WG mail list before 8/15. >=20 > Thanks and Regards, >=20 > Adam and Dan >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From Kent_Landfield@mcafee.com Mon Aug 5 09:05:55 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB70021F9D3A for ; Mon, 5 Aug 2013 09:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv7h+OOeMKZX for ; Mon, 5 Aug 2013 09:05:51 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 08AE321F9CE8 for ; Mon, 5 Aug 2013 09:05:33 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 1572_705a_88a6e772_204e_4982_ba3b_b1e75daa5345; Mon, 05 Aug 2013 11:05:25 -0500 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXAMER1N2.corp.nai.org ([169.254.3.103]) with mapi id 14.02.0328.009; Mon, 5 Aug 2013 12:04:01 -0400 From: To: , , Thread-Topic: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases Thread-Index: Ac6R849yIIsiER8oT9evwtziU7dGeQAAWBkg///wHYA= Date: Mon, 5 Aug 2013 16:03:51 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF2F16C9@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <250c25a43b3c470480ebd819688cf089@BLUPR05MB053.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.48.48.240] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF2F16C9MIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:05:55 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF2F16C9MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Stephen Hanna > Date: Monday, August 5, 2013 11:01 AM To: "Romascanu, Dan (Dan)" >,= "sacm@ietf.org" = > Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-= cases as start point for WG I-D for use cases Definitely yes! This document is a good start. Let's adopt it as a WG draft and work on the list to make it more complete and agreed-upon. Thanks, Steve -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Monday, August 05, 2013 11:51 AM To: sacm@ietf.org Subject: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use- cases as start point for WG I-D for use cases At the SACM WG meeting at IETF-88 the participants in the room did not raise any objection on the proposal to adopt draft-waltermire-sacm-use- cases as start point for WG I-D for use cases. We are asking the WG to confirm this consensus on the mail list. Please send all comments, questions and concerns to the SACM WG mail list before 8/15. Thanks and Regards, Adam and Dan _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_3CBA099FBA0AB843895D72474092B8CF2F16C9MIVEXAMER1N1corpn_ Content-Type: text/html; charset="us-ascii" Content-ID: <60F5083A667754469EA2B3AEC12ABCDB@McAfee.com> Content-Transfer-Encoding: quoted-printable
+1

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: Stephen Hanna <shanna@juniper.net>
Date: Monday, August 5, 2013 11:01 = AM
To: "Romascanu, Dan (Dan)"= ; <dromasca@avaya.com>, &qu= ot;sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] SACM - Consensu= s on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for= use cases

Definitely yes! This document is a good start.
Let's adopt it as a WG draft and work on the
list to make it more complete and agreed-upon.

Thanks,

Steve

-----Original Message-----
Romascanu, Dan (Dan)
Sent: Monday, August 05, 2013 11:51 AM
Subject: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use= -
cases as start point for WG I-D for use cases
At the SACM WG meeting at IETF-88 the participants in the room did not=
raise any objection on the proposal to adopt draft-waltermire-sacm-use= -
cases as start point for WG I-D for use cases. We are asking the WG to=
confirm this consensus on the mail list. Please send all comments,
questions and concerns to the SACM WG mail list before 8/15.
Thanks and Regards,
Adam and Dan
_______________________________________________
sacm mailing list



_______________________________________________
sacm mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF2F16C9MIVEXAMER1N1corpn_-- From Kent_Landfield@mcafee.com Mon Aug 5 09:05:56 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D91121F9CE8 for ; Mon, 5 Aug 2013 09:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZV0HqQUp+be for ; Mon, 5 Aug 2013 09:05:52 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id D368A21F9CA2 for ; Mon, 5 Aug 2013 09:05:35 -0700 (PDT) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 1578_2fae_05d1df73_8d1e_4ebc_9cef_fcdf6261a016; Mon, 05 Aug 2013 11:05:34 -0500 Received: from MIVEXEMEA1N2.corp.nai.org (10.48.48.32) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 5 Aug 2013 12:04:24 -0400 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.225]) by MIVEXEMEA1N2.corp.nai.org ([169.254.2.69]) with mapi id 14.02.0328.009; Mon, 5 Aug 2013 12:04:24 -0400 From: To: , Thread-Topic: [sacm] SACM - consensus on 'Way Forward' Thread-Index: Ac6R8xTLkINV4Y/AQbKf7+Autmo1N///8/gA Date: Mon, 5 Aug 2013 16:04:23 +0000 Message-ID: <3CBA099FBA0AB843895D72474092B8CF2F16D9@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.48.48.240] Content-Type: multipart/alternative; boundary="_000_3CBA099FBA0AB843895D72474092B8CF2F16D9MIVEXAMER1N1corpn_" MIME-Version: 1.0 Subject: Re: [sacm] SACM - consensus on 'Way Forward' X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:05:56 -0000 --_000_3CBA099FBA0AB843895D72474092B8CF2F16D9MIVEXAMER1N1corpn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I agree with this plan. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Dan (Dan)" > Date: Monday, August 5, 2013 10:47 AM To: "sacm@ietf.org" > Subject: [sacm] SACM - consensus on 'Way Forward' At the SACM WG meeting at IETF-88 the participants in the room did not rais= e any objection on the 'Way Forward' plan of action between now and IETF-88= presented by Adam Montville on behalf of the chairs. The plan included the= following: 8/16: Agreement on way forward on list 8/31: Adopt Use Case I-D as WG doc 9/13: Initial Requirements I-D submitted 9/30: Adopt Requirements I-D as WG doc 10/15: Initial Architecture I-Ds submitted IETF 88: Discuss architecture contributions and work for consensus We are asking the WG to confirm this consensus on the mail list. Please sen= d all comments, questions and concerns to the SACM WG mail list before 8/15= , so that the chairs can judge consensus on 8/16. Thanks and Regards, Adam and Dan _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_3CBA099FBA0AB843895D72474092B8CF2F16D9MIVEXAMER1N1corpn_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Yes, I agree with this plan.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: <Romascanu>, "Dan = (Dan)" <dromasca@avaya.com>
Date: Monday, August 5, 2013 10:47 = AM
To: "sacm@ietf.org" <sacm@i= etf.org>
Subject: [sacm] SACM - consensus on= 'Way Forward'

At the SACM WG meeting at IETF-88 the participants in the room did not= raise any objection on the 'Way Forward' plan of action between now and IE= TF-88 presented by Adam Montville on behalf of the chairs. The plan include= d the following:

8/16: Agreement on way forward on list
8/31: Adopt Use Case I-D as WG doc
9/13: Initial Requirements I-D submitted
9/30: Adopt Requirements I-D as WG doc
10/15: Initial Architecture I-Ds submitted
IETF 88: Discuss architecture contributions and work for consensus

We are asking the WG to confirm this consensus on the mail list. Pleas= e send all comments, questions and concerns to the SACM WG mail list before= 8/15, so that the chairs can judge consensus on 8/16.

Thanks and Regards,

Adam and Dan




_______________________________________________
sacm mailing list

 --_000_3CBA099FBA0AB843895D72474092B8CF2F16D9MIVEXAMER1N1corpn_-- From bakerj@mitre.org Mon Aug 5 09:06:48 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D2E21F9FE7 for ; Mon, 5 Aug 2013 09:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6zkp64LOMqs for ; Mon, 5 Aug 2013 09:06:39 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B408421F9EC3 for ; Mon, 5 Aug 2013 09:06:38 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2A9801F0926; Mon, 5 Aug 2013 12:06:38 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D32671F00D8; Mon, 5 Aug 2013 12:06:37 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.165]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0342.003; Mon, 5 Aug 2013 12:06:37 -0400 From: "Baker, Jon" To: "Kent_Landfield@McAfee.com" , "shanna@juniper.net" , "dromasca@avaya.com" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases Thread-Index: Ac6R849yIIsiER8oT9evwtziU7dGeQAAWBkg///wHYD//+6EwA== Date: Mon, 5 Aug 2013 16:06:37 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651304D2F687@IMCMBX03.MITRE.ORG> References: <250c25a43b3c470480ebd819688cf089@BLUPR05MB053.namprd05.prod.outlook.com> <3CBA099FBA0AB843895D72474092B8CF2F16C9@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF2F16C9@MIVEXAMER1N1.corp.nai.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_6C1C15D8B5510B4B8FF132B10D38651304D2F687IMCMBX03MITREOR_" MIME-Version: 1.0 Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:06:48 -0000 --_000_6C1C15D8B5510B4B8FF132B10D38651304D2F687IMCMBX03MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Monday, August 05, 2013 12:04 PM To: shanna@juniper.net; dromasca@avaya.com; sacm@ietf.org Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-= cases as start point for WG I-D for use cases +1 Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Stephen Hanna > Date: Monday, August 5, 2013 11:01 AM To: "Romascanu, Dan (Dan)" >,= "sacm@ietf.org" = > Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-= cases as start point for WG I-D for use cases Definitely yes! This document is a good start. Let's adopt it as a WG draft and work on the list to make it more complete and agreed-upon. Thanks, Steve -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Monday, August 05, 2013 11:51 AM To: sacm@ietf.org Subject: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use- cases as start point for WG I-D for use cases At the SACM WG meeting at IETF-88 the participants in the room did not raise any objection on the proposal to adopt draft-waltermire-sacm-use- cases as start point for WG I-D for use cases. We are asking the WG to confirm this consensus on the mail list. Please send all comments, questions and concerns to the SACM WG mail list before 8/15. Thanks and Regards, Adam and Dan _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_6C1C15D8B5510B4B8FF132B10D38651304D2F687IMCMBX03MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

Jon

 <= /p>

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Jonathan O. Baker

G022 - IA Industry Collab= oration

The MITRE Corporation

Email: bakerj@mitre.org<= /p>

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Monday, August 05, 2013 12:04 PM
To: shanna@juniper.net; dromasca@avaya.com; sacm@ietf.org
Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sa= cm-use-cases as start point for WG I-D for use cases

 

+1=

 =

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096  Mobile: +1.817.637.8026
Web: www.mcafee.com

 =

From: Stephen Hanna <shanna@juniper.net>
Date: Monday, August 5, 2013 11:01 AM
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "sacm@ietf.org" <sacm@ietf.o= rg>
Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sa= cm-use-cases as start point for WG I-D for use cases

 =

Definitely yes! This doc= ument is a good start.

Let's adopt it as a WG d= raft and work on the

list to make it more com= plete and agreed-upon.

 =

Thanks,

 =

Steve<= /p>

 =

-----Original Message---= --

Romascanu, Dan (Dan)

Sent: Monday, August 05,= 2013 11:51 AM

Subject: [sacm] SACM - C= onsensus on adopting draft-waltermire-sacm-use-

cases as start point for= WG I-D for use cases

At the SACM WG meeting a= t IETF-88 the participants in the room did not

raise any objection on t= he proposal to adopt draft-waltermire-sacm-use-

cases as start point for= WG I-D for use cases. We are asking the WG to

confirm this consensus o= n the mail list. Please send all comments,

questions and concerns t= o the SACM WG mail list before 8/15.

Thanks and Regards,=

Adam and Dan<= /span>

________________________= _______________________

sacm mailing list

 =

 =

 =

________________________= _______________________

sacm mailing list

 =

--_000_6C1C15D8B5510B4B8FF132B10D38651304D2F687IMCMBX03MITREOR_-- From bakerj@mitre.org Mon Aug 5 09:12:56 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB51E21F9F3D for ; Mon, 5 Aug 2013 09:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCnBY3TvLFxa for ; Mon, 5 Aug 2013 09:12:51 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6851F21F9ED4 for ; Mon, 5 Aug 2013 09:12:51 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1364D22602D7; Mon, 5 Aug 2013 12:12:51 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 03C5B22602E2; Mon, 5 Aug 2013 12:12:51 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.165]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0342.003; Mon, 5 Aug 2013 12:12:50 -0400 From: "Baker, Jon" To: "Kent_Landfield@McAfee.com" , "dromasca@avaya.com" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - consensus on 'Way Forward' Thread-Index: Ac6R8xTLkINV4Y/AQbKf7+Autmo1N///8/gA///s5dA= Date: Mon, 5 Aug 2013 16:12:50 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651304D2F6A8@IMCMBX03.MITRE.ORG> References: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com> <3CBA099FBA0AB843895D72474092B8CF2F16D9@MIVEXAMER1N1.corp.nai.org> In-Reply-To: <3CBA099FBA0AB843895D72474092B8CF2F16D9@MIVEXAMER1N1.corp.nai.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_6C1C15D8B5510B4B8FF132B10D38651304D2F6A8IMCMBX03MITREOR_" MIME-Version: 1.0 Subject: Re: [sacm] SACM - consensus on 'Way Forward' X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:12:56 -0000 --_000_6C1C15D8B5510B4B8FF132B10D38651304D2F6A8IMCMBX03MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Monday, August 05, 2013 12:04 PM To: dromasca@avaya.com; sacm@ietf.org Subject: Re: [sacm] SACM - consensus on 'Way Forward' Yes, I agree with this plan. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , "Dan (Dan)" > Date: Monday, August 5, 2013 10:47 AM To: "sacm@ietf.org" > Subject: [sacm] SACM - consensus on 'Way Forward' At the SACM WG meeting at IETF-88 the participants in the room did not rais= e any objection on the 'Way Forward' plan of action between now and IETF-88= presented by Adam Montville on behalf of the chairs. The plan included the= following: 8/16: Agreement on way forward on list 8/31: Adopt Use Case I-D as WG doc 9/13: Initial Requirements I-D submitted 9/30: Adopt Requirements I-D as WG doc 10/15: Initial Architecture I-Ds submitted IETF 88: Discuss architecture contributions and work for consensus We are asking the WG to confirm this consensus on the mail list. Please sen= d all comments, questions and concerns to the SACM WG mail list before 8/15= , so that the chairs can judge consensus on 8/16. Thanks and Regards, Adam and Dan _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm --_000_6C1C15D8B5510B4B8FF132B10D38651304D2F6A8IMCMBX03MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Monday, August 05, 2013 12:04 PM
To: dromasca@avaya.com; sacm@ietf.org
Subject: Re: [sacm] SACM - consensus on 'Way Forward'

 

Yes, I agree with this p= lan.

 =

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096  Mobile: +1.817.637.8026
Web: www.mcafee.com

 =

From: <Romascanu>, "Dan (Dan)"= ; <dromasca@avaya.com>
Date: Monday, August 5, 2013 10:47 AM
To: "sacm@ietf.org" &= lt;sacm@ietf.org>
Subject: [sacm] SACM - consensus on 'Way Forward'<= /p>

 =

At the SACM WG meeting a= t IETF-88 the participants in the room did not raise any objection on the '= Way Forward' plan of action between now and IETF-88 presented by Adam Montv= ille on behalf of the chairs. The plan included the following:

 =

8/16: Agreement on way f= orward on list

8/31: Adopt Use Case I-D= as WG doc

9/13: Initial Requiremen= ts I-D submitted

9/30: Adopt Requirements= I-D as WG doc

10/15: Initial Architect= ure I-Ds submitted

IETF 88: Discuss archite= cture contributions and work for consensus

 =

We are asking the WG to = confirm this consensus on the mail list. Please send all comments, question= s and concerns to the SACM WG mail list before 8/15, so that the chairs can= judge consensus on 8/16.

 =

Thanks and Regards,=

 =

Adam and Dan<= /span>

 =

 =

 =

 =

________________________= _______________________

sacm mailing list

 =

--_000_6C1C15D8B5510B4B8FF132B10D38651304D2F6A8IMCMBX03MITREOR_-- From gunnar.engelbach@threatguard.com Mon Aug 5 10:40:18 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF5221F9EAD for ; Mon, 5 Aug 2013 10:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3F0zsbP-Z-B for ; Mon, 5 Aug 2013 10:40:14 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDC521F9DD6 for ; Mon, 5 Aug 2013 10:40:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=brQKUKl3ljvhof3js72uZmVi5svk42vJ3X8xxrsCDRWLLX4a1wSl3YebrHNt0J6QV2vw1j8P/XnGcb7VTnIdbSjPtZbqUdcHi3Aq11+GzCtMdwprpzaHX3W5DmcdbxOp; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 31538 invoked from network); 5 Aug 2013 10:39:03 -0700 Received: from 97-125-26-97.eugn.qwest.net (HELO ?192.168.11.12?) (97.125.26.97) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Aug 2013 10:39:03 -0700 Message-ID: <51FFE375.1030307@ThreatGuard.com> Date: Mon, 05 Aug 2013 13:40:05 -0400 From: Gunnar Engelbach User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM - consensus on 'Way Forward' X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:40:18 -0000 +1 On 08/05/2013 11:47 AM, Romascanu, Dan (Dan) wrote: > At the SACM WG meeting at IETF-88 the participants in the room did not raise any objection on the 'Way Forward' plan of action between now and IETF-88 presented by Adam Montville on behalf of the chairs. The plan included the following: > > 8/16: Agreement on way forward on list > 8/31: Adopt Use Case I-D as WG doc > 9/13: Initial Requirements I-D submitted > 9/30: Adopt Requirements I-D as WG doc > 10/15: Initial Architecture I-Ds submitted > IETF 88: Discuss architecture contributions and work for consensus > > We are asking the WG to confirm this consensus on the mail list. Please send all comments, questions and concerns to the SACM WG mail list before 8/15, so that the chairs can judge consensus on 8/16. > > Thanks and Regards, > > Adam and Dan > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From stephen.whitlock@boeing.com Mon Aug 5 10:47:02 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7767921E80E0 for ; Mon, 5 Aug 2013 10:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9mqwS5PK1E4 for ; Mon, 5 Aug 2013 10:46:57 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5AC21F9FF3 for ; Mon, 5 Aug 2013 10:46:55 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r75HklbG028701 for ; Mon, 5 Aug 2013 12:46:48 -0500 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r75Hkls2028516 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 5 Aug 2013 12:46:47 -0500 Received: from XCH-BLV-103.nw.nos.boeing.com (130.247.25.118) by XCH-NWHT-08.nw.nos.boeing.com (130.247.25.112) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 5 Aug 2013 10:46:46 -0700 Received: from XCH-BLV-401.nw.nos.boeing.com ([169.254.1.219]) by XCH-BLV-103.nw.nos.boeing.com ([169.254.3.230]) with mapi id 14.02.0328.011; Mon, 5 Aug 2013 10:46:46 -0700 From: "Whitlock, Stephen" To: Gunnar Engelbach , "Romascanu, Dan (Dan)" Thread-Topic: [sacm] SACM - consensus on 'Way Forward' Thread-Index: AQHOkgLljjUa0EgaQE+TELY9sd0uYJmG42sA Date: Mon, 5 Aug 2013 17:46:45 +0000 Message-ID: <69235492DB20AC4EBBED65919EB0A2A6045EF6@XCH-BLV-401.nw.nos.boeing.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com> <51FFE375.1030307@ThreatGuard.com> In-Reply-To: <51FFE375.1030307@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM - consensus on 'Way Forward' X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:47:02 -0000 +1 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Gun= nar Engelbach Sent: Monday, August 05, 2013 10:40 AM To: Romascanu, Dan (Dan) Cc: sacm@ietf.org Subject: Re: [sacm] SACM - consensus on 'Way Forward' +1 On 08/05/2013 11:47 AM, Romascanu, Dan (Dan) wrote: > At the SACM WG meeting at IETF-88 the participants in the room did not ra= ise any objection on the 'Way Forward' plan of action between now and IETF-= 88 presented by Adam Montville on behalf of the chairs. The plan included t= he following: > > 8/16: Agreement on way forward on list > 8/31: Adopt Use Case I-D as WG doc > 9/13: Initial Requirements I-D submitted > 9/30: Adopt Requirements I-D as WG doc > 10/15: Initial Architecture I-Ds submitted IETF 88: Discuss=20 > architecture contributions and work for consensus > > We are asking the WG to confirm this consensus on the mail list. Please s= end all comments, questions and concerns to the SACM WG mail list before 8/= 15, so that the chairs can judge consensus on 8/16. > > Thanks and Regards, > > Adam and Dan > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From jclarke@cisco.com Mon Aug 5 14:41:41 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85AC21F9E80 for ; Mon, 5 Aug 2013 14:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ojnN34JxdIJ for ; Mon, 5 Aug 2013 14:41:36 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 743FC21F9DED for ; Mon, 5 Aug 2013 14:41:36 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r75LfXO5007347; Mon, 5 Aug 2013 17:41:33 -0400 (EDT) Received: from rtp-vpn5-53.cisco.com (rtp-vpn5-53.cisco.com [10.82.232.53]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r75LfQLn001677; Mon, 5 Aug 2013 17:41:29 -0400 (EDT) Message-ID: <52001C04.4040700@cisco.com> Date: Mon, 05 Aug 2013 17:41:24 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <9904FB1B0159DA42B0B887B7FA8119CA128A4113@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4113@AZ-FFEXMB04.global.avaya.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:41:42 -0000 On 8/5/13 11:50 AM, Romascanu, Dan (Dan) wrote: > > At the SACM WG meeting at IETF-88 the participants in the room did not raise any objection on the proposal to adopt draft-waltermire-sacm-use-cases as start point for WG I-D for use cases. We are asking the WG to confirm this consensus on the mail list. Please send all comments, questions and concerns to the SACM WG mail list before 8/15. +1 on adoption (noting that we were in IETF-87, not -88). Also, I have listed my need to clarify vulnerability management as well as perhaps adopt some sense of what it means to do vulnerability management independent of a network device. I have started this discussion on the mailing list already. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From dromasca@avaya.com Tue Aug 6 01:48:52 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D9B21F9D89 for ; Tue, 6 Aug 2013 01:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wssTma+5evkv for ; Tue, 6 Aug 2013 01:48:43 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id D3B2521F9D82 for ; Tue, 6 Aug 2013 01:48:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFACG3AFLGmAcV/2dsb2JhbABYA4JlIYEFvW4BgQ6BHxZ0giQBAQEBAxIoNAsMAgICAQgNBAQBAQEKFAUEBxsXFAkIAQEEDgUIGoduAZl9m38XBI5NEIEFIRAHBguDCHQDniiLB4FegTmBcTk X-IronPort-AV: E=Sophos;i="4.89,825,1367985600"; d="scan'208";a="23022637" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 06 Aug 2013 04:48:34 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Aug 2013 04:45:18 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Tue, 6 Aug 2013 04:48:33 -0400 From: "Romascanu, Dan (Dan)" To: Joe Marcus Clarke Thread-Topic: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases Thread-Index: Ac6R849yIIsiER8oT9evwtziU7dGeQAIDUcAABt3zrA= Date: Tue, 6 Aug 2013 08:48:32 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128A49C6@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128A4113@AZ-FFEXMB04.global.avaya.com> <52001C04.4040700@cisco.com> In-Reply-To: <52001C04.4040700@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 08:48:52 -0000 Thanks for the support and for the attentive reading. Of course it was 'onl= y' IETF-87! Regards, Dan > -----Original Message----- > From: Joe Marcus Clarke [mailto:jclarke@cisco.com] > Sent: Tuesday, August 06, 2013 12:41 AM > To: Romascanu, Dan (Dan) > Cc: sacm@ietf.org > Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sacm- > use-cases as start point for WG I-D for use cases >=20 > On 8/5/13 11:50 AM, Romascanu, Dan (Dan) wrote: > > > > At the SACM WG meeting at IETF-88 the participants in the room did not > raise any objection on the proposal to adopt draft-waltermire-sacm-use- > cases as start point for WG I-D for use cases. We are asking the WG to > confirm this consensus on the mail list. Please send all comments, > questions and concerns to the SACM WG mail list before 8/15. >=20 > +1 on adoption (noting that we were in IETF-87, not -88). Also, I have > listed my need to clarify vulnerability management as well as perhaps > adopt some sense of what it means to do vulnerability management > independent of a network device. I have started this discussion on the > mailing list already. >=20 > Joe >=20 > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > ------------------------------------------------------------------------ > ---- From kathleen.moriarty@emc.com Tue Aug 6 04:44:43 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D43F21F84EA for ; Tue, 6 Aug 2013 04:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLF8qLgr0WOH for ; Tue, 6 Aug 2013 04:44:38 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 849EE21F9DAF for ; Tue, 6 Aug 2013 04:44:24 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r76Bhcf7003251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 07:43:41 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 6 Aug 2013 07:43:23 -0400 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r76BhLA3003337; Tue, 6 Aug 2013 07:43:21 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Tue, 6 Aug 2013 07:43:21 -0400 From: "Moriarty, Kathleen" To: Gunnar Engelbach , Joe Marcus Clarke Date: Tue, 6 Aug 2013 07:43:19 -0400 Thread-Topic: [sacm] Feedback on vulnerability management use case Thread-Index: Ac6RTOGWDurPrL7gRZuaTQdnfDu/MgBTII7j Message-ID: References: <51FC4E85.8010501@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA1289E9D3@AZ-FFEXMB04.global.avaya.com> <51FE8D3A.8030109@cisco.com> <05BCCEB107AF88469B9F99783D47C1D673BFEE@CISEXCHANGE1.msisac.org.local> <51FE9977.4080600@cisco.com>,<51FEB21C.2000208@ThreatGuard.com> In-Reply-To: <51FEB21C.2000208@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "Romascanu, Dan \(Dan\)" , Jerome Athias , Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 11:44:43 -0000 For vulnerability information, there have been 2 efforts discussed previous= ly to bring to the IETF. NIST submitted the following draft, that I am sur= e if it is of interest could be updated (no longer expired): http://tools.ietf.org/html/draft-booth-sacm-vuln-model-01 There was also talk of CVRF coming into the IETF, possible in MILE since it= is related to that work. This has not happened yet and I don't have a cur= rent plan for them. Best regards, Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Gunnar Eng= elbach [Gunnar.Engelbach@ThreatGuard.com] Sent: Sunday, August 04, 2013 3:57 PM To: Joe Marcus Clarke Cc: Romascanu, Dan (Dan); Jerome Athias; Adam Montville; sacm@ietf.org Subject: Re: [sacm] Feedback on vulnerability management use case As Adam says, we'll want to go through the use case/requirements process and determine exactly what this working group is going to focus on, but I'll mention for now that the initial focus is security automation, which is deliberately non-specific. It's hard to imagine we won't, at a bare minimum, allow for automated assessment of software vulnerabilities and configuration compliance, but I think the goal is more to create tools sets that have the possibility of being used for other purposes as well. --gun On 08/04/2013 02:12 PM, Joe Marcus Clarke wrote: > On 8/4/13 2:05 PM, Adam Montville wrote: >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>> Joe Marcus Clarke >>> Sent: Sunday, August 04, 2013 10:20 AM >>> To: Romascanu, Dan (Dan) >>> Cc: Jerome Athias; sacm@ietf.org >>> Subject: Re: [sacm] Feedback on vulnerability management use case >>> >>> On 8/4/13 9:17 AM, Romascanu, Dan (Dan) wrote: >>>> Hi, >>>> >>>> >>>> >>>> The charter talks about information on vulnerabilities and >>>> vulnerability management. I agree that the system needs to be aware >>>> about existing vulnerabilities, I am not sure whether the description >>>> of vulnerabilities needs to be defined in this working group. >>>> According to the wording in the charter >>>> >>>> >>>> >>>> =D8 content repositories are expected >>>> to store up-to-date dictionary of specific enumerations, such as those >>>> used for configuration element identifiers, asset classifications, >>>> vulnerability identifiers, and so on. >>>> >>>> >>>> >>>> so it seems to be more about defining a format for vulnerability >>>> identifiers rather than semantics for vulnerability descriptions. >>> Hmmm....Above what you quote (in the charter) it talks about interfacin= g >>> with these repositories to store, update, and retrieve posture assessme= nt >>> content that may be used for vulnerability management (I paraphrased). >>> While an identifier alone might be sufficient for retrieval, storing ne= w data >>> about a vulnerability would imply (to me >>> anyway) a common data model for the vulnerability itself. >>> >> >> I think you both have valid points the working group may eventually need= to consider. At this point, we need to get the use cases figured out, con= sider which use cases we need to entertain, and then move forward from ther= e. > The reason I brought this up is that one use case for me in > vulnerability management, as a vendor, is to be able to publish my > vulnerabilities in a way that can be consumed by customers and > potentially other vendors (I'm thinking of OEMs) and vice versa. > >> I'm sure the WG would consider a use case for updating/augmenting vulner= ability context for inclusion in this chartered work or to, at least, consi= der for later phases. >> >> Additionally, I'd like to call attention to the terminology of "vulnerab= ility" and that we, typically, mean software vulnerability by it. It might= be more precise to call say so explicitly. There are many categories of v= ulnerabilities: Software, configuration, policy, process, etc. From my per= spective, it makes complete sense to be pedantic and state explicitly the t= ype of vulnerabilities we are interested in rather than assuming one type o= ver another. > I think that's fair. I was operating under a similar understanding of > vulnerability. > > Joe > _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From athiasjerome@gmail.com Tue Aug 6 05:50:17 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A7A21F9B07 for ; Tue, 6 Aug 2013 05:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGN0dlI4f-xt for ; Tue, 6 Aug 2013 05:50:15 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6101E21F9B01 for ; Tue, 6 Aug 2013 05:50:14 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so375279pbb.13 for ; Tue, 06 Aug 2013 05:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=baXwpi5D0hgB7h4tUkEkCoZ/4RhvnRVNI3w3g5XS9y8=; b=KL4xueukSFejrBgJvhgK17zpp1UJuTbilkwt8cQ8uL8OU3mrNfbGuzDrLNvdBAhjKf 5YS1VJQi/gfZJepRL2L/0dGxcyDq4+L+Oq5YzRYRxhBT6CqMJEXr09Abni50KhjweTKx gVgrXOhMAn5bOEheKFaSE6gi/kJJPQcw+vfggARml+IPMUZdz76uCqeT2xcgkpKRyqll bDIO0xP1rp45t0zZe3psjgwedi0UEZe3Oxo6kRhpulPKuHYC+AGoAmQ81GRYdvybnWig vRnUJnJdEWbAHhyiz2u+pAmt9O0o2l5LXZioewsh7qXpaxv9AfRHSWg70gmV2TbZYYkg 362w== MIME-Version: 1.0 X-Received: by 10.66.25.205 with SMTP id e13mr2987730pag.180.1375793414046; Tue, 06 Aug 2013 05:50:14 -0700 (PDT) Received: by 10.70.103.46 with HTTP; Tue, 6 Aug 2013 05:50:13 -0700 (PDT) In-Reply-To: References: <51FC4E85.8010501@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA1289E9D3@AZ-FFEXMB04.global.avaya.com> <51FE8D3A.8030109@cisco.com> <05BCCEB107AF88469B9F99783D47C1D673BFEE@CISEXCHANGE1.msisac.org.local> <51FE9977.4080600@cisco.com> <51FEB21C.2000208@ThreatGuard.com> Date: Tue, 6 Aug 2013 14:50:13 +0200 Message-ID: From: Jerome Athias To: "Moriarty, Kathleen" Content-Type: multipart/alternative; boundary=bcaec52998b3ba8b2f04e346ddbc Cc: Gunnar Engelbach , "Romascanu, Dan \(Dan\)" , Joe Marcus Clarke , Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 12:50:17 -0000 --bcaec52998b3ba8b2f04e346ddbc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, A Vulnerability Model is included in the XORCISM model http://www.frhack.org/research/xorcism.php As it is implemented, and used, it stores for example all CVEs, and other software vulnerabilities repositories It could be easily used also for other forms of vulnerabilities I would be happy to extract it to share and discuss it Best regards 2013/8/6 Moriarty, Kathleen > For vulnerability information, there have been 2 efforts discussed > previously to bring to the IETF. NIST submitted the following draft, tha= t > I am sure if it is of interest could be updated (no longer expired): > http://tools.ietf.org/html/draft-booth-sacm-vuln-model-01 > > There was also talk of CVRF coming into the IETF, possible in MILE since > it is related to that work. This has not happened yet and I don't have a > current plan for them. > > Best regards, > Kathleen > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Gunnar > Engelbach [Gunnar.Engelbach@ThreatGuard.com] > Sent: Sunday, August 04, 2013 3:57 PM > To: Joe Marcus Clarke > Cc: Romascanu, Dan (Dan); Jerome Athias; Adam Montville; sacm@ietf.org > Subject: Re: [sacm] Feedback on vulnerability management use case > > As Adam says, we'll want to go through the use case/requirements process > and determine exactly what this working group is going to focus on, but > I'll mention for now that the initial focus is security automation, > which is deliberately non-specific. It's hard to imagine we won't, at a > bare minimum, allow for automated assessment of software vulnerabilities > and configuration compliance, but I think the goal is more to create > tools sets that have the possibility of being used for other purposes as > well. > > > --gun > > On 08/04/2013 02:12 PM, Joe Marcus Clarke wrote: > > On 8/4/13 2:05 PM, Adam Montville wrote: > >> > >>> -----Original Message----- > >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > Of > >>> Joe Marcus Clarke > >>> Sent: Sunday, August 04, 2013 10:20 AM > >>> To: Romascanu, Dan (Dan) > >>> Cc: Jerome Athias; sacm@ietf.org > >>> Subject: Re: [sacm] Feedback on vulnerability management use case > >>> > >>> On 8/4/13 9:17 AM, Romascanu, Dan (Dan) wrote: > >>>> Hi, > >>>> > >>>> > >>>> > >>>> The charter talks about information on vulnerabilities and > >>>> vulnerability management. I agree that the system needs to be aware > >>>> about existing vulnerabilities, I am not sure whether the descriptio= n > >>>> of vulnerabilities needs to be defined in this working group. > >>>> According to the wording in the charter > >>>> > >>>> > >>>> > >>>> =D8 content repositories are expected > >>>> to store up-to-date dictionary of specific enumerations, such as tho= se > >>>> used for configuration element identifiers, asset classifications, > >>>> vulnerability identifiers, and so on. > >>>> > >>>> > >>>> > >>>> so it seems to be more about defining a format for vulnerability > >>>> identifiers rather than semantics for vulnerability descriptions. > >>> Hmmm....Above what you quote (in the charter) it talks about > interfacing > >>> with these repositories to store, update, and retrieve posture > assessment > >>> content that may be used for vulnerability management (I paraphrased)= . > >>> While an identifier alone might be sufficient for retrieval, storing > new data > >>> about a vulnerability would imply (to me > >>> anyway) a common data model for the vulnerability itself. > >>> > >> > >> I think you both have valid points the working group may eventually > need to consider. At this point, we need to get the use cases figured ou= t, > consider which use cases we need to entertain, and then move forward from > there. > > The reason I brought this up is that one use case for me in > > vulnerability management, as a vendor, is to be able to publish my > > vulnerabilities in a way that can be consumed by customers and > > potentially other vendors (I'm thinking of OEMs) and vice versa. > > > >> I'm sure the WG would consider a use case for updating/augmenting > vulnerability context for inclusion in this chartered work or to, at leas= t, > consider for later phases. > >> > >> Additionally, I'd like to call attention to the terminology of > "vulnerability" and that we, typically, mean software vulnerability by it= . > It might be more precise to call say so explicitly. There are many > categories of vulnerabilities: Software, configuration, policy, process, > etc. From my perspective, it makes complete sense to be pedantic and sta= te > explicitly the type of vulnerabilities we are interested in rather than > assuming one type over another. > > I think that's fair. I was operating under a similar understanding of > > vulnerability. > > > > Joe > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --bcaec52998b3ba8b2f04e346ddbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

A Vulnerability Model is incl= uded in the XORCISM model
http://www.frhack.org/research/xorcism.php
As it is implemented, and used, it stores for example all CVEs, = and other software vulnerabilities repositories
It could be= easily used also for other forms of vulnerabilities

I would be happy to extract it to share and discuss it

Best regards


2013/8/6 Moriarty, Kathleen <kathleen.moriarty@emc.com>
For vulnerability information, there have be= en 2 efforts discussed previously to bring to the IETF. =A0NIST submitted t= he following draft, that I am sure if it is of interest could be updated (n= o longer expired):
http://tools.ietf.org/html/draft-booth-sacm-vuln-model-01<= br>
There was also talk of CVRF coming into the IETF, possible in MILE since it= is related to that work. =A0This has not happened yet and I don't have= a current plan for them.

Best regards,
Kathleen
________________________________________
From: sacm-bounces@ietf.org [<= a href=3D"mailto:sacm-bounces@ietf.org">sacm-bounces@ietf.org] On Behal= f Of Gunnar Engelbach [Gunnar.Engelbach@ThreatGuard.com]
Sent: Sunday, August 04, 2013 3:57 PM
To: Joe Marcus Clarke
Cc: Romascanu, Dan (Dan); Jerome Athias; Adam Montville; sacm@ietf.org
Subject: Re: [sacm] Feedback on vul= nerability management use case

As Adam says, we'll want to go through the use case/requirements proces= s
and determine exactly what this working group is going to focus on, but
I'll mention for now that the initial focus is security automation,
which is deliberately non-specific. =A0It's hard to imagine we won'= t, at a
bare minimum, allow for automated assessment of software vulnerabilities and configuration compliance, but I think the goal is more to create
tools sets that have the possibility of being used for other purposes as well.


--gun

On 08/04/2013 02:12 PM, Joe Marcus Clarke wrote:
> On 8/4/13 2:05 PM, Adam Montville wrote:
>>
>>> -----Original Message-----
>>> From: sacm-bounces@ie= tf.org [mailto:sacm-bounces@ie= tf.org] On Behalf Of
>>> Joe Marcus Clarke
>>> Sent: Sunday, August 04, 2013 10:20 AM
>>> To: Romascanu, Dan (Dan)
>>> Cc: Jerome Athias; sacm@ietf.= org
>>> Subject: Re: [sacm] Feedback on vulnerability management use c= ase
>>>
>>> On 8/4/13 9:17 AM, Romascanu, Dan (Dan) wrote:
>>>> Hi,
>>>>
>>>>
>>>>
>>>> The charter talks about information on vulnerabilities and=
>>>> vulnerability management. I agree that the system needs to= be aware
>>>> about existing vulnerabilities, I am not sure whether the = description
>>>> of vulnerabilities needs to be defined in this working gro= up.
>>>> According to the wording in the charter
>>>>
>>>>
>>>>
>>>> =D8 =A0content repositories are expected
>>>> to store up-to-date dictionary of specific enumerations, s= uch as those
>>>> used for configuration element identifiers, asset classifi= cations,
>>>> vulnerability identifiers, and so on.
>>>>
>>>>
>>>>
>>>> so it seems to be more about defining a format for vulnera= bility
>>>> identifiers rather than semantics for vulnerability descri= ptions.
>>> Hmmm....Above what you quote (in the charter) it talks about i= nterfacing
>>> with these repositories to store, update, and retrieve posture= assessment
>>> content that may be used for vulnerability management (I parap= hrased).
>>> While an identifier alone might be sufficient for retrieval, s= toring new data
>>> about a vulnerability would imply (to me
>>> anyway) a common data model for the vulnerability itself.
>>>
>>
>> I think you both have valid points the working group may eventuall= y need to consider. =A0At this point, we need to get the use cases figured = out, consider which use cases we need to entertain, and then move forward f= rom there.
> The reason I brought this up is that one use case for me in
> vulnerability management, as a vendor, is to be able to publish my
> vulnerabilities in a way that can be consumed by customers and
> potentially other vendors (I'm thinking of OEMs) and vice versa. >
>> I'm sure the WG would consider a use case for updating/augment= ing vulnerability context for inclusion in this chartered work or to, at le= ast, consider for later phases.
>>
>> Additionally, I'd like to call attention to the terminology of= "vulnerability" and that we, typically, mean software vulnerabil= ity by it. =A0It might be more precise to call say so explicitly. =A0There = are many categories of vulnerabilities: Software, configuration, policy, pr= ocess, etc. =A0From my perspective, it makes complete sense to be pedantic = and state explicitly the type of vulnerabilities we are interested in rathe= r than assuming one type over another.
> I think that's fair. =A0I was operating under a similar understand= ing of
> vulnerability.
>
> Joe
>

_______________________= ________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm

--bcaec52998b3ba8b2f04e346ddbc-- From dromasca@avaya.com Tue Aug 6 05:57:36 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB7621F9E00 for ; Tue, 6 Aug 2013 05:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.437 X-Spam-Level: X-Spam-Status: No, score=-103.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4ZE1d6ME6bY for ; Tue, 6 Aug 2013 05:57:29 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5115A21F8F09 for ; Tue, 6 Aug 2013 05:57:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAG3yAFLGmAcV/2dsb2JhbABbgmUhgQW+fYEeFnSCJgEBAxIoUQEVFRRCJgEEGxqHbgGWAoREnB6OZIEFg1J0A54piwaDF4FxOQ X-IronPort-AV: E=Sophos;i="4.89,826,1367985600"; d="scan'208";a="22505594" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Aug 2013 08:57:15 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Aug 2013 08:53:59 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Tue, 6 Aug 2013 14:57:14 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6SpHgZAWpvrX0vRxuTXCLSjTwOnw== Date: Tue, 6 Aug 2013 12:57:13 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 12:57:36 -0000 At the SACM WG meeting at IETF-87 the participants in the room did not rais= e any objection to the proposal to separate the terminology section from dr= aft-waltermire-sacm-use-cases and make of it a separate document that defin= es the SACM terms in one place and can be referred by all other SACM docume= nts. We are asking the WG to confirm this consensus on the mail list. Pleas= e send all comments, questions and concerns to the SACM WG mail list before= 8/15. Thanks and Regards, Adam and Dan From shanna@juniper.net Tue Aug 6 06:47:11 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FCA21F9DA9 for ; Tue, 6 Aug 2013 06:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.533 X-Spam-Level: X-Spam-Status: No, score=-103.533 tagged_above=-999 required=5 tests=[AWL=3.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7lNqawWMidW for ; Tue, 6 Aug 2013 06:47:06 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id AAEF621F859B for ; Tue, 6 Aug 2013 06:47:06 -0700 (PDT) Received: from mail24-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE012.bigfish.com (10.236.130.75) with Microsoft SMTP Server id 14.1.225.22; Tue, 6 Aug 2013 13:47:05 +0000 Received: from mail24-co9 (localhost [127.0.0.1]) by mail24-co9-R.bigfish.com (Postfix) with ESMTP id CB604BA00E8; Tue, 6 Aug 2013 13:47:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371I542I1432I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail24-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(13464003)(199002)(189002)(164054003)(377454003)(63696002)(74316001)(16406001)(54316002)(66066001)(56776001)(80022001)(79102001)(50986001)(53806001)(54356001)(77982001)(59766001)(49866001)(76482001)(65816001)(33646001)(47976001)(47736001)(46102001)(19580405001)(83322001)(19580395003)(19580385001)(80976001)(83072001)(74662001)(74502001)(47446002)(561944002)(81342001)(81542001)(31966008)(74706001)(74366001)(77096001)(4396001)(76796001)(51856001)(76786001)(76576001)(56816003)(74876001)(69226001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB056; H:BLUPR05MB053.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail24-co9 (localhost.localdomain [127.0.0.1]) by mail24-co9 (MessageSwitch) id 1375796823629368_4536; Tue, 6 Aug 2013 13:47:03 +0000 (UTC) Received: from CO9EHSMHS030.bigfish.com (unknown [10.236.132.240]) by mail24-co9.bigfish.com (Postfix) with ESMTP id 8C64B20047; Tue, 6 Aug 2013 13:47:03 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS030.bigfish.com (10.236.130.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 6 Aug 2013 13:47:03 +0000 Received: from BLUPR05MB056.namprd05.prod.outlook.com (10.255.210.151) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 6 Aug 2013 13:47:00 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) by BLUPR05MB056.namprd05.prod.outlook.com (10.255.210.151) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 6 Aug 2013 13:46:58 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.169]) by BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.223]) with mapi id 15.00.0731.000; Tue, 6 Aug 2013 13:46:58 +0000 From: Stephen Hanna To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6SpHgZAWpvrX0vRxuTXCLSjTwOnwABu39A Date: Tue, 6 Aug 2013 13:46:58 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0930AAFAD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 13:47:11 -0000 Yes, that seems like a good idea. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Tuesday, August 06, 2013 8:57 AM > To: sacm@ietf.org > Subject: [sacm] SACM - consensus on defining SACM terminology in a > separate document >=20 > At the SACM WG meeting at IETF-87 the participants in the room did not > raise any objection to the proposal to separate the terminology section > from draft-waltermire-sacm-use-cases and make of it a separate document > that defines the SACM terms in one place and can be referred by all > other SACM documents. We are asking the WG to confirm this consensus on > the mail list. Please send all comments, questions and concerns to the > SACM WG mail list before 8/15. >=20 > Thanks and Regards, >=20 > Adam and Dan >=20 >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From aawoland@cisco.com Tue Aug 6 06:52:33 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEDA21F8C71 for ; Tue, 6 Aug 2013 06:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1EzaQBDO7UT for ; Tue, 6 Aug 2013 06:52:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 662D621F9950 for ; Tue, 6 Aug 2013 06:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1375; q=dns/txt; s=iport; t=1375797146; x=1377006746; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=MrbAsf9sf3HurWvtqN2W31IC/zvQ/hSWlHvNLKlIhG4=; b=Eji0IswMbm1iRRU6dtD30UlboGWtQiFHuRacEDccksQ1R6E3ln2s5vAW ZZQ1D05q9DM1/HjImErGr3t4IQeASFRE8VSDZMDdguhsbIBz/pSAqFS4l dXMeu38Zcpkiru7fD1BBEFpuMv1wVGP2Cf4CH0nFDq416UtvpJDb3t4VR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAGX+AFKtJXG+/2dsb2JhbABbgwY1UL59gR0WdIIkAQEBBAEBATc0FwYBCBEEAQELFAkuCxQJCAEBBAESCIgIDLZbBI5kgQU4BoMUdAOpL4MXgXE5 X-IronPort-AV: E=Sophos;i="4.89,826,1367971200"; d="scan'208";a="243876028" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 06 Aug 2013 13:52:25 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r76DqPYF003414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 13:52:25 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.107]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 08:52:25 -0500 From: "Aaron Woland (aawoland)" To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6SpHgZAWpvrX0vRxuTXCLSjTwOnwABu39AAAJKXAA= Date: Tue, 6 Aug 2013 13:52:25 +0000 Message-ID: <862FA31948313540BD2843B1AA96F25C46FE6067@xmb-rcd-x01.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.117.118.215] Content-Type: text/plain; charset="us-ascii" Content-ID: <155E790512B93B42A05DC655CCE15D12@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 13:52:33 -0000 I know I'm new to the WG, but that makes total sense to me. No objections. Aaron On 8/6/13 9:46 AM, "Stephen Hanna" wrote: >Yes, that seems like a good idea. > >Thanks, > >Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Romascanu, Dan (Dan) >> Sent: Tuesday, August 06, 2013 8:57 AM >> To: sacm@ietf.org >> Subject: [sacm] SACM - consensus on defining SACM terminology in a >> separate document >>=20 >> At the SACM WG meeting at IETF-87 the participants in the room did not >> raise any objection to the proposal to separate the terminology section >> from draft-waltermire-sacm-use-cases and make of it a separate document >> that defines the SACM terms in one place and can be referred by all >> other SACM documents. We are asking the WG to confirm this consensus on >> the mail list. Please send all comments, questions and concerns to the >> SACM WG mail list before 8/15. >>=20 >> Thanks and Regards, >>=20 >> Adam and Dan >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >>=20 > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From lnunez@mitre.org Tue Aug 6 07:03:43 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CA121F9F97 for ; Tue, 6 Aug 2013 07:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3623XFXT-vXF for ; Tue, 6 Aug 2013 07:03:38 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 13F8521F9EF5 for ; Tue, 6 Aug 2013 07:03:38 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 90FF71F09E7; Tue, 6 Aug 2013 10:03:37 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 78E491F074B; Tue, 6 Aug 2013 10:03:37 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.165]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0342.003; Tue, 6 Aug 2013 10:03:37 -0400 From: "Nunez, Luis K" To: "Aaron Woland (aawoland)" , "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6SpHgZAWpvrX0vRxuTXCLSjTwOnwABu39AAAJKXAAAAc6xIA== Date: Tue, 6 Aug 2013 14:03:36 +0000 Message-ID: References: <862FA31948313540BD2843B1AA96F25C46FE6067@xmb-rcd-x01.cisco.com> In-Reply-To: <862FA31948313540BD2843B1AA96F25C46FE6067@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 14:03:43 -0000 +1 Terminology such as remediation, mitigation and such will be helpful. -ln -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Aar= on Woland (aawoland) Sent: Tuesday, August 06, 2013 9:52 AM To: Romascanu, Dan (Dan); sacm@ietf.org Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a sepa= rate document I know I'm new to the WG, but that makes total sense to me. No objections. Aaron On 8/6/13 9:46 AM, "Stephen Hanna" wrote: >Yes, that seems like a good idea. > >Thanks, > >Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Romascanu, Dan (Dan) >> Sent: Tuesday, August 06, 2013 8:57 AM >> To: sacm@ietf.org >> Subject: [sacm] SACM - consensus on defining SACM terminology in a >> separate document >>=20 >> At the SACM WG meeting at IETF-87 the participants in the room did not >> raise any objection to the proposal to separate the terminology section >> from draft-waltermire-sacm-use-cases and make of it a separate document >> that defines the SACM terms in one place and can be referred by all >> other SACM documents. We are asking the WG to confirm this consensus on >> the mail list. Please send all comments, questions and concerns to the >> SACM WG mail list before 8/15. >>=20 >> Thanks and Regards, >>=20 >> Adam and Dan >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >>=20 > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From aawoland@cisco.com Tue Aug 6 06:08:15 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA49121F9E3C for ; Tue, 6 Aug 2013 06:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UXdRGcj6K52 for ; Tue, 6 Aug 2013 06:08:10 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 177F321F9E33 for ; Tue, 6 Aug 2013 06:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=838; q=dns/txt; s=iport; t=1375794490; x=1377004090; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=X3gFLnEnmANbsaJgarH1+1b7fEy3Qmk28XwootFPCHI=; b=A9/qeLZRLrGUP867RmTmNXNemm7gLvRmBuGcIbdMpeOXpPhrtX9zdZtP l948O85xnus7NxPrRp9dYdEx6gukCjoycZ5h7XG3gx52/DnyKEln3Ff2r 8KnefZn6OtJ0/bAGO2XSUkzmnDfcnTnd9zusg1h0XnjYbdzulgfleqdlz Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGAFz0AFKtJV2Y/2dsb2JhbABbgwY1UIJJvDSBHRZ0giYBBAEBATc0HQEIIhQ3CyUBAQQBEgiICAy2WASOZIEFOIMadAOpL4MXgXE5 X-IronPort-AV: E=Sophos;i="4.89,826,1367971200"; d="scan'208";a="244066617" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 06 Aug 2013 13:08:09 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r76D88er018945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 13:08:08 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.107]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 08:08:08 -0500 From: "Aaron Woland (aawoland)" To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6SpHgZAWpvrX0vRxuTXCLSjTwOnwACee6A Date: Tue, 6 Aug 2013 13:08:08 +0000 Message-ID: <862FA31948313540BD2843B1AA96F25C46FE5EA5@xmb-rcd-x01.cisco.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.117.118.215] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 06 Aug 2013 08:03:54 -0700 Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 13:08:16 -0000 I know I'm new to the WG, but that makes total sense to me. No objections. Aaron On 8/6/13 8:57 AM, "Romascanu, Dan (Dan)" wrote: >At the SACM WG meeting at IETF-87 the participants in the room did not >raise any objection to the proposal to separate the terminology section >from draft-waltermire-sacm-use-cases and make of it a separate document >that defines the SACM terms in one place and can be referred by all other >SACM documents. We are asking the WG to confirm this consensus on the >mail list. Please send all comments, questions and concerns to the SACM >WG mail list before 8/15. > >Thanks and Regards, > >Adam and Dan > > > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From shanna@juniper.net Tue Aug 6 08:18:39 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DFE21F9D52 for ; Tue, 6 Aug 2013 08:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=1.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um2t+iOpeMRv for ; Tue, 6 Aug 2013 08:18:34 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 1C26521F9E3C for ; Tue, 6 Aug 2013 08:18:32 -0700 (PDT) Received: from mail2-ch1-R.bigfish.com (10.43.68.247) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.22; Tue, 6 Aug 2013 15:18:31 +0000 Received: from mail2-ch1 (localhost [127.0.0.1]) by mail2-ch1-R.bigfish.com (Postfix) with ESMTP id 2CDE4260164; Tue, 6 Aug 2013 15:18:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I148cI542I1432I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail2-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(51704005)(199002)(189002)(164054003)(52604005)(24454002)(479174003)(377454003)(46102001)(51856001)(83072001)(74662001)(74502001)(31966008)(59766001)(77982001)(81342001)(47446002)(81542001)(76796001)(76786001)(56816003)(33646001)(77096001)(76482001)(561944002)(80022001)(65816001)(66066001)(54316002)(76576001)(56776001)(74316001)(69226001)(74366001)(53806001)(74876001)(63696002)(4396001)(47976001)(50986001)(49866001)(47736001)(74706001)(54356001)(79102001)(80976001)(19580385001)(83322001)(19580405001)(16406001)(19580395003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB053; H:BLUPR05MB053.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail2-ch1 (localhost.localdomain [127.0.0.1]) by mail2-ch1 (MessageSwitch) id 1375802309556600_12420; Tue, 6 Aug 2013 15:18:29 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233]) by mail2-ch1.bigfish.com (Postfix) with ESMTP id 65ED12004F; Tue, 6 Aug 2013 15:18:29 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 6 Aug 2013 15:18:25 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 6 Aug 2013 15:18:23 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) by BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 6 Aug 2013 15:18:22 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.169]) by BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.223]) with mapi id 15.00.0731.000; Tue, 6 Aug 2013 15:18:22 +0000 From: Stephen Hanna To: "Aaron Woland (aawoland)" , "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6SpHgZAWpvrX0vRxuTXCLSjTwOnwACee6AAAJW3lA= Date: Tue, 6 Aug 2013 15:18:21 +0000 Message-ID: <89ebc957e3684c2db80c4ba299bd0ced@BLUPR05MB053.namprd05.prod.outlook.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> <862FA31948313540BD2843B1AA96F25C46FE5EA5@xmb-rcd-x01.cisco.com> In-Reply-To: <862FA31948313540BD2843B1AA96F25C46FE5EA5@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0930AAFAD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:18:39 -0000 Aaron, We're all new to the WG. It was just created! ;-) Thanks for jumping in and expressing your opinion. That's a great way to get involved in an IETF WG. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Aaron Woland (aawoland) > Sent: Tuesday, August 06, 2013 9:08 AM > To: Romascanu, Dan (Dan); sacm@ietf.org > Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a > separate document >=20 > I know I'm new to the WG, but that makes total sense to me. >=20 > No objections. >=20 > Aaron >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 8/6/13 8:57 AM, "Romascanu, Dan (Dan)" wrote: >=20 > >At the SACM WG meeting at IETF-87 the participants in the room did not > >raise any objection to the proposal to separate the terminology > section > >from draft-waltermire-sacm-use-cases and make of it a separate > document > >that defines the SACM terms in one place and can be referred by all > other > >SACM documents. We are asking the WG to confirm this consensus on the > >mail list. Please send all comments, questions and concerns to the > SACM > >WG mail list before 8/15. > > > >Thanks and Regards, > > > >Adam and Dan > > > > > > > > > >_______________________________________________ > >sacm mailing list > >sacm@ietf.org > >https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From Adam.Montville@cisecurity.org Tue Aug 6 08:20:45 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C125721F9E33 for ; Tue, 6 Aug 2013 08:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rg-VPtqfLnWc for ; Tue, 6 Aug 2013 08:20:41 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.109]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACFF21F9E2B for ; Tue, 6 Aug 2013 08:20:40 -0700 (PDT) Received: from [216.82.253.227:4208] by server-13.bemta-7.messagelabs.com id 52/A3-01054-74411025; Tue, 06 Aug 2013 15:20:39 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-5.tower-170.messagelabs.com!1375802438!13984600!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 14423 invoked from network); 6 Aug 2013 15:20:39 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-5.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 6 Aug 2013 15:20:39 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Tue, 6 Aug 2013 11:20:38 -0400 From: Adam Montville To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6SpHgZAWpvrX0vRxuTXCLSjTwOnwAE6OWw Date: Tue, 6 Aug 2013 15:20:37 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D673CE82@CISEXCHANGE1.msisac.org.local> References: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:20:45 -0000 As a contributor, I believe a separate document is a good idea. As a chair, if we achieve rough consensus on this issue, we have someone w= ho is willing to be the author/maintainer of the document - not sure if th= at matters to anyone's decision-making process, but at least we know the d= ocument would be supported. > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Tuesday, August 06, 2013 5:58 AM > To: sacm@ietf.org > Subject: [sacm] SACM - consensus on defining SACM terminology in a > separate document >=20 > At the SACM WG meeting at IETF-87 the participants in the room did not r= aise > any objection to the proposal to separate the terminology section from > draft-waltermire-sacm-use-cases and make of it a separate document that > defines the SACM terms in one place and can be referred by all other SAC= M > documents. We are asking the WG to confirm this consensus on the mail li= st. > Please send all comments, questions and concerns to the SACM WG mail lis= t > before 8/15. >=20 > Thanks and Regards, >=20 > Adam and Dan >=20 >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... . . . From jclarke@cisco.com Tue Aug 6 08:33:37 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE7721F9E26 for ; Tue, 6 Aug 2013 08:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTmKnDAVbst8 for ; Tue, 6 Aug 2013 08:33:33 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A33D121F9D34 for ; Tue, 6 Aug 2013 08:33:32 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r76FXTf3028121; Tue, 6 Aug 2013 17:33:29 +0200 (CEST) Received: from dhcp-10-61-100-122.cisco.com (dhcp-10-61-100-122.cisco.com [10.61.100.122]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r76FWm78016304; Tue, 6 Aug 2013 17:33:16 +0200 (CEST) Message-ID: <5201171D.60000@cisco.com> Date: Tue, 06 Aug 2013 11:32:45 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:33:38 -0000 On 8/6/13 8:57 AM, Romascanu, Dan (Dan) wrote: > At the SACM WG meeting at IETF-87 the participants in the room did not raise any objection to the proposal to separate the terminology section from draft-waltermire-sacm-use-cases and make of it a separate document that defines the SACM terms in one place and can be referred by all other SACM documents. We are asking the WG to confirm this consensus on the mail list. Please send all comments, questions and concerns to the SACM WG mail list before 8/15. This approach makes sense to me. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From jclarke@cisco.com Tue Aug 6 08:37:02 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D33321F9F9E for ; Tue, 6 Aug 2013 08:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeE-A5sRwtor for ; Tue, 6 Aug 2013 08:36:58 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 139EC21F9F9D for ; Tue, 6 Aug 2013 08:36:57 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r76Faa7D028509; Tue, 6 Aug 2013 17:36:36 +0200 (CEST) Received: from dhcp-10-61-100-122.cisco.com (dhcp-10-61-100-122.cisco.com [10.61.100.122]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r76FYx1p017773; Tue, 6 Aug 2013 17:35:18 +0200 (CEST) Message-ID: <5201179E.8060205@cisco.com> Date: Tue, 06 Aug 2013 11:34:54 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Moriarty, Kathleen" References: <51FC4E85.8010501@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA1289E9D3@AZ-FFEXMB04.global.avaya.com> <51FE8D3A.8030109@cisco.com> <05BCCEB107AF88469B9F99783D47C1D673BFEE@CISEXCHANGE1.msisac.org.local> <51FE9977.4080600@cisco.com>, <51FEB21C.2000208@ThreatGuard.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Gunnar Engelbach , "Romascanu, Dan \(Dan\)" , Jerome Athias , Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:37:02 -0000 On 8/6/13 7:43 AM, Moriarty, Kathleen wrote: > For vulnerability information, there have been 2 efforts discussed previously to bring to the IETF. NIST submitted the following draft, that I am sure if it is of interest could be updated (no longer expired): > http://tools.ietf.org/html/draft-booth-sacm-vuln-model-01 > > There was also talk of CVRF coming into the IETF, possible in MILE since it is related to that work. This has not happened yet and I don't have a current plan for them. I would support CVRF coming into the IETF, but I think it fits more with SACM, honestly, given how I've read the charter and a need for this vulnerability management concept. Joe > > Best regards, > Kathleen > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach [Gunnar.Engelbach@ThreatGuard.com] > Sent: Sunday, August 04, 2013 3:57 PM > To: Joe Marcus Clarke > Cc: Romascanu, Dan (Dan); Jerome Athias; Adam Montville; sacm@ietf.org > Subject: Re: [sacm] Feedback on vulnerability management use case > > As Adam says, we'll want to go through the use case/requirements process > and determine exactly what this working group is going to focus on, but > I'll mention for now that the initial focus is security automation, > which is deliberately non-specific. It's hard to imagine we won't, at a > bare minimum, allow for automated assessment of software vulnerabilities > and configuration compliance, but I think the goal is more to create > tools sets that have the possibility of being used for other purposes as > well. > > > --gun > > On 08/04/2013 02:12 PM, Joe Marcus Clarke wrote: >> On 8/4/13 2:05 PM, Adam Montville wrote: >>> >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>>> Joe Marcus Clarke >>>> Sent: Sunday, August 04, 2013 10:20 AM >>>> To: Romascanu, Dan (Dan) >>>> Cc: Jerome Athias; sacm@ietf.org >>>> Subject: Re: [sacm] Feedback on vulnerability management use case >>>> >>>> On 8/4/13 9:17 AM, Romascanu, Dan (Dan) wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> The charter talks about information on vulnerabilities and >>>>> vulnerability management. I agree that the system needs to be aware >>>>> about existing vulnerabilities, I am not sure whether the description >>>>> of vulnerabilities needs to be defined in this working group. >>>>> According to the wording in the charter >>>>> >>>>> >>>>> >>>>> Ø content repositories are expected >>>>> to store up-to-date dictionary of specific enumerations, such as those >>>>> used for configuration element identifiers, asset classifications, >>>>> vulnerability identifiers, and so on. >>>>> >>>>> >>>>> >>>>> so it seems to be more about defining a format for vulnerability >>>>> identifiers rather than semantics for vulnerability descriptions. >>>> Hmmm....Above what you quote (in the charter) it talks about interfacing >>>> with these repositories to store, update, and retrieve posture assessment >>>> content that may be used for vulnerability management (I paraphrased). >>>> While an identifier alone might be sufficient for retrieval, storing new data >>>> about a vulnerability would imply (to me >>>> anyway) a common data model for the vulnerability itself. >>>> >>> >>> I think you both have valid points the working group may eventually need to consider. At this point, we need to get the use cases figured out, consider which use cases we need to entertain, and then move forward from there. >> The reason I brought this up is that one use case for me in >> vulnerability management, as a vendor, is to be able to publish my >> vulnerabilities in a way that can be consumed by customers and >> potentially other vendors (I'm thinking of OEMs) and vice versa. >> >>> I'm sure the WG would consider a use case for updating/augmenting vulnerability context for inclusion in this chartered work or to, at least, consider for later phases. >>> >>> Additionally, I'd like to call attention to the terminology of "vulnerability" and that we, typically, mean software vulnerability by it. It might be more precise to call say so explicitly. There are many categories of vulnerabilities: Software, configuration, policy, process, etc. From my perspective, it makes complete sense to be pedantic and state explicitly the type of vulnerabilities we are interested in rather than assuming one type over another. >> I think that's fair. I was operating under a similar understanding of >> vulnerability. >> >> Joe >> > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From ncamwing@cisco.com Tue Aug 6 09:29:49 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013EA21F8C0C for ; Tue, 6 Aug 2013 09:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulWhhzV7LeBq for ; Tue, 6 Aug 2013 09:29:44 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC6721F9FF6 for ; Tue, 6 Aug 2013 09:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=679; q=dns/txt; s=iport; t=1375806571; x=1377016171; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=U4JLpoVirFJZdWEWE1r2gqEu9Ynjrp8rMOCd0La6e1U=; b=ar9qO9YY36UO8lQPymwSQj8wTZAJL1s5KHyFgaPEIgon17xttocw4iGY YYzfbTMs9D/p9BGiJQae++bjlFoncYm1rXrazuN/TTcjcepuomkvSQmKC LPpjTmuBrsUjeYavGft6qodpzXhLgJoKcv39TWN/N9daA07jTgiE4eHVL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsGACgjAVKtJV2d/2dsb2JhbABagwY1UIJJuyaBDoEeFnSCJgEEAQEBNzQdAQgiFAUyCyUCBAESCIgIDLZgBI5kgQU4gxp0A6kvgV6BOYFxOQ X-IronPort-AV: E=Sophos;i="4.89,827,1367971200"; d="scan'208";a="244153576" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 06 Aug 2013 16:29:30 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r76GTTlm005747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 16:29:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 11:29:29 -0500 From: "Nancy Cam-Winget (ncamwing)" To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases Thread-Index: AQHOksIfDpzS3/zvhU+RtfcVQvpjgw== Date: Tue, 6 Aug 2013 16:29:28 +0000 Message-ID: In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4113@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.155.84.23] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 16:29:49 -0000 Yes, I am good with this draft as the starting base. Nancy. On 8/5/13 8:50 AM, "Romascanu, Dan (Dan)" wrote: > >At the SACM WG meeting at IETF-88 the participants in the room did not >raise any objection on the proposal to adopt >draft-waltermire-sacm-use-cases as start point for WG I-D for use cases. >We are asking the WG to confirm this consensus on the mail list. Please >send all comments, questions and concerns to the SACM WG mail list before >8/15. > >Thanks and Regards, > >Adam and Dan > > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From ncamwing@cisco.com Tue Aug 6 09:31:11 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4146621F8E2A for ; Tue, 6 Aug 2013 09:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mj+sMNZTy1KT for ; Tue, 6 Aug 2013 09:31:06 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0156E21F97C7 for ; Tue, 6 Aug 2013 09:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1524; q=dns/txt; s=iport; t=1375806666; x=1377016266; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=KkFd3oQoYCJ7Mx8VlDcnn92gTGHcOTk/KgSDmggJKNI=; b=H4X4OzfkS3yiowRnmR62yTx5u1Apq3lSdn/2QijbMtillTSd1cDu4KcC Hf/iXhqmyz6xy2Ioo5tEd2W3L1r1FtK8DsLsVzxKan0vAzp6F9a9ygpaH Vee0YXAgp0FrXAtPxnT574fQcoG67CttrlAccZAiZWYZKuFeGVAAocT39 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAOAjAVKtJXG8/2dsb2JhbABagwY1UL59gR4WdIIkAQEBBAEBATc0FwYBCA4DAQMBAQsUCS4LFAMGCAIEARIIiAgMtlsEjmSBBTgGgxR0A6kvgxeBcTk X-IronPort-AV: E=Sophos;i="4.89,827,1367971200"; d="scan'208";a="241154190" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 06 Aug 2013 16:31:03 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r76GV3w0018707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 16:31:03 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 11:31:03 -0500 From: "Nancy Cam-Winget (ncamwing)" To: Stephen Hanna , "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - consensus on 'Way Forward' Thread-Index: AQHOksJX3qd2pluvxUeDfgvr8DDdIA== Date: Tue, 6 Aug 2013 16:31:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.155.84.23] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM - consensus on 'Way Forward' X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 16:31:11 -0000 +1 On 8/5/13 9:00 AM, "Stephen Hanna" wrote: >Yes, I agree with this plan. > >Thanks, > >Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Romascanu, Dan (Dan) >> Sent: Monday, August 05, 2013 11:47 AM >> To: sacm@ietf.org >> Subject: [sacm] SACM - consensus on 'Way Forward' >>=20 >> At the SACM WG meeting at IETF-88 the participants in the room did not >> raise any objection on the 'Way Forward' plan of action between now and >> IETF-88 presented by Adam Montville on behalf of the chairs. The plan >> included the following: >>=20 >> 8/16: Agreement on way forward on list >> 8/31: Adopt Use Case I-D as WG doc >> 9/13: Initial Requirements I-D submitted >> 9/30: Adopt Requirements I-D as WG doc >> 10/15: Initial Architecture I-Ds submitted >> IETF 88: Discuss architecture contributions and work for consensus >>=20 >> We are asking the WG to confirm this consensus on the mail list. Please >> send all comments, questions and concerns to the SACM WG mail list >> before 8/15, so that the chairs can judge consensus on 8/16. >>=20 >> Thanks and Regards, >>=20 >> Adam and Dan >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >>=20 > > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From ncamwing@cisco.com Tue Aug 6 09:34:05 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AAB21E8088 for ; Tue, 6 Aug 2013 09:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7gV+Yrw+k86 for ; Tue, 6 Aug 2013 09:34:00 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 80DD921E8087 for ; Tue, 6 Aug 2013 09:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1830; q=dns/txt; s=iport; t=1375806840; x=1377016440; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=xVsu9jC74pFK/cZ4LPXwnHrxtTart6rgy2oqATm2c94=; b=R6SMa7ZCs2HiduZqbkEM6rezuqE5zTF1U5x4NrekbXhL49ikA13gCtew 2Uj+vqIPCcDNXA8XpUh+HkHC/HtvcJ5rIfPymxWkUj1cU9izJgj4qsm1z 8K21VD5Pjf/zkYHdUKGnuS5fw8GQvu7vKl3zE0NvoQRW4GJtfNWKGaUxV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAA8lAVKtJXG9/2dsb2JhbABagwY1UL59gR8WdIIkAQEBBAEBAWsXBgEIEQEDAQELHS4LFAMGCAIEARIIiAgMtmUEjmSBBQYyBoMUdAOpL4MXgXE5 X-IronPort-AV: E=Sophos;i="4.89,827,1367971200"; d="scan'208";a="241155678" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 06 Aug 2013 16:34:00 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r76GY0iq003140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 16:34:00 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 11:33:59 -0500 From: "Nancy Cam-Winget (ncamwing)" To: Adam Montville , "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: AQHOksLAVyoB6NHcg0iQfkjv+vE6Ig== Date: Tue, 6 Aug 2013 16:33:58 +0000 Message-ID: In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D673CE82@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.155.84.23] Content-Type: text/plain; charset="Windows-1252" Content-ID: <30D7E5520667EB48931ADDA4F45314F2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 16:34:05 -0000 A separate document is good=8A A suggestion could be to have the current authors of the Use Cases, Architecture and Requirements take the initial pen as we'll be updating the terminology as we evolve the respective drafts too=8A. Nancy. On 8/6/13 8:20 AM, "Adam Montville" wrote: >As a contributor, I believe a separate document is a good idea. > >As a chair, if we achieve rough consensus on this issue, we have someone >who is willing to be the author/maintainer of the document - not sure if >that matters to anyone's decision-making process, but at least we know >the document would be supported. > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Romascanu, Dan (Dan) >> Sent: Tuesday, August 06, 2013 5:58 AM >> To: sacm@ietf.org >> Subject: [sacm] SACM - consensus on defining SACM terminology in a >> separate document >>=20 >> At the SACM WG meeting at IETF-87 the participants in the room did not >>raise >> any objection to the proposal to separate the terminology section from >> draft-waltermire-sacm-use-cases and make of it a separate document that >> defines the SACM terms in one place and can be referred by all other >>SACM >> documents. We are asking the WG to confirm this consensus on the mail >>list. >> Please send all comments, questions and concerns to the SACM WG mail >>list >> before 8/15. >>=20 >> Thanks and Regards, >>=20 >> Adam and Dan >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >>=20 >> ... > >. . . >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From bakerj@mitre.org Tue Aug 6 10:33:16 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E551121E8086 for ; Tue, 6 Aug 2013 10:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaSX5Xaas1NV for ; Tue, 6 Aug 2013 10:33:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 32B0B21F9ED2 for ; Tue, 6 Aug 2013 10:33:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AA5F01F09FB for ; Tue, 6 Aug 2013 13:33:08 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9055C1F0409 for ; Tue, 6 Aug 2013 13:33:08 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.165]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Tue, 6 Aug 2013 13:33:08 -0400 From: "Baker, Jon" To: "sacm@ietf.org" Thread-Topic: [Netconf] [netmod] development plan Thread-Index: AQHOkdp3Zrixa9H9GUOrS6K9JR4LhJmG33MAgAAJJICAAB2bgIAAIGsAgAEMkACAAD4fcA== Date: Tue, 6 Aug 2013 17:33:07 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651304D313DD@IMCMBX03.MITRE.ORG> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> In-Reply-To: <5200C61C.4090103@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] FW: [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:33:17 -0000 How closely are SACM WG participants also following the ongoing netconf dis= cussion? This message seems to directly align with some of the work I have expected = SACM to do. Take a look at this quote in particular: > A configuration datastore is defined as the complete set of configuratio= n data >that > is required to get a device from its initial default state into a > desired operational state. The configuration datastore does not > include state data or executive commands. > > The running configuration datastore holds the complete configuration > currently active on the network device. Only one configuration > datastore of this type exists on the device, and it is always > present. Given that the netconf wg seems to be in the middle of a very active discus= sion on very closely related topics I would suggest that we specifically re= ach out to the netconf group to ensure alignment and reuse where possible.= =20 Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf >Of Balazs Lengyel >Sent: Tuesday, August 06, 2013 5:47 AM >To: Ladislav Lhotka >Cc: netmod@ietf.org; Netconf >Subject: Re: [Netconf] [netmod] development plan > > >On 2013-08-05 19:45, Ladislav Lhotka wrote: >> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel >wrote: >> >>> On 2013-08-05 16:03, Ladislav Lhotka wrote: >>>> It is a fact of life that YANG is being used outside NETCONF, and ther= e are >more plans for doing do, but with 6020 it is a slippery slope. For example= , >such non-NETCONF applications of YANG will most likely want to use "must" >for expressing semantic constraints. However, the accessible tree for "mus= t" is >defined like so: >>>> >>>> o If the context node represents configuration, the tree is the d= ata >>>> in the NETCONF datastore where the context node exists. The XP= ath >>>> root node has all top-level configuration data nodes in all >>>> modules as children. >>>> >>>> o If the context node represents state data, the tree is all stat= e >>>> data on the device, and the datastore. The XPath ro= ot >>>> node has all top-level data nodes in all modules as children. >>>> >>>> This cannot be unambiguously interpreted in a non-NETCONF context, so >it is effectively undefined, which is rather dangerous. >>>> So I don't mean to completely redesign YANG, but we cannot, on the >other hand, enable non-NETCONF YANG data modelling without providing >new definitions. >>>> >>>> Lada >>> In my view Netconf contains the "pure" protocol (encoding, operations, >transactional behavior...) and background plumbing (datastores, separation= of >state and config data, hierarchical data organisation, filtering, connecti= on >requirements, session concept, capability negotiation, many of the capabil= ites, >error messages). >>> The background plumbing is valid for all access methods (CLI, Netconf, >YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be redefined= . >> I don't think this is true. I2RS will probably have no distinction betwe= en >config and state data, though they may have read-write and read-only. >Sessions and capability negotiation are by no means necessary (RESTCONF >doesn't have it). I can actually imagine data modelling without any specif= ic >protocol for data exchange. >> >> Lada >IMHO we can debate whether some protocols need some of the features, or >whether some of the features belong to the plumbing or the pure >protocol, but I still believe that many of the concepts like "NETCONF >datastore" above are actually easily understandable without considering >the protocol on the wire. If you would just remove the word Netconf from >your example paragraphs IMHO they are quite understandable in a protocol >independent way. > >Let me just try as an exercise: >Running Datastore: > > A configuration datastore is defined as the complete set of configuratio= n data >that > is required to get a device from its initial default state into a > desired operational state. The configuration datastore does not > include state data or executive commands. > > The running configuration datastore holds the complete configuration > currently active on the network device. Only one configuration > datastore of this type exists on the device, and it is always > present. > >The above defeinition is extracted from RFC6241 (I just removed 2 >sentences). I think it is a very nice protocol independent definition. > > >Does anyone have a list of features that make YANG protocol (Netconf) >dependent? > >Balazs > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From bakerj@mitre.org Tue Aug 6 10:43:48 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2D711E80A2 for ; Tue, 6 Aug 2013 10:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtfvR6RksgfI for ; Tue, 6 Aug 2013 10:43:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E3CAA21E808A for ; Tue, 6 Aug 2013 10:43:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 660C41F06FD; Tue, 6 Aug 2013 13:43:37 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4ACE61F0438; Tue, 6 Aug 2013 13:43:37 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.165]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0342.003; Tue, 6 Aug 2013 13:43:37 -0400 From: "Baker, Jon" To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6SpHgZAWpvrX0vRxuTXCLSjTwOnwAJ5WVg Date: Tue, 6 Aug 2013 17:43:36 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651304D3143A@IMCMBX03.MITRE.ORG> References: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:43:48 -0000 A stand-alone document for now seems reasonable.=20 Somewhere down the road, after the use cases and requirements are more stab= le, we may want to consolidate some of these documents. Maybe in the end we= can have one document that covers use cases and then the derived requireme= nts and terms? This would allow all of our drafts to then reference this one location for = requirements, terms, and use cases. It may also be a bit easier for someone= new to ramp up on what the WG is trying to achieve. Thanks, Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Romascanu, Dan (Dan) >Sent: Tuesday, August 06, 2013 8:57 AM >To: sacm@ietf.org >Subject: [sacm] SACM - consensus on defining SACM terminology in a separat= e >document > >At the SACM WG meeting at IETF-87 the participants in the room did not rai= se >any objection to the proposal to separate the terminology section from dra= ft- >waltermire-sacm-use-cases and make of it a separate document that defines >the SACM terms in one place and can be referred by all other SACM >documents. We are asking the WG to confirm this consensus on the mail list= . >Please send all comments, questions and concerns to the SACM WG mail list >before 8/15. > >Thanks and Regards, > >Adam and Dan > > > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From Adam.Montville@cisecurity.org Tue Aug 6 10:53:13 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6869921E80AD for ; Tue, 6 Aug 2013 10:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.782 X-Spam-Level: X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEs2MWo0z4E4 for ; Tue, 6 Aug 2013 10:53:08 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.10]) by ietfa.amsl.com (Postfix) with ESMTP id 12F3521E8096 for ; Tue, 6 Aug 2013 10:52:51 -0700 (PDT) Received: from [216.82.250.19:64270] by server-10.bemta-12.messagelabs.com id 82/37-14756-1F731025; Tue, 06 Aug 2013 17:52:49 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-6.tower-87.messagelabs.com!1375811561!15693708!3 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 30504 invoked from network); 6 Aug 2013 17:52:49 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-6.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 6 Aug 2013 17:52:49 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::9d91:1cd4:d9fb:616c%14]) with mapi id 14.02.0342.003; Tue, 6 Aug 2013 13:52:44 -0400 From: Adam Montville To: "Baker, Jon" , "sacm@ietf.org" Thread-Topic: [Netconf] [netmod] development plan Thread-Index: AQHOkdp3Zrixa9H9GUOrS6K9JR4LhJmG33MAgAAJJICAAB2bgIAAIGsAgAEMkACAAD4fcIAABdmQ Date: Tue, 6 Aug 2013 17:52:43 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D673D033@CISEXCHANGE1.msisac.org.local> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <6C1C15D8B5510B4B8FF132B10D38651304D313DD@IMCMBX03.MITRE.ORG> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D38651304D313DD@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:53:14 -0000 Thanks for pointing this out, Jon. Is anyone on this list also working in netconf? On the surface, they look= very similar. It would be interesting to understand where, from an archi= tectural perspective, the datastore is said to reside for netconf and how = it should be accessed. I also find the phrase about not storing executive= commands interesting, because, presumably, some of the information we wan= t to store will be instructional in nature. > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Baker, Jon > Sent: Tuesday, August 06, 2013 10:34 AM > To: sacm@ietf.org > Subject: [sacm] FW: [Netconf] [netmod] development plan >=20 > How closely are SACM WG participants also following the ongoing netconf > discussion? >=20 > This message seems to directly align with some of the work I have expect= ed > SACM to do. Take a look at this quote in particular: >=20 > > A configuration datastore is defined as the complete set of > >configuration data that > > is required to get a device from its initial default state into a > > desired operational state. The configuration datastore does not > > include state data or executive commands. > > > > The running configuration datastore holds the complete configuratio= n > > currently active on the network device. Only one configuration > > datastore of this type exists on the device, and it is always > > present. >=20 > Given that the netconf wg seems to be in the middle of a very active > discussion on very closely related topics I would suggest that we specif= ically > reach out to the netconf group to ensure alignment and reuse where > possible. >=20 > Jon >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Jonathan O. Baker > G022 - IA Industry Collaboration > The MITRE Corporation > Email: bakerj@mitre.org >=20 >=20 > >-----Original Message----- > >From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > >Behalf Of Balazs Lengyel > >Sent: Tuesday, August 06, 2013 5:47 AM > >To: Ladislav Lhotka > >Cc:=20netmod@ietf.org; Netconf > >Subject: Re: [Netconf] [netmod] development plan > > > > > >On 2013-08-05 19:45, Ladislav Lhotka wrote: > >> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel > >> > >wrote: > >> > >>> On 2013-08-05 16:03, Ladislav Lhotka wrote: > >>>> It is a fact of life that YANG is being used outside NETCONF, and > >>>> there are > >more plans for doing do, but with 6020 it is a slippery slope. For > >example, such non-NETCONF applications of YANG will most likely want to= > use "must" > >for expressing semantic constraints. However, the accessible tree for > >"must" is defined like so: > >>>> > >>>> o If the context node represents configuration, the tree is th= e data > >>>> in the NETCONF datastore where the context node exists. The= > XPath > >>>> root node has all top-level configuration data nodes in all > >>>> modules as children. > >>>> > >>>> o If the context node represents state data, the tree is all s= tate > >>>> data on the=20device, and the datastore. The XPa= th root > >>>> node has all top-level data nodes in all modules as children= . > >>>> > >>>> This cannot be unambiguously interpreted in a non-NETCONF context, > >>>> so > >it is effectively undefined, which is rather dangerous. > >>>> So I don't mean to completely redesign YANG, but we cannot, on the > >other hand, enable non-NETCONF YANG data modelling without providing > >new definitions. > >>>> > >>>> Lada > >>> In my view Netconf contains the "pure" protocol (encoding, > >>> operations, > >transactional behavior...) and background plumbing (datastores, > >separation of state and config data, hierarchical data organisation, > >filtering, connection requirements, session concept, capability > >negotiation, many of the capabilites, error messages). > >>> The background plumbing is valid for all access methods (CLI, > >>> Netconf, > >YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be redefi= ned. > >> I don't think this is true. I2RS will probably have no distinction > >> between > >config and state data, though they may have read-write and read-only. > >Sessions and capability negotiation are by no means necessary (RESTCONF= > >doesn't have it). I can actually imagine data modelling without any > >specific protocol for data exchange. > >> > >> Lada > >IMHO we can debate whether some protocols need some of the features, > or > >whether some of the features belong to the plumbing or the pure > >protocol, but I still believe that many of the concepts like "NETCONF > >datastore" above are actually easily understandable without considering= > >the protocol on the wire. If you would just remove the word Netconf > >from your example paragraphs IMHO they are quite understandable in a > >protocol independent way. > > > >Let me just try as an exercise: > >Running Datastore: > > > > A configuration datastore is defined as the complete set of > >configuration data that > > is required to get a device from its initial default state into a > > desired operational state. The configuration datastore does not > > include state data or executive commands. > > > > The running configuration datastore holds the complete configuratio= n > > currently active on the network device. Only one configuration > > datastore of this type exists on the device, and it is always > > present. > > > >The above defeinition is extracted from RFC6241 (I just removed 2 > >sentences). I think it is a very nice protocol independent definition. > > > > > >Does anyone have a list of features that make YANG protocol (Netconf) > >dependent? > > > >Balazs > > > >_______________________________________________ > >Netconf mailing list > >Netconf@ietf.org > >https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... . . . From jarrett.lu@oracle.com Tue Aug 6 11:13:13 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E23721E809B for ; Tue, 6 Aug 2013 11:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QAEgVAdaDxV for ; Tue, 6 Aug 2013 11:13:07 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 18D6221F9971 for ; Tue, 6 Aug 2013 11:13:04 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76ID2MU013103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Aug 2013 18:13:03 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76ID24d006260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Aug 2013 18:13:02 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76ID2ZO012447 for ; Tue, 6 Aug 2013 18:13:02 GMT Received: from [10.132.148.74] (/10.132.148.74) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 11:13:01 -0700 Message-ID: <52013F5B.6030609@oracle.com> Date: Tue, 06 Aug 2013 11:24:27 -0700 From: Jarrett Lu User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sacm@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA128A4113@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4113@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jarrett.lu@oracle.com List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 18:13:13 -0000 On 08/ 5/13 08:50 AM, Romascanu, Dan (Dan) wrote: > At the SACM WG meeting at IETF-88 the participants in the room did not raise any objection on the proposal to adopt draft-waltermire-sacm-use-cases as start point for WG I-D for use cases. We are asking the WG to confirm this consensus on the mail list. Please send all comments, questions and concerns to the SACM WG mail list before 8/15. +1. Looking forward to progresses of this doc in WG. Jarrett > > Thanks and Regards, > > Adam and Dan > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From lnunez@mitre.org Tue Aug 6 11:47:23 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DB111E8104 for ; Tue, 6 Aug 2013 11:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r4FGpWD78NN for ; Tue, 6 Aug 2013 11:47:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BBF2711E8100 for ; Tue, 6 Aug 2013 11:47:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4BB5A1F06EE; Tue, 6 Aug 2013 14:47:17 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2B0B91F06CA; Tue, 6 Aug 2013 14:47:17 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.165]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Tue, 6 Aug 2013 14:47:16 -0400 From: "Nunez, Luis K" To: Adam Montville , "Baker, Jon" , "sacm@ietf.org" Thread-Topic: [Netconf] [netmod] development plan Thread-Index: AQHOkdp3Zrixa9H9GUOrS6K9JR4LhJmG33MAgAAJJICAAB2bgIAAIGsAgAEMkACAAD4fcIAABdmQgAABRwA= Date: Tue, 6 Aug 2013 18:47:16 +0000 Message-ID: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <6C1C15D8B5510B4B8FF132B10D38651304D313DD@IMCMBX03.MITRE.ORG> <05BCCEB107AF88469B9F99783D47C1D673D033@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D673D033@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_010B_01CE92B3.D49C08C0" MIME-Version: 1.0 Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 18:47:23 -0000 ------=_NextPart_000_010B_01CE92B3.D49C08C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit A NETCONF enabled device (router/switch) will publish configuration information locally into the "datastore". The NETCONF protocol is also used to access these devices for CRUD operations against this datastore. From an architectural perspective NETCONF would be used to Retrieve the configuration state information for vulnerability compliance assessments. Likewise NETCONF could also be used for Remediation. The tread below is related to recent efforts on SDN within the I2RS working group. Software Defined Networking or some would say Security Defined Networking will eventually cross paths with this working group at some point. -ln -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, August 06, 2013 1:53 PM To: Baker, Jon; sacm@ietf.org Subject: Re: [sacm] [Netconf] [netmod] development plan Thanks for pointing this out, Jon. Is anyone on this list also working in netconf? On the surface, they look very similar. It would be interesting to understand where, from an architectural perspective, the datastore is said to reside for netconf and how it should be accessed. I also find the phrase about not storing executive commands interesting, because, presumably, some of the information we want to store will be instructional in nature. > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Baker, Jon > Sent: Tuesday, August 06, 2013 10:34 AM > To: sacm@ietf.org > Subject: [sacm] FW: [Netconf] [netmod] development plan > > How closely are SACM WG participants also following the ongoing netconf > discussion? > > This message seems to directly align with some of the work I have expected > SACM to do. Take a look at this quote in particular: > > > A configuration datastore is defined as the complete set of > >configuration data that > > is required to get a device from its initial default state into a > > desired operational state. The configuration datastore does not > > include state data or executive commands. > > > > The running configuration datastore holds the complete configuration > > currently active on the network device. Only one configuration > > datastore of this type exists on the device, and it is always > > present. > > Given that the netconf wg seems to be in the middle of a very active > discussion on very closely related topics I would suggest that we specifically > reach out to the netconf group to ensure alignment and reuse where > possible. > > Jon > > ============================================ > Jonathan O. Baker > G022 - IA Industry Collaboration > The MITRE Corporation > Email: bakerj@mitre.org > > > >-----Original Message----- > >From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > >Behalf Of Balazs Lengyel > >Sent: Tuesday, August 06, 2013 5:47 AM > >To: Ladislav Lhotka > >Cc: netmod@ietf.org; Netconf > >Subject: Re: [Netconf] [netmod] development plan > > > > > >On 2013-08-05 19:45, Ladislav Lhotka wrote: > >> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel > >> > >wrote: > >> > >>> On 2013-08-05 16:03, Ladislav Lhotka wrote: > >>>> It is a fact of life that YANG is being used outside NETCONF, and > >>>> there are > >more plans for doing do, but with 6020 it is a slippery slope. For > >example, such non-NETCONF applications of YANG will most likely want to > use "must" > >for expressing semantic constraints. However, the accessible tree for > >"must" is defined like so: > >>>> > >>>> o If the context node represents configuration, the tree is the data > >>>> in the NETCONF datastore where the context node exists. The > XPath > >>>> root node has all top-level configuration data nodes in all > >>>> modules as children. > >>>> > >>>> o If the context node represents state data, the tree is all state > >>>> data on the device, and the datastore. The XPath root > >>>> node has all top-level data nodes in all modules as children. > >>>> > >>>> This cannot be unambiguously interpreted in a non-NETCONF context, > >>>> so > >it is effectively undefined, which is rather dangerous. > >>>> So I don't mean to completely redesign YANG, but we cannot, on the > >other hand, enable non-NETCONF YANG data modelling without providing > >new definitions. > >>>> > >>>> Lada > >>> In my view Netconf contains the "pure" protocol (encoding, > >>> operations, > >transactional behavior...) and background plumbing (datastores, > >separation of state and config data, hierarchical data organisation, > >filtering, connection requirements, session concept, capability > >negotiation, many of the capabilites, error messages). > >>> The background plumbing is valid for all access methods (CLI, > >>> Netconf, > >YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be redefined. > >> I don't think this is true. I2RS will probably have no distinction > >> between > >config and state data, though they may have read-write and read-only. > >Sessions and capability negotiation are by no means necessary (RESTCONF > >doesn't have it). I can actually imagine data modelling without any > >specific protocol for data exchange. > >> > >> Lada > >IMHO we can debate whether some protocols need some of the features, > or > >whether some of the features belong to the plumbing or the pure > >protocol, but I still believe that many of the concepts like "NETCONF > >datastore" above are actually easily understandable without considering > >the protocol on the wire. If you would just remove the word Netconf > >from your example paragraphs IMHO they are quite understandable in a > >protocol independent way. > > > >Let me just try as an exercise: > >Running Datastore: > > > > A configuration datastore is defined as the complete set of > >configuration data that > > is required to get a device from its initial default state into a > > desired operational state. The configuration datastore does not > > include state data or executive commands. > > > > The running configuration datastore holds the complete configuration > > currently active on the network device. Only one configuration > > datastore of this type exists on the device, and it is always > > present. > > > >The above defeinition is extracted from RFC6241 (I just removed 2 > >sentences). I think it is a very nice protocol independent definition. > > > > > >Does anyone have a list of features that make YANG protocol (Netconf) > >dependent? > > > >Balazs > > > >_______________________________________________ > >Netconf mailing list > >Netconf@ietf.org > >https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > ... . . . _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_010B_01CE92B3.D49C08C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYMDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhQwggP8oAMCAQICCniCA1UAAgAAfAUwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMTExMzE3MzkyNloXDTE1MTExMzE3MzkyNlowSTEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGTAXBgNVBAMTEE51 bmV6Lkx1aXMuMzY3NzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDl6/nMS7S4cBZA DKe5BG/m7Wn4VOXR+dgLgiyQAW1l677SXcWUIFhqafYao7Gz1NU1IMI6ZamPTPTqLm9ZnkJFvuzA Up/zCUwLPx7UqYOXg7nPGXAYhtBSYJBhkA6g9snZUE7EJkhs0vMWEQcTL5nIxz6K9mpbFrrDJpd5 3QSbN1faAhzzisxZ5ae/K4NywtMMYy+9esABY7lAAPndOTnBIFVugl7PJOu5CTczOkc8Ehe8+tGo n6Nbg2sRuTjB2SSjpXb4Q9/Bu5/btOVt3PjEYzfnFyPwlVQap7rpXIWfXZgMyxCSE3G1zi3PINk8 A4Zhdb3xteI+ww5QG0gFXgtPAgMBAAGjggH1MIIB8TAoBgNVHSUEITAfBggrBgEFBQcDBAYJKwYB BAFzAgEHBggrBgEFBQcDAjAdBgNVHQ4EFgQUsV/rNMaTpZcnVSIWE2DHeDtceFAwDgYDVR0PAQH/ BAQDAgbAMBsGA1UdEQQUMBKBEGxudW5lekBtaXRyZS5vcmcwHwYDVR0jBBgwFoAUaWcgIdRIwdAb Bm7zCCjiOoJ9QTEwSQYDVR0fBEIwQDA+oDygOoY4aHR0cDovL3BraS5taXRyZS5vcmcvTUlUUkUl MjBDb3Jwb3JhdGlvbiUyMFBFJTIwQ0EtMS5jcmwwfwYIKwYBBQUHAQEEczBxMEcGCCsGAQUFBzAC hjtodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xKDIp LmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AubWl0cmUub3JnL29jc3AwPgYJKwYBBAGCNxUH BDEwLwYnKwYBBAGCNxUIg66sI4aOlleBjYk9gqSrEoW+rgGBNoPSl32HoPtJAgFkAgEHMBYGA1Ud IAQPMA0wCwYJKwYBBAFzAgEIMDQGCSsGAQQBgjcVCgQnMCUwCgYIKwYBBQUHAwQwCwYJKwYBBAFz AgEHMAoGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4ICAQC/CxyG0kzVtkRM38Fxc/Q5xjCb9BwN HqUPPCcLqOIiLhaj4NfB7QK05lR3/grisrYzpiP2T/tbKygPu2q6OoZxLxQ7z5Um8FM6I78lNw0+ p3tSOABG1rLINKha+4OQJXpmFtUtGz3Tm12/Ef0ju8RngjFiFBS4ucobnrv/EZvSx7VmtlTFOLRr Iua0Y8Jvm3y2zsC4Xnknd3YMf76mW4XFrpUloFATq1gSyzSeKfXSwVG1Z78MFjARMohCIU5N8HCe Kurc1KgoxO45mWnu7CpY+7JRQPbD1M8Vo1hRLF7EzvO6aPIDGyvjRUwNHgyv5RMJcNA8Gi2k5dkh UfSEHfz/TzqWaplFns0f0P5n17JuqiZZYThZuwYIbQOaDVi6scO2E54IDy/SnIoKgryx3lBa9VCy zCkWU7WuMuil28UL0kDOhAbiJf8k4jQ/cUr+RhuAqtNeCH43UUCC7SukY5XFfXZlO8iROil+aBIS 33xVhJ2VBFjO6/PEN327XrgA+sRhfJHaUJU2sECx+7QnlqOD7SKvt+GGQMKDZ2UbtBW3H9e6bIV9 2BjKw/xSyzajf/95UCA8xnbuHEg05wElah/BAJ8zgdnoqToPwdpeE2z2CG0xgqYoWxizA9wTKq6N hey/AJkNaHnR25ArUXN7CFh9WLLYbDfubSc/B3oi1/jwQDCCBmIwggRKoAMCAQICChSXFtIAAAAA AAQwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBD QS0xMB4XDTExMDYxNDE3NDQ0NFoXDTE3MDYxNDE3NTQ0NFowUDETMBEGCgmSJomT8ixkARkWA09S RzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBD QS0xMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA0sSvUV4nqnU8+CVkZETLPxDrhdD9 EvUm7KWnSyZMfyww52gMJgJ6n6ptZ+/6fNqFY8tcgsnt0mbuGKe35gyALVm5B72Dn8R5Eb9YaP34 WjTdGEZHeuaCSc9p4BGzWcXSIgqImpUH1/4llOwKUPqLymxVetL+RNKdpj53LNtDWEX7GnrXYZwW WxQ/X5Q3F8CakrxhhgX5u4nxQkdS67RHDSozMH+2BFmTtFZN2coVavpOyTSxGyr9Dnwc/A1PBohl Po/PEJa4BlvDy5MDZO57EvwyafGi7nU7laiBNggPZqp+UI1PxGWDRxs0nwq/v7rFJm6I8lUibpIY awF7KUQDM/gomt8ot6t8PE5wJY11jdXYcdYrlL+RscszI36itbTLglFNl8xjTaqFWtZqqJQYsg0w jq/XfyAtGB2DAUqUPsYtMfc41yreBZkJpBAGYBeIbGWanCWC/4gkIsIs/HxMlT2br6Fr3RFzqMxW AqZpE9DGQicMiLsdGeryaelS7Tf+q2YHNsueB5U66d4n2s5qbH65NzXR8ZWU2boPZIxCPrxKMqf+ /ZwD8k1kENTBD9BKwlmr/NPxzotDC8f+5SFH71To5DhYBW/og70eE90QEK5xKYEzvn3Oycs4fS6R Q6ptLJcAz+B4/XAtyM3RA+QVONzxgHvh6GfDg/9aL1YMKP8CAwEAAaOCAWMwggFfMBAGCSsGAQQB gjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBRQojrYGW/mXX5ZMObAtstNbFEGlTAdBgNVHQ4EFgQU aWcgIdRIwdAbBm7zCCjiOoJ9QTEwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQD AgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUW4d9n/5svgLp8+ApOopUJSyfOC8wUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL3BraS5taXRyZS5vcmcvTUlUUkUlMjBDb3Jwb3JhdGlvbiUy MFBFJTIwUm9vdCUyMENBLTEuY3JsMFsGCCsGAQUFBwEBBE8wTTBLBggrBgEFBQcwAoY/aHR0cDov L3BraS5taXRyZS5vcmcvTUlUUkUlMjBDb3Jwb3JhdGlvbiUyMFBFJTIwUm9vdCUyMENBLTEuY3J0 MA0GCSqGSIb3DQEBCwUAA4ICAQB5wz33WCsajTrQGFzMsnpfN1bPHAgwEGYUriAdHOhpBqBHRa5l h/acIuNlfeqwqe072zTSjSV21R3yVAKfrqsOutwy/7F133/WRcT8SjnT56QPHCjO0QR/XuN+zcN3 dvAOz2hmz+rV5kqoVwIWGeFNdstVOXDn9hv6YVKAADJZ1SXX5l8zGs7y6NkiHosQCcgs3uqx0ExU PzfoAI21bkSfh7PBRClczEsKpTaLqXthC6i+HTACk+j9PLAH8Ztkq0ZUL3Fj2L6jP9QtdG4HNrXb vlhs0bj+VsfWK9eSjvUluM+359kVRF0IKAw56ObwiHH1D7igeZ/irfXgQorbIEg/cmLDVDfSxFSL 4wG/DFdi1i34HtW7pqOoO0DEWuBYIn8ObIhsIu1dhGiUKOlACFb8SihQu1uKegpK2NoGtXexiENA z4lmTnszmpCVQMS+YH/t1nTbdIoCnP8i323R5+oQndSj4A6pEiq/M1jmSP44gwVvee8QJmjukHRk AwWa0B1qSFcEBsxeWxq6prNpKuPZd7eypgbtAv/bRMaigJpX+GOZX0BnQmykKQKu9dg1UB2Lg15l UBAHNr5SdQuYUtyMPQ8AVk3yeL8gePG7oQYWyIT4hbWuTos15SnLCIvfYpANcomcfwwbY2sOCVOq ic1lBQdnnMhgjT7TW2I1EQNAPTCCBn0wggRloAMCAQICCniCAd4AAgAAfAQwDQYJKoZIhvcNAQEF BQAwUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQD ExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMTExMzE3MzkyNloXDTE1MTExMzE3Mzky NlowSTELMAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGTAXBgNV BAMTEE51bmV6Lkx1aXMuMzY3NzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDH0jmx J6Z/B/QJgS3AdKVc8cYrQ37qZP640qp42ASnLrvjjWPD2zv5ZOgxxyZ1JAwxUhQzQSBIC8nP+VOV 01h45E84FgNWj2MMp9/CS5TBKzSi6eG0a6BRx2DLRrzsnYVpUWb9OAVZG2FopSlsNmEJNJxyD5v1 EnBRPJXt120yDyDKLE0Wz1X+Pf0wq3xia/tnyy32hzZYrV/myYiEzs460MROur0157bL4d8SQ7Gw TlbBuHrjQBTysXr6wL/1QCS2FRYpiaLC5+fuELQ2yoRN/n7x5KY+eas7ap8aMQQMa8WZ+d6aub6h 1WcAZU2apYs034GFupKz4SmsDPlBCxuXAgMBAAGjggJeMIICWjATBgNVHSUEDDAKBggrBgEFBQcD BDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYF Kw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQMEARYw CwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFGORBI+1DaO/ W0YdePSU5240ZEyMMA4GA1UdDwEB/wQEAwIFIDAbBgNVHREEFDASgRBsbnVuZXpAbWl0cmUub3Jn MB8GA1UdIwQYMBaAFGlnICHUSMHQGwZu8wgo4jqCfUExMEkGA1UdHwRCMEAwPqA8oDqGOGh0dHA6 Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEuY3JsMH8GCCsG AQUFBwEBBHMwcTBHBggrBgEFBQcwAoY7aHR0cDovL3BraS5taXRyZS5vcmcvTUlUUkUlMjBDb3Jw b3JhdGlvbiUyMFBFJTIwQ0EtMSgyKS5jcnQwJgYIKwYBBQUHMAGGGmh0dHA6Ly9vY3NwLm1pdHJl Lm9yZy9vY3NwMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIOurCOGjpZXgY2JPYKkqxKFvq4B gTaGq5JohKjsRQIBZAIBDzAWBgNVHSAEDzANMAsGCSsGAQQBcwIBCDAbBgkrBgEEAYI3FQoEDjAM MAoGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4ICAQC8CcNFMKiKkMlvM1OEgE2GvFvO9t6qst3d /7R/iP3zpIcS+DFH+MuUMfNab5PanDuaAys7Yb1HkbkpkW4vcnwR01OIrpgOCKse31X6R9dEohVY 1A/YA/j/N7GdPMn87CMISlsYIodQRjt45h6psCaYvURKbDwr9x72sZTKY8wF149Vw5nOQk0/1exU 4ND+mlPbPSbnh4yWsr9ZBg4yvO2EEXisfmxC6FaQGSPCamwgmASmX8T1R4BWEbdSiNCxaR8KIUGz q88AWOeIhiWCiWcyGsgy2/l2veqNKzSGBOXr+TiEa9iswvrUvplbH4UhVxOBt38LuixGBtF+KxCg YgsF9+O8McfCEAgFQYVGtHOgRPjxRucKCSPDm1NCjaM6hmK67euB4VRHQHE3RzfmE3UzQM7WwZVW xvIAnRko6qCW2JzIFnYt0OyIV99NCVJVqAplp1TCk0QEQcD81mzLEczqTNu2R3qlFXznhUZIYZWD 2HuNfU4TUHem/Syyi4QDLLAdUO+86Zg7vmKqiQXrBeHoPAOGI0WLURtCaja7vGagbuJNnKE3RbqC TpdieqnghfOOChXVw9BHrlmCxE70ejLeoVMT+q/nTRwa/PjJuuUU1yDuKiZ+SYhRQG+6jyTbG0Bi IWpIx4rA5CVLVHec+4m97IDrNUdZQvjh08wE12UUujGCAyMwggMfAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3Jh dGlvbiBQRSBDQS0xAgp4ggNVAAIAAHwFMAkGBSsOAwIaBQCgggGaMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgwNjE4NDcxMFowIwYJKoZIhvcNAQkEMRYEFA8d X1R+1B5vkWwFvlbKy8qVLA7LMFsGCSqGSIb3DQEJDzFOMEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMG0G CSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1J VFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgp4ggHeAAIAAHwEMG8GCyqG SIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlU UkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTECCniCAd4AAgAAfAQwDQYJKoZI hvcNAQEBBQAEggEAoemktcOrN1SJzNuDeEVwH9mFXHPEqR17IVS8qei4nVBQn13K9+uQtMI67Uq4 9T4hrJ43kvHpeYyFWCtse8Z6PFd+uWYo2DwLZ2Q8rmEG5ezCtsRRKABHWHD3h9K29HiGw4Pjs2zf RKmS60okzqC1XfbW3J4Ujgg94hGXX+0alnHrQVjvB6vZCpju2r7rXmdeP5y2nD7NpFsrHaPtDGF8 XkdlzWVLCKAHGBvbzJVdsynyGEZFcjgCnogXMOeiv1SaeyLrKk9UQfMMwn1v0KDDZHmemzHZKnnc bb5EXYRfO7MQm6poW9+DF9uvrINJDb/G+d1EuCobKlWQsWOwnp/RmAAAAAAAAA== ------=_NextPart_000_010B_01CE92B3.D49C08C0-- From jarrett.lu@oracle.com Tue Aug 6 12:12:47 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8970621F9E7C for ; Tue, 6 Aug 2013 12:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8KjcMEMV+Cb for ; Tue, 6 Aug 2013 12:12:42 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C899D21F9DE1 for ; Tue, 6 Aug 2013 12:12:40 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76JCdel021148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Aug 2013 19:12:40 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76JCd5D010115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Aug 2013 19:12:39 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76JCciR029184 for ; Tue, 6 Aug 2013 19:12:38 GMT Received: from [10.132.148.74] (/10.132.148.74) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 12:12:38 -0700 Message-ID: <52014D54.4080008@oracle.com> Date: Tue, 06 Aug 2013 12:24:04 -0700 From: Jarrett Lu User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sacm@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: Re: [sacm] SACM - consensus on 'Way Forward' X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jarrett.lu@oracle.com List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 19:12:47 -0000 Agree. - Jarrett On 08/ 5/13 08:47 AM, Romascanu, Dan (Dan) wrote: > At the SACM WG meeting at IETF-88 the participants in the room did not raise any objection on the 'Way Forward' plan of action between now and IETF-88 presented by Adam Montville on behalf of the chairs. The plan included the following: > > 8/16: Agreement on way forward on list > 8/31: Adopt Use Case I-D as WG doc > 9/13: Initial Requirements I-D submitted > 9/30: Adopt Requirements I-D as WG doc > 10/15: Initial Architecture I-Ds submitted > IETF 88: Discuss architecture contributions and work for consensus > > We are asking the WG to confirm this consensus on the mail list. Please send all comments, questions and concerns to the SACM WG mail list before 8/15, so that the chairs can judge consensus on 8/16. > > Thanks and Regards, > > Adam and Dan > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From jarrett.lu@oracle.com Tue Aug 6 12:19:29 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E150A21E809E for ; Tue, 6 Aug 2013 12:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oASDD0x2rg8x for ; Tue, 6 Aug 2013 12:19:24 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C3BB821F9E7C for ; Tue, 6 Aug 2013 12:19:20 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r76JJJV7029784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Aug 2013 19:19:20 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76JJJGY022305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Aug 2013 19:19:19 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r76JJJOT010368 for ; Tue, 6 Aug 2013 19:19:19 GMT Received: from [10.132.148.74] (/10.132.148.74) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 12:19:18 -0700 Message-ID: <52014EEE.8030006@oracle.com> Date: Tue, 06 Aug 2013 12:30:54 -0700 From: Jarrett Lu User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sacm@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jarrett.lu@oracle.com List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 19:19:30 -0000 Yes, I agree with the "separate terminology doc" approach. - Jarrett On 08/ 6/13 05:57 AM, Romascanu, Dan (Dan) wrote: > At the SACM WG meeting at IETF-87 the participants in the room did not raise any objection to the proposal to separate the terminology section from draft-waltermire-sacm-use-cases and make of it a separate document that defines the SACM terms in one place and can be referred by all other SACM documents. We are asking the WG to confirm this consensus on the mail list. Please send all comments, questions and concerns to the SACM WG mail list before 8/15. > > Thanks and Regards, > > Adam and Dan > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Tue Aug 6 14:07:12 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B7321F9E54 for ; Tue, 6 Aug 2013 14:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcYN4K8g5GiQ for ; Tue, 6 Aug 2013 14:07:08 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id B27CE21E808E for ; Tue, 6 Aug 2013 14:07:08 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r76JO9f5014999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Aug 2013 15:24:09 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Tue, 6 Aug 2013 15:23:57 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r76JNuKG018103 for ; Tue, 6 Aug 2013 15:23:56 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Tue, 6 Aug 2013 15:23:56 -0400 From: "Moriarty, Kathleen" To: "sacm@ietf.org" Date: Tue, 6 Aug 2013 15:23:42 -0400 Thread-Topic: [sacm] SACM - consensus on 'Way Forward' Thread-Index: Ac6S2PNSuKlZEl9qRwOSiEbqbdfARgAAYMcU Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com>, <52014D54.4080008@oracle.com> In-Reply-To: <52014D54.4080008@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] SACM - consensus on 'Way Forward' X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:07:12 -0000 +1 ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Jarrett Lu= [jarrett.lu@oracle.com] Sent: Tuesday, August 06, 2013 3:24 PM To: sacm@ietf.org Subject: Re: [sacm] SACM - consensus on 'Way Forward' Agree. - Jarrett On 08/ 5/13 08:47 AM, Romascanu, Dan (Dan) wrote: > At the SACM WG meeting at IETF-88 the participants in the room did not ra= ise any objection on the 'Way Forward' plan of action between now and IETF-= 88 presented by Adam Montville on behalf of the chairs. The plan included t= he following: > > 8/16: Agreement on way forward on list > 8/31: Adopt Use Case I-D as WG doc > 9/13: Initial Requirements I-D submitted > 9/30: Adopt Requirements I-D as WG doc > 10/15: Initial Architecture I-Ds submitted > IETF 88: Discuss architecture contributions and work for consensus > > We are asking the WG to confirm this consensus on the mail list. Please s= end all comments, questions and concerns to the SACM WG mail list before 8/= 15, so that the chairs can judge consensus on 8/16. > > Thanks and Regards, > > Adam and Dan > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From ietfdbh@comcast.net Tue Aug 6 14:12:15 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAE121E809B for ; Tue, 6 Aug 2013 14:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdDr4oP9Xr2p for ; Tue, 6 Aug 2013 14:12:10 -0700 (PDT) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 4896121F9EE0 for ; Tue, 6 Aug 2013 14:12:10 -0700 (PDT) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta03.emeryville.ca.mail.comcast.net with comcast id 9XTz1m0061GXsucA3ZC9G7; Tue, 06 Aug 2013 21:12:09 +0000 Received: from [192.168.1.181] ([176.96.153.9]) by omta07.emeryville.ca.mail.comcast.net with comcast id 9ZBl1m00i0CRbBk8UZBrDS; Tue, 06 Aug 2013 21:12:07 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Tue, 06 Aug 2013 23:11:44 +0200 From: David Harrington To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Message-ID: Thread-Topic: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4113@AZ-FFEXMB04.global.avaya.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375823529; bh=akvt+Upvo8rZscx6vdDR76UvuztYnH5sxtOJkySXOAk=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=aL6y53ZMCqSDF1pMmSAjTDWDCuzvRo0HGf4jMjdEOYJf02nxu1zjGUgldgHux+SOT yTszfUroRVYsM2XyW91i2bMleItW4xYApxqq4qTsUKLcWXJKoQ4ohpJfP0r6vrJlkT x2oYrCml5qy0xOumJrUixuPxAyAv1kcgoVPxx4DwQOGoroITnsg7nPej8YRB5tJqxo pRUlywrdxNPBF9AgcmmU+daXWwJ5p48lKy2SKGmTjr8synVhahPoImhfq4YcU8qQCA dSXQFhYkr4nY4oQee5g86YaKfSmBZNSsAqTNvsPgjJumQ5oz4E/mWaz+Nmtp5xykaC VG2bg501vkJlw== Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:12:15 -0000 +1 -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 8/5/13 5:50 PM, "Romascanu, Dan (Dan)" wrote: > >At the SACM WG meeting at IETF-88 the participants in the room did not >raise any objection on the proposal to adopt >draft-waltermire-sacm-use-cases as start point for WG I-D for use cases. >We are asking the WG to confirm this consensus on the mail list. Please >send all comments, questions and concerns to the SACM WG mail list before >8/15. > >Thanks and Regards, > >Adam and Dan > > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From ietfdbh@comcast.net Tue Aug 6 14:13:19 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7698211E80EE for ; Tue, 6 Aug 2013 14:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+mSuioWEn7x for ; Tue, 6 Aug 2013 14:13:14 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id D998D21E80A1 for ; Tue, 6 Aug 2013 14:13:14 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 9XRZ1m0040b6N64A1ZDE1b; Tue, 06 Aug 2013 21:13:14 +0000 Received: from [192.168.1.181] ([176.96.153.9]) by omta03.emeryville.ca.mail.comcast.net with comcast id 9ZCQ1m0080CRbBk8PZCXlL; Tue, 06 Aug 2013 21:13:12 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Tue, 06 Aug 2013 23:12:22 +0200 From: David Harrington To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Message-ID: Thread-Topic: [sacm] SACM - consensus on 'Way Forward' In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375823594; bh=73b4HARpkhV1oG+oNEwxxkcvIzUglvI0NyY8lV4gWZM=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=VMhmxw9RC+dTWX3vtrh36YIg6gA+knTA7UUPoL6/TqErN7NSTuz3v31WCboE+IjNR Z1QMRnPUowS8XfxMekgcxDqqTyxV9XSmgBVSyTB3AFPbZijB2LFG7xjFtqSF86SuCC StQ0Ibjs2tMoNRXLV+ohisHtmGJbrj+s+DJ4OOs4+TgVCgcDUFxJ12hOYaYvmOGwgn RKLKi04O1ylbSGrELo8Xrtu1aNm7L/RWQ2TnXxIJOiUx5xyDSrxkSBp3VHo5RBQD8Z vNc/PldoDEgDq8m7MpJFy2KwkuE0qRJKgMPbs0E8WtFw2dIILYqwNmz4wK50vC6OQ3 0M9bzXO77rMtQ== Subject: Re: [sacm] SACM - consensus on 'Way Forward' X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:13:19 -0000 +1 -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 8/5/13 5:47 PM, "Romascanu, Dan (Dan)" wrote: >At the SACM WG meeting at IETF-88 the participants in the room did not >raise any objection on the 'Way Forward' plan of action between now and >IETF-88 presented by Adam Montville on behalf of the chairs. The plan >included the following: > >8/16: Agreement on way forward on list >8/31: Adopt Use Case I-D as WG doc >9/13: Initial Requirements I-D submitted >9/30: Adopt Requirements I-D as WG doc >10/15: Initial Architecture I-Ds submitted >IETF 88: Discuss architecture contributions and work for consensus > >We are asking the WG to confirm this consensus on the mail list. Please >send all comments, questions and concerns to the SACM WG mail list before >8/15, so that the chairs can judge consensus on 8/16. > >Thanks and Regards, > >Adam and Dan > > > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From blueroofmusic@gmail.com Tue Aug 6 14:18:12 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAEC21F9DFB for ; Tue, 6 Aug 2013 14:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7GMVkBGaMwc for ; Tue, 6 Aug 2013 14:18:11 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B056D21F9967 for ; Tue, 6 Aug 2013 14:18:11 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i10so1868282oag.2 for ; Tue, 06 Aug 2013 14:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=//dfs7N1HjLKpVaApnWamsVt1ogpi9yVx01A+NhROLA=; b=JA0eBPoHkBC6moJltOtNIL8wiEFUX428kRDCtsCJHPi6HPGmAfeMa9BHVgs0gDT2He kWdVGILIKREpJp53BBtOQHWTKomO7HIDK4D0FezKB6dVTFupS0vps5NofEVlsMmUiN0v e3finUtGM7ofF6Sn2OopG4FaWKNOqYV7EdyIqcZxxMKeQTNVFrFiNZkf7UlebLU0PWC4 VvEQ60XFunJOwnpiL6WJ5BLPMR8hpaN0c1l3f6/Tu1Wab08XoLOzVWW5ZWciTF09I7FM p/bywt+6bIuHJdkQXiWtZckobPPpYJ99XmK7g0FxSUDVlzYjuifFdgYyz+kdUarBOA2c DtLw== MIME-Version: 1.0 X-Received: by 10.43.15.68 with SMTP id pt4mr12750icb.35.1375823891238; Tue, 06 Aug 2013 14:18:11 -0700 (PDT) Received: by 10.50.100.168 with HTTP; Tue, 6 Aug 2013 14:18:11 -0700 (PDT) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128A40F5@AZ-FFEXMB04.global.avaya.com> Date: Tue, 6 Aug 2013 17:18:11 -0400 Message-ID: From: Ira McDonald To: "Romascanu, Dan (Dan)" , Ira McDonald Content-Type: multipart/alternative; boundary=bcaec50fdfb14f937a04e34df6bb Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM - consensus on 'Way Forward' X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:18:12 -0000 --bcaec50fdfb14f937a04e34df6bb Content-Type: text/plain; charset=ISO-8859-1 +1 Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Aug 5, 2013 at 11:47 AM, Romascanu, Dan (Dan) wrote: > At the SACM WG meeting at IETF-88 the participants in the room did not > raise any objection on the 'Way Forward' plan of action between now and > IETF-88 presented by Adam Montville on behalf of the chairs. The plan > included the following: > > 8/16: Agreement on way forward on list > 8/31: Adopt Use Case I-D as WG doc > 9/13: Initial Requirements I-D submitted > 9/30: Adopt Requirements I-D as WG doc > 10/15: Initial Architecture I-Ds submitted > IETF 88: Discuss architecture contributions and work for consensus > > We are asking the WG to confirm this consensus on the mail list. Please > send all comments, questions and concerns to the SACM WG mail list before > 8/15, so that the chairs can judge consensus on 8/16. > > Thanks and Regards, > > Adam and Dan > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --bcaec50fdfb14f937a04e34df6bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

+1

Cheers,
- Ira

Ira McDonald (Mus= ician / Software Architect)
Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solution= s WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert = - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Mon, Aug 5, 2013 at 11:47 AM, Romasca= nu, Dan (Dan) <dromasca@avaya.com> wrote:
At the SACM WG meeting at IETF-88 the participants in the room did not rais= e any objection on the 'Way Forward' plan of action between now and= IETF-88 presented by Adam Montville on behalf of the chairs. The plan incl= uded the following:

8/16: Agreement on way forward on list
8/31: Adopt Use Case I-D as WG doc
9/13: Initial Requirements I-D submitted
9/30: Adopt Requirements I-D as WG doc
10/15: Initial Architecture I-Ds submitted
IETF 88: Discuss architecture contributions and work for consensus

We are asking the WG to confirm this consensus on the mail list. Please sen= d all comments, questions and concerns to the SACM WG mail list before 8/15= , so that the chairs can judge consensus on 8/16.

Thanks and Regards,

Adam and Dan




_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm

--bcaec50fdfb14f937a04e34df6bb-- From jclarke@cisco.com Tue Aug 6 14:19:16 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D3721F997E for ; Tue, 6 Aug 2013 14:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmDdam1SgYph for ; Tue, 6 Aug 2013 14:19:12 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 21C2B21F991F for ; Tue, 6 Aug 2013 14:19:07 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r76LJ4Vc019139; Tue, 6 Aug 2013 17:19:04 -0400 (EDT) Received: from rtp-vpn4-373.cisco.com (rtp-vpn4-373.cisco.com [10.82.209.117]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r76LJ2e7022414; Tue, 6 Aug 2013 17:19:03 -0400 (EDT) Message-ID: <52016845.5040203@cisco.com> Date: Tue, 06 Aug 2013 17:19:01 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Montville References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <6C1C15D8B5510B4B8FF132B10D38651304D313DD@IMCMBX03.MITRE.ORG> <05BCCEB107AF88469B9F99783D47C1D673D033@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D673D033@CISEXCHANGE1.msisac.org.local> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sacm@ietf.org" , "Baker, Jon" Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:19:16 -0000 On 8/6/13 1:52 PM, Adam Montville wrote: > Thanks for pointing this out, Jon. > > Is anyone on this list also working in netconf? On the surface, they look very similar. It would be interesting to understand where, from an architectural perspective, the datastore is said to reside for netconf and how it should be accessed. I also find the phrase about not storing executive commands interesting, because, presumably, some of the information we want to store will be instructional in nature. I am on netconf. I agree with Luis' follow-up. I viewed NETCONF as a way to retrieve configuration data from the device as part of config mgmt in SACM as well as push back changes such as remediations. I never saw overlap in terms of the two WGs trying to do the same thing. I am reminded of David Harrington's talk about using SNMP to do the asset collection. NETCONF is another means to accomplish the same type of collection for config (as well as retrieve some operational data that may be helpful when identifying true posture). Joe > > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Baker, Jon >> Sent: Tuesday, August 06, 2013 10:34 AM >> To: sacm@ietf.org >> Subject: [sacm] FW: [Netconf] [netmod] development plan >> >> How closely are SACM WG participants also following the ongoing netconf >> discussion? >> >> This message seems to directly align with some of the work I have expected >> SACM to do. Take a look at this quote in particular: >> >>> A configuration datastore is defined as the complete set of >>> configuration data that >>> is required to get a device from its initial default state into a >>> desired operational state. The configuration datastore does not >>> include state data or executive commands. >>> >>> The running configuration datastore holds the complete configuration >>> currently active on the network device. Only one configuration >>> datastore of this type exists on the device, and it is always >>> present. >> >> Given that the netconf wg seems to be in the middle of a very active >> discussion on very closely related topics I would suggest that we specifically >> reach out to the netconf group to ensure alignment and reuse where >> possible. >> >> Jon >> >> ============================================ >> Jonathan O. Baker >> G022 - IA Industry Collaboration >> The MITRE Corporation >> Email: bakerj@mitre.org >> >> >>> -----Original Message----- >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >>> Behalf Of Balazs Lengyel >>> Sent: Tuesday, August 06, 2013 5:47 AM >>> To: Ladislav Lhotka >>> Cc: netmod@ietf.org; Netconf >>> Subject: Re: [Netconf] [netmod] development plan >>> >>> >>> On 2013-08-05 19:45, Ladislav Lhotka wrote: >>>> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel >>>> >>> wrote: >>>> >>>>> On 2013-08-05 16:03, Ladislav Lhotka wrote: >>>>>> It is a fact of life that YANG is being used outside NETCONF, and >>>>>> there are >>> more plans for doing do, but with 6020 it is a slippery slope. For >>> example, such non-NETCONF applications of YANG will most likely want to >> use "must" >>> for expressing semantic constraints. However, the accessible tree for >>> "must" is defined like so: >>>>>> >>>>>> o If the context node represents configuration, the tree is the data >>>>>> in the NETCONF datastore where the context node exists. The >> XPath >>>>>> root node has all top-level configuration data nodes in all >>>>>> modules as children. >>>>>> >>>>>> o If the context node represents state data, the tree is all state >>>>>> data on the device, and the datastore. The XPath root >>>>>> node has all top-level data nodes in all modules as children. >>>>>> >>>>>> This cannot be unambiguously interpreted in a non-NETCONF context, >>>>>> so >>> it is effectively undefined, which is rather dangerous. >>>>>> So I don't mean to completely redesign YANG, but we cannot, on the >>> other hand, enable non-NETCONF YANG data modelling without providing >>> new definitions. >>>>>> >>>>>> Lada >>>>> In my view Netconf contains the "pure" protocol (encoding, >>>>> operations, >>> transactional behavior...) and background plumbing (datastores, >>> separation of state and config data, hierarchical data organisation, >>> filtering, connection requirements, session concept, capability >>> negotiation, many of the capabilites, error messages). >>>>> The background plumbing is valid for all access methods (CLI, >>>>> Netconf, >>> YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be redefined. >>>> I don't think this is true. I2RS will probably have no distinction >>>> between >>> config and state data, though they may have read-write and read-only. >>> Sessions and capability negotiation are by no means necessary (RESTCONF >>> doesn't have it). I can actually imagine data modelling without any >>> specific protocol for data exchange. >>>> >>>> Lada >>> IMHO we can debate whether some protocols need some of the features, >> or >>> whether some of the features belong to the plumbing or the pure >>> protocol, but I still believe that many of the concepts like "NETCONF >>> datastore" above are actually easily understandable without considering >>> the protocol on the wire. If you would just remove the word Netconf >> >from your example paragraphs IMHO they are quite understandable in a >>> protocol independent way. >>> >>> Let me just try as an exercise: >>> Running Datastore: >>> >>> A configuration datastore is defined as the complete set of >>> configuration data that >>> is required to get a device from its initial default state into a >>> desired operational state. The configuration datastore does not >>> include state data or executive commands. >>> >>> The running configuration datastore holds the complete configuration >>> currently active on the network device. Only one configuration >>> datastore of this type exists on the device, and it is always >>> present. >>> >>> The above defeinition is extracted from RFC6241 (I just removed 2 >>> sentences). I think it is a very nice protocol independent definition. >>> >>> >>> Does anyone have a list of features that make YANG protocol (Netconf) >>> dependent? >>> >>> Balazs >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> >> ... > > . . . > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From ietfdbh@comcast.net Tue Aug 6 14:24:15 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D251E21F9DFB for ; Tue, 6 Aug 2013 14:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZS-35p57yHRN for ; Tue, 6 Aug 2013 14:24:07 -0700 (PDT) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by ietfa.amsl.com (Postfix) with ESMTP id DF5EB21F9EB0 for ; Tue, 6 Aug 2013 14:24:01 -0700 (PDT) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta11.emeryville.ca.mail.comcast.net with comcast id 9RLp1m00A1eYJf8ABZQ1Fi; Tue, 06 Aug 2013 21:24:01 +0000 Received: from [192.168.1.181] ([176.96.153.9]) by omta19.emeryville.ca.mail.comcast.net with comcast id 9ZPj1m00N0CRbBk01ZPndn; Tue, 06 Aug 2013 21:23:59 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Tue, 06 Aug 2013 23:23:42 +0200 From: David Harrington To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Message-ID: Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375824241; bh=wPaTL6GrFHFF6JzzZ7pb68QPvdzFafY5tCtORYGRcuM=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=ocStl+WBVTAMAqX9T1u6kOG97tm1gbJ7tCFa6pyR034GHmTDlo+1oXFj47Tft+kFg OkxgEsj5JkEoYOtOEC495+FnMyuV84VUMF9C8cw1ag8f9AYFyTJ6/sD8by/womwXTx G09lGHBD/GL8qv7VgdRpkzNJphJuVtc8bf4dRjpeAkQxn8mswaHZrAQ34Z1ilNZDog 3pVqiwGyFgjqOaXuF4GmfZhkAwIhRpo8rz4ukZydTrqXr+Z76zSgn2rLl6ofv86qmx iR1QnJDOPUIO5XpBXmQMPmvjsE3NHkGIkEFMEiJRdy39Z1vOpAQkqzE03CcmWTx3QH zf34FoNO/eWjg== Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:24:16 -0000 +1 -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 8/6/13 2:57 PM, "Romascanu, Dan (Dan)" wrote: >At the SACM WG meeting at IETF-87 the participants in the room did not >raise any objection to the proposal to separate the terminology section >from draft-waltermire-sacm-use-cases and make of it a separate document >that defines the SACM terms in one place and can be referred by all other >SACM documents. We are asking the WG to confirm this consensus on the >mail list. Please send all comments, questions and concerns to the SACM >WG mail list before 8/15. > >Thanks and Regards, > >Adam and Dan > > > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Tue Aug 6 14:27:37 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF2021F9CF5 for ; Tue, 6 Aug 2013 14:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+xIT37-kwZl for ; Tue, 6 Aug 2013 14:27:31 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 4806421F9F4F for ; Tue, 6 Aug 2013 14:27:30 -0700 (PDT) Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Aug 2013 17:27:23 -0400 Received: from wsget1.nist.gov (129.6.13.150) by wsghub2.xchange.nist.gov (129.6.16.197) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Aug 2013 17:27:26 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Aug 2013 17:27:22 -0400 Received: from na01-bl2-obe.outbound.protection.outlook.com (207.46.163.206) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Aug 2013 17:27:26 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB039.namprd09.prod.outlook.com (10.255.211.153) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 6 Aug 2013 21:27:26 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.53]) with mapi id 15.00.0731.000; Tue, 6 Aug 2013 21:27:25 +0000 From: "Waltermire, David A." To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6SpHgZAWpvrX0vRxuTXCLSjTwOnwAR0VQz Date: Tue, 6 Aug 2013 21:27:25 +0000 Message-ID: <7c43d8ef20ee4f7994a539ab3e6df042@BLUPR09MB038.namprd09.prod.outlook.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.16.52] x-forefront-prvs: 0930AAFAD9 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(47446002)(4396001)(33646001)(69226001)(47976001)(56816003)(19580395003)(76576001)(19580385001)(31966008)(76786001)(54356001)(83072001)(77982001)(74876001)(50986001)(74366001)(81342001)(54316002)(16406001)(63696002)(47736001)(51856001)(561944002)(80022001)(59766001)(74706001)(49866001)(81542001)(74316001)(53806001)(46102001)(76796001)(77096001)(56776001)(79102001)(65816001)(74502001)(80976001)(76482001)(19580405001)(66066001)(74662001)(83322001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB039; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.16.52; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:27:37 -0000 +1 Dave ________________________________________ From: sacm-bounces@ietf.org on behalf of Romascanu,= Dan (Dan) Sent: Tuesday, August 06, 2013 2:57:13 PM To: sacm@ietf.org Subject: [sacm] SACM - consensus on defining SACM terminology in a separate= document At the SACM WG meeting at IETF-87 the participants in the room did not rais= e any objection to the proposal to separate the terminology section from dr= aft-waltermire-sacm-use-cases and make of it a separate document that defin= es the SACM terms in one place and can be referred by all other SACM docume= nts. We are asking the WG to confirm this consensus on the mail list. Pleas= e send all comments, questions and concerns to the SACM WG mail list before= 8/15. Thanks and Regards, Adam and Dan _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Tue Aug 6 14:29:24 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2038E21F9EB0 for ; Tue, 6 Aug 2013 14:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA79fkl6KWaR for ; Tue, 6 Aug 2013 14:29:18 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1C021F9CF5 for ; Tue, 6 Aug 2013 14:29:15 -0700 (PDT) Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Aug 2013 17:29:10 -0400 Received: from wsget2.nist.gov (129.6.13.151) by wsghub2.xchange.nist.gov (129.6.16.197) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Aug 2013 17:29:14 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Aug 2013 17:28:58 -0400 Received: from na01-by2-obe.outbound.protection.outlook.com (207.46.163.244) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Aug 2013 17:29:14 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB040.namprd09.prod.outlook.com (10.255.211.154) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 6 Aug 2013 21:29:12 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.53]) with mapi id 15.00.0731.000; Tue, 6 Aug 2013 21:29:12 +0000 From: "Waltermire, David A." To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - consensus on 'Way Forward' Thread-Index: AQHOkuv9G8vnRCnynkO/9HV2yJeggQ== Date: Tue, 6 Aug 2013 21:29:11 +0000 Message-ID: <194409c0247e426c95234698d525cdc7@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.16.52] x-forefront-prvs: 0930AAFAD9 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(56776001)(79102001)(77982001)(65816001)(83072001)(77096001)(69226001)(19580385001)(74876001)(46102001)(74366001)(31966008)(47976001)(50986001)(53806001)(76576001)(83322001)(33646001)(54356001)(56816003)(76796001)(66066001)(4396001)(76176001)(49866001)(19580405001)(54316002)(76786001)(47736001)(80022001)(63696002)(81342001)(74502001)(80976001)(51856001)(19580395003)(74662001)(74706001)(76482001)(59766001)(16406001)(81542001)(47446002)(74316001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB040; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.16.52; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] SACM - consensus on 'Way Forward' X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:29:24 -0000 +1 Dave ________________________________________ From: sacm-bounces@ietf.org on behalf of Romascanu,= Dan (Dan) Sent: Monday, August 05, 2013 5:47:26 PM To: sacm@ietf.org Subject: [sacm] SACM - consensus on 'Way Forward' At the SACM WG meeting at IETF-88 the participants in the room did not rais= e any objection on the 'Way Forward' plan of action between now and IETF-88= presented by Adam Montville on behalf of the chairs. The plan included the= following: 8/16: Agreement on way forward on list 8/31: Adopt Use Case I-D as WG doc 9/13: Initial Requirements I-D submitted 9/30: Adopt Requirements I-D as WG doc 10/15: Initial Architecture I-Ds submitted IETF 88: Discuss architecture contributions and work for consensus We are asking the WG to confirm this consensus on the mail list. Please sen= d all comments, questions and concerns to the SACM WG mail list before 8/15= , so that the chairs can judge consensus on 8/16. Thanks and Regards, Adam and Dan _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From blueroofmusic@gmail.com Tue Aug 6 15:28:50 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9185A11E80F3 for ; Tue, 6 Aug 2013 15:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvFjdEIm7thK for ; Tue, 6 Aug 2013 15:28:50 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id BB06F21E80AA for ; Tue, 6 Aug 2013 15:28:44 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so2138015obc.26 for ; Tue, 06 Aug 2013 15:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e/kVzkcfEhcBaeSRPPOX3gyLXkK1s4uQX0z+bjZ3tn0=; b=xUoQfwOjxGMoaW0lvXSZupmOvRBEfRuaS/9MSpvtiBlL3XSgqVfTvNbceADIY+h5NC rvJsavsvtYKKeQjcZfJAB+aBc8B8mL6aOpkyA/eIsdHjwx8d0mC2eZh+Clrd9J8gLxl7 wFFflvNgPvYnE5K56qfiPyOlygWj29rHmqy4GbAL5g05e5CjATEsZhiV7CHEhB32bicO e1WNNWnGghkGDvttVp051H5cjhJUjd9oFnOIL/JzG//tajhwEhpFX5tqjYX5aKoPd7He vzGi9G0NvanhNjb2gzhYDq18ID9qU7KwzR91pmYI8MKseMD+0Tu+ytdRltRZ8SpFPWSP SXQw== MIME-Version: 1.0 X-Received: by 10.43.82.198 with SMTP id ad6mr16882icc.114.1375828124281; Tue, 06 Aug 2013 15:28:44 -0700 (PDT) Received: by 10.50.100.168 with HTTP; Tue, 6 Aug 2013 15:28:44 -0700 (PDT) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> Date: Tue, 6 Aug 2013 18:28:44 -0400 Message-ID: From: Ira McDonald To: "Romascanu, Dan (Dan)" , Ira McDonald Content-Type: multipart/alternative; boundary=bcaec51864769eb22f04e34ef2b9 Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 22:28:50 -0000 --bcaec51864769eb22f04e34ef2b9 Content-Type: text/plain; charset=ISO-8859-1 +1 Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Aug 6, 2013 at 8:57 AM, Romascanu, Dan (Dan) wrote: > At the SACM WG meeting at IETF-87 the participants in the room did not > raise any objection to the proposal to separate the terminology section > from draft-waltermire-sacm-use-cases and make of it a separate document > that defines the SACM terms in one place and can be referred by all other > SACM documents. We are asking the WG to confirm this consensus on the mail > list. Please send all comments, questions and concerns to the SACM WG mail > list before 8/15. > > Thanks and Regards, > > Adam and Dan > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --bcaec51864769eb22f04e34ef2b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1

Cheers,
- Ira
=

Ira McDonald (Musician / = Software Architect)
Chair - Linux Foundation Open Printing WG
Secreta= ry - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solution= s WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert = - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Tue, Aug 6, 2013 at 8:57 AM, Romascan= u, Dan (Dan) <dromasca@avaya.com> wrote:
At the SACM WG meeting at IETF-87 the participants in the room did not rais= e any objection to the proposal to separate the terminology section from dr= aft-waltermire-sacm-use-cases and make of it a separate document that defin= es the SACM terms in one place and can be referred by all other SACM docume= nts. We are asking the WG to confirm this consensus on the mail list. Pleas= e send all comments, questions and concerns to the SACM WG mail list before= 8/15.

Thanks and Regards,

Adam and Dan




_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm

--bcaec51864769eb22f04e34ef2b9-- From dromasca@avaya.com Wed Aug 7 03:52:25 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246A621E80F4 for ; Wed, 7 Aug 2013 03:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.442 X-Spam-Level: X-Spam-Status: No, score=-103.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQeK+VJDU5kl for ; Wed, 7 Aug 2013 03:52:19 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id F07F921E80D7 for ; Wed, 7 Aug 2013 03:52:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIJAGMmAlLGmAcV/2dsb2JhbABagmUhNVC+QgQBgR0WdIIkAQEBAQMBAQEPKDQXBAIBCA0EBAEBAQoUCQcnCxQJCAIEARIIEQmHbgELnDucBxMEjlQQMFU4BoMUdAOeKosGgxeBcTk X-IronPort-AV: E=Sophos;i="4.89,832,1367985600"; d="scan'208";a="19199763" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Aug 2013 06:52:15 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Aug 2013 06:48:55 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0146.000; Wed, 7 Aug 2013 06:52:14 -0400 From: "Romascanu, Dan (Dan)" To: Adam Montville , "Baker, Jon" , "sacm@ietf.org" Thread-Topic: [Netconf] [netmod] development plan Thread-Index: AQHOkgOnm/osYRe9J0e5PlM5rLMAL5mIMtsAgAAdnYCAAAV5gIABO7yQ Date: Wed, 7 Aug 2013 10:52:13 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128A5DB7@AZ-FFEXMB04.global.avaya.com> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <6C1C15D8B5510B4B8FF132B10D38651304D313DD@IMCMBX03.MITRE.ORG> <05BCCEB107AF88469B9F99783D47C1D673D033@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D673D033@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 10:52:25 -0000 David Harrington is one of the active participants in Netconf. Bert Wijnen,= one of the Netconf co-chairs, Andy Bierman one of the principal contributo= rs attended the meeting in Berlin, but I do not see them subscribed to the = mail list. There may be other, and we can bring them in the discussion or a= sk questions. Netconf is mostly about configuring network devices, so the datastores Netc= onf relates to are typically local to the devices (routers, servers).=20 Regards, Dan > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Adam Montville > Sent: Tuesday, August 06, 2013 8:53 PM > To: Baker, Jon; sacm@ietf.org > Subject: Re: [sacm] [Netconf] [netmod] development plan >=20 > Thanks for pointing this out, Jon. >=20 > Is anyone on this list also working in netconf? On the surface, they > look very similar. It would be interesting to understand where, from an > architectural perspective, the datastore is said to reside for netconf > and how it should be accessed. I also find the phrase about not storing > executive commands interesting, because, presumably, some of the > information we want to store will be instructional in nature. >=20 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Baker, Jon > > Sent: Tuesday, August 06, 2013 10:34 AM > > To: sacm@ietf.org > > Subject: [sacm] FW: [Netconf] [netmod] development plan > > > > How closely are SACM WG participants also following the ongoing > > netconf discussion? > > > > This message seems to directly align with some of the work I have > > expected SACM to do. Take a look at this quote in particular: > > > > > A configuration datastore is defined as the complete set of > > >configuration data that > > > is required to get a device from its initial default state into a > > > desired operational state. The configuration datastore does not > > > include state data or executive commands. > > > > > > The running configuration datastore holds the complete > configuration > > > currently active on the network device. Only one configuration > > > datastore of this type exists on the device, and it is always > > > present. > > > > Given that the netconf wg seems to be in the middle of a very active > > discussion on very closely related topics I would suggest that we > > specifically reach out to the netconf group to ensure alignment and > > reuse where possible. > > > > Jon > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Jonathan O. Baker > > G022 - IA Industry Collaboration > > The MITRE Corporation > > Email: bakerj@mitre.org > > > > > > >-----Original Message----- > > >From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > >Behalf Of Balazs Lengyel > > >Sent: Tuesday, August 06, 2013 5:47 AM > > >To: Ladislav Lhotka > > >Cc: netmod@ietf.org; Netconf > > >Subject: Re: [Netconf] [netmod] development plan > > > > > > > > >On 2013-08-05 19:45, Ladislav Lhotka wrote: > > >> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel > > >> > > >wrote: > > >> > > >>> On 2013-08-05 16:03, Ladislav Lhotka wrote: > > >>>> It is a fact of life that YANG is being used outside NETCONF, and > > >>>> there are > > >more plans for doing do, but with 6020 it is a slippery slope. For > > >example, such non-NETCONF applications of YANG will most likely want > > >to > > use "must" > > >for expressing semantic constraints. However, the accessible tree for > > >"must" is defined like so: > > >>>> > > >>>> o If the context node represents configuration, the tree is > the data > > >>>> in the NETCONF datastore where the context node exists. > > >>>> The > > XPath > > >>>> root node has all top-level configuration data nodes in > all > > >>>> modules as children. > > >>>> > > >>>> o If the context node represents state data, the tree is all > state > > >>>> data on the device, and the datastore. The > XPath root > > >>>> node has all top-level data nodes in all modules as > children. > > >>>> > > >>>> This cannot be unambiguously interpreted in a non-NETCONF > > >>>> context, so > > >it is effectively undefined, which is rather dangerous. > > >>>> So I don't mean to completely redesign YANG, but we cannot, on > > >>>> the > > >other hand, enable non-NETCONF YANG data modelling without providing > > >new definitions. > > >>>> > > >>>> Lada > > >>> In my view Netconf contains the "pure" protocol (encoding, > > >>> operations, > > >transactional behavior...) and background plumbing (datastores, > > >separation of state and config data, hierarchical data organisation, > > >filtering, connection requirements, session concept, capability > > >negotiation, many of the capabilites, error messages). > > >>> The background plumbing is valid for all access methods (CLI, > > >>> Netconf, > > >YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be > redefined. > > >> I don't think this is true. I2RS will probably have no distinction > > >> between > > >config and state data, though they may have read-write and read-only. > > >Sessions and capability negotiation are by no means necessary > > >(RESTCONF doesn't have it). I can actually imagine data modelling > > >without any specific protocol for data exchange. > > >> > > >> Lada > > >IMHO we can debate whether some protocols need some of the features, > > or > > >whether some of the features belong to the plumbing or the pure > > >protocol, but I still believe that many of the concepts like "NETCONF > > >datastore" above are actually easily understandable without > > >considering the protocol on the wire. If you would just remove the > > >word Netconf from your example paragraphs IMHO they are quite > > >understandable in a protocol independent way. > > > > > >Let me just try as an exercise: > > >Running Datastore: > > > > > > A configuration datastore is defined as the complete set of > > >configuration data that > > > is required to get a device from its initial default state into a > > > desired operational state. The configuration datastore does not > > > include state data or executive commands. > > > > > > The running configuration datastore holds the complete > configuration > > > currently active on the network device. Only one configuration > > > datastore of this type exists on the device, and it is always > > > present. > > > > > >The above defeinition is extracted from RFC6241 (I just removed 2 > > >sentences). I think it is a very nice protocol independent > definition. > > > > > > > > >Does anyone have a list of features that make YANG protocol (Netconf) > > >dependent? > > > > > >Balazs > > > > > >_______________________________________________ > > >Netconf mailing list > > >Netconf@ietf.org > > >https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > > ... >=20 > . . . > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Wed Aug 7 04:51:24 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5402E21F9EFB for ; Wed, 7 Aug 2013 04:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiNAVEKUoYzo for ; Wed, 7 Aug 2013 04:51:18 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id D092521F9C4A for ; Wed, 7 Aug 2013 04:51:17 -0700 (PDT) Received: from WSGHUB2.xchange.nist.gov (129.6.16.197) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 7 Aug 2013 07:50:58 -0400 Received: from wsget1.nist.gov (129.6.13.150) by wsghub2.xchange.nist.gov (129.6.16.197) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 7 Aug 2013 07:51:14 -0400 Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 7 Aug 2013 07:51:09 -0400 Received: from na01-bn1-obe.outbound.protection.outlook.com (207.46.163.158) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 7 Aug 2013 07:51:14 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 7 Aug 2013 11:51:12 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.53]) with mapi id 15.00.0731.000; Wed, 7 Aug 2013 11:51:12 +0000 From: "Waltermire, David A." To: "Romascanu, Dan (Dan)" , Adam Montville , "Baker, Jon" , "sacm@ietf.org" Thread-Topic: [Netconf] [netmod] development plan Thread-Index: AQHOkdp3Zrixa9H9GUOrS6K9JR4LhJmG33MAgAAJJICAAB2bgIAAIGsAgAEMkACAAD4fcIAABdmQgAEdfoCAAAbioA== Date: Wed, 7 Aug 2013 11:51:11 +0000 Message-ID: <275bdaf693a04bc1b81493d998047e7d@BLUPR09MB038.namprd09.prod.outlook.com> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <6C1C15D8B5510B4B8FF132B10D38651304D313DD@IMCMBX03.MITRE.ORG> <05BCCEB107AF88469B9F99783D47C1D673D033@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA128A5DB7@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A5DB7@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 0931CB1479 x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(51704005)(252514010)(377454003)(24454002)(52604005)(199002)(189002)(377424004)(74316001)(54316002)(31966008)(76786001)(74366001)(47736001)(66066001)(74876001)(74502001)(59766001)(76482001)(76576001)(80022001)(33646001)(81542001)(77096001)(81342001)(80976001)(77982001)(83072001)(47446002)(50986001)(51856001)(49866001)(53806001)(47976001)(83322001)(19580405001)(74706001)(76796001)(46102001)(65816001)(4396001)(551934002)(19580395003)(56776001)(56816003)(19580385001)(69226001)(63696002)(79102001)(16406001)(54356001)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB038; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 11:51:24 -0000 I have been subscribed to the list and have been following NETMOD for almos= t a couple of years. While the current modeling work is focused on network = devices, there is little that prevents this approach from being used by oth= er endpoint device types. NETCONF/NETMOD addresses 3 types of configuratio= ns, the current running configuration, the persisted boot configuration, an= d an intermediate configuration that is used to build new configurations th= at have not been applied. At the last NETMOD WG meeting there was quite a b= it of discussion around decoupling NETMOD from NETCONF to make it more gene= rally useful to other efforts in the IETF. Both Adam and I were at the last= NETMOD meeting and advertised the SACM WG meeting to get some attendance f= rom the NETMOD community. While no decision was made to decouple NETCONF and NETMOD yet, IMHO making = use of NETMOD is something that we should consider as part of SACM. At mini= mum we could use it to retrieve configuration data from network devices and= it could be extended to do more. Depending on the level of coupling, there= may be some flexibility in transport (e.g., NETCONF, NEA). Considering how= it could fit into the architectural discussion, it might be used by a type= of NETCONF sensor/collector to remotely poll the device and to monitor not= ifications. Another way of looking at it architecturally would be to use N= ETCONF/NETMOD as a mechanism to communicate with the device, with the NETMO= D functionality serving as the sensor. Thoughts? Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Wednesday, August 07, 2013 6:52 AM > To: Adam Montville; Baker, Jon; sacm@ietf.org > Subject: Re: [sacm] [Netconf] [netmod] development plan >=20 > David Harrington is one of the active participants in Netconf. Bert Wijne= n, > one of the Netconf co-chairs, Andy Bierman one of the principal contribut= ors > attended the meeting in Berlin, but I do not see them subscribed to the m= ail > list. There may be other, and we can bring them in the discussion or ask > questions. >=20 > Netconf is mostly about configuring network devices, so the datastores > Netconf relates to are typically local to the devices (routers, servers). >=20 > Regards, >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Tuesday, August 06, 2013 8:53 PM > > To: Baker, Jon; sacm@ietf.org > > Subject: Re: [sacm] [Netconf] [netmod] development plan > > > > Thanks for pointing this out, Jon. > > > > Is anyone on this list also working in netconf? On the surface, they > > look very similar. It would be interesting to understand where, from > > an architectural perspective, the datastore is said to reside for > > netconf and how it should be accessed. I also find the phrase about > > not storing executive commands interesting, because, presumably, some > > of the information we want to store will be instructional in nature. > > > > > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > > > Of Baker, Jon > > > Sent: Tuesday, August 06, 2013 10:34 AM > > > To: sacm@ietf.org > > > Subject: [sacm] FW: [Netconf] [netmod] development plan > > > > > > How closely are SACM WG participants also following the ongoing > > > netconf discussion? > > > > > > This message seems to directly align with some of the work I have > > > expected SACM to do. Take a look at this quote in particular: > > > > > > > A configuration datastore is defined as the complete set of > > > >configuration data that > > > > is required to get a device from its initial default state into = a > > > > desired operational state. The configuration datastore does not > > > > include state data or executive commands. > > > > > > > > The running configuration datastore holds the complete > > configuration > > > > currently active on the network device. Only one configuration > > > > datastore of this type exists on the device, and it is always > > > > present. > > > > > > Given that the netconf wg seems to be in the middle of a very active > > > discussion on very closely related topics I would suggest that we > > > specifically reach out to the netconf group to ensure alignment and > > > reuse where possible. > > > > > > Jon > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Jonathan O. Baker > > > G022 - IA Industry Collaboration > > > The MITRE Corporation > > > Email: bakerj@mitre.org > > > > > > > > > >-----Original Message----- > > > >From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] > On > > > >Behalf Of Balazs Lengyel > > > >Sent: Tuesday, August 06, 2013 5:47 AM > > > >To: Ladislav Lhotka > > > >Cc: netmod@ietf.org; Netconf > > > >Subject: Re: [Netconf] [netmod] development plan > > > > > > > > > > > >On 2013-08-05 19:45, Ladislav Lhotka wrote: > > > >> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel > > > >> > > > >wrote: > > > >> > > > >>> On 2013-08-05 16:03, Ladislav Lhotka wrote: > > > >>>> It is a fact of life that YANG is being used outside NETCONF, > > > >>>> and there are > > > >more plans for doing do, but with 6020 it is a slippery slope. For > > > >example, such non-NETCONF applications of YANG will most likely > > > >want to > > > use "must" > > > >for expressing semantic constraints. However, the accessible tree > > > >for "must" is defined like so: > > > >>>> > > > >>>> o If the context node represents configuration, the tree > > > >>>> is > > the data > > > >>>> in the NETCONF datastore where the context node exists. > > > >>>> The > > > XPath > > > >>>> root node has all top-level configuration data nodes in > > all > > > >>>> modules as children. > > > >>>> > > > >>>> o If the context node represents state data, the tree is > > > >>>> all > > state > > > >>>> data on the device, and the datastore. The > > XPath root > > > >>>> node has all top-level data nodes in all modules as > > children. > > > >>>> > > > >>>> This cannot be unambiguously interpreted in a non-NETCONF > > > >>>> context, so > > > >it is effectively undefined, which is rather dangerous. > > > >>>> So I don't mean to completely redesign YANG, but we cannot, on > > > >>>> the > > > >other hand, enable non-NETCONF YANG data modelling without > > > >providing new definitions. > > > >>>> > > > >>>> Lada > > > >>> In my view Netconf contains the "pure" protocol (encoding, > > > >>> operations, > > > >transactional behavior...) and background plumbing (datastores, > > > >separation of state and config data, hierarchical data > > > >organisation, filtering, connection requirements, session concept, > > > >capability negotiation, many of the capabilites, error messages). > > > >>> The background plumbing is valid for all access methods (CLI, > > > >>> Netconf, > > > >YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be > > redefined. > > > >> I don't think this is true. I2RS will probably have no > > > >> distinction between > > > >config and state data, though they may have read-write and read-only= . > > > >Sessions and capability negotiation are by no means necessary > > > >(RESTCONF doesn't have it). I can actually imagine data modelling > > > >without any specific protocol for data exchange. > > > >> > > > >> Lada > > > >IMHO we can debate whether some protocols need some of the > > > >features, > > > or > > > >whether some of the features belong to the plumbing or the pure > > > >protocol, but I still believe that many of the concepts like > > > >"NETCONF datastore" above are actually easily understandable > > > >without considering the protocol on the wire. If you would just > > > >remove the word Netconf from your example paragraphs IMHO they > are > > > >quite understandable in a protocol independent way. > > > > > > > >Let me just try as an exercise: > > > >Running Datastore: > > > > > > > > A configuration datastore is defined as the complete set of > > > >configuration data that > > > > is required to get a device from its initial default state into = a > > > > desired operational state. The configuration datastore does not > > > > include state data or executive commands. > > > > > > > > The running configuration datastore holds the complete > > configuration > > > > currently active on the network device. Only one configuration > > > > datastore of this type exists on the device, and it is always > > > > present. > > > > > > > >The above defeinition is extracted from RFC6241 (I just removed 2 > > > >sentences). I think it is a very nice protocol independent > > definition. > > > > > > > > > > > >Does anyone have a list of features that make YANG protocol > > > >(Netconf) dependent? > > > > > > > >Balazs > > > > > > > >_______________________________________________ > > > >Netconf mailing list > > > >Netconf@ietf.org > > > >https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > ... > > > > . . . > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Wed Aug 7 05:39:49 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA62821F9B8C for ; Wed, 7 Aug 2013 05:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHQZ+NJ-Z0Pf for ; Wed, 7 Aug 2013 05:39:45 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 535AA21E80EE for ; Wed, 7 Aug 2013 05:39:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=kd57HtyM6CP6VCo/b+ViUYFA7nO3V3sK0vvUs7YndoZAwScCnYoHnHTmN+O5LSBu8kpNy1VsdNuXw7TXvKlNEPYQVslMfq3kni8ABf/MqeKl/yaKo4is3rZrHdngGSEy; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 27244 invoked from network); 7 Aug 2013 05:38:30 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 7 Aug 2013 05:38:30 -0700 Message-ID: <52024002.3070009@ThreatGuard.com> Date: Wed, 07 Aug 2013 08:39:30 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 12:39:49 -0000 +1 On 8/6/2013 8:57 AM, Romascanu, Dan (Dan) wrote: > At the SACM WG meeting at IETF-87 the participants in the room did not raise any objection to the proposal to separate the terminology section from draft-waltermire-sacm-use-cases and make of it a separate document that defines the SACM terms in one place and can be referred by all other SACM documents. We are asking the WG to confirm this consensus on the mail list. Please send all comments, questions and concerns to the SACM WG mail list before 8/15. > > Thanks and Regards, > > Adam and Dan > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From dromasca@avaya.com Wed Aug 7 06:58:26 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E617921E8124 for ; Wed, 7 Aug 2013 06:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cu-CSVqcU3N for ; Wed, 7 Aug 2013 06:58:20 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 39E6721E811B for ; Wed, 7 Aug 2013 06:58:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAL9RAlKHCzI1/2dsb2JhbABbgmUhgQW+R4EcFnSCJgEBAxIoUQEVFRRCJgEEGxqHbgGXeIREnBeOZIEFg1J0A54qiwaDF4FxOQ X-IronPort-AV: E=Sophos;i="4.89,833,1367985600"; d="scan'208";a="19222995" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Aug 2013 09:58:18 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Aug 2013 09:51:30 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Wed, 7 Aug 2013 15:58:15 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: SACM - Consensus on the format of the use cases Thread-Index: Ac6Tdilw25Byrnv1QxqR9Zzd1z4+xg== Date: Wed, 7 Aug 2013 13:58:15 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128A62B4@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] SACM - Consensus on the format of the use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:58:27 -0000 At the SACM WG meeting at IETF-87 the participants in the room did not rais= e objections to the proposal made by David Harrington about the format of t= he use cases:=20 - do not make it too formal in structure - use narrative English but describe the actors and actions. - include some descriptive text after to further clarify wherever necessary We are asking the WG to confirm this consensus on the mail list. Please sen= d all comments, questions and concerns to the SACM WG mail list before 8/15= . Adam and Dan From bakerj@mitre.org Wed Aug 7 07:17:06 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4913E21F9A26 for ; Wed, 7 Aug 2013 07:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdRkYbc73Dzi for ; Wed, 7 Aug 2013 07:17:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2B92D21E8117 for ; Wed, 7 Aug 2013 07:17:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B84BB1F0AA2; Wed, 7 Aug 2013 10:17:00 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 81D2F1F03C9; Wed, 7 Aug 2013 10:17:00 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.165]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Wed, 7 Aug 2013 10:17:00 -0400 From: "Baker, Jon" To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: SACM - Consensus on the format of the use cases Thread-Index: Ac6Tdilw25Byrnv1QxqR9Zzd1z4+xgAAodMA Date: Wed, 7 Aug 2013 14:16:59 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651304D335B8@IMCMBX03.MITRE.ORG> References: <9904FB1B0159DA42B0B887B7FA8119CA128A62B4@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A62B4@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM - Consensus on the format of the use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:17:06 -0000 This seems reasonable and will align with the format of use cases generated= by other WGs in the IETF.=20 Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Romascanu, Dan (Dan) >Sent: Wednesday, August 07, 2013 9:58 AM >To: sacm@ietf.org >Subject: [sacm] SACM - Consensus on the format of the use cases > >At the SACM WG meeting at IETF-87 the participants in the room did not rai= se >objections to the proposal made by David Harrington about the format of th= e >use cases: > >- do not make it too formal in structure >- use narrative English but describe the actors and actions. >- include some descriptive text after to further clarify wherever necessar= y > >We are asking the WG to confirm this consensus on the mail list. Please se= nd >all comments, questions and concerns to the SACM WG mail list before 8/15. > >Adam and Dan > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From lnunez@mitre.org Wed Aug 7 07:26:16 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5474921E8134 for ; Wed, 7 Aug 2013 07:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WcemKnb-3SU for ; Wed, 7 Aug 2013 07:26:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id AEC3611E812B for ; Wed, 7 Aug 2013 07:25:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 44C101F0AB4; Wed, 7 Aug 2013 10:25:55 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 04A471F0AC2; Wed, 7 Aug 2013 10:25:55 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.165]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Wed, 7 Aug 2013 10:25:54 -0400 From: "Nunez, Luis K" To: "Waltermire, David A." , "Romascanu, Dan (Dan)" , Adam Montville , "Baker, Jon" , "sacm@ietf.org" Thread-Topic: [Netconf] [netmod] development plan Thread-Index: AQHOkdp3Zrixa9H9GUOrS6K9JR4LhJmG33MAgAAJJICAAB2bgIAAIGsAgAEMkACAAD4fcIAABdmQgAFgjICAABB6gP//1mhQ Date: Wed, 7 Aug 2013 14:25:53 +0000 Message-ID: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <6C1C15D8B5510B4B8FF132B10D38651304D313DD@IMCMBX03.MITRE.ORG> <05BCCEB107AF88469B9F99783D47C1D673D033@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA128A5DB7@AZ-FFEXMB04.global.avaya.com> <275bdaf693a04bc1b81493d998047e7d@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <275bdaf693a04bc1b81493d998047e7d@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:26:16 -0000 On your last point "NETMOD functionality serving as the sensor". I agree N= ETCONF could be used in other ways. For example RFC 6728 IPFIX/PSAMP Config= uration Data Model includes NETCONF and Yang. From a SACM architecture, NE= TCONF could be used to deploy IPFIX sensing definitions based on threat int= elligence and observables (STIX/MILE). As SACM evolves, these kinds of c= onnections will emerge into use cases. -ln=20 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Wal= termire, David A. Sent: Wednesday, August 07, 2013 7:51 AM To: Romascanu, Dan (Dan); Adam Montville; Baker, Jon; sacm@ietf.org Subject: Re: [sacm] [Netconf] [netmod] development plan I have been subscribed to the list and have been following NETMOD for almos= t a couple of years. While the current modeling work is focused on network = devices, there is little that prevents this approach from being used by oth= er endpoint device types. NETCONF/NETMOD addresses 3 types of configuratio= ns, the current running configuration, the persisted boot configuration, an= d an intermediate configuration that is used to build new configurations th= at have not been applied. At the last NETMOD WG meeting there was quite a b= it of discussion around decoupling NETMOD from NETCONF to make it more gene= rally useful to other efforts in the IETF. Both Adam and I were at the last= NETMOD meeting and advertised the SACM WG meeting to get some attendance f= rom the NETMOD community. While no decision was made to decouple NETCONF and NETMOD yet, IMHO making = use of NETMOD is something that we should consider as part of SACM. At mini= mum we could use it to retrieve configuration data from network devices and= it could be extended to do more. Depending on the level of coupling, there= may be some flexibility in transport (e.g., NETCONF, NEA). Considering how= it could fit into the architectural discussion, it might be used by a type= of NETCONF sensor/collector to remotely poll the device and to monitor not= ifications. Another way of looking at it architecturally would be to use N= ETCONF/NETMOD as a mechanism to communicate with the device, with the NETMO= D functionality serving as the sensor. Thoughts? Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Wednesday, August 07, 2013 6:52 AM > To: Adam Montville; Baker, Jon; sacm@ietf.org > Subject: Re: [sacm] [Netconf] [netmod] development plan >=20 > David Harrington is one of the active participants in Netconf. Bert Wijne= n, > one of the Netconf co-chairs, Andy Bierman one of the principal contribut= ors > attended the meeting in Berlin, but I do not see them subscribed to the m= ail > list. There may be other, and we can bring them in the discussion or ask > questions. >=20 > Netconf is mostly about configuring network devices, so the datastores > Netconf relates to are typically local to the devices (routers, servers). >=20 > Regards, >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Adam Montville > > Sent: Tuesday, August 06, 2013 8:53 PM > > To: Baker, Jon; sacm@ietf.org > > Subject: Re: [sacm] [Netconf] [netmod] development plan > > > > Thanks for pointing this out, Jon. > > > > Is anyone on this list also working in netconf? On the surface, they > > look very similar. It would be interesting to understand where, from > > an architectural perspective, the datastore is said to reside for > > netconf and how it should be accessed. I also find the phrase about > > not storing executive commands interesting, because, presumably, some > > of the information we want to store will be instructional in nature. > > > > > > > -----Original Message----- > > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On > Behalf > > > Of Baker, Jon > > > Sent: Tuesday, August 06, 2013 10:34 AM > > > To: sacm@ietf.org > > > Subject: [sacm] FW: [Netconf] [netmod] development plan > > > > > > How closely are SACM WG participants also following the ongoing > > > netconf discussion? > > > > > > This message seems to directly align with some of the work I have > > > expected SACM to do. Take a look at this quote in particular: > > > > > > > A configuration datastore is defined as the complete set of > > > >configuration data that > > > > is required to get a device from its initial default state into = a > > > > desired operational state. The configuration datastore does not > > > > include state data or executive commands. > > > > > > > > The running configuration datastore holds the complete > > configuration > > > > currently active on the network device. Only one configuration > > > > datastore of this type exists on the device, and it is always > > > > present. > > > > > > Given that the netconf wg seems to be in the middle of a very active > > > discussion on very closely related topics I would suggest that we > > > specifically reach out to the netconf group to ensure alignment and > > > reuse where possible. > > > > > > Jon > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Jonathan O. Baker > > > G022 - IA Industry Collaboration > > > The MITRE Corporation > > > Email: bakerj@mitre.org > > > > > > > > > >-----Original Message----- > > > >From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] > On > > > >Behalf Of Balazs Lengyel > > > >Sent: Tuesday, August 06, 2013 5:47 AM > > > >To: Ladislav Lhotka > > > >Cc: netmod@ietf.org; Netconf > > > >Subject: Re: [Netconf] [netmod] development plan > > > > > > > > > > > >On 2013-08-05 19:45, Ladislav Lhotka wrote: > > > >> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel > > > >> > > > >wrote: > > > >> > > > >>> On 2013-08-05 16:03, Ladislav Lhotka wrote: > > > >>>> It is a fact of life that YANG is being used outside NETCONF, > > > >>>> and there are > > > >more plans for doing do, but with 6020 it is a slippery slope. For > > > >example, such non-NETCONF applications of YANG will most likely > > > >want to > > > use "must" > > > >for expressing semantic constraints. However, the accessible tree > > > >for "must" is defined like so: > > > >>>> > > > >>>> o If the context node represents configuration, the tree > > > >>>> is > > the data > > > >>>> in the NETCONF datastore where the context node exists. > > > >>>> The > > > XPath > > > >>>> root node has all top-level configuration data nodes in > > all > > > >>>> modules as children. > > > >>>> > > > >>>> o If the context node represents state data, the tree is > > > >>>> all > > state > > > >>>> data on the device, and the datastore. The > > XPath root > > > >>>> node has all top-level data nodes in all modules as > > children. > > > >>>> > > > >>>> This cannot be unambiguously interpreted in a non-NETCONF > > > >>>> context, so > > > >it is effectively undefined, which is rather dangerous. > > > >>>> So I don't mean to completely redesign YANG, but we cannot, on > > > >>>> the > > > >other hand, enable non-NETCONF YANG data modelling without > > > >providing new definitions. > > > >>>> > > > >>>> Lada > > > >>> In my view Netconf contains the "pure" protocol (encoding, > > > >>> operations, > > > >transactional behavior...) and background plumbing (datastores, > > > >separation of state and config data, hierarchical data > > > >organisation, filtering, connection requirements, session concept, > > > >capability negotiation, many of the capabilites, error messages). > > > >>> The background plumbing is valid for all access methods (CLI, > > > >>> Netconf, > > > >YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be > > redefined. > > > >> I don't think this is true. I2RS will probably have no > > > >> distinction between > > > >config and state data, though they may have read-write and read-only= . > > > >Sessions and capability negotiation are by no means necessary > > > >(RESTCONF doesn't have it). I can actually imagine data modelling > > > >without any specific protocol for data exchange. > > > >> > > > >> Lada > > > >IMHO we can debate whether some protocols need some of the > > > >features, > > > or > > > >whether some of the features belong to the plumbing or the pure > > > >protocol, but I still believe that many of the concepts like > > > >"NETCONF datastore" above are actually easily understandable > > > >without considering the protocol on the wire. If you would just > > > >remove the word Netconf from your example paragraphs IMHO they > are > > > >quite understandable in a protocol independent way. > > > > > > > >Let me just try as an exercise: > > > >Running Datastore: > > > > > > > > A configuration datastore is defined as the complete set of > > > >configuration data that > > > > is required to get a device from its initial default state into = a > > > > desired operational state. The configuration datastore does not > > > > include state data or executive commands. > > > > > > > > The running configuration datastore holds the complete > > configuration > > > > currently active on the network device. Only one configuration > > > > datastore of this type exists on the device, and it is always > > > > present. > > > > > > > >The above defeinition is extracted from RFC6241 (I just removed 2 > > > >sentences). I think it is a very nice protocol independent > > definition. > > > > > > > > > > > >Does anyone have a list of features that make YANG protocol > > > >(Netconf) dependent? > > > > > > > >Balazs > > > > > > > >_______________________________________________ > > > >Netconf mailing list > > > >Netconf@ietf.org > > > >https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > > > sacm mailing list > > > sacm@ietf.org > > > https://www.ietf.org/mailman/listinfo/sacm > > > > > > ... > > > > . . . > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From aawoland@cisco.com Wed Aug 7 07:54:09 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DAA11E813D for ; Wed, 7 Aug 2013 07:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jws2pC7dd7pW for ; Wed, 7 Aug 2013 07:54:04 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 17D0911E8142 for ; Wed, 7 Aug 2013 07:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1569; q=dns/txt; s=iport; t=1375887244; x=1377096844; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=NLW5EbSICiDbouRfOmzHGqRawEXVNyVRr6G6gghBAwQ=; b=kar3MPc0hNrKZvOif/xOfKfhscMpgi3LXCjedrmBcrc75DmXlM8nIzGV 73MQuiubLs71EKhuFAwXhjL2HJ9k7NXqhpK0p2fpFYmt7MnQ+76up6Y2z r293INQ5e5NM4UXI4fldgBj6HhZzOpf8NjS1WUxoNMptqBZnS1qbmeEJl g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFACxeAlKtJV2Y/2dsb2JhbABbgwY1UL5FgRwWdIIkAQEBBAEBATc0FwYBCBEEAQELFAkuCxQJCAEBBAESCIgIDLgzBI5UEIEDAjgGgxR0A6kwgxeBcTk X-IronPort-AV: E=Sophos;i="4.89,833,1367971200"; d="scan'208";a="241580055" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 07 Aug 2013 14:54:02 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r77Es2Sp028516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 14:54:02 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.107]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 09:54:02 -0500 From: "Aaron Woland (aawoland)" To: "Baker, Jon" , "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: [sacm] SACM - Consensus on the format of the use cases Thread-Index: Ac6Tdilw25Byrnv1QxqR9Zzd1z4+xgAAodMAAANrIgA= Date: Wed, 7 Aug 2013 14:54:02 +0000 Message-ID: <862FA31948313540BD2843B1AA96F25C46FEA1E4@xmb-rcd-x01.cisco.com> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D38651304D335B8@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.150.5.63] Content-Type: text/plain; charset="us-ascii" Content-ID: <4B9D53E02A126C409DB3CE02CD45EC6F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] SACM - Consensus on the format of the use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:54:09 -0000 That sounds good. Aaron On 8/7/13 10:16 AM, "Baker, Jon" wrote: >This seems reasonable and will align with the format of use cases >generated by other WGs in the IETF. > >Jon > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Jonathan O. Baker >G022 - IA Industry Collaboration >The MITRE Corporation >Email: bakerj@mitre.org > > >>-----Original Message----- >>From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>Romascanu, Dan (Dan) >>Sent: Wednesday, August 07, 2013 9:58 AM >>To: sacm@ietf.org >>Subject: [sacm] SACM - Consensus on the format of the use cases >> >>At the SACM WG meeting at IETF-87 the participants in the room did not >>raise >>objections to the proposal made by David Harrington about the format of >>the >>use cases: >> >>- do not make it too formal in structure >>- use narrative English but describe the actors and actions. >>- include some descriptive text after to further clarify wherever >>necessary >> >>We are asking the WG to confirm this consensus on the mail list. Please >>send >>all comments, questions and concerns to the SACM WG mail list before >>8/15. >> >>Adam and Dan >> >> >>_______________________________________________ >>sacm mailing list >>sacm@ietf.org >>https://www.ietf.org/mailman/listinfo/sacm >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From blueroofmusic@gmail.com Wed Aug 7 08:03:54 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448A021E804E for ; Wed, 7 Aug 2013 08:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BSoWmaUttqz for ; Wed, 7 Aug 2013 08:03:53 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id D74CE21E8137 for ; Wed, 7 Aug 2013 08:03:37 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo10so3932939obc.27 for ; Wed, 07 Aug 2013 08:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h98cI0cxB6+TBRN15csQ/h13PPH+/kOq8GGHPm3Fgds=; b=HVNmn2nONtlGGJOlx4B9ZOtqAT6PbB4tJCBTvJqt2bdLAoMb/N7GUnK388PpHqhsXs 5brFjp3FaYdBCLc3ijjF+NLuYW6YFZxn+RlGYKNdpuR49BwPrkBGqVUUF1DfLGMyYOlg Ww7lLybZFL+RXwtRPfe+quUiZWr4rviQwGxkdxK/CdoZucTEPPWqptZwXwV0IclaWq1t TcUI/fsDKyILtjJPpZhT4fGt5ae1uzeRY7hdqIc5fB4wZ/94+/60HPHkVZhBZnPSVSnV rlNLjZWfP9CxVvHFxBSxmxvcq6/8dsaUxkwgJ0ebfo+mnQiqS0MhDM1ryX8K+s6ywEMR ttnA== MIME-Version: 1.0 X-Received: by 10.50.152.34 with SMTP id uv2mr87155igb.56.1375887817267; Wed, 07 Aug 2013 08:03:37 -0700 (PDT) Received: by 10.50.100.168 with HTTP; Wed, 7 Aug 2013 08:03:37 -0700 (PDT) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A62B4@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128A62B4@AZ-FFEXMB04.global.avaya.com> Date: Wed, 7 Aug 2013 11:03:37 -0400 Message-ID: From: Ira McDonald To: "Romascanu, Dan (Dan)" , Ira McDonald Content-Type: multipart/alternative; boundary=089e0149c01c995ee204e35cd886 Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM - Consensus on the format of the use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:03:54 -0000 --089e0149c01c995ee204e35cd886 Content-Type: text/plain; charset=ISO-8859-1 +1 Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Aug 7, 2013 at 9:58 AM, Romascanu, Dan (Dan) wrote: > At the SACM WG meeting at IETF-87 the participants in the room did not > raise objections to the proposal made by David Harrington about the format > of the use cases: > > - do not make it too formal in structure > - use narrative English but describe the actors and actions. > - include some descriptive text after to further clarify wherever necessary > > We are asking the WG to confirm this consensus on the mail list. Please > send all comments, questions and concerns to the SACM WG mail list before > 8/15. > > Adam and Dan > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --089e0149c01c995ee204e35cd886 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1

Cheers,
- Ira
=

Ira McDonald (Musician / = Software Architect)
Chair - Linux Foundation Open Printing WG
Secreta= ry - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solution= s WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert = - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Wed, Aug 7, 2013 at 9:58 AM, Romascan= u, Dan (Dan) <dromasca@avaya.com> wrote:
At the SACM WG meeting at IETF-87 the participants in the room did not rais= e objections to the proposal made by David Harrington about the format of t= he use cases:

- do not make it too formal in structure
- use narrative English but describe the actors and actions.
- include some descriptive text after to further clarify wherever necessary=

We are asking the WG to confirm this consensus on the mail list. Please sen= d all comments, questions and concerns to the SACM WG mail list before 8/15= .

Adam and Dan


_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm

--089e0149c01c995ee204e35cd886-- From david.waltermire@nist.gov Wed Aug 7 08:11:04 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974F921F9D04 for ; Wed, 7 Aug 2013 08:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYZSwD21h52Q for ; Wed, 7 Aug 2013 08:10:58 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id EC3B121F9F7F for ; Wed, 7 Aug 2013 08:10:46 -0700 (PDT) Received: from WSGHUB2.xchange.nist.gov (129.6.16.197) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 7 Aug 2013 11:10:28 -0400 Received: from wsget2.nist.gov (129.6.13.151) by wsghub2.xchange.nist.gov (129.6.16.197) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 7 Aug 2013 11:10:44 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 7 Aug 2013 11:10:27 -0400 Received: from na01-bl2-obe.outbound.protection.outlook.com (207.46.163.205) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 7 Aug 2013 11:10:44 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB037.namprd09.prod.outlook.com (10.255.211.139) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 7 Aug 2013 15:10:32 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.53]) with mapi id 15.00.0731.000; Wed, 7 Aug 2013 15:10:32 +0000 From: "Waltermire, David A." To: "Romascanu, Dan (Dan)" , "sacm@ietf.org" Thread-Topic: SACM - Consensus on the format of the use cases Thread-Index: Ac6Tdilw25Byrnv1QxqR9Zzd1z4+xgACXDHA Date: Wed, 7 Aug 2013 15:10:31 +0000 Message-ID: <55ac5b886faa43c2b2b8b8313ff232f4@BLUPR09MB038.namprd09.prod.outlook.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128A62B4@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A62B4@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 0931CB1479 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(51704005)(13464003)(16406001)(47446002)(76576001)(56816003)(19580395003)(69226001)(4396001)(31966008)(19580385001)(76786001)(54316002)(54356001)(83072001)(74366001)(50986001)(81342001)(33646001)(74876001)(77982001)(53806001)(46102001)(83322001)(47736001)(59766001)(76796001)(63696002)(51856001)(561944002)(80022001)(74706001)(81542001)(49866001)(74316001)(77096001)(56776001)(79102001)(65816001)(74502001)(76482001)(47976001)(74662001)(80976001)(19580405001)(66066001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB037; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] SACM - Consensus on the format of the use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:11:04 -0000 +1 with one caveat. It was also discussed that references to specific technological concerns wo= uld be abstracted and provided as examples. For example identification of = endpoints by network addressing info and other endpoint sources (e.g., hw/s= w certs, BIOS ids, etc.) This represents a shift in the current format as w= ell that we should have some consensus around. Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Wednesday, August 07, 2013 9:58 AM > To: sacm@ietf.org > Subject: [sacm] SACM - Consensus on the format of the use cases >=20 > At the SACM WG meeting at IETF-87 the participants in the room did not ra= ise > objections to the proposal made by David Harrington about the format of t= he > use cases: >=20 > - do not make it too formal in structure > - use narrative English but describe the actors and actions. > - include some descriptive text after to further clarify wherever necessa= ry >=20 > We are asking the WG to confirm this consensus on the mail list. Please s= end > all comments, questions and concerns to the SACM WG mail list before 8/15= . >=20 > Adam and Dan >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From jclarke@cisco.com Wed Aug 7 11:46:13 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F9321F9C66 for ; Wed, 7 Aug 2013 11:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6muxidkjpMOI for ; Wed, 7 Aug 2013 11:46:07 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDA821F9951 for ; Wed, 7 Aug 2013 11:46:07 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r77Ik1ke011294; Wed, 7 Aug 2013 14:46:01 -0400 (EDT) Received: from rtp-vpn2-88.cisco.com (rtp-vpn2-88.cisco.com [10.82.240.88]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r77Ijxsf026144; Wed, 7 Aug 2013 14:46:00 -0400 (EDT) Message-ID: <520295E7.1010208@cisco.com> Date: Wed, 07 Aug 2013 14:45:59 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <9904FB1B0159DA42B0B887B7FA8119CA128A62B4@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A62B4@AZ-FFEXMB04.global.avaya.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM - Consensus on the format of the use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:46:13 -0000 On 8/7/13 9:58 AM, Romascanu, Dan (Dan) wrote: > At the SACM WG meeting at IETF-87 the participants in the room did not raise objections to the proposal made by David Harrington about the format of the use cases: > > - do not make it too formal in structure > - use narrative English but describe the actors and actions. > - include some descriptive text after to further clarify wherever necessary > > We are asking the WG to confirm this consensus on the mail list. Please send all comments, questions and concerns to the SACM WG mail list before 8/15. This list captures my understanding of what was discussed, though I recall some talk about deep-dive details like SNMP collection was too specific and jumped to solutions. I thought it was discussed that part would get generalized as part of the next edit. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From Adam.Montville@cisecurity.org Wed Aug 7 11:51:36 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A446621E805A for ; Wed, 7 Aug 2013 11:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2xrIgMPQU6W for ; Wed, 7 Aug 2013 11:51:25 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.205]) by ietfa.amsl.com (Postfix) with ESMTP id A51E121E8082 for ; Wed, 7 Aug 2013 11:51:20 -0700 (PDT) Received: from [216.82.242.179:16641] by server-13.bemta-8.messagelabs.com id 37/F6-25873-72792025; Wed, 07 Aug 2013 18:51:19 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-6.tower-86.messagelabs.com!1375901479!47087986!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 28231 invoked from network); 7 Aug 2013 18:51:19 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-6.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 7 Aug 2013 18:51:19 -0000 Received: from CISEXCHANGE1.msisac.org.local ([::1]) by CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3%14]) with mapi id 14.02.0342.003; Wed, 7 Aug 2013 14:51:16 -0400 From: Adam Montville To: Joe Marcus Clarke , "Romascanu, Dan (Dan)" Thread-Topic: [sacm] SACM - Consensus on the format of the use cases Thread-Index: Ac6Tdilw25Byrnv1QxqR9Zzd1z4+xgASbkqAAAhKDnA= Date: Wed, 7 Aug 2013 18:51:16 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D673D83A@CISEXCHANGE1.msisac.org.local> References: <9904FB1B0159DA42B0B887B7FA8119CA128A62B4@AZ-FFEXMB04.global.avaya.com> <520295E7.1010208@cisco.com> In-Reply-To: <520295E7.1010208@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM - Consensus on the format of the use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:51:36 -0000 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Joe Marcus Clarke > Sent: Wednesday, August 07, 2013 11:46 AM > To: Romascanu, Dan (Dan) > Cc: sacm@ietf.org > Subject: Re: [sacm] SACM - Consensus on the format of the use cases >=20 > On 8/7/13 9:58 AM, Romascanu, Dan (Dan) wrote: > > At the SACM WG meeting at IETF-87 the participants in the room did not= > raise objections to the proposal made by David Harrington about the form= at > of the use cases: > > > > - do not make it too formal in structure > > - use narrative English but describe the actors and actions. > > - include some descriptive text after to further clarify wherever > > necessary > > > > We are asking the WG to confirm this consensus on the mail list. Pleas= e > send all comments, questions and concerns to the SACM WG mail list befor= e > 8/15. >=20 > This list captures my understanding of what was discussed, though I reca= ll > some talk about deep-dive details like SNMP collection was too specific = and > jumped to solutions. I thought it was discussed that part would get > generalized as part of the next edit. >=20 You are correct. There was a discussion about what would be too detailed = and jump toward solutions, and there seemed to be consensus in the room ar= ound this. > Joe >=20 >=20 > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > ------------------------------------------------------------------------= ---- > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > ... . . . From shanna@juniper.net Wed Aug 7 12:47:47 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A6221F937E for ; Wed, 7 Aug 2013 12:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.612 X-Spam-Level: X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5m19xE199w4 for ; Wed, 7 Aug 2013 12:47:41 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id EF1E521E815A for ; Wed, 7 Aug 2013 12:47:19 -0700 (PDT) Received: from mail115-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE024.bigfish.com (10.243.66.87) with Microsoft SMTP Server id 14.1.225.22; Wed, 7 Aug 2013 19:47:18 +0000 Received: from mail115-co1 (localhost [127.0.0.1]) by mail115-co1-R.bigfish.com (Postfix) with ESMTP id 53AA8E03DE; Wed, 7 Aug 2013 19:47:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI62a3I98dI9371I542I1432I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail115-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(164054003)(51704005)(189002)(199002)(377454003)(24454002)(479174003)(252514010)(51856001)(4396001)(50986001)(47976001)(47736001)(56776001)(49866001)(79102001)(31966008)(74662001)(74502001)(47446002)(77982001)(74876001)(59766001)(74706001)(69226001)(81342001)(46102001)(65816001)(16406001)(561944002)(74366001)(54356001)(54316002)(76482001)(83072001)(81542001)(33646001)(66066001)(74316001)(53806001)(80022001)(76576001)(76796001)(76786001)(19580405001)(19580385001)(83322001)(19580395003)(56816003)(77096001)(80976001)(63696002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB054; H:BLUPR05MB053.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail115-co1 (localhost.localdomain [127.0.0.1]) by mail115-co1 (MessageSwitch) id 1375904835849338_12218; Wed, 7 Aug 2013 19:47:15 +0000 (UTC) Received: from CO1EHSMHS027.bigfish.com (unknown [10.243.78.227]) by mail115-co1.bigfish.com (Postfix) with ESMTP id C2407680048; Wed, 7 Aug 2013 19:47:15 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS027.bigfish.com (10.243.66.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 7 Aug 2013 19:47:03 +0000 Received: from BLUPR05MB054.namprd05.prod.outlook.com (10.255.210.149) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Wed, 7 Aug 2013 19:47:02 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) by BLUPR05MB054.namprd05.prod.outlook.com (10.255.210.149) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 7 Aug 2013 19:47:02 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.169]) by BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.223]) with mapi id 15.00.0731.000; Wed, 7 Aug 2013 19:47:02 +0000 From: Stephen Hanna To: Joe Marcus Clarke , "Romascanu, Dan (Dan)" Thread-Topic: [sacm] SACM - Consensus on the format of the use cases Thread-Index: Ac6Tdilw25Byrnv1QxqR9Zzd1z4+xgAKDIWAAAIdNfA= Date: Wed, 7 Aug 2013 19:47:01 +0000 Message-ID: <3f100726ce5a4fb58a4f0b68096c0a0f@BLUPR05MB053.namprd05.prod.outlook.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128A62B4@AZ-FFEXMB04.global.avaya.com> <520295E7.1010208@cisco.com> In-Reply-To: <520295E7.1010208@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0931CB1479 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM - Consensus on the format of the use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 19:47:47 -0000 With the modifications that Joe articulated, I support this agreement on SACM use case format. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Joe Marcus Clarke > Sent: Wednesday, August 07, 2013 2:46 PM > To: Romascanu, Dan (Dan) > Cc: sacm@ietf.org > Subject: Re: [sacm] SACM - Consensus on the format of the use cases >=20 > On 8/7/13 9:58 AM, Romascanu, Dan (Dan) wrote: > > At the SACM WG meeting at IETF-87 the participants in the room did > not raise objections to the proposal made by David Harrington about the > format of the use cases: > > > > - do not make it too formal in structure > > - use narrative English but describe the actors and actions. > > - include some descriptive text after to further clarify wherever > necessary > > > > We are asking the WG to confirm this consensus on the mail list. > Please send all comments, questions and concerns to the SACM WG mail > list before 8/15. >=20 > This list captures my understanding of what was discussed, though I > recall some talk about deep-dive details like SNMP collection was too > specific and jumped to solutions. I thought it was discussed that part > would get generalized as part of the next edit. >=20 > Joe >=20 >=20 > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > ----------------------------------------------------------------------- > ----- > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From gunnar.engelbach@threatguard.com Wed Aug 7 13:46:24 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B9121F9DC7 for ; Wed, 7 Aug 2013 13:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njU2RKXBylGg for ; Wed, 7 Aug 2013 13:46:10 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 01C3111E80EC for ; Wed, 7 Aug 2013 13:46:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=c+i3YxxxY/UYjx1nNsLrgU2OQT+Wyaz2+F7yxrdxfE6njqdmZNOW/zLF3+zsxSkBk+5x/bw74Q46hPLbGflIJLFl0/NcogfAR8xvF1rbXw4YADpgPzsEk4DWJ9Udq0Tj; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 20487 invoked from network); 7 Aug 2013 13:44:55 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 7 Aug 2013 13:44:55 -0700 Message-ID: <5202B207.3040000@ThreatGuard.com> Date: Wed, 07 Aug 2013 16:45:59 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Waltermire, David A." References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <6C1C15D8B5510B4B8FF132B10D38651304D313DD@IMCMBX03.MITRE.ORG> <05BCCEB107AF88469B9F99783D47C1D673D033@CISEXCHANGE1.msisac.org.local> <9904FB1B0159DA42B0B887B7FA8119CA128A5DB7@AZ-FFEXMB04.global.avaya.com> <275bdaf693a04bc1b81493d998047e7d@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <275bdaf693a04bc1b81493d998047e7d@BLUPR09MB038.namprd09.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Romascanu, Dan \(Dan\)" , Adam Montville , "sacm@ietf.org" , "Baker, Jon" Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:46:24 -0000 I'm not all that familiar with NETCONF yet so I'm looking forward to learning more. However, even if it's a great fit for SACM purposes, I would say that we should not adopt NETCONF or any other such collection standard (WBEM/WMI, SNMP, etc) as our single collection standard, even if for a subset of endpoint types. If instead we focus on a way to communicate what items are to be collected from endpoints and return the collected items we shouldn't care about how the collection is performed. That leaves things open enough to cover the widest possible range of endpoints including EOL legacy devices. I'll also point out that as we've seen in using OVAL for collection it's not enough to simply send a list of items to collect -- there often needs to be logic chains where the value of one or more collected items determines what is to be collected for other items. That's why SCAP uses OVAL for collection, so whatever SACM settles on needs to have at least that level of functionality. --gun On 8/7/2013 7:51 AM, Waltermire, David A. wrote: > I have been subscribed to the list and have been following NETMOD for almost a couple of years. While the current modeling work is focused on network devices, there is little that prevents this approach from being used by other endpoint device types. NETCONF/NETMOD addresses 3 types of configurations, the current running configuration, the persisted boot configuration, and an intermediate configuration that is used to build new configurations that have not been applied. At the last NETMOD WG meeting there was quite a bit of discussion around decoupling NETMOD from NETCONF to make it more generally useful to other efforts in the IETF. Both Adam and I were at the last NETMOD meeting and advertised the SACM WG meeting to get some attendance from the NETMOD community. > > While no decision was made to decouple NETCONF and NETMOD yet, IMHO making use of NETMOD is something that we should consider as part of SACM. At minimum we could use it to retrieve configuration data from network devices and it could be extended to do more. Depending on the level of coupling, there may be some flexibility in transport (e.g., NETCONF, NEA). Considering how it could fit into the architectural discussion, it might be used by a type of NETCONF sensor/collector to remotely poll the device and to monitor notifications. Another way of looking at it architecturally would be to use NETCONF/NETMOD as a mechanism to communicate with the device, with the NETMOD functionality serving as the sensor. > > Thoughts? > > Dave > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Romascanu, Dan (Dan) >> Sent: Wednesday, August 07, 2013 6:52 AM >> To: Adam Montville; Baker, Jon; sacm@ietf.org >> Subject: Re: [sacm] [Netconf] [netmod] development plan >> >> David Harrington is one of the active participants in Netconf. Bert Wijnen, >> one of the Netconf co-chairs, Andy Bierman one of the principal contributors >> attended the meeting in Berlin, but I do not see them subscribed to the mail >> list. There may be other, and we can bring them in the discussion or ask >> questions. >> >> Netconf is mostly about configuring network devices, so the datastores >> Netconf relates to are typically local to the devices (routers, servers). >> >> Regards, >> >> Dan >> >> >> >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>> Of Adam Montville >>> Sent: Tuesday, August 06, 2013 8:53 PM >>> To: Baker, Jon; sacm@ietf.org >>> Subject: Re: [sacm] [Netconf] [netmod] development plan >>> >>> Thanks for pointing this out, Jon. >>> >>> Is anyone on this list also working in netconf? On the surface, they >>> look very similar. It would be interesting to understand where, from >>> an architectural perspective, the datastore is said to reside for >>> netconf and how it should be accessed. I also find the phrase about >>> not storing executive commands interesting, because, presumably, some >>> of the information we want to store will be instructional in nature. >>> >>> >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >> Behalf >>>> Of Baker, Jon >>>> Sent: Tuesday, August 06, 2013 10:34 AM >>>> To: sacm@ietf.org >>>> Subject: [sacm] FW: [Netconf] [netmod] development plan >>>> >>>> How closely are SACM WG participants also following the ongoing >>>> netconf discussion? >>>> >>>> This message seems to directly align with some of the work I have >>>> expected SACM to do. Take a look at this quote in particular: >>>> >>>>> A configuration datastore is defined as the complete set of >>>>> configuration data that >>>>> is required to get a device from its initial default state into a >>>>> desired operational state. The configuration datastore does not >>>>> include state data or executive commands. >>>>> >>>>> The running configuration datastore holds the complete >>> configuration >>>>> currently active on the network device. Only one configuration >>>>> datastore of this type exists on the device, and it is always >>>>> present. >>>> >>>> Given that the netconf wg seems to be in the middle of a very active >>>> discussion on very closely related topics I would suggest that we >>>> specifically reach out to the netconf group to ensure alignment and >>>> reuse where possible. >>>> >>>> Jon >>>> >>>> ============================================ >>>> Jonathan O. Baker >>>> G022 - IA Industry Collaboration >>>> The MITRE Corporation >>>> Email: bakerj@mitre.org >>>> >>>> >>>>> -----Original Message----- >>>>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] >> On >>>>> Behalf Of Balazs Lengyel >>>>> Sent: Tuesday, August 06, 2013 5:47 AM >>>>> To: Ladislav Lhotka >>>>> Cc: netmod@ietf.org; Netconf >>>>> Subject: Re: [Netconf] [netmod] development plan >>>>> >>>>> >>>>> On 2013-08-05 19:45, Ladislav Lhotka wrote: >>>>>> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel >>>>>> >>>>> wrote: >>>>>> >>>>>>> On 2013-08-05 16:03, Ladislav Lhotka wrote: >>>>>>>> It is a fact of life that YANG is being used outside NETCONF, >>>>>>>> and there are >>>>> more plans for doing do, but with 6020 it is a slippery slope. For >>>>> example, such non-NETCONF applications of YANG will most likely >>>>> want to >>>> use "must" >>>>> for expressing semantic constraints. However, the accessible tree >>>>> for "must" is defined like so: >>>>>>>> >>>>>>>> o If the context node represents configuration, the tree >>>>>>>> is >>> the data >>>>>>>> in the NETCONF datastore where the context node exists. >>>>>>>> The >>>> XPath >>>>>>>> root node has all top-level configuration data nodes in >>> all >>>>>>>> modules as children. >>>>>>>> >>>>>>>> o If the context node represents state data, the tree is >>>>>>>> all >>> state >>>>>>>> data on the device, and the datastore. The >>> XPath root >>>>>>>> node has all top-level data nodes in all modules as >>> children. >>>>>>>> >>>>>>>> This cannot be unambiguously interpreted in a non-NETCONF >>>>>>>> context, so >>>>> it is effectively undefined, which is rather dangerous. >>>>>>>> So I don't mean to completely redesign YANG, but we cannot, on >>>>>>>> the >>>>> other hand, enable non-NETCONF YANG data modelling without >>>>> providing new definitions. >>>>>>>> >>>>>>>> Lada >>>>>>> In my view Netconf contains the "pure" protocol (encoding, >>>>>>> operations, >>>>> transactional behavior...) and background plumbing (datastores, >>>>> separation of state and config data, hierarchical data >>>>> organisation, filtering, connection requirements, session concept, >>>>> capability negotiation, many of the capabilites, error messages). >>>>>>> The background plumbing is valid for all access methods (CLI, >>>>>>> Netconf, >>>>> YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be >>> redefined. >>>>>> I don't think this is true. I2RS will probably have no >>>>>> distinction between >>>>> config and state data, though they may have read-write and read-only. >>>>> Sessions and capability negotiation are by no means necessary >>>>> (RESTCONF doesn't have it). I can actually imagine data modelling >>>>> without any specific protocol for data exchange. >>>>>> >>>>>> Lada >>>>> IMHO we can debate whether some protocols need some of the >>>>> features, >>>> or >>>>> whether some of the features belong to the plumbing or the pure >>>>> protocol, but I still believe that many of the concepts like >>>>> "NETCONF datastore" above are actually easily understandable >>>>> without considering the protocol on the wire. If you would just >>>>> remove the word Netconf from your example paragraphs IMHO they >> are >>>>> quite understandable in a protocol independent way. >>>>> >>>>> Let me just try as an exercise: >>>>> Running Datastore: >>>>> >>>>> A configuration datastore is defined as the complete set of >>>>> configuration data that >>>>> is required to get a device from its initial default state into a >>>>> desired operational state. The configuration datastore does not >>>>> include state data or executive commands. >>>>> >>>>> The running configuration datastore holds the complete >>> configuration >>>>> currently active on the network device. Only one configuration >>>>> datastore of this type exists on the device, and it is always >>>>> present. >>>>> >>>>> The above defeinition is extracted from RFC6241 (I just removed 2 >>>>> sentences). I think it is a very nice protocol independent >>> definition. >>>>> >>>>> >>>>> Does anyone have a list of features that make YANG protocol >>>>> (Netconf) dependent? >>>>> >>>>> Balazs >>>>> >>>>> _______________________________________________ >>>>> Netconf mailing list >>>>> Netconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netconf >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>> >>>> ... >>> >>> . . . >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From ietfdbh@comcast.net Thu Aug 8 14:00:10 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D784411E821E for ; Thu, 8 Aug 2013 14:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUT3o3MwmleP for ; Thu, 8 Aug 2013 14:00:05 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id C199711E8231 for ; Thu, 8 Aug 2013 14:00:04 -0700 (PDT) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta13.emeryville.ca.mail.comcast.net with comcast id ADaT1m0031vN32cADM04Zc; Thu, 08 Aug 2013 21:00:04 +0000 Received: from [192.168.1.181] ([176.96.153.9]) by omta22.emeryville.ca.mail.comcast.net with comcast id ALza1m00e0CRbBk8iLzfYR; Thu, 08 Aug 2013 21:00:02 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 08 Aug 2013 22:59:33 +0200 From: David Harrington To: Gunnar Engelbach , "Waltermire, David A." Message-ID: Thread-Topic: [sacm] [Netconf] [netmod] development plan In-Reply-To: <5202B207.3040000@ThreatGuard.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375995604; bh=F/Zlb51+xY7wIWUc4eNfu74HjsswLWGwD3KRe36K8gA=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=VwzdX1zzGZmINg2GQG+Y3AGYWZJzWuPb1Zockq1nqfY6KcdqqJldUMFdgfZsaPhIT Iez2gueeutcfW1osuLg4zkIn8IhiWpaHNrUHyrqMFug80fnmKP7rlaNYQUD/uHO4pW A0JGvAKWA1eQViRIJb4j+P1CVajGaPa8ZDdOelYcIAT3nMQenss3QyrOEgXD2K/DMf Mn1oAEFIY3bMuOLFcDVFWuQouh66fJu5Oe9ckqoZqYlMbAFb7RFBcSXBsYr7sxneIP KCSwzZ5jnEy8MlAg7R/klkBRihsgxxFERUS0U/9/UodgrQDt3jDHPY8Mf48U/YnGGz IDUn80oX8wmBw== Cc: "Romascanu, Dan \(Dan\)" , Adam Montville , "sacm@ietf.org" , "Baker, Jon" Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:00:11 -0000 On 8/7/13 10:45 PM, "Gunnar Engelbach" wrote: > >I'm not all that familiar with NETCONF yet so I'm looking forward to >learning more. > >However, even if it's a great fit for SACM purposes, I would say that we >should not adopt NETCONF or any other such collection standard >(WBEM/WMI, SNMP, etc) as our single collection standard, even if for a >subset of endpoint types. > >If instead we focus on a way to communicate what items are to be >collected from endpoints and return the collected items we shouldn't >care about how the collection is performed. That leaves things open >enough to cover the widest possible range of endpoints including EOL >legacy devices. IETF works on standards. If every device gets to use a different protocol for query operations, how does that support interoperability? Does an application doing evaluation need to be written to understand different protocols for every device/model/OS in the network? I agree that we shouldn't choose just one protocol, but I think we should use standardized protocols and data models to promote vendor-neutral interoperability. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 > From Adam.Montville@cisecurity.org Thu Aug 8 14:07:39 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B13711E822C for ; Thu, 8 Aug 2013 14:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xh7aiVrV6L1 for ; Thu, 8 Aug 2013 14:07:23 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.110]) by ietfa.amsl.com (Postfix) with ESMTP id 2B51D11E8220 for ; Thu, 8 Aug 2013 14:07:21 -0700 (PDT) Received: from [216.82.253.227:44663] by server-14.bemta-7.messagelabs.com id D0/A5-13364-78804025; Thu, 08 Aug 2013 21:07:19 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-8.tower-170.messagelabs.com!1375996015!3932490!10 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 23934 invoked from network); 8 Aug 2013 21:07:19 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-8.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 8 Aug 2013 21:07:19 -0000 Received: from CISEXCHANGE1.msisac.org.local ([::1]) by CISEXCHANGE2.msisac.org.local ([fe80::b899:f128:212e:984c%14]) with mapi id 14.02.0247.003; Thu, 8 Aug 2013 16:54:12 -0400 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Meeting Minutes from IETF 87 Posted Thread-Index: Ac6UeWywJRpL39dYT526AiE9QSeOsQ== Date: Thu, 8 Aug 2013 20:54:10 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D675B6B0@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] Meeting Minutes from IETF 87 Posted X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:07:39 -0000 http://www.ietf.org/proceedings/87/minutes/minutes-87-sacm Regards, Adam . . . From Adam.Montville@cisecurity.org Thu Aug 8 14:52:59 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEB211E8248 for ; Thu, 8 Aug 2013 14:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avYOhjPruxyS for ; Thu, 8 Aug 2013 14:52:45 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.9]) by ietfa.amsl.com (Postfix) with ESMTP id 039C411E8159 for ; Thu, 8 Aug 2013 14:52:21 -0700 (PDT) Received: from [216.82.250.19:4852] by server-9.bemta-12.messagelabs.com id F5/C1-01285-41314025; Thu, 08 Aug 2013 21:52:20 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-9.tower-87.messagelabs.com!1375998739!16333198!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 20882 invoked from network); 8 Aug 2013 21:52:20 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-9.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 8 Aug 2013 21:52:20 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE1.msisac.org.local ([::1]) with mapi id 14.02.0342.003; Thu, 8 Aug 2013 17:52:18 -0400 From: Adam Montville To: David Harrington , Gunnar Engelbach , "Waltermire, David A." Thread-Topic: [sacm] [Netconf] [netmod] development plan Thread-Index: AQHOkdp3Zrixa9H9GUOrS6K9JR4LhJmG33MAgAAJJICAAB2bgIAAIGsAgAEMkACAAD4fcIAABdmQgAFgjICAABB6gIAAlWyAgAGWH4D//8oZgA== Date: Thu, 8 Aug 2013 21:52:18 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D675B738@CISEXCHANGE1.msisac.org.local> References: <5202B207.3040000@ThreatGuard.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Romascanu, Dan \(Dan\)" , "sacm@ietf.org" , "Baker, Jon" Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:52:59 -0000 At this point, I wouldn't disagree with either perspective. To be pedanti= c about it, the use cases should probably be at a level where we are not p= rescribing or presuming any particular protocol or data format. =20 Requirements will then be able to describe use case needs in more detail, = but still without prescribing or presuming particular protocols/formats - = requirements are more likely to describe the characteristics such protocol= s/formats would need to possess. Then, architectures would "take the plunge" into the details of which prot= ocols and/or data formats would be viable to meet the requirements, and th= erefore the use cases. We all have ideas about what an architecture might look like, and we are t= rying to do some things in parallel, but I think it's important to keep th= e delineation between use cases, requirements, and architecture as clean a= s we can. Adam > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, August 08, 2013 2:00 PM > To: Gunnar Engelbach; Waltermire, David A. > Cc: Romascanu, Dan (Dan); Adam Montville; sacm@ietf.org; Baker, Jon > Subject: Re: [sacm] [Netconf] [netmod] development plan >=20 >=20 >=20 >=20 >=20 > On 8/7/13 10:45 PM, "Gunnar Engelbach" > > wrote: >=20 > > > >I'm not all that familiar with NETCONF yet so I'm looking forward to > >learning more. > > > >However, even if it's a great fit for SACM purposes, I would say that > >we should not adopt NETCONF or any other such collection standard > >(WBEM/WMI, SNMP, etc) as our single collection standard, even if for a > >subset of endpoint types. > > > >If instead we focus on a way to communicate what items are to be > >collected from endpoints and return the collected items we shouldn't > >care about how the collection is performed. That leaves things open > >enough to cover the widest possible range of endpoints including EOL > >legacy devices. >=20 >=20 > IETF works on standards. > If every device gets to use a different protocol for query operations, h= ow > does that support interoperability? > Does an application doing evaluation need to be written to understand > different protocols for every device/model/OS in the network? >=20 > I agree that we shouldn't choose just one protocol, but I think we shoul= d use > standardized protocols and data models to promote vendor-neutral > interoperability. > -- > David Harrington > Ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 > > >=20 >=20 >=20 > ... . . . From david.waltermire@nist.gov Thu Aug 8 15:23:40 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0314F11E8242 for ; Thu, 8 Aug 2013 15:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtpLuG42MM98 for ; Thu, 8 Aug 2013 15:23:33 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 0797611E8241 for ; Thu, 8 Aug 2013 15:23:29 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 8 Aug 2013 18:22:54 -0400 Received: from wsget1.nist.gov (129.6.13.150) by wsghub1.xchange.nist.gov (129.6.16.196) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 8 Aug 2013 18:23:13 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 8 Aug 2013 18:23:05 -0400 Received: from na01-by2-obe.outbound.protection.outlook.com (207.46.163.239) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 8 Aug 2013 18:23:13 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) with Microsoft SMTP Server (TLS) id 15.0.731.16; Thu, 8 Aug 2013 22:23:10 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.53]) with mapi id 15.00.0731.000; Thu, 8 Aug 2013 22:23:10 +0000 From: "Waltermire, David A." To: Adam Montville , David Harrington , Gunnar Engelbach Thread-Topic: [sacm] [Netconf] [netmod] development plan Thread-Index: AQHOkdp3Zrixa9H9GUOrS6K9JR4LhJmG33MAgAAJJICAAB2bgIAAIGsAgAEMkACAAD4fcIAABdmQgAEdfoCAAAbioIAAnwSAgAGWH4CAAA69AIAABfWw Date: Thu, 8 Aug 2013 22:23:10 +0000 Message-ID: References: <5202B207.3040000@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D675B738@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D675B738@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(13464003)(51704005)(377454003)(199002)(479174003)(189002)(74502001)(74366001)(54316002)(31966008)(59766001)(80022001)(81686001)(76482001)(74316001)(47736001)(66066001)(76576001)(74876001)(33646001)(77096001)(77982001)(81542001)(81342001)(80976001)(46102001)(19580405001)(54356001)(47446002)(69226001)(49866001)(74706001)(65816001)(53806001)(47976001)(4396001)(50986001)(76786001)(76796001)(83072001)(83322001)(51856001)(63696002)(79102001)(56776001)(16406001)(56816003)(19580395003)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB038; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Cc: "Romascanu, Dan \(Dan\)" , "sacm@ietf.org" , "Baker, Jon" Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 22:23:40 -0000 +1. This is consistent with my understanding of where we are in the process= today. I also don't disagree with either perspective. A solid architectural approa= ch will allow for some flexibility in standards used to collect data from e= ndpoints. We may find that multiple are needed to get adequate coverage. We= may decide that one approach should be mandatory-to-implement to encourage= interoperability. However, it's too early to make a decision on any of thi= s. However, it does feel like there are some requirements buried in this discu= ssion. ;-) Perhaps we can focus on that view of the problem? Dave > -----Original Message----- > From: Adam Montville [mailto:Adam.Montville@cisecurity.org] > Sent: Thursday, August 08, 2013 5:52 PM > To: David Harrington; Gunnar Engelbach; Waltermire, David A. > Cc: Romascanu, Dan (Dan); sacm@ietf.org; Baker, Jon > Subject: RE: [sacm] [Netconf] [netmod] development plan >=20 > At this point, I wouldn't disagree with either perspective. To be pedant= ic > about it, the use cases should probably be at a level where we are not > prescribing or presuming any particular protocol or data format. >=20 > Requirements will then be able to describe use case needs in more detail, > but still without prescribing or presuming particular protocols/formats - > requirements are more likely to describe the characteristics such > protocols/formats would need to possess. >=20 > Then, architectures would "take the plunge" into the details of which > protocols and/or data formats would be viable to meet the requirements, > and therefore the use cases. >=20 > We all have ideas about what an architecture might look like, and we are > trying to do some things in parallel, but I think it's important to keep = the > delineation between use cases, requirements, and architecture as clean as > we can. >=20 > Adam >=20 > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Thursday, August 08, 2013 2:00 PM > > To: Gunnar Engelbach; Waltermire, David A. > > Cc: Romascanu, Dan (Dan); Adam Montville; sacm@ietf.org; Baker, Jon > > Subject: Re: [sacm] [Netconf] [netmod] development plan > > > > > > > > > > > > On 8/7/13 10:45 PM, "Gunnar Engelbach" > > > > wrote: > > > > > > > >I'm not all that familiar with NETCONF yet so I'm looking forward to > > >learning more. > > > > > >However, even if it's a great fit for SACM purposes, I would say that > > >we should not adopt NETCONF or any other such collection standard > > >(WBEM/WMI, SNMP, etc) as our single collection standard, even if for > > >a subset of endpoint types. > > > > > >If instead we focus on a way to communicate what items are to be > > >collected from endpoints and return the collected items we shouldn't > > >care about how the collection is performed. That leaves things open > > >enough to cover the widest possible range of endpoints including EOL > > >legacy devices. > > > > > > IETF works on standards. > > If every device gets to use a different protocol for query operations, > > how does that support interoperability? > > Does an application doing evaluation need to be written to understand > > different protocols for every device/model/OS in the network? > > > > I agree that we shouldn't choose just one protocol, but I think we > > should use standardized protocols and data models to promote > > vendor-neutral interoperability. > > -- > > David Harrington > > Ietfdbh@comcast.net > > +1-603-828-1401 > > > > > > > > > > > > > > > ... > This message and attachments may contain confidential information. If it > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments is > strictly prohibited. Please notify the sender immediately and permanently > delete the message and any attachments. >=20 > . . . From gunnar.engelbach@threatguard.com Thu Aug 8 15:44:35 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC95311E8248 for ; Thu, 8 Aug 2013 15:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYq-l7GYyltU for ; Thu, 8 Aug 2013 15:44:30 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id AACB011E8236 for ; Thu, 8 Aug 2013 15:44:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=el0g0MtNhvnmMRSGTJsk6CL4XisluSMY80oVQqhAT6jzU3fCJUko4rC+vxeKANGVSMhEBUfpoJ8xJY5vY2uSOR9qJkRaTl7Gn6JAInLqRQC3/W/WLoqVpNJDoTvcPQSf; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 28406 invoked from network); 8 Aug 2013 15:43:28 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 Aug 2013 15:43:27 -0700 Message-ID: <52041F4E.3020707@ThreatGuard.com> Date: Thu, 08 Aug 2013 18:44:30 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Montville References: <5202B207.3040000@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D675B738@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D675B738@CISEXCHANGE1.msisac.org.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Romascanu, Dan \(Dan\)" , David Harrington , "Waltermire, David A." , "Baker, Jon" , "sacm@ietf.org" Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 22:44:35 -0000 This approach makes sense, Adam, and this conversation is a bit further down in the process, but nonetheless I'd like to respond to David and see how that jives with the group. Reasons to not require the use of a specific collection methodology: 1) It's a recognition of a practical necessity: NETCONF is not going to be universally usable. Nor is SNMP, WBEM, or any other technology. In a heterogeneous environment it will be necessary to use a combination of these to do the actual collection in order to achieve full coverage, especially considering the number of legacy and embedded devices for which adding software is impractical. 2) It muddies things a bit that NETCONF, WBEM, SNMP, etc, are also network protocols, but the actual artifact collection will frequently *not* be done over the network. It will be done with database queries, using local APIs, parsing backed up configuration files, terminal command over an RS-232 cable, etc. The initiator for collection of an endpoint may be a network message, but fulfillment can be anything, including another network protocol. 3) As I mentioned it's not enough to simply give a list of artifacts that need to be collected. It will also be necessary to do multi-step collections where initial collected values are applied via logic rules to complete the collection process. Is the NETCONF group, or any other, going to be willing to perturb their work to this degree? 4) For the collection process we are interested in the ability to dispatch a document that details all artifacts necessary to complete an automated security task, and the response to that request*. Those two documents are the standards that I am interested in: how that collection actually happens I don't care about. So if the receiving end translates that into NETCONF to fulfill part/all of it, or makes WMI queries, I don't care, just as I don't care if that receiver is a local agent, a database, a proxy for multiple devices, or a relay, except that I would also like to receive some information about the collection process that can be used to determine timeliness, and accuracy of the response. * Yeah, this statement is a bit presumptive. Anybody see things differently? On 8/8/2013 5:52 PM, Adam Montville wrote: > At this point, I wouldn't disagree with either perspective. To be pedantic about it, the use cases should probably be at a level where we are not prescribing or presuming any particular protocol or data format. > > Requirements will then be able to describe use case needs in more detail, but still without prescribing or presuming particular protocols/formats - requirements are more likely to describe the characteristics such protocols/formats would need to possess. > > Then, architectures would "take the plunge" into the details of which protocols and/or data formats would be viable to meet the requirements, and therefore the use cases. > > We all have ideas about what an architecture might look like, and we are trying to do some things in parallel, but I think it's important to keep the delineation between use cases, requirements, and architecture as clean as we can. > > Adam > >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net] >> Sent: Thursday, August 08, 2013 2:00 PM >> To: Gunnar Engelbach; Waltermire, David A. >> Cc: Romascanu, Dan (Dan); Adam Montville; sacm@ietf.org; Baker, Jon >> Subject: Re: [sacm] [Netconf] [netmod] development plan >> >> >> >> >> >> On 8/7/13 10:45 PM, "Gunnar Engelbach" >> >> wrote: >> >>> >>> I'm not all that familiar with NETCONF yet so I'm looking forward to >>> learning more. >>> >>> However, even if it's a great fit for SACM purposes, I would say that >>> we should not adopt NETCONF or any other such collection standard >>> (WBEM/WMI, SNMP, etc) as our single collection standard, even if for a >>> subset of endpoint types. >>> >>> If instead we focus on a way to communicate what items are to be >>> collected from endpoints and return the collected items we shouldn't >>> care about how the collection is performed. That leaves things open >>> enough to cover the widest possible range of endpoints including EOL >>> legacy devices. >> >> >> IETF works on standards. >> If every device gets to use a different protocol for query operations, how >> does that support interoperability? >> Does an application doing evaluation need to be written to understand >> different protocols for every device/model/OS in the network? >> >> I agree that we shouldn't choose just one protocol, but I think we should use >> standardized protocols and data models to promote vendor-neutral >> interoperability. >> -- >> David Harrington >> Ietfdbh@comcast.net >> +1-603-828-1401 >> >> >>> >> >> >> >> ... > This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. > > . . . > From gunnar.engelbach@threatguard.com Thu Aug 8 15:54:43 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD4321F9BBD for ; Thu, 8 Aug 2013 15:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSHMjKH8Xwbz for ; Thu, 8 Aug 2013 15:54:21 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8A51F11E8161 for ; Thu, 8 Aug 2013 15:54:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=mqElnB90usZ9LWASozW12wpu18yhOlC/cpyPqBDjYagUaXYdG2rk4TYhCRVuaIILT5tDMIqSq5020320c8Yo9zkXjgq3yP+K23v8AoxnFJ021FVxeeNHWbXf0RB55sO9; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 28727 invoked from network); 8 Aug 2013 15:53:01 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 Aug 2013 15:53:01 -0700 Message-ID: <5204218B.4060504@ThreatGuard.com> Date: Thu, 08 Aug 2013 18:54:03 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Waltermire, David A." References: <5202B207.3040000@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D675B738@CISEXCHANGE1.msisac.org.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Harrington , Adam Montville , "sacm@ietf.org" , "Baker, Jon" , "Romascanu, Dan \(Dan\)" Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 22:54:44 -0000 On 8/8/2013 6:23 PM, Waltermire, David A. wrote: > +1. This is consistent with my understanding of where we are in the process today. > > I also don't disagree with either perspective. A solid architectural approach will allow for some flexibility in standards used to collect data from endpoints. We may find that multiple are needed to get adequate coverage. We may decide that one approach should be mandatory-to-implement to encourage interoperability. However, it's too early to make a decision on any of this. I think that interoperability will be achieved by implementing data interchanges at the level above physical collection -- allowing implementers to create SACM-compliant front-ends to existing collection methods. But I'm not sure I made that very clear in my previous response. > > However, it does feel like there are some requirements buried in this discussion. ;-) Perhaps we can focus on that view of the problem? Any requirements pop out at you? > > Dave > >> -----Original Message----- >> From: Adam Montville [mailto:Adam.Montville@cisecurity.org] >> Sent: Thursday, August 08, 2013 5:52 PM >> To: David Harrington; Gunnar Engelbach; Waltermire, David A. >> Cc: Romascanu, Dan (Dan); sacm@ietf.org; Baker, Jon >> Subject: RE: [sacm] [Netconf] [netmod] development plan >> >> At this point, I wouldn't disagree with either perspective. To be pedantic >> about it, the use cases should probably be at a level where we are not >> prescribing or presuming any particular protocol or data format. >> >> Requirements will then be able to describe use case needs in more detail, >> but still without prescribing or presuming particular protocols/formats - >> requirements are more likely to describe the characteristics such >> protocols/formats would need to possess. >> >> Then, architectures would "take the plunge" into the details of which >> protocols and/or data formats would be viable to meet the requirements, >> and therefore the use cases. >> >> We all have ideas about what an architecture might look like, and we are >> trying to do some things in parallel, but I think it's important to keep the >> delineation between use cases, requirements, and architecture as clean as >> we can. >> >> Adam >> >>> -----Original Message----- >>> From: David Harrington [mailto:ietfdbh@comcast.net] >>> Sent: Thursday, August 08, 2013 2:00 PM >>> To: Gunnar Engelbach; Waltermire, David A. >>> Cc: Romascanu, Dan (Dan); Adam Montville; sacm@ietf.org; Baker, Jon >>> Subject: Re: [sacm] [Netconf] [netmod] development plan >>> >>> >>> >>> >>> >>> On 8/7/13 10:45 PM, "Gunnar Engelbach" >>> >>> wrote: >>> >>>> >>>> I'm not all that familiar with NETCONF yet so I'm looking forward to >>>> learning more. >>>> >>>> However, even if it's a great fit for SACM purposes, I would say that >>>> we should not adopt NETCONF or any other such collection standard >>>> (WBEM/WMI, SNMP, etc) as our single collection standard, even if for >>>> a subset of endpoint types. >>>> >>>> If instead we focus on a way to communicate what items are to be >>>> collected from endpoints and return the collected items we shouldn't >>>> care about how the collection is performed. That leaves things open >>>> enough to cover the widest possible range of endpoints including EOL >>>> legacy devices. >>> >>> >>> IETF works on standards. >>> If every device gets to use a different protocol for query operations, >>> how does that support interoperability? >>> Does an application doing evaluation need to be written to understand >>> different protocols for every device/model/OS in the network? >>> >>> I agree that we shouldn't choose just one protocol, but I think we >>> should use standardized protocols and data models to promote >>> vendor-neutral interoperability. >>> -- >>> David Harrington >>> Ietfdbh@comcast.net >>> +1-603-828-1401 >>> >>> >>>> >>> >>> >>> >>> ... >> This message and attachments may contain confidential information. If it >> appears that this message was sent to you by mistake, any retention, >> dissemination, distribution or copying of this message and attachments is >> strictly prohibited. Please notify the sender immediately and permanently >> delete the message and any attachments. >> >> . . . From shanna@juniper.net Thu Aug 8 16:52:56 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6000A11E8164 for ; Thu, 8 Aug 2013 16:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.722 X-Spam-Level: X-Spam-Status: No, score=-102.722 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXopN2Wws2DK for ; Thu, 8 Aug 2013 16:52:51 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id EE0BF21F9A4A for ; Thu, 8 Aug 2013 16:52:50 -0700 (PDT) Received: from mail165-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.22; Thu, 8 Aug 2013 23:52:49 +0000 Received: from mail165-va3 (localhost [127.0.0.1]) by mail165-va3-R.bigfish.com (Postfix) with ESMTP id 1A5062E02FF; Thu, 8 Aug 2013 23:52:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI9371I542I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail165-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(24454002)(199002)(164054003)(479174003)(13464003)(51704005)(377454003)(51856001)(53806001)(54356001)(56776001)(56816003)(77096001)(74502001)(47446002)(74662001)(16406001)(63696002)(65816001)(59766001)(81686001)(80022001)(77982001)(31966008)(76786001)(54316002)(76482001)(76796001)(76576001)(19580395003)(33646001)(81342001)(79102001)(74706001)(74316001)(69226001)(46102001)(19580405001)(19580385001)(83322001)(80976001)(66066001)(47736001)(47976001)(50986001)(74876001)(81542001)(74366001)(4396001)(83072001)(49866001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB056; H:BLUPR05MB053.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail165-va3 (localhost.localdomain [127.0.0.1]) by mail165-va3 (MessageSwitch) id 1376005897925499_28931; Thu, 8 Aug 2013 23:51:37 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.237]) by mail165-va3.bigfish.com (Postfix) with ESMTP id 36DF43400A5; Thu, 8 Aug 2013 23:51:35 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 8 Aug 2013 23:51:34 +0000 Received: from BLUPR05MB056.namprd05.prod.outlook.com (10.255.210.151) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Thu, 8 Aug 2013 23:51:34 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) by BLUPR05MB056.namprd05.prod.outlook.com (10.255.210.151) with Microsoft SMTP Server (TLS) id 15.0.731.16; Thu, 8 Aug 2013 23:51:33 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.169]) by BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.223]) with mapi id 15.00.0731.000; Thu, 8 Aug 2013 23:51:32 +0000 From: Stephen Hanna To: Gunnar Engelbach , Adam Montville Thread-Topic: [sacm] [Netconf] [netmod] development plan Thread-Index: AQHOlIjXZrixa9H9GUOrS6K9JR4LhJmL+bTg Date: Thu, 8 Aug 2013 23:51:32 +0000 Message-ID: <9e2f4cd6525847bc9526acd995c67d5d@BLUPR05MB053.namprd05.prod.outlook.com> References: <5202B207.3040000@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D675B738@CISEXCHANGE1.msisac.org.local> <52041F4E.3020707@ThreatGuard.com> In-Reply-To: <52041F4E.3020707@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 093290AD39 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "Romascanu, Dan \(Dan\)" , David Harrington , "Waltermire, David A." , "Baker, Jon" , "sacm@ietf.org" Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 23:52:56 -0000 Gunnar, While I realize that in today's world there are many protocols for obtaining information on endpoint posture and I agree that we'll need to support those, I also believe that we (the IETF) can and should nudge people toward one or a small number of protocols that endpoints should support. Legacy devices won't change and there will always be some recalcitrant devices that refuse to supply posture information and databases of historical data have utility and there's more to security than endpoint posture and... but I don't really see any reason why most if not all endpoints couldn't support one simple set of protocols and data formats for direct endpoint posture collection. Thanks, Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Gunnar Engelbach > Sent: Thursday, August 08, 2013 6:44 PM > To: Adam Montville > Cc: Romascanu, Dan (Dan); David Harrington; Waltermire, David A.; > Baker, Jon; sacm@ietf.org > Subject: Re: [sacm] [Netconf] [netmod] development plan >=20 > This approach makes sense, Adam, and this conversation is a bit further > down in the process, but nonetheless I'd like to respond to David and > see how that jives with the group. >=20 > Reasons to not require the use of a specific collection methodology: >=20 > 1) It's a recognition of a practical necessity: NETCONF is not going > to > be universally usable. Nor is SNMP, WBEM, or any other technology. In > a heterogeneous environment it will be necessary to use a combination > of > these to do the actual collection in order to achieve full coverage, > especially considering the number of legacy and embedded devices for > which adding software is impractical. >=20 > 2) It muddies things a bit that NETCONF, WBEM, SNMP, etc, are also > network protocols, but the actual artifact collection will frequently > *not* be done over the network. It will be done with database queries, > using local APIs, parsing backed up configuration files, terminal > command over an RS-232 cable, etc. The initiator for collection of an > endpoint may be a network message, but fulfillment can be anything, > including another network protocol. >=20 > 3) As I mentioned it's not enough to simply give a list of artifacts > that need to be collected. It will also be necessary to do multi-step > collections where initial collected values are applied via logic rules > to complete the collection process. Is the NETCONF group, or any > other, > going to be willing to perturb their work to this degree? >=20 > 4) For the collection process we are interested in the ability to > dispatch a document that details all artifacts necessary to complete an > automated security task, and the response to that request*. Those two > documents are the standards that I am interested in: how that > collection actually happens I don't care about. So if the receiving > end > translates that into NETCONF to fulfill part/all of it, or makes WMI > queries, I don't care, just as I don't care if that receiver is a local > agent, a database, a proxy for multiple devices, or a relay, except > that > I would also like to receive some information about the collection > process that can be used to determine timeliness, and accuracy of the > response. >=20 >=20 >=20 > * Yeah, this statement is a bit presumptive. Anybody see things > differently? >=20 >=20 >=20 > On 8/8/2013 5:52 PM, Adam Montville wrote: > > At this point, I wouldn't disagree with either perspective. To be > pedantic about it, the use cases should probably be at a level where we > are not prescribing or presuming any particular protocol or data > format. > > > > Requirements will then be able to describe use case needs in more > detail, but still without prescribing or presuming particular > protocols/formats - requirements are more likely to describe the > characteristics such protocols/formats would need to possess. > > > > Then, architectures would "take the plunge" into the details of which > protocols and/or data formats would be viable to meet the requirements, > and therefore the use cases. > > > > We all have ideas about what an architecture might look like, and we > are trying to do some things in parallel, but I think it's important to > keep the delineation between use cases, requirements, and architecture > as clean as we can. > > > > Adam > > > >> -----Original Message----- > >> From: David Harrington [mailto:ietfdbh@comcast.net] > >> Sent: Thursday, August 08, 2013 2:00 PM > >> To: Gunnar Engelbach; Waltermire, David A. > >> Cc: Romascanu, Dan (Dan); Adam Montville; sacm@ietf.org; Baker, Jon > >> Subject: Re: [sacm] [Netconf] [netmod] development plan > >> > >> > >> > >> > >> > >> On 8/7/13 10:45 PM, "Gunnar Engelbach" > >> > >> wrote: > >> > >>> > >>> I'm not all that familiar with NETCONF yet so I'm looking forward > to > >>> learning more. > >>> > >>> However, even if it's a great fit for SACM purposes, I would say > that > >>> we should not adopt NETCONF or any other such collection standard > >>> (WBEM/WMI, SNMP, etc) as our single collection standard, even if > for a > >>> subset of endpoint types. > >>> > >>> If instead we focus on a way to communicate what items are to be > >>> collected from endpoints and return the collected items we > shouldn't > >>> care about how the collection is performed. That leaves things > open > >>> enough to cover the widest possible range of endpoints including > EOL > >>> legacy devices. > >> > >> > >> IETF works on standards. > >> If every device gets to use a different protocol for query > operations, how > >> does that support interoperability? > >> Does an application doing evaluation need to be written to > understand > >> different protocols for every device/model/OS in the network? > >> > >> I agree that we shouldn't choose just one protocol, but I think we > should use > >> standardized protocols and data models to promote vendor-neutral > >> interoperability. > >> -- > >> David Harrington > >> Ietfdbh@comcast.net > >> +1-603-828-1401 > >> > >> > >>> > >> > >> > >> > >> ... > > This message and attachments may contain confidential information. If > it appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments > is strictly prohibited. Please notify the sender immediately and > permanently delete the message and any attachments. > > > > . . . > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From dromasca@avaya.com Thu Aug 8 22:03:16 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C306D21F9AA1 for ; Thu, 8 Aug 2013 22:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6+lQYqDkEyc for ; Thu, 8 Aug 2013 22:03:11 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id DB1C021F9CC7 for ; Thu, 8 Aug 2013 22:03:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugHAF53BFLGmAcV/2dsb2JhbABbgmUhNVCqQZQPgRkWdIIkAQEBAQMBAQEPKDQbAgEIDQQEAQELFBAnCx0IAQEEARIIARmHbgELnRabShePajiDGnQDniqLBoMYgio X-IronPort-AV: E=Sophos;i="4.89,844,1367985600"; d="scan'208";a="23523893" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Aug 2013 01:03:08 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Aug 2013 00:59:42 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Fri, 9 Aug 2013 07:03:06 +0200 From: "Romascanu, Dan (Dan)" To: Adam Montville , "sacm@ietf.org" Thread-Topic: Meeting Minutes from IETF 87 Posted Thread-Index: Ac6UeWywJRpL39dYT526AiE9QSeOsQARAc8Y Date: Fri, 9 Aug 2013 05:03:06 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128A77D9@AZ-FFEXMB04.global.avaya.com> References: <05BCCEB107AF88469B9F99783D47C1D675B6B0@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D675B6B0@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.152.73.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] Meeting Minutes from IETF 87 Posted X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 05:03:16 -0000 Thanks to Chris and Steve for their excellent notes taking. =0A= =0A= Comments and corrections, questions and discussions are welcome. =0A= =0A= Dan=0A= =0A= ________________________________________=0A= From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of Adam Montv= ille [Adam.Montville@cisecurity.org]=0A= Sent: Thursday, August 08, 2013 11:54 PM=0A= To: sacm@ietf.org=0A= Subject: [sacm] Meeting Minutes from IETF 87 Posted=0A= =0A= http://www.ietf.org/proceedings/87/minutes/minutes-87-sacm=0A= =0A= Regards,=0A= =0A= Adam=0A= =0A= . . .=0A= _______________________________________________=0A= sacm mailing list=0A= sacm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sacm=0A= From dbharrington@comcast.net Fri Aug 9 00:14:30 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0294E21F9E0B for ; Fri, 9 Aug 2013 00:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvYIdtwHdLLB for ; Fri, 9 Aug 2013 00:14:25 -0700 (PDT) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 6511121F9A10 for ; Fri, 9 Aug 2013 00:14:25 -0700 (PDT) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta02.emeryville.ca.mail.comcast.net with comcast id AXDq1m0020mlR8UA2XEQwK; Fri, 09 Aug 2013 07:14:24 +0000 Received: from [192.168.1.181] ([176.96.153.9]) by omta11.emeryville.ca.mail.comcast.net with comcast id AXDT1m0070CRbBk8XXDXzL; Fri, 09 Aug 2013 07:14:22 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Fri, 09 Aug 2013 09:13:26 +0200 From: David Harrington To: Gunnar Engelbach , Adam Montville Message-ID: Thread-Topic: subject lines In-Reply-To: <52041F4E.3020707@ThreatGuard.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376032464; bh=lxP6sj0FBTgHuKyUfgojzsKScQCn3tWyy0ts7KdSN8Q=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=YQS6Ux8iykRTwvyJxbGbOIg5nD8eakWWjZ97c8zSmD5pPkPVuVC+kQu3uvx+S+ap6 ONMM9dWd9iEuljTLMs+OFbLcOMxJJW+KeeZrWDa2lKwvB2+Pz74PuQ4gk45986ZJT3 ExRYyt3obHyZlXhAaocZ68MIkvZ8Vg2pKeIFFQx2i7hu3U7zxuZ+qrdEyNbWXkk/yr Mas7AoSb+zkDB4WSsB9VvryuZXIlt1lHi17hIq+egSPEMjCDw3vdb/JGQA6uSr/1X0 f4MDirjVt4+iOgGf44OeGX7MSOA+jRVBV4ANpzoAjPetHEv1Np3hIDtzPl+6HIO92H MouPbkCx/eLmQ== Cc: "Romascanu, Dan \(Dan\)" , David Harrington , "Waltermire, David A." , "Baker, Jon" , "sacm@ietf.org" Subject: [sacm] subject lines X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 07:14:30 -0000 First if our discussion is about using multiple protocols, let's change the subject line from "[sacm] [Netconf] [netmod] development plan" to demonstrate that we are not trying to tie sacm/netconf/netmod togther. I considered changing this to use text from Gunnar's message, such as "collection methodologies". But that subject line doesn't reflect for which document we are having this discussion. Gunnar, do you consider this a use cases discussion? A requirements discussion? An architecture discussion? Maybe we should use "use cases" or "requirements" or "architecture" or "terminology" in the subject line where ossible -- David Harrington dbharrington@comcast.net +1-603-828-1401 On 8/9/13 12:44 AM, "Gunnar Engelbach" wrote: >This approach makes sense, Adam, and this conversation is a bit further >down in the process, but nonetheless I'd like to respond to David and >see how that jives with the group. > >Reasons to not require the use of a specific collection methodology: > >1) It's a recognition of a practical necessity: NETCONF is not going to >be universally usable. Nor is SNMP, WBEM, or any other technology. In >a heterogeneous environment it will be necessary to use a combination of >these to do the actual collection in order to achieve full coverage, >especially considering the number of legacy and embedded devices for >which adding software is impractical. > >2) It muddies things a bit that NETCONF, WBEM, SNMP, etc, are also >network protocols, but the actual artifact collection will frequently >*not* be done over the network. It will be done with database queries, >using local APIs, parsing backed up configuration files, terminal >command over an RS-232 cable, etc. The initiator for collection of an >endpoint may be a network message, but fulfillment can be anything, >including another network protocol. > >3) As I mentioned it's not enough to simply give a list of artifacts >that need to be collected. It will also be necessary to do multi-step >collections where initial collected values are applied via logic rules >to complete the collection process. Is the NETCONF group, or any other, >going to be willing to perturb their work to this degree? > >4) For the collection process we are interested in the ability to >dispatch a document that details all artifacts necessary to complete an >automated security task, and the response to that request*. Those two >documents are the standards that I am interested in: how that >collection actually happens I don't care about. So if the receiving end >translates that into NETCONF to fulfill part/all of it, or makes WMI >queries, I don't care, just as I don't care if that receiver is a local >agent, a database, a proxy for multiple devices, or a relay, except that >I would also like to receive some information about the collection >process that can be used to determine timeliness, and accuracy of the >response. > > > >* Yeah, this statement is a bit presumptive. Anybody see things >differently? > > > >On 8/8/2013 5:52 PM, Adam Montville wrote: >> At this point, I wouldn't disagree with either perspective. To be >>pedantic about it, the use cases should probably be at a level where we >>are not prescribing or presuming any particular protocol or data format. >> >> Requirements will then be able to describe use case needs in more >>detail, but still without prescribing or presuming particular >>protocols/formats - requirements are more likely to describe the >>characteristics such protocols/formats would need to possess. >> >> Then, architectures would "take the plunge" into the details of which >>protocols and/or data formats would be viable to meet the requirements, >>and therefore the use cases. >> >> We all have ideas about what an architecture might look like, and we >>are trying to do some things in parallel, but I think it's important to >>keep the delineation between use cases, requirements, and architecture >>as clean as we can. >> >> Adam >> >>> -----Original Message----- >>> From: David Harrington [mailto:ietfdbh@comcast.net] >>> Sent: Thursday, August 08, 2013 2:00 PM >>> To: Gunnar Engelbach; Waltermire, David A. >>> Cc: Romascanu, Dan (Dan); Adam Montville; sacm@ietf.org; Baker, Jon >>> Subject: Re: [sacm] [Netconf] [netmod] development plan >>> >>> >>> >>> >>> >>> On 8/7/13 10:45 PM, "Gunnar Engelbach" >>> >>> wrote: >>> >>>> >>>> I'm not all that familiar with NETCONF yet so I'm looking forward to >>>> learning more. >>>> >>>> However, even if it's a great fit for SACM purposes, I would say that >>>> we should not adopt NETCONF or any other such collection standard >>>> (WBEM/WMI, SNMP, etc) as our single collection standard, even if for a >>>> subset of endpoint types. >>>> >>>> If instead we focus on a way to communicate what items are to be >>>> collected from endpoints and return the collected items we shouldn't >>>> care about how the collection is performed. That leaves things open >>>> enough to cover the widest possible range of endpoints including EOL >>>> legacy devices. >>> >>> >>> IETF works on standards. >>> If every device gets to use a different protocol for query operations, >>>how >>> does that support interoperability? >>> Does an application doing evaluation need to be written to understand >>> different protocols for every device/model/OS in the network? >>> >>> I agree that we shouldn't choose just one protocol, but I think we >>>should use >>> standardized protocols and data models to promote vendor-neutral >>> interoperability. >>> -- >>> David Harrington >>> Ietfdbh@comcast.net >>> +1-603-828-1401 >>> >>> >>>> >>> >>> >>> >>> ... >> This message and attachments may contain confidential information. If >>it appears that this message was sent to you by mistake, any retention, >>dissemination, distribution or copying of this message and attachments >>is strictly prohibited. Please notify the sender immediately and >>permanently delete the message and any attachments. >> >> . . . >> >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From henk.birkholz@sit.fraunhofer.de Fri Aug 9 01:25:20 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D2221F99B7 for ; Fri, 9 Aug 2013 01:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osUhP5BAGtOT for ; Fri, 9 Aug 2013 01:25:13 -0700 (PDT) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by ietfa.amsl.com (Postfix) with ESMTP id 4D06521F99C3 for ; Fri, 9 Aug 2013 01:25:05 -0700 (PDT) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171] (may be forged)) by mailext.sit.fraunhofer.de (8.14.2/8.13.6/9.9.9) with ESMTP id r798Oecx026200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 9 Aug 2013 10:24:40 +0200 Received: from [134.102.117.126] (134.102.117.126) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 9 Aug 2013 10:24:37 +0200 Message-ID: <5204A744.6080701@sit.fraunhofer.de> Date: Fri, 9 Aug 2013 10:24:36 +0200 From: Henk Birkholz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephen Hanna References: <5202B207.3040000@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D675B738@CISEXCHANGE1.msisac.org.local> <52041F4E.3020707@ThreatGuard.com> <9e2f4cd6525847bc9526acd995c67d5d@BLUPR05MB053.namprd05.prod.outlook.com> In-Reply-To: <9e2f4cd6525847bc9526acd995c67d5d@BLUPR05MB053.namprd05.prod.outlook.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [134.102.117.126] Cc: "sacm@ietf.org" , David Harrington , Gunnar Engelbach , "Romascanu, Dan \(Dan\)" , "Waltermire, David A." , "Baker, Jon" , Adam Montville Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 08:25:20 -0000 Hello, analogously to the discussion in the meeting, I think that providing a recommendation/guideline regarding meta-data acquisition processes really helps. At least to better highlight context and purpose. Maybe, describing/defining categories for potential sources of information (from DBs, over real-time services, to automated discovery), for types of administrative domain (from well known IT-systems that support business processes, to unknown BYOD handhelds), or for acquisition methods (via agent or agent-less, via polling or pushing, or even recommended characteristics of specific protocols in certain environments), can result in better quality of aggregated meta-data - overall? Best, Henk On 08/09/2013 01:51 AM, Stephen Hanna wrote: > Gunnar, > > While I realize that in today's world there are many > protocols for obtaining information on endpoint posture > and I agree that we'll need to support those, I also > believe that we (the IETF) can and should nudge people > toward one or a small number of protocols that endpoints > should support. > > Legacy devices won't change and there will always be > some recalcitrant devices that refuse to supply posture > information and databases of historical data have utility > and there's more to security than endpoint posture and... > but I don't really see any reason why most if not all > endpoints couldn't support one simple set of protocols > and data formats for direct endpoint posture collection. > > Thanks, > > Steve > >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Gunnar Engelbach >> Sent: Thursday, August 08, 2013 6:44 PM >> To: Adam Montville >> Cc: Romascanu, Dan (Dan); David Harrington; Waltermire, David A.; >> Baker, Jon; sacm@ietf.org >> Subject: Re: [sacm] [Netconf] [netmod] development plan >> >> This approach makes sense, Adam, and this conversation is a bit further >> down in the process, but nonetheless I'd like to respond to David and >> see how that jives with the group. >> >> Reasons to not require the use of a specific collection methodology: >> >> 1) It's a recognition of a practical necessity: NETCONF is not going >> to >> be universally usable. Nor is SNMP, WBEM, or any other technology. In >> a heterogeneous environment it will be necessary to use a combination >> of >> these to do the actual collection in order to achieve full coverage, >> especially considering the number of legacy and embedded devices for >> which adding software is impractical. >> >> 2) It muddies things a bit that NETCONF, WBEM, SNMP, etc, are also >> network protocols, but the actual artifact collection will frequently >> *not* be done over the network. It will be done with database queries, >> using local APIs, parsing backed up configuration files, terminal >> command over an RS-232 cable, etc. The initiator for collection of an >> endpoint may be a network message, but fulfillment can be anything, >> including another network protocol. >> >> 3) As I mentioned it's not enough to simply give a list of artifacts >> that need to be collected. It will also be necessary to do multi-step >> collections where initial collected values are applied via logic rules >> to complete the collection process. Is the NETCONF group, or any >> other, >> going to be willing to perturb their work to this degree? >> >> 4) For the collection process we are interested in the ability to >> dispatch a document that details all artifacts necessary to complete an >> automated security task, and the response to that request*. Those two >> documents are the standards that I am interested in: how that >> collection actually happens I don't care about. So if the receiving >> end >> translates that into NETCONF to fulfill part/all of it, or makes WMI >> queries, I don't care, just as I don't care if that receiver is a local >> agent, a database, a proxy for multiple devices, or a relay, except >> that >> I would also like to receive some information about the collection >> process that can be used to determine timeliness, and accuracy of the >> response. >> >> >> >> * Yeah, this statement is a bit presumptive. Anybody see things >> differently? From david.waltermire@nist.gov Fri Aug 9 06:50:13 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F3D11E8116 for ; Fri, 9 Aug 2013 06:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUVWocpZ9HyE for ; Fri, 9 Aug 2013 06:49:59 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id BD1E611E8105 for ; Fri, 9 Aug 2013 06:49:58 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 Aug 2013 09:49:45 -0400 Received: from wsget1.nist.gov (129.6.13.150) by WSXGHUB2.xchange.nist.gov (129.6.18.19) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 9 Aug 2013 09:49:54 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 Aug 2013 09:49:45 -0400 Received: from na01-by2-obe.outbound.protection.outlook.com (207.46.163.243) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 Aug 2013 09:49:53 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB039.namprd09.prod.outlook.com (10.255.211.153) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 13:49:51 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.53]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 13:49:51 +0000 From: "Waltermire, David A." To: Gunnar Engelbach , Adam Montville Thread-Topic: [sacm] [Netconf] [netmod] development plan Thread-Index: AQHOkdp3Zrixa9H9GUOrS6K9JR4LhJmG33MAgAAJJICAAB2bgIAAIGsAgAEMkACAAD4fcIAABdmQgAEdfoCAAAbioIAAnwSAgAGWH4CAAA69AIAADpUAgAD7gmA= Date: Fri, 9 Aug 2013 13:49:50 +0000 Message-ID: References: <5202B207.3040000@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D675B738@CISEXCHANGE1.msisac.org.local> <52041F4E.3020707@ThreatGuard.com> In-Reply-To: <52041F4E.3020707@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(199002)(377454003)(189002)(51704005)(80976001)(80022001)(83322001)(51856001)(74316001)(46102001)(74706001)(81686001)(49866001)(65816001)(59766001)(63696002)(4396001)(83072001)(76482001)(69226001)(53806001)(66066001)(47976001)(33646001)(47736001)(56776001)(77096001)(79102001)(74662001)(81542001)(76796001)(77982001)(19580405001)(19580395003)(76576001)(56816003)(16406001)(81342001)(74876001)(47446002)(76786001)(54356001)(31966008)(74502001)(50986001)(54316002)(74366001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB039; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Cc: "Romascanu, Dan \(Dan\)" , David Harrington , "sacm@ietf.org" , "Baker, Jon" Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 13:50:14 -0000 > -----Original Message----- > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > Sent: Thursday, August 08, 2013 6:45 PM > To: Adam Montville > Cc: David Harrington; Waltermire, David A.; Romascanu, Dan (Dan); > sacm@ietf.org; Baker, Jon > Subject: Re: [sacm] [Netconf] [netmod] development plan >=20 > Reasons to not require the use of a specific collection methodology: >=20 > 3) As I mentioned it's not enough to simply give a list of artifacts that= need to > be collected. It will also be necessary to do multi-step collections whe= re > initial collected values are applied via logic rules to complete the coll= ection > process. Is the NETCONF group, or any other, going to be willing to pert= urb > their work to this degree? I don't see how this would perturb the underlying transport in any way. If = collection of a subset of posture is allowed, wouldn't this simply be handl= ed (regardless of transport) using multiple requests for posture? Dave From david.waltermire@nist.gov Fri Aug 9 06:57:18 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B603F21F95DD for ; Fri, 9 Aug 2013 06:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILdpNUvJFQss for ; Fri, 9 Aug 2013 06:57:11 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id B262821F9406 for ; Fri, 9 Aug 2013 06:57:10 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 Aug 2013 09:57:00 -0400 Received: from wsget2.nist.gov (129.6.13.151) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 9 Aug 2013 09:57:09 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 Aug 2013 09:56:48 -0400 Received: from na01-bl2-obe.outbound.protection.outlook.com (207.46.163.205) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 Aug 2013 09:57:09 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB039.namprd09.prod.outlook.com (10.255.211.153) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 13:57:01 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.53]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 13:57:01 +0000 From: "Waltermire, David A." To: Gunnar Engelbach Thread-Topic: [sacm] [Netconf] [netmod] development plan Thread-Index: AQHOkdp3Zrixa9H9GUOrS6K9JR4LhJmG33MAgAAJJICAAB2bgIAAIGsAgAEMkACAAD4fcIAABdmQgAEdfoCAAAbioIAAnwSAgAGWH4CAAA69AIAABfWwgAALTICAAPXFcA== Date: Fri, 9 Aug 2013 13:57:00 +0000 Message-ID: References: <5202B207.3040000@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D675B738@CISEXCHANGE1.msisac.org.local> <5204218B.4060504@ThreatGuard.com> In-Reply-To: <5204218B.4060504@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(199002)(377454003)(35774003)(189002)(51704005)(80976001)(80022001)(83322001)(51856001)(74316001)(46102001)(74706001)(81686001)(49866001)(65816001)(59766001)(63696002)(4396001)(83072001)(76482001)(69226001)(53806001)(66066001)(47976001)(33646001)(47736001)(56776001)(77096001)(79102001)(74662001)(81542001)(76796001)(77982001)(19580405001)(19580395003)(76576001)(56816003)(16406001)(81342001)(74876001)(47446002)(76786001)(54356001)(31966008)(74502001)(50986001)(54316002)(74366001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB039; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Cc: David Harrington , Adam Montville , "sacm@ietf.org" , "Baker, Jon" , "Romascanu, Dan \(Dan\)" Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 13:57:18 -0000 > -----Original Message----- > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > Sent: Thursday, August 08, 2013 6:54 PM > To: Waltermire, David A. > Cc: Adam Montville; David Harrington; Romascanu, Dan (Dan); > sacm@ietf.org; Baker, Jon > Subject: Re: [sacm] [Netconf] [netmod] development plan >=20 > Any requirements pop out at you? Here are a few potential requirements extracted from the discussion thread: - We SHOULD achieve complete/adequate coverage of all endpoint device types= . - We MUST identify (select existing, design new as needed) one or a small n= umber of transports for use in exchanging endpoint posture with a focus on = maximizing interoperability. - Transports MUST support client (endpoint) initiation of the exchange. - Transports MUST support server initiation of exchange, including reques= ts for a subset of posture. - Transports SHOULD support multiple data representations, allowing for m= ultiple posture information types. - If multiple transports are used, there MUST be a method to consolidate da= ta collected from each into a cohesive data set. - Posture collection MUST be allowed to be performed remotely and locally r= elative to the endpoint. - Exchanged metadata information associated with a posture exchange SHOULD = include information about the collection process that can be used to determ= ine timeliness, and accuracy of the response. Comments? Dave From eric.walker@us.ibm.com Fri Aug 9 08:47:02 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BE021F9A94 for ; Fri, 9 Aug 2013 08:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.044 X-Spam-Level: X-Spam-Status: No, score=-9.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkxQf9-Y9w0A for ; Fri, 9 Aug 2013 08:46:56 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id 10F4B21F9A65 for ; Fri, 9 Aug 2013 08:40:03 -0700 (PDT) Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 9 Aug 2013 09:40:03 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 9 Aug 2013 09:40:01 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 0893E3E4003F for ; Fri, 9 Aug 2013 09:39:37 -0600 (MDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r79FdxuY253140 for ; Fri, 9 Aug 2013 09:39:59 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r79Fdvhj020258 for ; Fri, 9 Aug 2013 09:39:58 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.63.40.12]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r79FdogM019657; Fri, 9 Aug 2013 09:39:50 -0600 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <5202B207.3040000@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D675B738@CISEXCHANGE1.msisac.org.local> <5204218B.4060504@ThreatGuard.com> From: Eric Walker To: "Waltermire, David A." , Adam Montville , "Baker, Jon" , "Romascanu, Dan \(Dan\)" , Gunnar Engelbach , David Harrington , "sacm@ietf.org" Message-ID: Date: Fri, 9 Aug 2013 09:39:43 -0600 X-Mailer: Lotus Domino Web Server Release 8.5.3FP2 ZX853FP2HF5 February, 2013 X-MIMETrack: Serialize by Notes Server on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/09/2013 09:39:43, Serialize complete at 08/09/2013 09:39:43, Itemize by Notes Server on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/09/2013 09:39:43, Serialize by Router on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/09/2013 09:39:50, Serialize complete at 08/09/2013 09:39:50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13080915-7408-0000-0000-000012D66B2F Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:47:02 -0000
Hi,

I have been following the SACM thr= eads only very lightly up to now due to competing commitments, but this one= stood out -- my apologies in advance for not being more familiar with the = preceding conversation.

It seems to me that we hav= e headed well into architectural details at this point.  In this case,= we're discussing a client-server architecture and the existence of a set o= f protocols that are to be used to communicate between client and server ("= transports").  In a sense I feel fortunate, because what is being prop= osed is at a high level similar to the product that I currently work on. &n= bsp;But I'm also somewhat nervous, because if we're getting into this level= of detail, there's a good chance that later on something could get rolled = into the use cases or standard that would be at variance with what my produ= ct does and that we would have a hard time accommodating within the medium = term.

Are people comfortable with this level of de= tail in the requirements -- agent, server, the existence of one or more tra= nsport protocols, etc.?  Is this level of detail required to fulfill t= he mission of this working group?  Perhaps it is, in which case existi= ng products that do not have this architecture will have to adapt.  Bu= t I sort of feel like we're approaching the problem from the wrong directio= n -- we have a solution in mind, and next we'll get to the challenges that = it will address.  This is fine on one level, because years of familiar= ity with the problem space may have given us a sufficient sense of what a v= iable solution would look like for us to be able to go about things this wa= y.  But if I might propose sorting out the use cases first, without in= troducing details that would necessarily imply an agent-based architecture = if such details can be omitted, that might be something that people would w= ant to consider.  That way we would be working from customer value bac= k to architecture, which will help to avoid over-engineering things.
<= div>
If we are comfortable getting into this level of detail = at this point, what about omitting the part about transport protocols and t= he need to support multiple ones?  Personally, I would like to avoid a= standard that implies an architecture that is so general that it can do an= ything and everything.  Another possibility is to limit things to a si= ngle transport protocol (one based on JSON or a single XML schema, for exam= ple).

Eric 


-----sacm-bounces@ietf.org wrote: -----
To: Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com>From: "Waltermire, David A."
Sent by: sacm= -bounces@ietf.org
Date: 08/09/2013 06:57AM
Cc: David Harrington <i= etfdbh@comcast.net>, Adam Montville <Adam.Montville@cisecurity.org>= ;, "sacm@ietf.org" <sacm@ietf.org>, "Baker, Jon" <bakerj@mitre.org= >, "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
Subject: Re: [= sacm] [Netconf] [netmod] development plan

> -----Original Message-----
>= From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com]
> Sent: Thursday, Augu= st 08, 2013 6:54 PM
> To: Waltermire, David A.
> Cc: Adam Montv= ille; David Harrington; Romascanu, Dan (Dan);
> sacm@ietf.org; Baker,= Jon
> Subject: Re: [sacm] [Netconf] [netmod] development plan
>= ;
> Any requirements pop out at you?

Here are a few potential= requirements extracted from the discussion thread:

- We SHOULD achi= eve complete/adequate coverage of all endpoint device types.
- We MUST i= dentify (select existing, design new as needed) one or a small number of tr= ansports for use in exchanging endpoint posture with a focus on maximizing = interoperability.
  - Transports MUST support client (endpoint= ) initiation of the exchange.
  - Transports MUST support serv= er initiation of exchange, including requests for a subset of posture.
&= nbsp; - Transports SHOULD support multiple data representations, allow= ing for multiple posture information types.
- If multiple transports are= used, there MUST be a method to consolidate data collected from each into = a cohesive data set.
- Posture collection MUST be allowed to be performe= d remotely and locally relative to the endpoint.
- Exchanged metadata in= formation associated with a posture exchange SHOULD include information abo= ut the collection process that can be used to determine timeliness, and acc= uracy of the response.

Comments?

Dave
=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
sacm mailing list
sa= cm@ietf.org
https= ://www.ietf.org/mailman/listinfo/sacm

= From eric.walker@us.ibm.com Fri Aug 9 09:29:45 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8598421F995A for ; Fri, 9 Aug 2013 09:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.044 X-Spam-Level: X-Spam-Status: No, score=-9.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jG7g87P8HVmt for ; Fri, 9 Aug 2013 09:29:38 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id B8FFC21F9AF5 for ; Fri, 9 Aug 2013 09:22:15 -0700 (PDT) Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 9 Aug 2013 10:22:10 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 9 Aug 2013 10:22:08 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id EC07D3E40030 for ; Fri, 9 Aug 2013 10:21:40 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r79GLvv6314888 for ; Fri, 9 Aug 2013 10:21:59 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r79GLtJV015147 for ; Fri, 9 Aug 2013 10:21:56 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.63.40.12]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r79GLmNA013970; Fri, 9 Aug 2013 10:21:51 -0600 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Eric Walker To: "Waltermire, David A." , Adam Montville , "Baker, Jon" , "Romascanu, Dan \(Dan\)" , Gunnar Engelbach , David Harrington , "sacm@ietf.org" Message-ID: Date: Fri, 9 Aug 2013 10:18:40 -0600 X-Mailer: Lotus Domino Web Server Release 8.5.3FP2 ZX853FP2HF5 February, 2013 X-MIMETrack: Serialize by Notes Server on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/09/2013 10:18:40, Serialize complete at 08/09/2013 10:18:40, Itemize by Notes Server on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/09/2013 10:18:40, Serialize by Router on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/09/2013 10:21:51, Serialize complete at 08/09/2013 10:21:51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13080916-7408-0000-0000-000012D6D338 Subject: [sacm] Fw: Re: [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:29:45 -0000
I wrote:

>But if I might propose sorting out t= he use
>cases first, without introducing details that would necessa= rily imply
>an agent-based architecture if such details can be omitte= d, that
>might be something that people would want to consider.  = ;That way we
>would be working from customer value back to architectu= re, which will
>help to avoid over-engineering things.

=
It occurs to me that a set of use cases have already been approved, al= though I have not had a chance to review them.  Perhaps as an assistan= ce to those of us who have yet to come up to speed on this discussion, any = architectural proposals could make a passing reference to the customer prob= lem being solved, even at the risk of repeating things a little for those w= ho are closely following the discussion?

Also, am = I to understand that the initial SACM standard will go beyond some existing= products?  I had the impression at one point that the initial revisio= n would seek to capture what existing products are doing and then, later on= , we could iterate and modify it organically.  This is my preferred ap= proach.

Eric

= From gunnar.engelbach@threatguard.com Fri Aug 9 09:36:13 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FE211E81D4 for ; Fri, 9 Aug 2013 09:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8kKk+kqgDrw for ; Fri, 9 Aug 2013 09:35:56 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 17DF921F9D0F for ; Fri, 9 Aug 2013 09:29:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=bfvCglvK/Q8rmcVVPXPu960qY2qsP1v9gaXNcctpIN1z4VTIXi2PwPhcznaNa29Ga1JJaxSuJn+0We6GIPnWzTR8GVC7p6swTgXRJqibWrFgaDmdIM6firWufp0cXNjX; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; Received: (qmail 16620 invoked from network); 9 Aug 2013 09:28:05 -0700 Received: from c-98-217-42-80.hsd1.nh.comcast.net (HELO ?192.168.2.149?) (98.217.42.80) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 9 Aug 2013 09:28:05 -0700 Message-ID: <520518C3.3020705@ThreatGuard.com> Date: Fri, 09 Aug 2013 12:28:51 -0400 From: Gunnar Engelbach User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eric Walker References: , <5202B207.3040000@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D675B738@CISEXCHANGE1.msisac.org.local> <5204218B.4060504@ThreatGuard.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050906030202030505000204" Cc: "sacm@ietf.org" , Adam Montville , "Romascanu, Dan \(Dan\)" , "Waltermire, David A." , "Baker, Jon" , David Harrington Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:36:13 -0000 This is a multi-part message in MIME format. --------------050906030202030505000204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Adam laid out the steps in a traditional development process from use cases to requirements, and it sounds like there is general agreement on that as the approach. However, I'm not against listing requirements now if we are aware of them. We can always change/remove them later if the process necessitates that. Use cases will help communicate the goals of the working group via examples, but I don't expect them to be complete enough to be able to derive all requirements from. --gun On 08/09/2013 11:39 AM, Eric Walker wrote: > Hi, > > I have been following the SACM threads only very lightly up to now due > to competing commitments, but this one stood out -- my apologies in > advance for not being more familiar with the preceding conversation. > > It seems to me that we have headed well into architectural details at > this point. In this case, we're discussing a client-server > architecture and the existence of a set of protocols that are to be > used to communicate between client and server ("transports"). In a > sense I feel fortunate, because what is being proposed is at a high > level similar to the product that I currently work on. But I'm also > somewhat nervous, because if we're getting into this level of detail, > there's a good chance that later on something could get rolled into > the use cases or standard that would be at variance with what my > product does and that we would have a hard time accommodating within > the medium term. > > Are people comfortable with this level of detail in the requirements > -- agent, server, the existence of one or more transport protocols, > etc.? Is this level of detail required to fulfill the mission of this > working group? Perhaps it is, in which case existing products that do > not have this architecture will have to adapt. But I sort of feel > like we're approaching the problem from the wrong direction -- we have > a solution in mind, and next we'll get to the challenges that it will > address. This is fine on one level, because years of familiarity with > the problem space may have given us a sufficient sense of what a > viable solution would look like for us to be able to go about things > this way. But if I might propose sorting out the use cases first, > without introducing details that would necessarily imply an > agent-based architecture if such details can be omitted, that might be > something that people would want to consider. That way we would be > working from customer value back to architecture, which will help to > avoid over-engineering things. > > If we are comfortable getting into this level of detail at this point, > what about omitting the part about transport protocols and the need to > support multiple ones? Personally, I would like to avoid a standard > that implies an architecture that is so general that it can do > anything and everything. Another possibility is to limit things to a > single transport protocol (one based on JSON or a single XML schema, > for example). > > Eric > > > -----sacm-bounces@ietf.org wrote: ----- > To: Gunnar Engelbach > From: "Waltermire, David A." > Sent by: sacm-bounces@ietf.org > Date: 08/09/2013 06:57AM > Cc: David Harrington , Adam Montville > , "sacm@ietf.org" , > "Baker, Jon" , "Romascanu, Dan \(Dan\)" > > Subject: Re: [sacm] [Netconf] [netmod] development plan > > > -----Original Message----- > > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > > Sent: Thursday, August 08, 2013 6:54 PM > > To: Waltermire, David A. > > Cc: Adam Montville; David Harrington; Romascanu, Dan (Dan); > > sacm@ietf.org; Baker, Jon > > Subject: Re: [sacm] [Netconf] [netmod] development plan > > > > Any requirements pop out at you? > > Here are a few potential requirements extracted from the discussion > thread: > > - We SHOULD achieve complete/adequate coverage of all endpoint device > types. > - We MUST identify (select existing, design new as needed) one or a > small number of transports for use in exchanging endpoint posture with > a focus on maximizing interoperability. > - Transports MUST support client (endpoint) initiation of the exchange. > - Transports MUST support server initiation of exchange, including > requests for a subset of posture. > - Transports SHOULD support multiple data representations, allowing > for multiple posture information types. > - If multiple transports are used, there MUST be a method to > consolidate data collected from each into a cohesive data set. > - Posture collection MUST be allowed to be performed remotely and > locally relative to the endpoint. > - Exchanged metadata information associated with a posture exchange > SHOULD include information about the collection process that can be > used to determine timeliness, and accuracy of the response. > > Comments? > > Dave > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --------------050906030202030505000204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Adam laid out the steps in a traditional development process from use cases to requirements, and it sounds like there is general agreement on that as the approach.

However, I'm not against listing requirements now if we are aware of them.  We can always change/remove them later if the process necessitates that.  Use cases will help communicate the goals of the working group via examples, but I don't expect them to be complete enough to be able to derive all requirements from.

--gun



On 08/09/2013 11:39 AM, Eric Walker wrote:
Hi,

I have been following the SACM threads only very lightly up to now due to competing commitments, but this one stood out -- my apologies in advance for not being more familiar with the preceding conversation.

It seems to me that we have headed well into architectural details at this point.  In this case, we're discussing a client-server architecture and the existence of a set of protocols that are to be used to communicate between client and server ("transports").  In a sense I feel fortunate, because what is being proposed is at a high level similar to the product that I currently work on.  But I'm also somewhat nervous, because if we're getting into this level of detail, there's a good chance that later on something could get rolled into the use cases or standard that would be at variance with what my product does and that we would have a hard time accommodating within the medium term.

Are people comfortable with this level of detail in the requirements -- agent, server, the existence of one or more transport protocols, etc.?  Is this level of detail required to fulfill the mission of this working group?  Perhaps it is, in which case existing products that do not have this architecture will have to adapt.  But I sort of feel like we're approaching the problem from the wrong direction -- we have a solution in mind, and next we'll get to the challenges that it will address.  This is fine on one level, because years of familiarity with the problem space may have given us a sufficient sense of what a viable solution would look like for us to be able to go about things this way.  But if I might propose sorting out the use cases first, without introducing details that would necessarily imply an agent-based architecture if such details can be omitted, that might be something that people would want to consider.  That way we would be working from customer value back to architecture, which will help to avoid over-engineering things.

If we are comfortable getting into this level of detail at this point, what about omitting the part about transport protocols and the need to support multiple ones?  Personally, I would like to avoid a standard that implies an architecture that is so general that it can do anything and everything.  Another possibility is to limit things to a single transport protocol (one based on JSON or a single XML schema, for example).

Eric 


-----sacm-bounces@ietf.org wrote: -----
To: Gunnar Engelbach <Gunnar.Engelbach@ThreatGuard.com>
From: "Waltermire, David A."
Sent by: sacm-bounces@ietf.org
Date: 08/09/2013 06:57AM
Cc: David Harrington <ietfdbh@comcast.net>, Adam Montville <Adam.Montville@cisecurity.org>, "sacm@ietf.org" <sacm@ietf.org>, "Baker, Jon" <bakerj@mitre.org>, "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
Subject: Re: [sacm] [Netconf] [netmod] development plan

> -----Original Message-----
> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com]
> Sent: Thursday, August 08, 2013 6:54 PM
> To: Waltermire, David A.
> Cc: Adam Montville; David Harrington; Romascanu, Dan (Dan);
> sacm@ietf.org; Baker, Jon
> Subject: Re: [sacm] [Netconf] [netmod] development plan
>
> Any requirements pop out at you?

Here are a few potential requirements extracted from the discussion thread:

- We SHOULD achieve complete/adequate coverage of all endpoint device types.
- We MUST identify (select existing, design new as needed) one or a small number of transports for use in exchanging endpoint posture with a focus on maximizing interoperability.
  - Transports MUST support client (endpoint) initiation of the exchange.
  - Transports MUST support server initiation of exchange, including requests for a subset of posture.
  - Transports SHOULD support multiple data representations, allowing for multiple posture information types.
- If multiple transports are used, there MUST be a method to consolidate data collected from each into a cohesive data set.
- Posture collection MUST be allowed to be performed remotely and locally relative to the endpoint.
- Exchanged metadata information associated with a posture exchange SHOULD include information about the collection process that can be used to determine timeliness, and accuracy of the response.

Comments?

Dave
_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm

--------------050906030202030505000204-- From shanna@juniper.net Fri Aug 9 10:57:54 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4F311E8168 for ; Fri, 9 Aug 2013 10:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.809 X-Spam-Level: X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuMerkN8bT97 for ; Fri, 9 Aug 2013 10:57:47 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 12AD621F90DC for ; Fri, 9 Aug 2013 10:52:36 -0700 (PDT) Received: from mail162-co1-R.bigfish.com (10.243.78.252) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 17:52:36 +0000 Received: from mail162-co1 (localhost [127.0.0.1]) by mail162-co1-R.bigfish.com (Postfix) with ESMTP id 1B2ECA2028C; Fri, 9 Aug 2013 17:52:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz98dI9371Ic85fh1432I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz70kz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de096h8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail162-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(189002)(164054003)(377454003)(199002)(19580385001)(83322001)(54316002)(19580395003)(19580405001)(54356001)(16236675002)(56776001)(51856001)(33646001)(16406001)(56816003)(59766001)(77982001)(81686001)(53806001)(63696002)(79102001)(18717965001)(76482001)(76786001)(80976001)(76796001)(77096001)(76576001)(46102001)(81342001)(74662001)(74502001)(83072001)(47446002)(81542001)(31966008)(561944002)(47736001)(19300405004)(15202345003)(74876001)(69226001)(74316001)(50986001)(80022001)(47976001)(66066001)(65816001)(49866001)(4396001)(74706001)(74366001)(921001)(1121002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB053; H:BLUPR05MB053.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail162-co1 (localhost.localdomain [127.0.0.1]) by mail162-co1 (MessageSwitch) id 1376070733969463_2773; Fri, 9 Aug 2013 17:52:13 +0000 (UTC) Received: from CO1EHSMHS017.bigfish.com (unknown [10.243.78.237]) by mail162-co1.bigfish.com (Postfix) with ESMTP id DE04D94004A; Fri, 9 Aug 2013 17:52:13 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS017.bigfish.com (10.243.66.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 17:52:12 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 17:52:11 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) by BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 17:52:10 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.169]) by BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.223]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 17:52:10 +0000 From: Stephen Hanna To: Eric Walker , "Waltermire, David A." , Adam Montville , "Baker, Jon" , "Romascanu, Dan (Dan)" , Gunnar Engelbach , David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] Fw: Re: [Netconf] [netmod] development plan Thread-Index: AQHOlR28TnpwRDyGFEqqU+JybrTHfpmNJl+g Date: Fri, 9 Aug 2013 17:52:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0933E9FD8D Content-Type: multipart/alternative; boundary="_000_c60d892bf24f404facdd98f9e60d63c0BLUPR05MB053namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] Fw: Re: [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:57:54 -0000 --_000_c60d892bf24f404facdd98f9e60d63c0BLUPR05MB053namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, we have not achieved WG consensus on the use cases yet. We agreed= to make the use case draft into a WG document but that does not mean that = there's WG consensus that it's done. It just means that this draft is a goo= d starting point for the project of listing and agreeing on the use cases. While this has been a fun diversion from the use cases, I agree with Eric's= original email. We should REFOCUS on the USE CASES and not jump into archi= tecture and implementation. This whole discussion started with a discussion= about whether NetConf will be useful. Discussing that is getting way ahead= of ourselves. Let's stop and go back to use cases. Dave Waltermire, how soon can we expect to have another use case draft? Or = should we just start sending more comments on the current draft? Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Eri= c Walker Sent: Friday, August 09, 2013 12:19 PM To: Waltermire, David A.; Adam Montville; Baker, Jon; Romascanu, Dan (Dan);= Gunnar Engelbach; David Harrington; sacm@ietf.org Subject: [sacm] Fw: Re: [Netconf] [netmod] development plan I wrote: >But if I might propose sorting out the use >cases first, without introducing details that would necessarily imply >an agent-based architecture if such details can be omitted, that >might be something that people would want to consider. That way we >would be working from customer value back to architecture, which will >help to avoid over-engineering things. It occurs to me that a set of use cases have already been approved, althoug= h I have not had a chance to review them. Perhaps as an assistance to thos= e of us who have yet to come up to speed on this discussion, any architectu= ral proposals could make a passing reference to the customer problem being = solved, even at the risk of repeating things a little for those who are clo= sely following the discussion? Also, am I to understand that the initial SACM standard will go beyond some= existing products? I had the impression at one point that the initial rev= ision would seek to capture what existing products are doing and then, late= r on, we could iterate and modify it organically. This is my preferred app= roach. Eric --_000_c60d892bf24f404facdd98f9e60d63c0BLUPR05MB053namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually, we have not ach= ieved WG consensus on the use cases yet. We agreed to make the use case dra= ft into a WG document but that does not mean that there’s WG consensus that it’s done. It just means that this draft is a good= starting point for the project of listing and agreeing on the use cases.

 <= /p>

While this has been a fun= diversion from the use cases, I agree with Eric’s original email. We= should REFOCUS on the USE CASES and not jump into architecture and implementation. This whole discussion started with a discussion about = whether NetConf will be useful. Discussing that is getting way ahead of our= selves. Let’s stop and go back to use cases.

 <= /p>

Dave Waltermire, how soon= can we expect to have another use case draft? Or should we just start send= ing more comments on the current draft?

 <= /p>

Thanks,=

 <= /p>

Steve

 <= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Eric Walker
Sent: Friday, August 09, 2013 12:19 PM
To: Waltermire, David A.; Adam Montville; Baker, Jon; Romascanu, Dan= (Dan); Gunnar Engelbach; David Harrington; sacm@ietf.org
Subject: [sacm] Fw: Re: [Netconf] [netmod] development plan

 

I wrote:


>But if I might propose sorting out the use

>cases first, without introducing de= tails that would necessarily imply
>an agent-based architecture if such details can be omitted, that
>might be something that people would want to consider.  That way w= e
>would be working from customer value back to architecture, which will >help to avoid over-engineering things.

 

It occurs to me that a set of use cases= have already been approved, although I have not had a chance to review the= m.  Perhaps as an assistance to those of us who have yet to come up to speed on this discussion, any architectural proposals could = make a passing reference to the customer problem being solved, even at the = risk of repeating things a little for those who are closely following the d= iscussion?

 

Also, am I to understand that the initi= al SACM standard will go beyond some existing products?  I had the imp= ression at one point that the initial revision would seek to capture what existing products are doing and then, later on, we could iter= ate and modify it organically.  This is my preferred approach.

 

Eric

 

--_000_c60d892bf24f404facdd98f9e60d63c0BLUPR05MB053namprd05pro_-- From david.waltermire@nist.gov Fri Aug 9 11:02:58 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F164021F9F1B for ; Fri, 9 Aug 2013 11:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFp2ORiPpBt8 for ; Fri, 9 Aug 2013 11:02:50 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 08E9211E80EA for ; Fri, 9 Aug 2013 10:57:35 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 Aug 2013 13:57:21 -0400 Received: from wsget2.nist.gov (129.6.13.151) by WSXGHUB2.xchange.nist.gov (129.6.18.19) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 9 Aug 2013 13:57:30 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 Aug 2013 13:57:09 -0400 Received: from na01-bl2-obe.outbound.protection.outlook.com (207.46.163.203) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 Aug 2013 13:57:30 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB037.namprd09.prod.outlook.com (10.255.211.139) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 17:57:23 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.86]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.53]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 17:57:23 +0000 From: "Waltermire, David A." To: Stephen Hanna , Eric Walker , Adam Montville , "Baker, Jon" , "Romascanu, Dan (Dan)" , "Gunnar Engelbach" , David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] Fw: Re: [Netconf] [netmod] development plan Thread-Index: AQHOlSlFdQgvAbD6x0q2PLW2JUcjaJmNKRiA Date: Fri, 9 Aug 2013 17:57:22 +0000 Message-ID: <7f81fe8690b84379b6931cdd3a4b690a@BLUPR09MB038.namprd09.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(164054003)(199002)(377454003)(189002)(24454002)(80022001)(80976001)(74706001)(83322001)(74316001)(46102001)(81686001)(19300405004)(49866001)(51856001)(15202345003)(76796001)(65816001)(63696002)(59766001)(4396001)(69226001)(76482001)(83072001)(47976001)(66066001)(53806001)(47736001)(56776001)(79102001)(74662001)(561944002)(81542001)(77096001)(19580405001)(16236675002)(1941001)(76576001)(16406001)(56816003)(81342001)(19580395003)(47446002)(74876001)(76786001)(50986001)(31966008)(54356001)(74502001)(19580385001)(74366001)(54316002)(77982001)(33646001)(921001)(1121002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB037; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_7f81fe8690b84379b6931cdd3a4b690aBLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sacm] Fw: Re: [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:02:58 -0000 --_000_7f81fe8690b84379b6931cdd3a4b690aBLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am hoping to have an update of the use case draft by the end of next week= . I also plan to post some questions throughout the week. Please continue= to discuss the current draft and to contribute any new use cases. Thanks, Dave From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Friday, August 09, 2013 1:52 PM To: Eric Walker; Waltermire, David A.; Adam Montville; Baker, Jon; Romascan= u, Dan (Dan); Gunnar Engelbach; David Harrington; sacm@ietf.org Subject: RE: [sacm] Fw: Re: [Netconf] [netmod] development plan Actually, we have not achieved WG consensus on the use cases yet. We agreed= to make the use case draft into a WG document but that does not mean that = there's WG consensus that it's done. It just means that this draft is a goo= d starting point for the project of listing and agreeing on the use cases. While this has been a fun diversion from the use cases, I agree with Eric's= original email. We should REFOCUS on the USE CASES and not jump into archi= tecture and implementation. This whole discussion started with a discussion= about whether NetConf will be useful. Discussing that is getting way ahead= of ourselves. Let's stop and go back to use cases. Dave Waltermire, how soon can we expect to have another use case draft? Or = should we just start sending more comments on the current draft? Thanks, Steve From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Eric Walker Sent: Friday, August 09, 2013 12:19 PM To: Waltermire, David A.; Adam Montville; Baker, Jon; Romascanu, Dan (Dan);= Gunnar Engelbach; David Harrington; sacm@ietf.org Subject: [sacm] Fw: Re: [Netconf] [netmod] development plan I wrote: >But if I might propose sorting out the use >cases first, without introducing details that would necessarily imply >an agent-based architecture if such details can be omitted, that >might be something that people would want to consider. That way we >would be working from customer value back to architecture, which will >help to avoid over-engineering things. It occurs to me that a set of use cases have already been approved, althoug= h I have not had a chance to review them. Perhaps as an assistance to thos= e of us who have yet to come up to speed on this discussion, any architectu= ral proposals could make a passing reference to the customer problem being = solved, even at the risk of repeating things a little for those who are clo= sely following the discussion? Also, am I to understand that the initial SACM standard will go beyond some= existing products? I had the impression at one point that the initial rev= ision would seek to capture what existing products are doing and then, late= r on, we could iterate and modify it organically. This is my preferred app= roach. Eric --_000_7f81fe8690b84379b6931cdd3a4b690aBLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am hoping to have an up= date of the use case draft by the end of next week.  I also plan to po= st some questions throughout the week.  Please continue to discuss the current draft and to contribute any new use cases.

 <= /p>

Thanks,=

Dave

 <= /p>

From: Stephen = Hanna [mailto:shanna@juniper.net]
Sent: Friday, August 09, 2013 1:52 PM
To: Eric Walker; Waltermire, David A.; Adam Montville; Baker, Jon; R= omascanu, Dan (Dan); Gunnar Engelbach; David Harrington; sacm@ietf.org
Subject: RE: [sacm] Fw: Re: [Netconf] [netmod] development plan=

 

Actually, we have not ach= ieved WG consensus on the use cases yet. We agreed to make the use case dra= ft into a WG document but that does not mean that there’s WG consensus that it’s done. It just means that this draft is a good= starting point for the project of listing and agreeing on the use cases.

 <= /p>

While this has been a fun= diversion from the use cases, I agree with Eric’s original email. We= should REFOCUS on the USE CASES and not jump into architecture and implementation. This whole discussion started with a discussion about = whether NetConf will be useful. Discussing that is getting way ahead of our= selves. Let’s stop and go back to use cases.

 <= /p>

Dave Waltermire, how soon= can we expect to have another use case draft? Or should we just start send= ing more comments on the current draft?

 <= /p>

Thanks,=

 <= /p>

Steve

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Eric Walker
Sent: Friday, August 09, 2013 12:19 PM
To: Waltermire, David A.; Adam Montville; Baker, Jon; Romascanu, Dan= (Dan); Gunnar Engelbach; David Harrington; sacm@ietf.org
Subject: [sacm] Fw: Re: [Netconf] [netmod] development plan

 

I wrote:


>But if I might propose sorting out the use

>cases first, without introducing de= tails that would necessarily imply
>an agent-based architecture if such details can be omitted, that
>might be something that people would want to consider.  That way w= e
>would be working from customer value back to architecture, which will >help to avoid over-engineering things.

 

It occurs to me that a set of use cases= have already been approved, although I have not had a chance to review the= m.  Perhaps as an assistance to those of us who have yet to come up to speed on this discussion, any architectural proposals could = make a passing reference to the customer problem being solved, even at the = risk of repeating things a little for those who are closely following the d= iscussion?

 

Also, am I to understand that the initi= al SACM standard will go beyond some existing products?  I had the imp= ression at one point that the initial revision would seek to capture what existing products are doing and then, later on, we could iter= ate and modify it organically.  This is my preferred approach.

 

Eric

 

--_000_7f81fe8690b84379b6931cdd3a4b690aBLUPR09MB038namprd09pro_-- From ietfdbh@comcast.net Fri Aug 9 13:04:09 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7814C21F9C4E for ; Fri, 9 Aug 2013 13:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtf10RBDM6wf for ; Fri, 9 Aug 2013 13:04:04 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF901F0C55 for ; Fri, 9 Aug 2013 12:57:47 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta05.westchester.pa.mail.comcast.net with comcast id Ab5j1m0021GhbT855jxmpf; Fri, 09 Aug 2013 19:57:46 +0000 Received: from [10.121.20.164] ([195.50.158.227]) by omta07.westchester.pa.mail.comcast.net with comcast id AjxE1m0124ufcbF3TjxRUl; Fri, 09 Aug 2013 19:57:44 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Fri, 09 Aug 2013 21:57:14 +0200 From: David Harrington To: "Waltermire, David A." , Gunnar Engelbach Message-ID: Thread-Topic: [sacm] [Netconf] [netmod] development plan In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376078266; bh=qdGcQ5NseNIJKEgwKXHBHp0n8+GiBuNKnQXlXnk5tX0=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=rwAnDSdF5AxRYG+7eXSFp0aCL3DY1HLK7N1u5hTfV8jBg2Em1fHZPFpOAgYfZaJMK i4nlGzMP1deRZ2ZDYsTYb8GX9mvAIPujqV2D+eKsPivPQjZstK9xRJV+Oj9rsDlwMX UJIldQZQ/8N9sJK+gYwvXellBXmzOMhxnX9Dg55UlZZ1mS63L6mqcuxUxrLxXGdHeU g04zHdAwa6SWNFCN8PlYj2z/NK7ac7RhuiBYEWrrWkv3HAUwhhU+hrU5bcufLs6ntI VqLYmUUV2QA/69XWIRtCcOCY8OH0YWTScY2fCJDewMXlzV3te/Y7ZA9RznQ9ZKN4wc pNB2gChWLsw8w== Cc: "Romascanu, Dan \(Dan\)" , Adam Montville , "sacm@ietf.org" , "Baker, Jon" Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 20:04:09 -0000 Can we please change the subject thread from "Re: [sacm] [Netconf] [netmod] development plan" I also subscribe to netmod and netconf lists, and there is discussion going on there undet the same subject line (minus the [sacm]) It would be MUCH better for the editors to be able to find emails they need to respond during editing if the subject line reflects the message content. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 8/9/13 3:57 PM, "Waltermire, David A." wrote: > >> -----Original Message----- >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >> Sent: Thursday, August 08, 2013 6:54 PM >> To: Waltermire, David A. >> Cc: Adam Montville; David Harrington; Romascanu, Dan (Dan); >> sacm@ietf.org; Baker, Jon >> Subject: Re: [sacm] [Netconf] [netmod] development plan >> >> Any requirements pop out at you? > >Here are a few potential requirements extracted from the discussion >thread: > >- We SHOULD achieve complete/adequate coverage of all endpoint device >types. >- We MUST identify (select existing, design new as needed) one or a small >number of transports for use in exchanging endpoint posture with a focus >on maximizing interoperability. > - Transports MUST support client (endpoint) initiation of the exchange. > - Transports MUST support server initiation of exchange, including >requests for a subset of posture. > - Transports SHOULD support multiple data representations, allowing for >multiple posture information types. >- If multiple transports are used, there MUST be a method to consolidate >data collected from each into a cohesive data set. >- Posture collection MUST be allowed to be performed remotely and locally >relative to the endpoint. >- Exchanged metadata information associated with a posture exchange >SHOULD include information about the collection process that can be used >to determine timeliness, and accuracy of the response. > >Comments? > >Dave >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Fri Aug 9 14:31:04 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F7F11E81E9 for ; Fri, 9 Aug 2013 14:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns7TEh6Q9p+u for ; Fri, 9 Aug 2013 14:30:59 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4069521F9CF7 for ; Fri, 9 Aug 2013 14:21:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=GaqKRcCassBvmCWjyK+5UmUxrd0SApRp9s3WeGtHkgOWa6AfnK5a/1faZwo0p17a3PKCmpHfDgEEcg9vZAwFKqjfnSli9syezolVW8z0QC/l2VwkvFsernDKpotwLkT/; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 3399 invoked from network); 9 Aug 2013 14:20:37 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 9 Aug 2013 14:20:37 -0700 Message-ID: <52055D63.60409@ThreatGuard.com> Date: Fri, 09 Aug 2013 17:21:39 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Waltermire, David A." References: <5202B207.3040000@ThreatGuard.com> <05BCCEB107AF88469B9F99783D47C1D675B738@CISEXCHANGE1.msisac.org.local> <5204218B.4060504@ThreatGuard.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Harrington , Adam Montville , "sacm@ietf.org" , "Baker, Jon" , "Romascanu, Dan \(Dan\)" Subject: Re: [sacm] [Netconf] [netmod] development plan X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:31:04 -0000 On 8/9/2013 9:57 AM, Waltermire, David A. wrote: > >> -----Original Message----- >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >> Sent: Thursday, August 08, 2013 6:54 PM >> To: Waltermire, David A. >> Cc: Adam Montville; David Harrington; Romascanu, Dan (Dan); >> sacm@ietf.org; Baker, Jon >> Subject: Re: [sacm] [Netconf] [netmod] development plan >> >> Any requirements pop out at you? > > Here are a few potential requirements extracted from the discussion thread: > > - We SHOULD achieve complete/adequate coverage of all endpoint device types. > - We MUST identify (select existing, design new as needed) one or a small number of transports for use in exchanging endpoint posture with a focus on maximizing interoperability. > - Transports MUST support client (endpoint) initiation of the exchange. > - Transports MUST support server initiation of exchange, including requests for a subset of posture. > - Transports SHOULD support multiple data representations, allowing for multiple posture information types. > - If multiple transports are used, there MUST be a method to consolidate data collected from each into a cohesive data set. > - Posture collection MUST be allowed to be performed remotely and locally relative to the endpoint. > - Exchanged metadata information associated with a posture exchange SHOULD include information about the collection process that can be used to determine timeliness, and accuracy of the response. > > Comments? Yeah: good list. Hang on to it. > > Dave > From ietfdbh@comcast.net Sat Aug 10 08:58:00 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9679621F9D17 for ; Sat, 10 Aug 2013 08:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPeAt1Ve0Igo for ; Sat, 10 Aug 2013 08:57:55 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id F10F511E8101 for ; Sat, 10 Aug 2013 08:51:09 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta13.westchester.pa.mail.comcast.net with comcast id B3nf1m0030EZKEL5D3r0yd; Sat, 10 Aug 2013 15:51:00 +0000 Received: from [10.121.23.117] ([195.50.158.227]) by omta01.westchester.pa.mail.comcast.net with comcast id B3qm1m00G4ufcbF3M3qqJw; Sat, 10 Aug 2013 15:50:58 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Sat, 10 Aug 2013 17:50:44 +0200 From: David Harrington To: "sacm@ietf.org" Message-ID: Thread-Topic: New Version Notification for draft-dbh-sacm-terminology-00.txt In-Reply-To: <20130810131139.14498.22193.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376149860; bh=GxNbFRjhGWIClr+tXMzGS6ntfWvX3icn+UO6qHmsdVs=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=E68AU4WCB33hRq4/8KkiBWixMwDyU4Pidk7NZTYeFiWBKkihSkYB1wT8Q0FnbYj3W jeLnjNIJRmqd/MJVc2oglDqfPNM1X1TrA84oRUz9wC8/8lorhpNEL6Jt9SXlt4/BmL DerNIGw5ahHklsvq/WXcsU+B1d6zdStuF2XL7M+Xi1dxY0cwXySLDsWNfzKq6i/vsH 9g9oJogRtL4DhXW4PCerVRWEcCddEglNGFxjeQNs2O2fyIdounklvXFTCQxAZ0ydHt X7OT2e7qedBu5K7P+17zc9adNGlgIxXL9V0CF0c3F9Ageqnx5YrNolI31wx1gsQ9Zk TLfgPrWosGYiA== Subject: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 15:58:00 -0000 Hi, I cut the terminology from use-cases and created a terminology doc. This is an individual draft; the WG will need to decide whether to accept it as a wg draft to start the wg's terminology doc. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 8/10/13 3:11 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-dbh-sacm-terminology-00.txt >has been successfully submitted by David Waltermire and posted to the >IETF repository. > >Filename: draft-dbh-sacm-terminology >Revision: 00 >Title: Terminology for Security Assessment >Creation date: 2013-08-10 >Group: Individual Submission >Number of pages: 7 >URL: >http://www.ietf.org/internet-drafts/draft-dbh-sacm-terminology-00.txt >Status: >http://datatracker.ietf.org/doc/draft-dbh-sacm-terminology >Htmlized: http://tools.ietf.org/html/draft-dbh-sacm-terminology-00 > > >Abstract: > This memo documents terminology used in the documents produced by the > SACM WG (Security Automation and Continuous Monitoring). > > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From Adam.Montville@cisecurity.org Sat Aug 10 19:06:26 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7261011E80F1 for ; Sat, 10 Aug 2013 19:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.747 X-Spam-Level: X-Spam-Status: No, score=-2.747 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtctBU60R35n for ; Sat, 10 Aug 2013 19:06:21 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1C821F8904 for ; Sat, 10 Aug 2013 19:00:49 -0700 (PDT) Received: from [216.82.250.19:64527] by server-1.bemta-12.messagelabs.com id 62/A4-04524-F40F6025; Sun, 11 Aug 2013 02:00:47 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-5.tower-87.messagelabs.com!1376186446!15691565!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 22299 invoked from network); 11 Aug 2013 02:00:47 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-5.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 11 Aug 2013 02:00:47 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::b899:f128:212e:984c%13]) with mapi id 14.02.0342.003; Sat, 10 Aug 2013 22:00:45 -0400 From: Adam Montville To: David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt Thread-Index: AQHOleJqh4LofhpXnUWuN+zTZg/M05mPQL3A Date: Sun, 11 Aug 2013 02:00:43 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D6791142@CISEXCHANGE1.msisac.org.local> References: <20130810131139.14498.22193.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 02:06:26 -0000 David, Thanks for putting this together. I know that, if the WG decides to adopt= the draft, there are at least two individuals interested in maintaining i= t, so you wouldn't necessarily have to. =20 I know the draft doesn't *need* more than one editor, but it could be good= to have two to handle reaction time (i.e. when a new term is needed, the = draft can be updated quickly). Anyone have thoughts on this? Regards, Adam ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of David Har= rington [ietfdbh@comcast.net] Sent: Saturday, August 10, 2013 8:58 AM To: sacm@ietf.org Subject: [sacm] FW: New Version Notification for draft-dbh-sacm-ter= minology-00.txt Hi, I cut the terminology from use-cases and created a terminology doc. This is an individual draft; the WG will need to decide whether to accept it as a wg draft to start the wg's terminology doc. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 8/10/13 3:11 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-dbh-sacm-terminology-00.txt >has been successfully submitted by David Waltermire and posted to the >IETF repository. > >Filename: draft-dbh-sacm-terminology >Revision: 00 >Title: Terminology for Security Assessment >Creation date: 2013-08-10 >Group: Individual Submission >Number of pages: 7 >URL: >http://www.ietf.org/internet-drafts/draft-dbh-sacm-terminology-00.txt >Status: >http://datatracker.ietf.org/doc/draft-dbh-sacm-terminology >Htmlized: http://tools.ietf.org/html/draft-dbh-sacm-terminology-00= > > >Abstract: > This memo documents terminology used in the documents produced by the > SACM WG (Security Automation and Continuous Monitoring). > > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ... . . . From ietfdbh@comcast.net Sun Aug 11 03:14:04 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0379821F9EA9 for ; Sun, 11 Aug 2013 03:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8iGR4yzF8HY for ; Sun, 11 Aug 2013 03:13:51 -0700 (PDT) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by ietfa.amsl.com (Postfix) with ESMTP id D523F21F9E99 for ; Sun, 11 Aug 2013 03:06:34 -0700 (PDT) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta06.emeryville.ca.mail.comcast.net with comcast id BN6Q1m0010QkzPwA6N6Yc1; Sun, 11 Aug 2013 10:06:32 +0000 Received: from [10.121.19.50] ([195.50.158.227]) by omta02.emeryville.ca.mail.comcast.net with comcast id BN6A1m00J4ufcbF8NN6ERN; Sun, 11 Aug 2013 10:06:30 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Sun, 11 Aug 2013 12:06:09 +0200 From: David Harrington To: Adam Montville , "sacm@ietf.org" Message-ID: Thread-Topic: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6791142@CISEXCHANGE1.msisac.org.local> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376215592; bh=Uy5oYWMKQwvTG2IefFJ7fIuGYaJrbbYxDp6jTO7FgHw=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=H0fNHCubDASko3R82icH/u6VRzQJqe7nlPq51l1jlbCR3u80Y//EiFa8/j8iOvafC KoMwEwa+bfjoKEyMjtIYAmsQTq2mrf589NJq40soR22UaIdQ7lU4B8ZsG5sGu7AbLf xzlwo7S9OLWhNcSYPZClwwcKMH1WdYC7JOlcokurWL43l9EfxcPBlj3xlHP8Mwk/UD 9oHNRgFUfxfi+69s8kBKuRYLNS1Y0fvKu2dHDm85maIRjmZEzkpFJSj+M2/k9s3RYk 74topaYSzpLVzZWprh3rOaVUo5Y5CnMaY6gP+KDKbl95PCoFLEDdR1weiaEQT0o4lU ZU/DSw/0qMA4w== Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 10:14:04 -0000 Hi, I THINK, but am not sure, that the tools team has made it possible for a WG to use subversion or another SCCS so editors can simultaneously edit shared WG drafts. I have asked Tero, but have not yet gotten a reply. Henrick is on vacation. My sources are in a BOX location, in the cloud, so I can share the document with a list of other editors. I think the best approach would be having the editors of the other documents, the documents that will use the terminology, maintain the terminology draft jointly. That way, we ar enot adding a delay in processing having to wait for somebody else to update the document so we can reference it. We have a rather tight deadline, and adding unnecessary delay could hurt meeting our deadlines. I am sure we can find work for those who want to volunteer, but I think inserting them into the critical path would be a mistake. We can add them to the editing team for the terminology doc, but what terminology would they add that wasn't driven by usage in the other documents? We don't need terminology for the sake of terminology; we need terminology needed by the other docs. The editors of the other docs are in the best position to know what that is. These volunteers can review the drafts and the terminology draft and find terms we have not yet included. They can open debates about whether the terminology we have is appropriate/accurate, and so on. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 8/11/13 4:00 AM, "Adam Montville" wrote: >David, > >Thanks for putting this together. I know that, if the WG decides to >adopt the draft, there are at least two individuals interested in >maintaining it, so you wouldn't necessarily have to. > >I know the draft doesn't *need* more than one editor, but it could be >good to have two to handle reaction time (i.e. when a new term is needed, >the draft can be updated quickly). Anyone have thoughts on this? > >Regards, > >Adam > >________________________________________ >From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of David >Harrington [ietfdbh@comcast.net] >Sent: Saturday, August 10, 2013 8:58 AM >To: sacm@ietf.org >Subject: [sacm] FW: New Version Notification for >draft-dbh-sacm-terminology-00.txt > >Hi, > >I cut the terminology from use-cases and created a terminology doc. >This is an individual draft; the WG will need to decide whether to accept >it as a wg draft to start the wg's terminology doc. > > >-- >David Harrington >Ietfdbh@comcast.net >+1-603-828-1401 > > > > > >On 8/10/13 3:11 PM, "internet-drafts@ietf.org" >wrote: > >> >>A new version of I-D, draft-dbh-sacm-terminology-00.txt >>has been successfully submitted by David Waltermire and posted to the >>IETF repository. >> >>Filename: draft-dbh-sacm-terminology >>Revision: 00 >>Title: Terminology for Security Assessment >>Creation date: 2013-08-10 >>Group: Individual Submission >>Number of pages: 7 >>URL: >>http://www.ietf.org/internet-drafts/draft-dbh-sacm-terminology-00.txt >>Status: >>http://datatracker.ietf.org/doc/draft-dbh-sacm-terminology >>Htmlized: http://tools.ietf.org/html/draft-dbh-sacm-terminology-00 >> >> >>Abstract: >> This memo documents terminology used in the documents produced by the >> SACM WG (Security Automation and Continuous Monitoring). >> >> >> >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>The IETF Secretariat >> > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm > >... >This message and attachments may contain confidential information. If it >appears that this message was sent to you by mistake, any retention, >dissemination, distribution or copying of this message and attachments is >strictly prohibited. Please notify the sender immediately and permanently >delete the message and any attachments. > >. . . From shanna@juniper.net Sun Aug 11 04:19:03 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BD421F9E3F for ; Sun, 11 Aug 2013 04:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.381 X-Spam-Level: X-Spam-Status: No, score=-104.381 tagged_above=-999 required=5 tests=[AWL=2.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjTCt5XxmrEu for ; Sun, 11 Aug 2013 04:18:50 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFFA21F9E28 for ; Sun, 11 Aug 2013 04:13:22 -0700 (PDT) Received: from mail164-tx2-R.bigfish.com (10.9.14.228) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.22; Sun, 11 Aug 2013 11:13:21 +0000 Received: from mail164-tx2 (localhost [127.0.0.1]) by mail164-tx2-R.bigfish.com (Postfix) with ESMTP id 90A8D60164; Sun, 11 Aug 2013 11:13:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I936eI148cI542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah1de096h8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail164-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(479174003)(51704005)(377454003)(199002)(189002)(377424004)(52604005)(24454002)(77096001)(56776001)(74876001)(77982001)(19580395003)(47736001)(16406001)(49866001)(76786001)(76796001)(80976001)(19580385001)(83322001)(76576001)(19580405001)(56816003)(74662001)(74366001)(4396001)(54316002)(81686001)(59766001)(33646001)(51856001)(63696002)(80022001)(69226001)(81342001)(83072001)(74502001)(54356001)(79102001)(47446002)(65816001)(74706001)(47976001)(66066001)(50986001)(76482001)(46102001)(74316001)(81542001)(15202345003)(53806001)(31966008)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB056; H:BLUPR05MB053.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail164-tx2 (localhost.localdomain [127.0.0.1]) by mail164-tx2 (MessageSwitch) id 1376219599335232_19232; Sun, 11 Aug 2013 11:13:19 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.232]) by mail164-tx2.bigfish.com (Postfix) with ESMTP id 4421D260041; Sun, 11 Aug 2013 11:13:19 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 11 Aug 2013 11:13:18 +0000 Received: from BLUPR05MB056.namprd05.prod.outlook.com (10.255.210.151) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sun, 11 Aug 2013 11:13:18 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) by BLUPR05MB056.namprd05.prod.outlook.com (10.255.210.151) with Microsoft SMTP Server (TLS) id 15.0.731.16; Sun, 11 Aug 2013 11:13:16 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.169]) by BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.173]) with mapi id 15.00.0731.000; Sun, 11 Aug 2013 11:13:16 +0000 From: Stephen Hanna To: David Harrington , Adam Montville , "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt Thread-Index: AQHOlnuNfXlN7mgKLk2FXwNugdL4fJmP2o6w Date: Sun, 11 Aug 2013 11:13:15 +0000 Message-ID: References: <05BCCEB107AF88469B9F99783D47C1D6791142@CISEXCHANGE1.msisac.org.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09352FD734 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 11:19:04 -0000 +1 Steve > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > David Harrington > Sent: Sunday, August 11, 2013 6:06 AM > To: Adam Montville; sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm- > terminology-00.txt >=20 > Hi, >=20 > I THINK, but am not sure, that the tools team has made it possible for > a > WG to use subversion or another SCCS so editors can simultaneously edit > shared WG drafts. > I have asked Tero, but have not yet gotten a reply. Henrick is on > vacation. > My sources are in a BOX location, in the cloud, so I can share the > document with a list of other editors. >=20 >=20 > I think the best approach would be having the editors of the other > documents, the documents that will use the terminology, maintain the > terminology draft jointly. > That way, we ar enot adding a delay in processing having to wait for > somebody else to update the document so we can reference it. > We have a rather tight deadline, and adding unnecessary delay could > hurt > meeting our deadlines. >=20 > I am sure we can find work for those who want to volunteer, but I think > inserting them into the critical path would be a mistake. > We can add them to the editing team for the terminology doc, but what > terminology would they add that wasn't driven by usage in the other > documents? > We don't need terminology for the sake of terminology; we need > terminology > needed by the other docs. > The editors of the other docs are in the best position to know what > that > is. >=20 > These volunteers can review the drafts and the terminology draft and > find > terms we have not yet included. > They can open debates about whether the terminology we have is > appropriate/accurate, and so on. >=20 > -- > David Harrington > Ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 >=20 >=20 >=20 > On 8/11/13 4:00 AM, "Adam Montville" > wrote: >=20 > >David, > > > >Thanks for putting this together. I know that, if the WG decides to > >adopt the draft, there are at least two individuals interested in > >maintaining it, so you wouldn't necessarily have to. > > > >I know the draft doesn't *need* more than one editor, but it could be > >good to have two to handle reaction time (i.e. when a new term is > needed, > >the draft can be updated quickly). Anyone have thoughts on this? > > > >Regards, > > > >Adam > > > >________________________________________ > >From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of David > >Harrington [ietfdbh@comcast.net] > >Sent: Saturday, August 10, 2013 8:58 AM > >To: sacm@ietf.org > >Subject: [sacm] FW: New Version Notification for > >draft-dbh-sacm-terminology-00.txt > > > >Hi, > > > >I cut the terminology from use-cases and created a terminology doc. > >This is an individual draft; the WG will need to decide whether to > accept > >it as a wg draft to start the wg's terminology doc. > > > > > >-- > >David Harrington > >Ietfdbh@comcast.net > >+1-603-828-1401 > > > > > > > > > > > >On 8/10/13 3:11 PM, "internet-drafts@ietf.org" drafts@ietf.org> > >wrote: > > > >> > >>A new version of I-D, draft-dbh-sacm-terminology-00.txt > >>has been successfully submitted by David Waltermire and posted to the > >>IETF repository. > >> > >>Filename: draft-dbh-sacm-terminology > >>Revision: 00 > >>Title: Terminology for Security Assessment > >>Creation date: 2013-08-10 > >>Group: Individual Submission > >>Number of pages: 7 > >>URL: > >>http://www.ietf.org/internet-drafts/draft-dbh-sacm-terminology-00.txt > >>Status: > >>http://datatracker.ietf.org/doc/draft-dbh-sacm-terminology > >>Htmlized: http://tools.ietf.org/html/draft-dbh-sacm- > terminology-00 > >> > >> > >>Abstract: > >> This memo documents terminology used in the documents produced by > the > >> SACM WG (Security Automation and Continuous Monitoring). > >> > >> > >> > >> > >> > >>Please note that it may take a couple of minutes from the time of > >>submission > >>until the htmlized version and diff are available at tools.ietf.org. > >> > >>The IETF Secretariat > >> > > > > > >_______________________________________________ > >sacm mailing list > >sacm@ietf.org > >https://www.ietf.org/mailman/listinfo/sacm > > > >... > >This message and attachments may contain confidential information. If > it > >appears that this message was sent to you by mistake, any retention, > >dissemination, distribution or copying of this message and attachments > is > >strictly prohibited. Please notify the sender immediately and > permanently > >delete the message and any attachments. > > > >. . . >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From Adam.Montville@cisecurity.org Sun Aug 11 06:41:12 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181A921F8793 for ; Sun, 11 Aug 2013 06:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.743 X-Spam-Level: X-Spam-Status: No, score=-2.743 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLGj2VI-GIO0 for ; Sun, 11 Aug 2013 06:41:07 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.15]) by ietfa.amsl.com (Postfix) with ESMTP id 29B6D21F9F1B for ; Sun, 11 Aug 2013 06:33:58 -0700 (PDT) Received: from [216.82.250.19:38255] by server-15.bemta-12.messagelabs.com id F2/D1-03788-4C297025; Sun, 11 Aug 2013 13:33:56 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-9.tower-87.messagelabs.com!1376228034!16755905!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 313 invoked from network); 11 Aug 2013 13:33:55 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-9.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 11 Aug 2013 13:33:55 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([fe80::b899:f128:212e:984c%13]) with mapi id 14.02.0342.003; Sun, 11 Aug 2013 09:33:51 -0400 From: Adam Montville To: David Harrington , "sacm@ietf.org" Thread-Topic: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt Thread-Index: AQHOlnp0ywm+A6w1RkKJ+kDMhln2SJmP/+8A Date: Sun, 11 Aug 2013 13:33:51 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D67911C5@CISEXCHANGE1.msisac.org.local> References: <05BCCEB107AF88469B9F99783D47C1D6791142@CISEXCHANGE1.msisac.org.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 13:41:12 -0000 A couple of comments inline. The bottom line is that the WG needs to work= effectively and the WG is in the best position to determine how that look= s. > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Sunday, August 11, 2013 3:07 AM > To: Adam Montville; sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm- > terminology-00.txt >=20 > Hi, >=20 > I THINK, but am not sure, that the tools team has made it possible for a= WG > to use subversion or another SCCS so editors can simultaneously edit sha= red > WG drafts. > I have asked Tero, but have not yet gotten a reply. Henrick is on vacati= on. > My sources are in a BOX location, in the cloud, so I can share the docum= ent > with a list of other editors. >=20 >=20 > I think the best approach would be having the editors of the other > documents, the documents that will use the terminology, maintain the > terminology draft jointly. > That way, we ar enot adding a delay in processing having to wait for > somebody else to update the document so we can reference it. > We have a rather tight deadline, and adding unnecessary delay could hurt= > meeting our deadlines. The way I was looking at this is that terms are likely to be discussed on = this list before they're added to and defined in a draft and it seems most= critical to have the use cases, requirements, and architecture drafts unh= indered by their respective authors/editors needing to maintain or co-main= tain a tangential draft. =20 >=20 > I am sure we can find work for those who want to volunteer, but I think > inserting them into the critical path would be a mistake. While all of this is somewhat academic, I think the terminology draft itse= lf should not be in the critical path at all. Instead, the terminology dr= aft should be something that "falls out" of the others and does not hinder= forward progress. > We can add them to the editing team for the terminology doc, but what > terminology would they add that wasn't driven by usage in the other > documents? > We=20don't need terminology for the sake of terminology; we need > terminology needed by the other docs. > The editors of the other docs are in the best position to know what that= is. >=20 > These volunteers can review the drafts and the terminology draft and fin= d > terms we have not yet included. > They can open debates about whether the terminology we have is > appropriate/accurate, and so on. >=20 > -- > David Harrington > Ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 >=20 >=20 >=20 > On 8/11/13 4:00 AM, "Adam Montville" > wrote: >=20 > >David, > > > >Thanks for putting this together. I know that, if the WG decides to > >adopt the draft, there are at least two individuals interested in > >maintaining it, so you wouldn't necessarily have to. > > > >I know the draft doesn't *need* more than one editor, but it could be > >good to have two to handle reaction time (i.e. when a new term is > >needed, the draft can be updated quickly). Anyone have thoughts on thi= s? > > > >Regards, > > > >Adam > > > >________________________________________ > >From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of David > >Harrington [ietfdbh@comcast.net] > >Sent: Saturday, August 10, 2013 8:58 AM > >To: sacm@ietf.org > >Subject: [sacm] FW: New Version Notification for > >draft-dbh-sacm-terminology-00.txt > > > >Hi, > > > >I cut the terminology from use-cases and created a terminology doc. > >This is an individual draft; the WG will need to decide whether to > >accept it as a wg draft to start the wg's terminology doc. > > > > > >-- > >David Harrington > >Ietfdbh@comcast.net > >+1-603-828-1401 > > > > > > > > > > > >On 8/10/13 3:11 PM, "internet-drafts@ietf.org" > > > >wrote: > > > >> > >>A new version of I-D, draft-dbh-sacm-terminology-00.txt has been > >>successfully submitted by David Waltermire and posted to the IETF > >>repository. > >> > >>Filename: draft-dbh-sacm-terminology > >>Revision: 00 > >>Title: Terminology for Security Assessment > >>Creation date: 2013-08-10 > >>Group: Individual Submission > >>Number of pages: 7 > >>URL: > >>http://www.ietf.org/internet-drafts/draft-dbh-sacm-terminology-00.txt > >>Status: > >>http://datatracker.ietf.org/doc/draft-dbh-sacm-terminology > >>Htmlized: http://tools.ietf.org/html/draft-dbh-sacm-terminology= -00 > >> > >> > >>Abstract: > >> This memo documents terminology used in the documents produced by > the > >> SACM WG (Security Automation and Continuous Monitoring). > >> > >> > >> > >> > >> > >>Please note that it may take a couple of minutes from the time of > >>submission until the htmlized version and diff are available at > >>tools.ietf.org. > >> > >>The IETF Secretariat > >> > > > > > >_______________________________________________ > >sacm mailing list > >sacm@ietf.org > >https://www.ietf.org/mailman/listinfo/sacm > > > >... > >This message and attachments may contain confidential information. If > >it appears that this message was sent to you by mistake, any retention,= > >dissemination, distribution or copying of this message and attachments > >is strictly prohibited. Please notify the sender immediately and > >permanently delete the message and any attachments. > > > >. . . >=20 >=20 >=20 > ... . . . From lnunez@c3isecurity.com Sun Aug 11 15:46:44 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139C421F9AA1 for ; Sun, 11 Aug 2013 15:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oWTMkuTj2+Y for ; Sun, 11 Aug 2013 15:46:39 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6A821F9017 for ; Sun, 11 Aug 2013 15:40:14 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id u12so3082962qcx.35 for ; Sun, 11 Aug 2013 15:40:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=y94hvkJZeC63tf9NY9rdgfwNTJdwMyE0O9MpHhnQwKk=; b=U6R9EuXT0q1mMXZNU/s6ZV40sYBH2dO4rFniHLbYyMzHeTg1+O/UQKNHu3sOPK/TI/ 9pOdiO1FwWocXr4wBo9KypJhb3fwX3fGo+dajQ5/bz1mTTVYXcFgedHYExNCmCIvOoOl ymQk3fZO5awkvgK5LZaL0R1WTo8KB21WeJy1wnquOsL93xXr2WRf5rsDFyu7ZLYw6Vi4 dTFNCy0nrQf2H4co8sEeod01nO9uJ2XO5MKp0CpLuSI2mWvdteeAxxzA8B5HLoSLhMug bIP958gibSbp5o8/vflEuG4chujlCnvnK3IEjpoqaPTciNOTcr9qRoNseSuixVdgoiA0 urRA== X-Gm-Message-State: ALoCoQl3S1QgVb0XDMC8Rz+zUP/WkDhm/CWTr9FgFs4y5fwrqDDBFJXz49fiRthyU22NZEvNOMI5 X-Received: by 10.49.109.37 with SMTP id hp5mr11122585qeb.59.1376260813769; Sun, 11 Aug 2013 15:40:13 -0700 (PDT) Received: from [192.168.2.88] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPSA id i1sm34071350qas.10.2013.08.11.15.40.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 11 Aug 2013 15:40:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Luis Nunez In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D67911C5@CISEXCHANGE1.msisac.org.local> Date: Sun, 11 Aug 2013 18:40:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05BCCEB107AF88469B9F99783D47C1D6791142@CISEXCHANGE1.msisac.org.local> <05BCCEB107AF88469B9F99783D47C1D67911C5@CISEXCHANGE1.msisac.org.local> To: Adam Montville X-Mailer: Apple Mail (2.1283) Cc: David Harrington , "sacm@ietf.org" Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 22:46:44 -0000 +1 on "I think the terminology draft itself should not be in the = critical path at all. Instead, the terminology draft should be = something that "falls out" of the others and does not hinder forward = progress." I believe the terminology doc will evolve as we get consensus on the use = cases and requirements. With that I think we will eventually need the = following definitions: - Vulnerability - Remediation - Mitigation -ln =20 On Aug 11, 2013, at 9:33 AM, Adam Montville wrote: > A couple of comments inline. The bottom line is that the WG needs to = work effectively and the WG is in the best position to determine how = that looks. >=20 >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net] >> Sent: Sunday, August 11, 2013 3:07 AM >> To: Adam Montville; sacm@ietf.org >> Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm- >> terminology-00.txt >>=20 >> Hi, >>=20 >> I THINK, but am not sure, that the tools team has made it possible = for a WG >> to use subversion or another SCCS so editors can simultaneously edit = shared >> WG drafts. >> I have asked Tero, but have not yet gotten a reply. Henrick is on = vacation. >> My sources are in a BOX location, in the cloud, so I can share the = document >> with a list of other editors. >>=20 >>=20 >> I think the best approach would be having the editors of the other >> documents, the documents that will use the terminology, maintain the >> terminology draft jointly. >> That way, we ar enot adding a delay in processing having to wait for >> somebody else to update the document so we can reference it. >> We have a rather tight deadline, and adding unnecessary delay could = hurt >> meeting our deadlines. >=20 > The way I was looking at this is that terms are likely to be discussed = on this list before they're added to and defined in a draft and it seems = most critical to have the use cases, requirements, and architecture = drafts unhindered by their respective authors/editors needing to = maintain or co-maintain a tangential draft. =20 >=20 >>=20 >> I am sure we can find work for those who want to volunteer, but I = think >> inserting them into the critical path would be a mistake. >=20 > While all of this is somewhat academic, I think the terminology draft = itself should not be in the critical path at all. Instead, the = terminology draft should be something that "falls out" of the others and = does not hinder forward progress. >=20 >> We can add them to the editing team for the terminology doc, but what >> terminology would they add that wasn't driven by usage in the other >> documents? >> We don't need terminology for the sake of terminology; we need >> terminology needed by the other docs. >> The editors of the other docs are in the best position to know what = that is. >>=20 >> These volunteers can review the drafts and the terminology draft and = find >> terms we have not yet included. >> They can open debates about whether the terminology we have is >> appropriate/accurate, and so on. >>=20 >> -- >> David Harrington >> Ietfdbh@comcast.net >> +1-603-828-1401 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 8/11/13 4:00 AM, "Adam Montville" >> wrote: >>=20 >>> David, >>>=20 >>> Thanks for putting this together. I know that, if the WG decides to >>> adopt the draft, there are at least two individuals interested in >>> maintaining it, so you wouldn't necessarily have to. >>>=20 >>> I know the draft doesn't *need* more than one editor, but it could = be >>> good to have two to handle reaction time (i.e. when a new term is >>> needed, the draft can be updated quickly). Anyone have thoughts on = this? >>>=20 >>> Regards, >>>=20 >>> Adam >>>=20 >>> ________________________________________ >>> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of = David >>> Harrington [ietfdbh@comcast.net] >>> Sent: Saturday, August 10, 2013 8:58 AM >>> To: sacm@ietf.org >>> Subject: [sacm] FW: New Version Notification for >>> draft-dbh-sacm-terminology-00.txt >>>=20 >>> Hi, >>>=20 >>> I cut the terminology from use-cases and created a terminology doc. >>> This is an individual draft; the WG will need to decide whether to >>> accept it as a wg draft to start the wg's terminology doc. >>>=20 >>>=20 >>> -- >>> David Harrington >>> Ietfdbh@comcast.net >>> +1-603-828-1401 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 8/10/13 3:11 PM, "internet-drafts@ietf.org" >>> >>> wrote: >>>=20 >>>>=20 >>>> A new version of I-D, draft-dbh-sacm-terminology-00.txt has been >>>> successfully submitted by David Waltermire and posted to the IETF >>>> repository. >>>>=20 >>>> Filename: draft-dbh-sacm-terminology >>>> Revision: 00 >>>> Title: Terminology for Security Assessment >>>> Creation date: 2013-08-10 >>>> Group: Individual Submission >>>> Number of pages: 7 >>>> URL: >>>> = http://www.ietf.org/internet-drafts/draft-dbh-sacm-terminology-00.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-dbh-sacm-terminology >>>> Htmlized: = http://tools.ietf.org/html/draft-dbh-sacm-terminology-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> This memo documents terminology used in the documents produced by >> the >>>> SACM WG (Security Automation and Continuous Monitoring). >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of >>>> submission until the htmlized version and diff are available at >>>> tools.ietf.org. >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>>=20 >>> ... >>> This message and attachments may contain confidential information. = If >>> it appears that this message was sent to you by mistake, any = retention, >>> dissemination, distribution or copying of this message and = attachments >>> is strictly prohibited. Please notify the sender immediately and >>> permanently delete the message and any attachments. >>>=20 >>> . . . >>=20 >>=20 >>=20 >> ... >=20 > . . . > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From dbharrington@comcast.net Mon Aug 12 00:47:36 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6716321F96CA for ; Mon, 12 Aug 2013 00:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjpcB-YEEZ1b for ; Mon, 12 Aug 2013 00:47:31 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id C9DFE21F9A1F for ; Mon, 12 Aug 2013 00:35:42 -0700 (PDT) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta15.emeryville.ca.mail.comcast.net with comcast id BjbF1m0010EPchoAFjbaza; Mon, 12 Aug 2013 07:35:34 +0000 Received: from [10.121.21.189] ([195.50.158.227]) by omta01.emeryville.ca.mail.comcast.net with comcast id BjbD1m00J4ufcbF8MjbHUj; Mon, 12 Aug 2013 07:35:32 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Mon, 12 Aug 2013 09:35:12 +0200 From: David Harrington To: Luis Nunez , Adam Montville Message-ID: Thread-Topic: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376292934; bh=G/cccP1nbYu0Iqppt/vIlXwH5Ki/E6Mezx6p/Q7ycc0=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=J8qa4J4SV8vJu/UPF1v9QZWcBCh8Fd1zx83RMYqebwsliMRfBxpc5h14bZEbpOMHS YaPtYiNl4jySvyag7OYNzPOwA5vQsQaaSeNTY+k0QCgDS41vu42ADtyZm/yO6NMkQV TU6iH+Ya8+5YVrRvt5cP6rfz1EaWmpFBcy91Pej+cr/TSOd+2D0e8n1Myz4lMa44LM W/EhzydMXcpo6g0Ji2OyVDXn2L/bq1k+22SdVMk5FrFWIefbRoHVyd4LMGUGVkiBWs dr1IeNYj5Gxp9ZaBkYgeuqJkcCm5j/7B043Qam9ceWCm8O7ZRLw+VSqkKIcjFUpbwJ Wlh5uCKIAb3hA== Cc: David Harrington , "sacm@ietf.org" Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 07:47:36 -0000 Can you provide text, or better yet, a reference to an existing document that contains such definitions? -- David Harrington dbharrington@comcast.net +1-603-828-1401 On 8/12/13 12:40 AM, "Luis Nunez" wrote: >+1 on "I think the terminology draft itself should not be in the critical >path at all. Instead, the terminology draft should be something that >"falls out" of the others and does not hinder forward progress." > >I believe the terminology doc will evolve as we get consensus on the use >cases and requirements. With that I think we will eventually need the >following definitions: >- Vulnerability >- Remediation >- Mitigation > > >-ln > >On Aug 11, 2013, at 9:33 AM, Adam Montville wrote: > >> A couple of comments inline. The bottom line is that the WG needs to >>work effectively and the WG is in the best position to determine how >>that looks. >> >>> -----Original Message----- >>> From: David Harrington [mailto:ietfdbh@comcast.net] >>> Sent: Sunday, August 11, 2013 3:07 AM >>> To: Adam Montville; sacm@ietf.org >>> Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm- >>> terminology-00.txt >>> >>> Hi, >>> >>> I THINK, but am not sure, that the tools team has made it possible for >>>a WG >>> to use subversion or another SCCS so editors can simultaneously edit >>>shared >>> WG drafts. >>> I have asked Tero, but have not yet gotten a reply. Henrick is on >>>vacation. >>> My sources are in a BOX location, in the cloud, so I can share the >>>document >>> with a list of other editors. >>> >>> >>> I think the best approach would be having the editors of the other >>> documents, the documents that will use the terminology, maintain the >>> terminology draft jointly. >>> That way, we ar enot adding a delay in processing having to wait for >>> somebody else to update the document so we can reference it. >>> We have a rather tight deadline, and adding unnecessary delay could >>>hurt >>> meeting our deadlines. >> >> The way I was looking at this is that terms are likely to be discussed >>on this list before they're added to and defined in a draft and it seems >>most critical to have the use cases, requirements, and architecture >>drafts unhindered by their respective authors/editors needing to >>maintain or co-maintain a tangential draft. >> >>> >>> I am sure we can find work for those who want to volunteer, but I think >>> inserting them into the critical path would be a mistake. >> >> While all of this is somewhat academic, I think the terminology draft >>itself should not be in the critical path at all. Instead, the >>terminology draft should be something that "falls out" of the others and >>does not hinder forward progress. >> >>> We can add them to the editing team for the terminology doc, but what >>> terminology would they add that wasn't driven by usage in the other >>> documents? >>> We don't need terminology for the sake of terminology; we need >>> terminology needed by the other docs. >>> The editors of the other docs are in the best position to know what >>>that is. >>> >>> These volunteers can review the drafts and the terminology draft and >>>find >>> terms we have not yet included. >>> They can open debates about whether the terminology we have is >>> appropriate/accurate, and so on. >>> >>> -- >>> David Harrington >>> Ietfdbh@comcast.net >>> +1-603-828-1401 >>> >>> >>> >>> >>> >>> On 8/11/13 4:00 AM, "Adam Montville" >>> wrote: >>> >>>> David, >>>> >>>> Thanks for putting this together. I know that, if the WG decides to >>>> adopt the draft, there are at least two individuals interested in >>>> maintaining it, so you wouldn't necessarily have to. >>>> >>>> I know the draft doesn't *need* more than one editor, but it could be >>>> good to have two to handle reaction time (i.e. when a new term is >>>> needed, the draft can be updated quickly). Anyone have thoughts on >>>>this? >>>> >>>> Regards, >>>> >>>> Adam >>>> >>>> ________________________________________ >>>> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of David >>>> Harrington [ietfdbh@comcast.net] >>>> Sent: Saturday, August 10, 2013 8:58 AM >>>> To: sacm@ietf.org >>>> Subject: [sacm] FW: New Version Notification for >>>> draft-dbh-sacm-terminology-00.txt >>>> >>>> Hi, >>>> >>>> I cut the terminology from use-cases and created a terminology doc. >>>> This is an individual draft; the WG will need to decide whether to >>>> accept it as a wg draft to start the wg's terminology doc. >>>> >>>> >>>> -- >>>> David Harrington >>>> Ietfdbh@comcast.net >>>> +1-603-828-1401 >>>> >>>> >>>> >>>> >>>> >>>> On 8/10/13 3:11 PM, "internet-drafts@ietf.org" >>>> >>>> wrote: >>>> >>>>> >>>>> A new version of I-D, draft-dbh-sacm-terminology-00.txt has been >>>>> successfully submitted by David Waltermire and posted to the IETF >>>>> repository. >>>>> >>>>> Filename: draft-dbh-sacm-terminology >>>>> Revision: 00 >>>>> Title: Terminology for Security Assessment >>>>> Creation date: 2013-08-10 >>>>> Group: Individual Submission >>>>> Number of pages: 7 >>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-dbh-sacm-terminology-00.txt >>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-dbh-sacm-terminology >>>>> Htmlized: >>>>>http://tools.ietf.org/html/draft-dbh-sacm-terminology-00 >>>>> >>>>> >>>>> Abstract: >>>>> This memo documents terminology used in the documents produced by >>> the >>>>> SACM WG (Security Automation and Continuous Monitoring). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>> >>>>> The IETF Secretariat >>>>> >>>> >>>> >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>> >>>> ... >>>> This message and attachments may contain confidential information. If >>>> it appears that this message was sent to you by mistake, any >>>>retention, >>>> dissemination, distribution or copying of this message and attachments >>>> is strictly prohibited. Please notify the sender immediately and >>>> permanently delete the message and any attachments. >>>> >>>> . . . >>> >>> >>> >>> ... >> >> . . . >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From lnunez@mitre.org Mon Aug 12 05:02:28 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453DE21F9DA1 for ; Mon, 12 Aug 2013 05:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf9Sq+l+mluX for ; Mon, 12 Aug 2013 05:02:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 37F3B11E8117 for ; Mon, 12 Aug 2013 04:49:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A0CD51F0645; Mon, 12 Aug 2013 07:49:00 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7160C1F02F8; Mon, 12 Aug 2013 07:49:00 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.165]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0342.003; Mon, 12 Aug 2013 07:49:00 -0400 From: "Nunez, Luis K" To: David Harrington , Luis Nunez , Adam Montville Thread-Topic: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt Thread-Index: AQHOlzA5ZUsBB0hBE062F5eI1+grpZmRbz8w Date: Mon, 12 Aug 2013 11:48:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_023D_01CE9730.6465F170" MIME-Version: 1.0 Cc: David Harrington , "sacm@ietf.org" Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 12:02:28 -0000 ------=_NextPart_000_023D_01CE9730.6465F170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Here is a good reference from the NIST IR 7670 for vulnerability, remediation and misconfigurations. Mitigation is not listed and is something we could define. A vulnerability is an error, flaw, or mistake in computer software that permits or causes an unintended behavior or side effect to occur. A remediation is defined as a security-related set of actions that results in a change to a computer's state and may consist of changes motivated by the need to enforce organizational security policies, address discovered vulnerabilities, or correct misconfigurations. A misconfiguration is a configuration setting that violates organizational security policies, introduces a possible security weakness in a system, or permits or causes unintended behavior that may impact the security posture of a system. Reference: Waltermire, D., Johnson, C., Kerr, M., Wojcik, M., & Wunder, J. Proposed Open Specifications for Enterprise Information Security Remediation - Draft (NIST Interagency Report 7670). NIST, 2011 http://csrc.nist.gov/publications/drafts/nistir-7670/Draft-NISTIR-7670_Feb20 11.pdf -ln -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of David Harrington Sent: Monday, August 12, 2013 3:35 AM To: Luis Nunez; Adam Montville Cc: David Harrington; sacm@ietf.org Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt Can you provide text, or better yet, a reference to an existing document that contains such definitions? -- David Harrington dbharrington@comcast.net +1-603-828-1401 On 8/12/13 12:40 AM, "Luis Nunez" wrote: >+1 on "I think the terminology draft itself should not be in the critical >path at all. Instead, the terminology draft should be something that >"falls out" of the others and does not hinder forward progress." > >I believe the terminology doc will evolve as we get consensus on the use >cases and requirements. With that I think we will eventually need the >following definitions: >- Vulnerability >- Remediation >- Mitigation > > >-ln > >On Aug 11, 2013, at 9:33 AM, Adam Montville wrote: > >> A couple of comments inline. The bottom line is that the WG needs to >>work effectively and the WG is in the best position to determine how >>that looks. >> >>> -----Original Message----- >>> From: David Harrington [mailto:ietfdbh@comcast.net] >>> Sent: Sunday, August 11, 2013 3:07 AM >>> To: Adam Montville; sacm@ietf.org >>> Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm- >>> terminology-00.txt >>> >>> Hi, >>> >>> I THINK, but am not sure, that the tools team has made it possible for >>>a WG >>> to use subversion or another SCCS so editors can simultaneously edit >>>shared >>> WG drafts. >>> I have asked Tero, but have not yet gotten a reply. Henrick is on >>>vacation. >>> My sources are in a BOX location, in the cloud, so I can share the >>>document >>> with a list of other editors. >>> >>> >>> I think the best approach would be having the editors of the other >>> documents, the documents that will use the terminology, maintain the >>> terminology draft jointly. >>> That way, we ar enot adding a delay in processing having to wait for >>> somebody else to update the document so we can reference it. >>> We have a rather tight deadline, and adding unnecessary delay could >>>hurt >>> meeting our deadlines. >> >> The way I was looking at this is that terms are likely to be discussed >>on this list before they're added to and defined in a draft and it seems >>most critical to have the use cases, requirements, and architecture >>drafts unhindered by their respective authors/editors needing to >>maintain or co-maintain a tangential draft. >> >>> >>> I am sure we can find work for those who want to volunteer, but I think >>> inserting them into the critical path would be a mistake. >> >> While all of this is somewhat academic, I think the terminology draft >>itself should not be in the critical path at all. Instead, the >>terminology draft should be something that "falls out" of the others and >>does not hinder forward progress. >> >>> We can add them to the editing team for the terminology doc, but what >>> terminology would they add that wasn't driven by usage in the other >>> documents? >>> We don't need terminology for the sake of terminology; we need >>> terminology needed by the other docs. >>> The editors of the other docs are in the best position to know what >>>that is. >>> >>> These volunteers can review the drafts and the terminology draft and >>>find >>> terms we have not yet included. >>> They can open debates about whether the terminology we have is >>> appropriate/accurate, and so on. >>> >>> -- >>> David Harrington >>> Ietfdbh@comcast.net >>> +1-603-828-1401 >>> >>> >>> >>> >>> >>> On 8/11/13 4:00 AM, "Adam Montville" >>> wrote: >>> >>>> David, >>>> >>>> Thanks for putting this together. I know that, if the WG decides to >>>> adopt the draft, there are at least two individuals interested in >>>> maintaining it, so you wouldn't necessarily have to. >>>> >>>> I know the draft doesn't *need* more than one editor, but it could be >>>> good to have two to handle reaction time (i.e. when a new term is >>>> needed, the draft can be updated quickly). Anyone have thoughts on >>>>this? >>>> >>>> Regards, >>>> >>>> Adam >>>> >>>> ________________________________________ >>>> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of David >>>> Harrington [ietfdbh@comcast.net] >>>> Sent: Saturday, August 10, 2013 8:58 AM >>>> To: sacm@ietf.org >>>> Subject: [sacm] FW: New Version Notification for >>>> draft-dbh-sacm-terminology-00.txt >>>> >>>> Hi, >>>> >>>> I cut the terminology from use-cases and created a terminology doc. >>>> This is an individual draft; the WG will need to decide whether to >>>> accept it as a wg draft to start the wg's terminology doc. >>>> >>>> >>>> -- >>>> David Harrington >>>> Ietfdbh@comcast.net >>>> +1-603-828-1401 >>>> >>>> >>>> >>>> >>>> >>>> On 8/10/13 3:11 PM, "internet-drafts@ietf.org" >>>> >>>> wrote: >>>> >>>>> >>>>> A new version of I-D, draft-dbh-sacm-terminology-00.txt has been >>>>> successfully submitted by David Waltermire and posted to the IETF >>>>> repository. >>>>> >>>>> Filename: draft-dbh-sacm-terminology >>>>> Revision: 00 >>>>> Title: Terminology for Security Assessment >>>>> Creation date: 2013-08-10 >>>>> Group: Individual Submission >>>>> Number of pages: 7 >>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-dbh-sacm-terminology-00.txt >>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-dbh-sacm-terminology >>>>> Htmlized: >>>>>http://tools.ietf.org/html/draft-dbh-sacm-terminology-00 >>>>> >>>>> >>>>> Abstract: >>>>> This memo documents terminology used in the documents produced by >>> the >>>>> SACM WG (Security Automation and Continuous Monitoring). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>> >>>>> The IETF Secretariat >>>>> >>>> >>>> >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>> >>>> ... >>>> This message and attachments may contain confidential information. If >>>> it appears that this message was sent to you by mistake, any >>>>retention, >>>> dissemination, distribution or copying of this message and attachments >>>> is strictly prohibited. Please notify the sender immediately and >>>> permanently delete the message and any attachments. >>>> >>>> . . . >>> >>> >>> >>> ... >> >> . . . >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_023D_01CE9730.6465F170 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYMDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhQwggP8oAMCAQICCniCA1UAAgAAfAUwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMTExMzE3MzkyNloXDTE1MTExMzE3MzkyNlowSTEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGTAXBgNVBAMTEE51 bmV6Lkx1aXMuMzY3NzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDl6/nMS7S4cBZA DKe5BG/m7Wn4VOXR+dgLgiyQAW1l677SXcWUIFhqafYao7Gz1NU1IMI6ZamPTPTqLm9ZnkJFvuzA Up/zCUwLPx7UqYOXg7nPGXAYhtBSYJBhkA6g9snZUE7EJkhs0vMWEQcTL5nIxz6K9mpbFrrDJpd5 3QSbN1faAhzzisxZ5ae/K4NywtMMYy+9esABY7lAAPndOTnBIFVugl7PJOu5CTczOkc8Ehe8+tGo n6Nbg2sRuTjB2SSjpXb4Q9/Bu5/btOVt3PjEYzfnFyPwlVQap7rpXIWfXZgMyxCSE3G1zi3PINk8 A4Zhdb3xteI+ww5QG0gFXgtPAgMBAAGjggH1MIIB8TAoBgNVHSUEITAfBggrBgEFBQcDBAYJKwYB BAFzAgEHBggrBgEFBQcDAjAdBgNVHQ4EFgQUsV/rNMaTpZcnVSIWE2DHeDtceFAwDgYDVR0PAQH/ BAQDAgbAMBsGA1UdEQQUMBKBEGxudW5lekBtaXRyZS5vcmcwHwYDVR0jBBgwFoAUaWcgIdRIwdAb Bm7zCCjiOoJ9QTEwSQYDVR0fBEIwQDA+oDygOoY4aHR0cDovL3BraS5taXRyZS5vcmcvTUlUUkUl MjBDb3Jwb3JhdGlvbiUyMFBFJTIwQ0EtMS5jcmwwfwYIKwYBBQUHAQEEczBxMEcGCCsGAQUFBzAC hjtodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xKDIp LmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AubWl0cmUub3JnL29jc3AwPgYJKwYBBAGCNxUH BDEwLwYnKwYBBAGCNxUIg66sI4aOlleBjYk9gqSrEoW+rgGBNoPSl32HoPtJAgFkAgEHMBYGA1Ud IAQPMA0wCwYJKwYBBAFzAgEIMDQGCSsGAQQBgjcVCgQnMCUwCgYIKwYBBQUHAwQwCwYJKwYBBAFz AgEHMAoGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4ICAQC/CxyG0kzVtkRM38Fxc/Q5xjCb9BwN HqUPPCcLqOIiLhaj4NfB7QK05lR3/grisrYzpiP2T/tbKygPu2q6OoZxLxQ7z5Um8FM6I78lNw0+ p3tSOABG1rLINKha+4OQJXpmFtUtGz3Tm12/Ef0ju8RngjFiFBS4ucobnrv/EZvSx7VmtlTFOLRr Iua0Y8Jvm3y2zsC4Xnknd3YMf76mW4XFrpUloFATq1gSyzSeKfXSwVG1Z78MFjARMohCIU5N8HCe Kurc1KgoxO45mWnu7CpY+7JRQPbD1M8Vo1hRLF7EzvO6aPIDGyvjRUwNHgyv5RMJcNA8Gi2k5dkh UfSEHfz/TzqWaplFns0f0P5n17JuqiZZYThZuwYIbQOaDVi6scO2E54IDy/SnIoKgryx3lBa9VCy zCkWU7WuMuil28UL0kDOhAbiJf8k4jQ/cUr+RhuAqtNeCH43UUCC7SukY5XFfXZlO8iROil+aBIS 33xVhJ2VBFjO6/PEN327XrgA+sRhfJHaUJU2sECx+7QnlqOD7SKvt+GGQMKDZ2UbtBW3H9e6bIV9 2BjKw/xSyzajf/95UCA8xnbuHEg05wElah/BAJ8zgdnoqToPwdpeE2z2CG0xgqYoWxizA9wTKq6N hey/AJkNaHnR25ArUXN7CFh9WLLYbDfubSc/B3oi1/jwQDCCBmIwggRKoAMCAQICChSXFtIAAAAA AAQwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBD QS0xMB4XDTExMDYxNDE3NDQ0NFoXDTE3MDYxNDE3NTQ0NFowUDETMBEGCgmSJomT8ixkARkWA09S RzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBD QS0xMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA0sSvUV4nqnU8+CVkZETLPxDrhdD9 EvUm7KWnSyZMfyww52gMJgJ6n6ptZ+/6fNqFY8tcgsnt0mbuGKe35gyALVm5B72Dn8R5Eb9YaP34 WjTdGEZHeuaCSc9p4BGzWcXSIgqImpUH1/4llOwKUPqLymxVetL+RNKdpj53LNtDWEX7GnrXYZwW WxQ/X5Q3F8CakrxhhgX5u4nxQkdS67RHDSozMH+2BFmTtFZN2coVavpOyTSxGyr9Dnwc/A1PBohl Po/PEJa4BlvDy5MDZO57EvwyafGi7nU7laiBNggPZqp+UI1PxGWDRxs0nwq/v7rFJm6I8lUibpIY awF7KUQDM/gomt8ot6t8PE5wJY11jdXYcdYrlL+RscszI36itbTLglFNl8xjTaqFWtZqqJQYsg0w jq/XfyAtGB2DAUqUPsYtMfc41yreBZkJpBAGYBeIbGWanCWC/4gkIsIs/HxMlT2br6Fr3RFzqMxW AqZpE9DGQicMiLsdGeryaelS7Tf+q2YHNsueB5U66d4n2s5qbH65NzXR8ZWU2boPZIxCPrxKMqf+ /ZwD8k1kENTBD9BKwlmr/NPxzotDC8f+5SFH71To5DhYBW/og70eE90QEK5xKYEzvn3Oycs4fS6R Q6ptLJcAz+B4/XAtyM3RA+QVONzxgHvh6GfDg/9aL1YMKP8CAwEAAaOCAWMwggFfMBAGCSsGAQQB gjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBRQojrYGW/mXX5ZMObAtstNbFEGlTAdBgNVHQ4EFgQU aWcgIdRIwdAbBm7zCCjiOoJ9QTEwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQD AgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUW4d9n/5svgLp8+ApOopUJSyfOC8wUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL3BraS5taXRyZS5vcmcvTUlUUkUlMjBDb3Jwb3JhdGlvbiUy MFBFJTIwUm9vdCUyMENBLTEuY3JsMFsGCCsGAQUFBwEBBE8wTTBLBggrBgEFBQcwAoY/aHR0cDov L3BraS5taXRyZS5vcmcvTUlUUkUlMjBDb3Jwb3JhdGlvbiUyMFBFJTIwUm9vdCUyMENBLTEuY3J0 MA0GCSqGSIb3DQEBCwUAA4ICAQB5wz33WCsajTrQGFzMsnpfN1bPHAgwEGYUriAdHOhpBqBHRa5l h/acIuNlfeqwqe072zTSjSV21R3yVAKfrqsOutwy/7F133/WRcT8SjnT56QPHCjO0QR/XuN+zcN3 dvAOz2hmz+rV5kqoVwIWGeFNdstVOXDn9hv6YVKAADJZ1SXX5l8zGs7y6NkiHosQCcgs3uqx0ExU PzfoAI21bkSfh7PBRClczEsKpTaLqXthC6i+HTACk+j9PLAH8Ztkq0ZUL3Fj2L6jP9QtdG4HNrXb vlhs0bj+VsfWK9eSjvUluM+359kVRF0IKAw56ObwiHH1D7igeZ/irfXgQorbIEg/cmLDVDfSxFSL 4wG/DFdi1i34HtW7pqOoO0DEWuBYIn8ObIhsIu1dhGiUKOlACFb8SihQu1uKegpK2NoGtXexiENA z4lmTnszmpCVQMS+YH/t1nTbdIoCnP8i323R5+oQndSj4A6pEiq/M1jmSP44gwVvee8QJmjukHRk AwWa0B1qSFcEBsxeWxq6prNpKuPZd7eypgbtAv/bRMaigJpX+GOZX0BnQmykKQKu9dg1UB2Lg15l UBAHNr5SdQuYUtyMPQ8AVk3yeL8gePG7oQYWyIT4hbWuTos15SnLCIvfYpANcomcfwwbY2sOCVOq ic1lBQdnnMhgjT7TW2I1EQNAPTCCBn0wggRloAMCAQICCniCAd4AAgAAfAQwDQYJKoZIhvcNAQEF BQAwUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQD ExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMTExMzE3MzkyNloXDTE1MTExMzE3Mzky NlowSTELMAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxGTAXBgNV BAMTEE51bmV6Lkx1aXMuMzY3NzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDH0jmx J6Z/B/QJgS3AdKVc8cYrQ37qZP640qp42ASnLrvjjWPD2zv5ZOgxxyZ1JAwxUhQzQSBIC8nP+VOV 01h45E84FgNWj2MMp9/CS5TBKzSi6eG0a6BRx2DLRrzsnYVpUWb9OAVZG2FopSlsNmEJNJxyD5v1 EnBRPJXt120yDyDKLE0Wz1X+Pf0wq3xia/tnyy32hzZYrV/myYiEzs460MROur0157bL4d8SQ7Gw TlbBuHrjQBTysXr6wL/1QCS2FRYpiaLC5+fuELQ2yoRN/n7x5KY+eas7ap8aMQQMa8WZ+d6aub6h 1WcAZU2apYs034GFupKz4SmsDPlBCxuXAgMBAAGjggJeMIICWjATBgNVHSUEDDAKBggrBgEFBQcD BDCBlAYJKoZIhvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYF Kw4DAgcwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQMEARYw CwYJYIZIAWUDBAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFGORBI+1DaO/ W0YdePSU5240ZEyMMA4GA1UdDwEB/wQEAwIFIDAbBgNVHREEFDASgRBsbnVuZXpAbWl0cmUub3Jn MB8GA1UdIwQYMBaAFGlnICHUSMHQGwZu8wgo4jqCfUExMEkGA1UdHwRCMEAwPqA8oDqGOGh0dHA6 Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEuY3JsMH8GCCsG AQUFBwEBBHMwcTBHBggrBgEFBQcwAoY7aHR0cDovL3BraS5taXRyZS5vcmcvTUlUUkUlMjBDb3Jw b3JhdGlvbiUyMFBFJTIwQ0EtMSgyKS5jcnQwJgYIKwYBBQUHMAGGGmh0dHA6Ly9vY3NwLm1pdHJl Lm9yZy9vY3NwMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIOurCOGjpZXgY2JPYKkqxKFvq4B gTaGq5JohKjsRQIBZAIBDzAWBgNVHSAEDzANMAsGCSsGAQQBcwIBCDAbBgkrBgEEAYI3FQoEDjAM MAoGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4ICAQC8CcNFMKiKkMlvM1OEgE2GvFvO9t6qst3d /7R/iP3zpIcS+DFH+MuUMfNab5PanDuaAys7Yb1HkbkpkW4vcnwR01OIrpgOCKse31X6R9dEohVY 1A/YA/j/N7GdPMn87CMISlsYIodQRjt45h6psCaYvURKbDwr9x72sZTKY8wF149Vw5nOQk0/1exU 4ND+mlPbPSbnh4yWsr9ZBg4yvO2EEXisfmxC6FaQGSPCamwgmASmX8T1R4BWEbdSiNCxaR8KIUGz q88AWOeIhiWCiWcyGsgy2/l2veqNKzSGBOXr+TiEa9iswvrUvplbH4UhVxOBt38LuixGBtF+KxCg YgsF9+O8McfCEAgFQYVGtHOgRPjxRucKCSPDm1NCjaM6hmK67euB4VRHQHE3RzfmE3UzQM7WwZVW xvIAnRko6qCW2JzIFnYt0OyIV99NCVJVqAplp1TCk0QEQcD81mzLEczqTNu2R3qlFXznhUZIYZWD 2HuNfU4TUHem/Syyi4QDLLAdUO+86Zg7vmKqiQXrBeHoPAOGI0WLURtCaja7vGagbuJNnKE3RbqC TpdieqnghfOOChXVw9BHrlmCxE70ejLeoVMT+q/nTRwa/PjJuuUU1yDuKiZ+SYhRQG+6jyTbG0Bi IWpIx4rA5CVLVHec+4m97IDrNUdZQvjh08wE12UUujGCAyMwggMfAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3Jh dGlvbiBQRSBDQS0xAgp4ggNVAAIAAHwFMAkGBSsOAwIaBQCgggGaMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgxMjExNDg1M1owIwYJKoZIhvcNAQkEMRYEFGOq drKusgmXEhromoIDpJZCh5YtMFsGCSqGSIb3DQEJDzFOMEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMG0G CSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1J VFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgp4ggHeAAIAAHwEMG8GCyqG SIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlU UkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTECCniCAd4AAgAAfAQwDQYJKoZI hvcNAQEBBQAEggEAaDQoBgQNypUM2Cbeej87Icp5MR2oZQLu4kQOkBC19iXyau93yHQz0dv0Y4nM EebYZaEs5NKhKEZwSvvxS/s3qhneYfiHx84k630WwCYe+4P10yDrLtIJPJToGkU9PtXhJFwyLw4V FKnkK4yXXCBlYee2sMNysym/ygkkTMLxi2sDKNY82JxXm47bqo5ED0Ybovt34ynqsUGxlP7gZkGw kpTT78fQTxkZ9A2sVauro9JUd7NZfPeutZ0TJ55vnaXvz6/LOs3ZvzzvrXW+FCmRTPGCbmJsu4mg nUS8MHOeDVyjx9AK6a6Yv9qs8p8W15r+uvHW1UQRwrg0yMq20f7mXwAAAAAAAA== ------=_NextPart_000_023D_01CE9730.6465F170-- From inacio@cert.org Tue Aug 13 09:03:19 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A2321E80C3 for ; Tue, 13 Aug 2013 09:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEROEd8E8Lnm for ; Tue, 13 Aug 2013 09:03:16 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id D955D11E8187 for ; Tue, 13 Aug 2013 09:03:15 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7DG3BhP029385; Tue, 13 Aug 2013 12:03:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1376409791; bh=dla2EtDt3NGe5oPh5/ORhoTZTzhR+EYU8ksXlgL9Xdw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=dsu29g5apkgCBgx5NKIi95PMFKTK49RtZ1gcpz1ZPGQxG42l4GkqmPjBd35DszTpw A47JwxG8kYFoUTzt4qtBmfllSJ/Hr4MAChX9OjOpwmIMv2KwkC1bb+OwJox3KbVBQx 9LYQX3fpdKpl2/qElqCvY4sGl8e9L7mktWNudlWo= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7DG3KTL020927; Tue, 13 Aug 2013 12:03:21 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 12:03:11 -0400 From: Chris Inacio To: Joe Marcus Clarke Thread-Topic: [sacm] Feedback on vulnerability management use case Thread-Index: AQHOj+BS7Qmkha6vB0q7G2752tLnJJmToIMA Date: Tue, 13 Aug 2013 16:03:10 +0000 Message-ID: <4AE532C8B0B4B548AF47570D250D81741421ACB5@marathon> References: <51FC4E85.8010501@cisco.com> In-Reply-To: <51FC4E85.8010501@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.51.92] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:03:20 -0000 On Aug 2, 2013, at 8:27 PM, Joe Marcus Clarke wrote: > After talking with Eliot today after the WG meeting, I think my comments > regarding vulnerability management were unclear. I'd like to clarify > and still see if people think this is out of scope. >=20 > I am not asking to standardize vulnerability assessment per se (meaning > standardize IPS signatures). What I am asking is whether or not SACM > needs to define a new (or standardize an existing) data model to > describe a vulnerability for purposes of efficient interchange? >=20 > My argument for "yes" is that if I am to learn about things like device > type, hardware version, software version, place in network, > configuration, etc. how can I effectively build a policy around security > posture if I do not know what vulnerabilities exist? If we have a way > to exchange descriptions of vulnerabilities, it would enable consistent > communication to a vulnerability repository as described in the charter. > To me, this directly goes towards posture assessment. >=20 > I don't see this as being in scope for MILE, so I wonder if this is out > of scope for SACM, would SACM disregard this type of model, point to an > existing, non-IETF model, look to tackle this in a future re-charter, or > ...? >=20 > Joe >=20 > --=20 > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > -------------------------------------------------------------------------= --- > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm Joe, Let me attempt to inject a little more context, and you can tell me if I'm = off track, because I'm trying to understand your original comments. Is what you are looking to accomplish is a little more complex than just sa= ying "X has vulnerability Y" such that you can understand that "Windows Se= rver 2008 R2 has a *remotely exploitable* software vulnerability on port 12= 345" such that you can include within the framework a mitigation that might= include say putting a Cisco :) firewall in front of said Windows Server in= the network to remediate the said vulnerability? So that SACM supports no= t just saying "patch X with software level N+1", but that "Vuln Y on X is m= itigated by device P"? Is that the intent? I like the idea of the generic IDS/IPS language though=85 :)=20 -- Chris Inacio inacio@cert.org From inacio@cert.org Tue Aug 13 09:04:32 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38A021F9D9B for ; Tue, 13 Aug 2013 09:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7LkET8BHS0u for ; Tue, 13 Aug 2013 09:04:17 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id A846D11E80A2 for ; Tue, 13 Aug 2013 09:04:09 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7DG47sf018623; Tue, 13 Aug 2013 12:04:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1376409847; bh=7w074BPjxy3pn3KZ7A44f7vnnQGf2m/0+9dFDfepCH0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=UFgcojtezQ0p3rbcusNoOcqWlZs0hGRRK9rAUh2Z7COOYshzpME2eWjqpzMBZjSRw Z9K4abSMheIR/iTmuKlaSL25HQ7ieO5EhUyCTgaJrrbvvz62m2p06xikTDjWRvsVq/ IQSI05GNX3S9VAWS2EEDBWkxpOyaxNySRXJMjQYg= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7DG4G4q021012; Tue, 13 Aug 2013 12:04:16 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 12:04:06 -0400 From: Chris Inacio To: "Romascanu, Dan (Dan)" Thread-Topic: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases Thread-Index: Ac6R849yIIsiER8oT9evwtziU7dGeQGbLQ4A Date: Tue, 13 Aug 2013 16:04:06 +0000 Message-ID: <4AE532C8B0B4B548AF47570D250D81741421ACD6@marathon> References: <9904FB1B0159DA42B0B887B7FA8119CA128A4113@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A4113@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.51.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C59D2CFF2EEB04E80F711F727B77B4A@sei.cmu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM - Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:04:32 -0000 +1 -- Chris Inacio inacio@cert.org On Aug 5, 2013, at 11:50 AM, "Romascanu, Dan (Dan)" wr= ote: >=20 > At the SACM WG meeting at IETF-88 the participants in the room did not ra= ise any objection on the proposal to adopt draft-waltermire-sacm-use-cases = as start point for WG I-D for use cases. We are asking the WG to confirm th= is consensus on the mail list. Please send all comments, questions and conc= erns to the SACM WG mail list before 8/15. >=20 > Thanks and Regards, >=20 > Adam and Dan >=20 >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From inacio@cert.org Tue Aug 13 09:07:51 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF3121E8119 for ; Tue, 13 Aug 2013 09:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeEw-WRIM1tY for ; Tue, 13 Aug 2013 09:07:41 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id A846121E80F0 for ; Tue, 13 Aug 2013 09:07:23 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7DG7IVa018752; Tue, 13 Aug 2013 12:07:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1376410038; bh=AWqC5XyjXp/cNqQOlE2HBOBPW0wRGI4keG/oq9RtBhc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=SAHK5jv70YQNIbgSL8w/KOehp3JIePnpAYa+AcxLUrdT4p6OFoSCNe0ey08rLWr4m ggjqm4xk0InW1ksYtJAxjV2C9zsj9mCWAFDBkkx2ru39yQpCXZG7jPEVxx3aQZhFAr y3OqS9GL+CE8OZG4Do44mO6YDek3RpTlLED2siqM= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7DG7GU5005670; Tue, 13 Aug 2013 12:07:17 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 12:07:16 -0400 From: Chris Inacio To: Adam Montville Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6SpHgZAWpvrX0vRxuTXCLSjTwOnwAE6OWwAWomTwA= Date: Tue, 13 Aug 2013 16:07:16 +0000 Message-ID: <4AE532C8B0B4B548AF47570D250D81741421AD59@marathon> References: <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> <05BCCEB107AF88469B9F99783D47C1D673CE82@CISEXCHANGE1.msisac.org.local> In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D673CE82@CISEXCHANGE1.msisac.org.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.51.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <9323AEB9755C444EB992B652BFCACB80@sei.cmu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Romascanu, Dan \(Dan\)" , "sacm@ietf.org" Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:07:52 -0000 On Aug 6, 2013, at 11:20 AM, Adam Montville = wrote: > As a contributor, I believe a separate document is a good idea. >=20 > As a chair, if we achieve rough consensus on this issue, we have someone = who is willing to be the author/maintainer of the document - not sure if th= at matters to anyone's decision-making process, but at least we know the do= cument would be supported. >=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Romascanu, Dan (Dan) >> Sent: Tuesday, August 06, 2013 5:58 AM >> To: sacm@ietf.org >> Subject: [sacm] SACM - consensus on defining SACM terminology in a >> separate document >>=20 >> At the SACM WG meeting at IETF-87 the participants in the room did not r= aise >> any objection to the proposal to separate the terminology section from >> draft-waltermire-sacm-use-cases and make of it a separate document that >> defines the SACM terms in one place and can be referred by all other SAC= M >> documents. We are asking the WG to confirm this consensus on the mail li= st. >> Please send all comments, questions and concerns to the SACM WG mail lis= t >> before 8/15. >>=20 >> Thanks and Regards, >>=20 >> Adam and Dan >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >>=20 >> ... >=20 > . . . > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm Can we set up some type of wiki that might allow multiple folks simultaneou= s editing so that people working on the various drafts that would depend on= this (use-cases, arch, requirements) can all work unimpeded? I know that it's crazy to suggest such collaborative technology, but we can= convert the content into an RFC at the appropriate time. Thoughts? But yes, it should be a separate document. -- Chris Inacio inacio@cert.org From eric.walker@us.ibm.com Tue Aug 13 09:31:52 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9E611E816D for ; Tue, 13 Aug 2013 09:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.63 X-Spam-Level: X-Spam-Status: No, score=-6.63 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvxdowoYkrRz for ; Tue, 13 Aug 2013 09:31:45 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCCA11E811F for ; Tue, 13 Aug 2013 09:31:44 -0700 (PDT) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 13 Aug 2013 12:31:44 -0400 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 13 Aug 2013 12:31:41 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 3E974C90081 for ; Tue, 13 Aug 2013 12:31:30 -0400 (EDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r7DGVUMZ180630 for ; Tue, 13 Aug 2013 12:31:30 -0400 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r7DGYDUt012250 for ; Tue, 13 Aug 2013 10:34:13 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.63.40.12]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r7DGYDsr012247; Tue, 13 Aug 2013 10:34:13 -0600 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <4AE532C8B0B4B548AF47570D250D81741421AD59@marathon> References: <4AE532C8B0B4B548AF47570D250D81741421AD59@marathon>, <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> <05BCCEB107AF88469B9F99783D47C1D673CE82@CISEXCHANGE1.msisac.org.local> From: Eric Walker To: Chris Inacio Message-ID: Date: Tue, 13 Aug 2013 10:31:24 -0600 X-Mailer: Lotus Domino Web Server Release 8.5.3FP2 ZX853FP2HF5 February, 2013 X-MIMETrack: Serialize by Notes Server on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/13/2013 10:31:24, Serialize complete at 08/13/2013 10:31:24, Itemize by Notes Server on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/13/2013 10:31:24, Serialize by Router on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/13/2013 10:31:25, Serialize complete at 08/13/2013 10:31:25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13081316-7182-0000-0000-000008124180 Cc: "Romascanu, Dan \(Dan\)" , Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:31:52 -0000
>Can we set up some type of wiki that might allow multiple f= olks
>simultaneous editing so that people working on the various dr= afts
>that would depend on this (use-cases, arch, requirements) can a= ll
>work unimpeded?

How about a Github repo?
=

Eric

= From kathleen.moriarty@emc.com Tue Aug 13 09:40:59 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C0711E8188 for ; Tue, 13 Aug 2013 09:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMSCFJJRQPcV for ; Tue, 13 Aug 2013 09:40:53 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0948911E8184 for ; Tue, 13 Aug 2013 09:40:52 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7DGeONp027180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Aug 2013 12:40:25 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 13 Aug 2013 12:40:14 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r7DGeDcs024837; Tue, 13 Aug 2013 12:40:13 -0400 Received: from mx15a.corp.emc.com ([169.254.1.99]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Tue, 13 Aug 2013 12:40:12 -0400 From: "Moriarty, Kathleen" To: Eric Walker , Chris Inacio Date: Tue, 13 Aug 2013 12:38:57 -0400 Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6YQotv7vfmgjsfSHiu0gxoxttQ6gAASX1a Message-ID: References: <4AE532C8B0B4B548AF47570D250D81741421AD59@marathon>, <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> <05BCCEB107AF88469B9F99783D47C1D673CE82@CISEXCHANGE1.msisac.org.local>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "Romascanu, Dan \(Dan\)" , Adam Montville , "sacm@ietf.org" Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:40:59 -0000 That has been done for other working groups where they can edit the documen= t and generate the updated draft in RFC format when ready for an update. -Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Eric Walke= r [eric.walker@us.ibm.com] Sent: Tuesday, August 13, 2013 12:31 PM To: Chris Inacio Cc: Romascanu, Dan (Dan); Adam Montville; sacm@ietf.org Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a sepa= rate document >Can we set up some type of wiki that might allow multiple folks >simultaneous editing so that people working on the various drafts >that would depend on this (use-cases, arch, requirements) can all >work unimpeded? How about a Github repo? Eric From eric.walker@us.ibm.com Tue Aug 13 09:42:15 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A71B11E819D for ; Tue, 13 Aug 2013 09:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.837 X-Spam-Level: X-Spam-Status: No, score=-7.837 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3EGMIAhWDOY for ; Tue, 13 Aug 2013 09:42:08 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by ietfa.amsl.com (Postfix) with ESMTP id E027111E819B for ; Tue, 13 Aug 2013 09:42:07 -0700 (PDT) Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 13 Aug 2013 10:42:07 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 13 Aug 2013 10:42:06 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id D415E1FF0043 for ; Tue, 13 Aug 2013 10:36:39 -0600 (MDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r7DGg5Uo100634 for ; Tue, 13 Aug 2013 10:42:05 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r7DGg3BF015059 for ; Tue, 13 Aug 2013 10:42:04 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.63.40.12]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r7DGg2Xq014771; Tue, 13 Aug 2013 10:42:02 -0600 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <4AE532C8B0B4B548AF47570D250D81741421ACB5@marathon> References: <4AE532C8B0B4B548AF47570D250D81741421ACB5@marathon>, <51FC4E85.8010501@cisco.com> From: Eric Walker To: Chris Inacio , Joe Marcus Clarke , "" Message-ID: Date: Tue, 13 Aug 2013 10:42:00 -0600 X-Mailer: Lotus Domino Web Server Release 8.5.3FP2 ZX853FP2HF5 February, 2013 X-MIMETrack: Serialize by Notes Server on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/13/2013 10:42:00, Serialize complete at 08/13/2013 10:42:01, Itemize by Notes Server on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/13/2013 10:42:01, Serialize by Router on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/13/2013 10:42:02, Serialize complete at 08/13/2013 10:42:02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13081316-7606-0000-0000-00000E4BEE85 Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:42:15 -0000
Hi,

It is easy to split hairs on the d= istinction between a "vulnerability," a "misconfiguration," a patch check, = and other, similar concepts.  There are good reasons for distinguishin= g these things -- a vulnerability can be addressed in any number of ways, e= .g., by removing the host from the network, by blocking a port in the firew= all, etc., so detecting or addressing a vulnerability is not always a simpl= e matter of applying a patch, updating software or toggling a security-rela= ted setting.

But we know from experience that many= vulnerabilities that go back to the state of an endpoint can be detected u= sing the same means that are used to detect deviations from security policy= or missing OS patches or out-of-date software.  I'm concerned that if= we make too fine a distinction between these different use cases, we'll se= t ourselves up for parallel standards that overlap in important ways.  = ;This is something to be avoided.

Eric
<= br>


>On Aug 2, 2013, at 8:27 PM,= Joe Marcus Clarke <jclarke@cisco.com>
>wrote:

[.= ..]

>> I am not asking to standardize vulnerability asse= ssment per se (meaning
>> standardize IPS signatures). What = I am asking is whether or not SACM
>> needs to define a new (= or standardize an existing) data model to
>> describe a vulnerabil= ity for purposes of efficient interchange?
>>
>> My argu= ment for "yes" is that if I am to learn about things like device
&g= t;> type, hardware version, software version, place in network,
>&= gt; configuration, etc. how can I effectively build a policy around se= curity
>> posture if I do not know what vulnerabilities exist? If= we have a way
>> to exchange descriptions of vulnerabilities= , it would enable consistent
>> communication to a vulnerabil= ity repository as described in the charter.
>> To me, this di= rectly goes towards posture assessment.
>>
>> I don't se= e this as being in scope for MILE, so I wonder if this is out
>&= gt; of scope for SACM, would SACM disregard this type of model, point = to an
>> existing, non-IETF model, look to tackle this in a future=  re-charter, or
>> ...?


= From michael.hammer@yaanatech.com Tue Aug 13 09:52:35 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC3211E81A4 for ; Tue, 13 Aug 2013 09:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35-OqMf40VZ7 for ; Tue, 13 Aug 2013 09:52:31 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3C111E81A7 for ; Tue, 13 Aug 2013 09:52:31 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 13 Aug 2013 09:52:30 -0700 From: Michael Hammer To: "kathleen.moriarty@emc.com" , "eric.walker@us.ibm.com" , "inacio@cert.org" Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6SpHgZAWpvrX0vRxuTXCLSjTwOnwAE6OWwAWomTwAAByEYAAAAQ4GAAA475TA= Date: Tue, 13 Aug 2013 16:52:29 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC27C53@EX2K10MB1.corp.yaanatech.com> References: <4AE532C8B0B4B548AF47570D250D81741421AD59@marathon>, <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> <05BCCEB107AF88469B9F99783D47C1D673CE82@CISEXCHANGE1.msisac.org.local>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.69] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0140_01CE9823.F791AE00" MIME-Version: 1.0 Cc: "dromasca@avaya.com" , "Adam.Montville@cisecurity.org" , "sacm@ietf.org" Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:52:35 -0000 ------=_NextPart_000_0140_01CE9823.F791AE00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't think there are any restrictions on how a group of authors creates an ID. So long as the resulting ID has the correct boilerplate. Mike -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Tuesday, August 13, 2013 12:39 PM To: Eric Walker; Chris Inacio Cc: Romascanu, Dan (Dan); Adam Montville; sacm@ietf.org Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document That has been done for other working groups where they can edit the document and generate the updated draft in RFC format when ready for an update. -Kathleen ________________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Eric Walker [eric.walker@us.ibm.com] Sent: Tuesday, August 13, 2013 12:31 PM To: Chris Inacio Cc: Romascanu, Dan (Dan); Adam Montville; sacm@ietf.org Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document >Can we set up some type of wiki that might allow multiple folks >simultaneous editing so that people working on the various drafts that >would depend on this (use-cases, arch, requirements) can all work >unimpeded? How about a Github repo? Eric _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_0140_01CE9823.F791AE00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgx MzE2NTIyOFowIwYJKoZIhvcNAQkEMRYEFLvuzTC3hlBXurd6XfBm0/0dVL9TMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAFC0cWeZsH4FT7p+PKCQ9Ebwd+ZiMjV1LTxNZWKf6 FUKpu2+XYcWUbG2q22W5TT2cr9Ofck0qwh/tQ/3m9FoDf5hbDfCPh+gEKsr3cWxpQ1TN6wrjhuxz +N1gjyKsbeZbrPpd9oxznmYe4vgRyHSoGyOfKT1b3eYzvIuOF2uhSKNvxfsm3n6qRG0BZJ5LukDD UQYfxitVCA5kppBV9qLl6ty/YfxznPn6mDHu+L7jiguDM5gjVHMnZOUFb1njBxMhDG7x5q3RsS/X 0sI8r9C2mQJbj4s68CEO3iirybUCra4VRY90H5QrvlG0uLkfmJuaM31AvOMkoweOz/uY437TjAAA AAAAAA== ------=_NextPart_000_0140_01CE9823.F791AE00-- From dromasca@avaya.com Wed Aug 14 02:03:48 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6C111E80ED for ; Wed, 14 Aug 2013 02:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.332 X-Spam-Level: X-Spam-Status: No, score=-103.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8JVxJpM9qsu for ; Wed, 14 Aug 2013 02:03:43 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id F2E5A11E8100 for ; Wed, 14 Aug 2013 02:03:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAOFGC1LGmAcV/2dsb2JhbABbgmUhNVC+YoEjFnSCJAEBAQEDAQEBDyg0CwwEAgEIDQQEAQELFAkHJwsUCQgCBAENBQgah24BC50Ym2kTBJALMQcGgxV2A54viwaDG4Iq X-IronPort-AV: E=Sophos;i="4.89,875,1367985600"; d="scan'208";a="23545978" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Aug 2013 05:03:41 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Aug 2013 04:59:58 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Wed, 14 Aug 2013 11:03:39 +0200 From: "Romascanu, Dan (Dan)" To: Michael Hammer , "kathleen.moriarty@emc.com" , "eric.walker@us.ibm.com" , "inacio@cert.org" Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6SpHgZAWpvrX0vRxuTXCLSjTwOnwAE6OWwAWomTwAAANfFAAAAQ4GAAAB4/4AAGX/AUA== Date: Wed, 14 Aug 2013 09:03:38 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128AAFA0@AZ-FFEXMB04.global.avaya.com> References: <4AE532C8B0B4B548AF47570D250D81741421AD59@marathon>, <9904FB1B0159DA42B0B887B7FA8119CA128A4DFA@AZ-FFEXMB04.global.avaya.com> <05BCCEB107AF88469B9F99783D47C1D673CE82@CISEXCHANGE1.msisac.org.local>, <00C069FD01E0324C9FFCADF539701DB3BBC27C53@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC27C53@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Adam.Montville@cisecurity.org" , "sacm@ietf.org" Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 09:03:48 -0000 Indeed. What matters is the resulting document (Internet-Draft). How the au= thors get there is completely up to them.=20 Regards, Dan > -----Original Message----- > From: Michael Hammer [mailto:michael.hammer@yaanatech.com] > Sent: Tuesday, August 13, 2013 7:52 PM > To: kathleen.moriarty@emc.com; eric.walker@us.ibm.com; inacio@cert.org > Cc: Romascanu, Dan (Dan); Adam.Montville@cisecurity.org; sacm@ietf.org > Subject: RE: [sacm] SACM - consensus on defining SACM terminology in a > separate document >=20 > I don't think there are any restrictions on how a group of authors > creates > an ID. > So long as the resulting ID has the correct boilerplate. >=20 > Mike >=20 >=20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Moriarty, Kathleen > Sent: Tuesday, August 13, 2013 12:39 PM > To: Eric Walker; Chris Inacio > Cc: Romascanu, Dan (Dan); Adam Montville; sacm@ietf.org > Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a > separate document >=20 > That has been done for other working groups where they can edit the > document > and generate the updated draft in RFC format when ready for an update. >=20 > -Kathleen > ________________________________________ > From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Eric > Walker > [eric.walker@us.ibm.com] > Sent: Tuesday, August 13, 2013 12:31 PM > To: Chris Inacio > Cc: Romascanu, Dan (Dan); Adam Montville; sacm@ietf.org > Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a > separate document >=20 > >Can we set up some type of wiki that might allow multiple folks > >simultaneous editing so that people working on the various drafts that > >would depend on this (use-cases, arch, requirements) can all work > >unimpeded? >=20 > How about a Github repo? >=20 > Eric >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From Erik.Cockrell@polycom.com Wed Aug 14 07:40:20 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F4611E81F3 for ; Wed, 14 Aug 2013 07:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHj2nMNKioe3 for ; Wed, 14 Aug 2013 07:40:15 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id E214F11E8169 for ; Wed, 14 Aug 2013 07:40:09 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 14 Aug 2013 07:40:09 -0700 From: "Cockrell, Erik" To: "sacm@ietf.org" Date: Wed, 14 Aug 2013 07:39:12 -0700 Thread-Topic: Several basic edits recommended for SACM Use Cases 05 Thread-Index: Ac6XlaRbj32RfoUiSyuOrTSAenh7jgAEHvEQAFVF/5A= Message-ID: <6E789DB94EAF0A4D979B56F5C47D0FBDB6DE88@CRPMBOXPRD07.polycom.com> References: <6E789DB94EAF0A4D979B56F5C47D0FBDB6DC24@CRPMBOXPRD07.polycom.com> <00367696f2134d28b34b38c986fac95a@BLUPR09MB038.namprd09.prod.outlook.com> In-Reply-To: <00367696f2134d28b34b38c986fac95a@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6E789DB94EAF0A4D979B56F5C47D0FBDB6DE88CRPMBOXPRD07polyc_" MIME-Version: 1.0 Subject: [sacm] Several basic edits recommended for SACM Use Cases 05 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:40:20 -0000 --_000_6E789DB94EAF0A4D979B56F5C47D0FBDB6DE88CRPMBOXPRD07polyc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all - I would like to introduce myself. I am a member of the Polycom Product Sec= urity Office. I have met several of you over the past couple of years (very= ) briefly at that OVAL Dev Days at MITRE. I have also been attending the IT= Security Automation Conference the past few years and in fact presented a = demo at the ThreatGuard exhibit booth last year showing how Polycom is usin= g SCAP to assess our video endpoints and UC infrastructure. I have also been subscribed to SACM mailing list for the past year. I view= ed the recorded SACM sessions from Berlin and have read both architecture d= ocs as well as the use cases 05 doc. I noticed a few (very) basic edits for the use cases 05 doc and Dave asked = that I post these to the mailing list. I purely mean this to be helpful and= not critical in any way. If these edits have already been addressed, I apo= logize. I very much look forward to becoming more involved with SACM in the= future. Basic edits/feedback for use cases 05: Terms and Definitions - - Relative to monitoring of Cloud based applications, it is not clear to me= how VM's are classified - can they be called out whether they are asset, e= ndpoint or system resource (or all 3)? Asset Management - - 4.1.1 - misspells -- "bradcast" should be broadcast -- "determing" should be determining - 4.1.7 - typo -- should delete "the" in first paragraph, second sentence - 4.3.4 - misspell - "analysts" should be analyst - 4.4 - Why is "policy attribute collection" left on a line by itself? Is t= his a typo? - 4.4.1 - misspells -- "associated" should be associated -- "initates" should be initiates - [page 13] - typo - "An asset identifier SHOULD be able to represented in a simple unambiguous manner" -- should add "be" before "represented" - 4.5 [page 14] -- can "provenance" be added to terms and definitions? -- can "entailment" be added to terms and definitions? - [page 17] typo - "Waltmire's" should be Waltermire's Thanks very much! Erik Cockrell, Senior Staff Product Security & Automation Engineer, Polycom= Product Security Office The holy grail of security is airtight input validation. 7700 West Parmer Lane, Bldg. C, Suite 100, Austin, TX 78730 | t: 512.372.71= 55 | c: 512.739.4250 | f: 512.372.7142 --_000_6E789DB94EAF0A4D979B56F5C47D0FBDB6DE88CRPMBOXPRD07polyc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all –

 

I would like to introduce myself.  I am a member of the Polycom Produ= ct Security Office. I have met several of you over the past couple of years= (very) briefly at that OVAL Dev Days at MITRE. I have also been attending = the IT Security Automation Conference the past few years and in fact presen= ted a demo at the ThreatGuard exhibit booth last year showing how Polycom i= s using SCAP to assess our video endpoints and UC infrastructure.

 

I have= also been subscribed to SACM mailing list for the past year.  I viewe= d the recorded SACM sessions from Berlin and have read both architecture do= cs as well as the use cases 05 doc.

 

I noticed a few (very) basic edits fo= r the use cases 05 doc and Dave asked that I post these to the mailing list= . I purely mean this to be helpful and not critical in any way. If these ed= its have already been addressed, I apologize. I very much look forward to b= ecoming more involved with SACM in the future.

 

Basic edits/feedback for use cases 05:

<= p class=3DMsoNormal>Terms and Definitions -

- Relative to monitoring of Cloud based applications, it is not clear = to me how VM's are classified – can they be called out whether they a= re asset, endpoint or system resource (or all 3)?

 

Asset Management -=

- 4.1.1 - misspells

-- “bradcast” should be= broadcast

--= “determing” should be determining

- 4.1.7 - typo -- should delete "the" in first paragraph, = second sentence

- 4.3.4 - misspell ̵= 1; “analysts” should be analyst

- 4.4 - Why is "policy attribute collection" left on a line b= y itself? Is this a typo?

- 4.4.1 - miss= pells

-- = 220;associated” should be associated

-- “initates” should be initiates=

- [page 13] - typo -

“An asset identifier SHOU= LD be able to represented in a

simple unambiguous manner”

-- should add "be" before= "represented"

- 4.5 [page 14]=

-- can &quo= t;provenance" be added to terms and definitions?

-- can "entailment" be a= dded to terms and definitions?

- [page 1= 7] typo – “Waltmire's” should be Waltermire's<= /p>

 

Thanks ve= ry much!

 

Erik Cockrell, Senior Staff Product= Security & Autom= ation Engineer, Polyco= m Product Security Office

The= holy grail of security is airtight input validation.=

7700 West Parmer Lane, Bldg. C, Suite 100, Au= stin, TX 78730 | t: 512.372.7155 | c: 512.739.42= 50 | f: 512.372.7142

&nbs= p;

= --_000_6E789DB94EAF0A4D979B56F5C47D0FBDB6DE88CRPMBOXPRD07polyc_-- From Adam.Montville@cisecurity.org Wed Aug 14 08:02:03 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008EA21F9E51 for ; Wed, 14 Aug 2013 08:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v3vP9I3qGUE for ; Wed, 14 Aug 2013 08:01:55 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5A011E81ED for ; Wed, 14 Aug 2013 08:01:48 -0700 (PDT) Received: from [216.82.250.19:8995] by server-8.bemta-12.messagelabs.com id D6/0B-31440-ADB9B025; Wed, 14 Aug 2013 15:01:46 +0000 X-Env-Sender: Adam.Montville@cisecurity.org X-Msg-Ref: server-16.tower-87.messagelabs.com!1376492505!17435812!2 X-Originating-IP: [69.195.43.86] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=cisecurity.org,-,- X-VirusChecked: Checked Received: (qmail 16869 invoked from network); 14 Aug 2013 15:01:46 -0000 Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-16.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 14 Aug 2013 15:01:46 -0000 Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0342.003; Wed, 14 Aug 2013 11:01:43 -0400 From: Adam Montville To: "Cockrell, Erik" , "sacm@ietf.org" Thread-Topic: Several basic edits recommended for SACM Use Cases 05 Thread-Index: Ac6XlaRbj32RfoUiSyuOrTSAenh7jgAEHvEQAFVF/5AAANO8Rg== Date: Wed, 14 Aug 2013 15:01:43 +0000 Message-ID: <05BCCEB107AF88469B9F99783D47C1D67D9CA1@CISEXCHANGE1.msisac.org.local> References: <6E789DB94EAF0A4D979B56F5C47D0FBDB6DC24@CRPMBOXPRD07.polycom.com> <00367696f2134d28b34b38c986fac95a@BLUPR09MB038.namprd09.prod.outlook.com>, <6E789DB94EAF0A4D979B56F5C47D0FBDB6DE88@CRPMBOXPRD07.polycom.com> In-Reply-To: <6E789DB94EAF0A4D979B56F5C47D0FBDB6DE88@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.252.38] Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D67D9CA1CISEXCHANGE1msisa_" MIME-Version: 1.0 Subject: Re: [sacm] Several basic edits recommended for SACM Use Cases 05 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 15:02:12 -0000 --_000_05BCCEB107AF88469B9F99783D47C1D67D9CA1CISEXCHANGE1msisa_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Erik, Thank you for these, and future, contributions! Welcome, and we look forw= ard to your continued involvement, especially as you represent an importan= t piece of the (IMO) underrepresented enterprise in terms of what we typic= ally consider a "traditional" endpoint. To address your question pertaining to how VMs are viewed, they are consid= ered an endpoint. We had a (brief) discussion about this on the list, and= I believe the general consensus was: 1) Yes, a VM is an endpoint, and 2) = this fact would be explicitly added to the "endpoint" definition. Others = on the list can add/correct as needed. Regards, Adam ________________________________ From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] on behalf of Cockrell,= Erik [Erik.Cockrell@polycom.com] Sent: Wednesday, August 14, 2013 7:40 AM To: sacm@ietf.org Subject: [sacm] Several basic edits recommended for SACM Use Cases 05 Hi all =96 I would like to introduce myself. I am a member of the Polycom Product Se= curity Office. I have met several of you over=20the past couple of years (= very) briefly at that OVAL Dev Days at MITRE. I have also been attending t= he IT Security Automation Conference the past few years and in fact presen= ted a demo at the ThreatGuard exhibit booth last year showing how Polycom = is using SCAP to assess our video endpoints and UC infrastructure. I have also been subscribed to SACM mailing list for the past year. I vie= wed the recorded SACM sessions from Berlin and have read both architecture= docs as well as the use cases 05 doc. I noticed a few (very) basic edits for the use cases 05 doc and Dave asked= that I post these to the mailing list. I purely mean this to be helpful a= nd not critical in any way. If these edits have already been addressed, I = apologize. I very much look forward to becoming more involved with SACM in= the future. Basic edits/feedback for use cases 05: Terms and Definitions - - Relative to monitoring of Cloud based applications, it is not clear to m= e how VM's are classified =96 can they be called out whether they are asse= t, endpoint or system resource (or all 3)? Asset Management - - 4.1.1 - misspells -- =93bradcast=94 should be broadcast -- =93determing=94 should be determining - 4.1.7 - typo -- should delete "the" in first paragraph, second sentence - 4.3.4 - misspell =96 =93analysts=94 should be analyst - 4.4 - Why is "policy attribute collection" left on a line by itself? Is = this a typo? - 4.4.1 - misspells -- =93associated=94 should be associated -- =93initates=94 should be initiates - [page 13] - typo - =93An asset identifier SHOULD be able to represented in a simple unambiguous manner=94 -- should add "be" before "represented" - 4.5 [page 14] -- can "provenance" be added to terms and definitions? -- can "entailment" be added to terms and definitions? - [page 17] typo =96 =93Waltmire's=94 should be Waltermire's Thanks very much! Erik Cockrell, Senior Staff Product Security & Automation Engineer, Polyco= m Product Security Office The holy grail of security is airtight input validation. 7700 West Parmer Lane, Bldg. C, Suite 100, Austin, TX 78730 | t:=20512.372= .7155 | c: 512.739.4250 | f: 512.372.7142 ... . . . --_000_05BCCEB107AF88469B9F99783D47C1D67D9CA1CISEXCHANGE1msisa_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Erik, 

Thank you for these, and future, contributions!  Welcome, and we= look forward to your continued involvement, especially as you represent a= n important piece of the (IMO) underrepresented enterprise in terms of wha= t we typically consider a "traditional" endpoint.

To address your question pertaining to how VMs are viewed, they are c= onsidered an endpoint.  We had a (brief) discussion about this on the= list, and I believe the general consensus was: 1) Yes, a VM is an endpoin= t, and 2) this fact would be explicitly added to the "endpoint" definition.  Others on the list ca= n add/correct as needed.

Regards,

Adam

From: sacm-bounces@ietf.org [sacm-boun= ces@ietf.org] on behalf of Cockrell, Erik [Erik.Cockrell@polycom.com]
Sent: Wednesday, August 14, 2013 7:40 AM
To: sacm@ietf.org
Subject: [sacm] Several basic edits recommended for SACM Use Cases = 05

Hi all =96

 

I would like to introduce myself.  I am a memb= er of the Polycom Product Security Office. I have met several of you over = the past couple of years (very) briefly at that OVAL Dev Days at MITRE. I = have also been attending the IT Security Automation Conference the past few years and in fact presented a demo at the ThreatG= uard exhibit booth last year showing how Polycom is using SCAP to assess o= ur video endpoints and UC infrastructure.

 

I have also been subscribed to SACM mailing list fo= r the past year.  I viewed the recorded SACM sessions from Berlin and= have read both architecture docs as well as the use cases 05 doc.

 

I noticed a few (very) basic edits for the use case= s 05 doc and Dave asked that I post these to the mailing list. I purely me= an this to be helpful and not critical in any way. If these edits have alr= eady been addressed, I apologize. I very much look forward to becoming more involved with SACM in the future.

 

Basic edits/fee= dback for use cases 05:

Terms and Definitions -

- Relative to monitoring of Cloud based application= s, it is not clear to me how VM's are classified =96 can they be called ou= t whether they are asset, endpoint or system resource (or all 3)?

 

Asset Management -

- 4.1.1 - misspells

-- =93bradcast=94 should= be broadcast

-- =93determing=94 shoul= d be determining

- 4.1.7 - typo -- should delete "the" in = first paragraph, second sentence

- 4.3.4 - misspell =96 =93analysts=94 should be ana= lyst

- 4.4 - Why is "policy attribute collection&qu= ot; left on a line by itself? Is this a typo?

- 4.4.1 - misspells

-- =93associated=94 shou= ld be associated

-- =93initates=94 should= be initiates

- [page 13] - typo -

=93An asset identifier S= HOULD be able to represented in a

simple unambiguous manne= r=94

-- should add "be&q= uot; before "represented"

- 4.5 [page 14]

-- can "provenance&= quot; be added to terms and definitions?

-- can "entailment&= quot; be added to terms and definitions?

- [page 17] typo =96 =93Waltmire's=94 should be Wal= termire's

 

Thanks very much!

 

Erik Cockrell= , Senior Staff Product Security & Automation Engineer, Polycom Product Security Office<= /p>

The holy grail of securi= ty is airtight input validation.

7700 West Parmer Lane, = Bldg. C, Suite 100, Austin, TX 78730 | t: 512.372.7155 | c: 512.739.4250 | f: 512.372.7142

 


...

. . .
--_000_05BCCEB107AF88469B9F99783D47C1D67D9CA1CISEXCHANGE1msisa_-- From ietfdbh@comcast.net Wed Aug 14 14:10:13 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1174F11E818D for ; Wed, 14 Aug 2013 14:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKvQUDGNo-nJ for ; Wed, 14 Aug 2013 14:09:59 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 107AE11E815C for ; Wed, 14 Aug 2013 14:09:58 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id Cb5T1m0061ei1Bg5Al9ypG; Wed, 14 Aug 2013 21:09:58 +0000 Received: from [10.59.1.23] ([67.189.237.137]) by omta24.westchester.pa.mail.comcast.net with comcast id Cl9t1m00M2yZEBF3kl9uCm; Wed, 14 Aug 2013 21:09:58 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Wed, 14 Aug 2013 17:09:52 -0400 From: David Harrington To: Eric Walker , Chris Inacio , Joe Marcus Clarke , "" Message-ID: Thread-Topic: [sacm] Feedback on vulnerability management use case In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376514598; bh=2ovn+WVpgUvpZU3Spp3bO35SoPZ4XON7Sv7VaU/BC7o=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=Wrv94DjEt/19K0qUwysjqEEzFxu8Y5AxL0p02E7l/yhhwk4IMdx8ACEX/t/4Jc21B 2mw7SVZ8yu1bhZbMgEg/lvPAw5Ok0ce8GQWHMX632CHcs/vCwpRQROPvXyRsay44hb UqoOY7ZG5Wz+Ms/TkhgsZnH8oMHkxrx9CMjAHfy4kCk/bMMu/4I6dhuj6wLKIBed7j TXngJjXu2tdFkmvWKQArWNQRjO1CDZMMiGFY/igkkhD/jZ6y8BVoc1vdIhDatqIsR7 cCSBqhpl5A1GM9xk3AkFtG42NOhTUS26yUhL+WSOuHwisf4c8sfYB47x5+LncxUBJD /k44AexnrSr0w== Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 21:10:14 -0000 Can you provide proposed text for the document? -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 8/13/13 12:42 PM, "Eric Walker" wrote: >Hi, > >It is easy to split hairs on the distinction between a "vulnerability," a >"misconfiguration," a patch check, and other, similar concepts. There >are good reasons for distinguishing these things -- a vulnerability can >be addressed in any number of ways, e.g., by removing the host from the >network, by blocking a port in the firewall, etc., so detecting or >addressing a vulnerability is not always a simple matter of applying a >patch, updating software or toggling a security-related setting. > >But we know from experience that many vulnerabilities that go back to the >state of an endpoint can be detected using the same means that are used >to detect deviations from security policy or missing OS patches or >out-of-date software. I'm concerned that if we make too fine a >distinction between these different use cases, we'll set ourselves up for >parallel standards that overlap in important ways. This is something to >be avoided. > >Eric > > > >>On Aug 2, 2013, at 8:27 PM, Joe Marcus Clarke >>wrote: > >[...] >>> I am not asking to standardize vulnerability assessment per se (meaning >>> standardize IPS signatures). What I am asking is whether or not SACM >>> needs to define a new (or standardize an existing) data model to >>> describe a vulnerability for purposes of efficient interchange? >>> >>> My argument for "yes" is that if I am to learn about things like device >>> type, hardware version, software version, place in network, >>> configuration, etc. how can I effectively build a policy around >>>security >>> posture if I do not know what vulnerabilities exist? If we have a way >>> to exchange descriptions of vulnerabilities, it would enable consistent >>> communication to a vulnerability repository as described in the >>>charter. >>> To me, this directly goes towards posture assessment. >>> >>> I don't see this as being in scope for MILE, so I wonder if this is out >>> of scope for SACM, would SACM disregard this type of model, point to an >>> existing, non-IETF model, look to tackle this in a future re-charter, >>>or >>> ...? > > > > > >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From jarrett.lu@oracle.com Wed Aug 14 16:58:46 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD38B21E80F2 for ; Wed, 14 Aug 2013 16:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOjVjb1aX4+u for ; Wed, 14 Aug 2013 16:58:41 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5231B21E8082 for ; Wed, 14 Aug 2013 16:58:41 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7ENweTA021624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Aug 2013 23:58:40 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7ENwdnX020862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Aug 2013 23:58:39 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7ENwcVs012669 for ; Wed, 14 Aug 2013 23:58:38 GMT Received: from [10.132.148.74] (/10.132.148.74) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Aug 2013 16:58:38 -0700 Message-ID: <520C1C65.3050107@oracle.com> Date: Wed, 14 Aug 2013 17:10:13 -0700 From: Jarrett Lu User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sacm@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA128A62B4@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A62B4@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: Re: [sacm] SACM - Consensus on the format of the use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jarrett.lu@oracle.com List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 23:58:47 -0000 I also support using David's proposed use case format. Thanks. - Jarrett On 08/ 7/13 06:58 AM, Romascanu, Dan (Dan) wrote: > At the SACM WG meeting at IETF-87 the participants in the room did not raise objections to the proposal made by David Harrington about the format of the use cases: > > - do not make it too formal in structure > - use narrative English but describe the actors and actions. > - include some descriptive text after to further clarify wherever necessary > > We are asking the WG to confirm this consensus on the mail list. Please send all comments, questions and concerns to the SACM WG mail list before 8/15. > > Adam and Dan > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From eric.walker@us.ibm.com Thu Aug 15 09:22:05 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E08D21E814B for ; Thu, 15 Aug 2013 09:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.441 X-Spam-Level: X-Spam-Status: No, score=-8.441 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7LT9MTMRF3u for ; Thu, 15 Aug 2013 09:21:52 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 9D53321E80A1 for ; Thu, 15 Aug 2013 09:21:51 -0700 (PDT) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Aug 2013 17:21:50 +0100 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 15 Aug 2013 17:21:48 +0100 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id DAA086E803F for ; Thu, 15 Aug 2013 12:21:41 -0400 (EDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r7FGLkok169108 for ; Thu, 15 Aug 2013 12:21:46 -0400 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r7FGLapo014075 for ; Thu, 15 Aug 2013 10:21:36 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.63.40.12]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r7FGLWmL013725; Thu, 15 Aug 2013 10:21:33 -0600 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Eric Walker To: David Harrington Message-ID: Date: Thu, 15 Aug 2013 10:21:27 -0600 X-Mailer: Lotus Domino Web Server Release 8.5.3FP2 ZX853FP2HF5 February, 2013 X-MIMETrack: Serialize by Notes Server on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/15/2013 10:21:27, Serialize complete at 08/15/2013 10:21:28, Itemize by Notes Server on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/15/2013 10:21:28, Serialize by Router on D03NM129/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/15/2013 10:21:32, Serialize complete at 08/15/2013 10:21:32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13081516-0320-0000-0000-000000B001EA Cc: Chris Inacio , Joe Marcus Clarke , "" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 16:22:05 -0000
My comments were of a general nature and were addressing points= raised by Joe Marcus Clark, below, and others.  I assume this thread = is commenting on the use cases, but I'm not sure.

= There is this paragraph in version 5 of the use cases:

=
=
Vulnerability management involves identifying the patch level of softw= are installed on the device and the identification of insecure custom code = (e.g. web vulnerabilities).  All vulnerabilities need to be addressed = as part of a comprehensive risk management program, which is a superset of = software vulnerabilities.  Thus, the capability of assessing non-softw= are vulnerabilities applicable to the system is required.  Additionall= y, it may be necessary to support non-technical assessment of data relating= to assets such as aspects related to operational and management controls.<= /div>

The first sentence seems fine t= o me if we understand SACM's scope to be restricted to vulnerabilities that= go back to the state of an endpoint.  To capture the recent thread, p= erhaps we would want something like this:

A vulnerabili= ty is generally understood to refer to a situation that will facilitate the= compromise of a network or an endpoint.  Some vulnerabilities relate = to processes and network topologies, while others go back to the state of i= ndividual endpoints and can be inferred from their patch level, whether the= y have up-to-date software, and so on.  A comprehensive risk managemen= t program may try to take into account all of these kinds of vulnerabilitie= s, and effort should be made to anticipate how such a program might work in= the real world so that the SACM work will integrate well with such efforts= .  In the context of software running on an endpoint, a "vulnerability= " is often closely related to the operating system patch level, the version= s of programs installed and the configuration of settings.  While it w= ould be difficult to define the term precisely, an important area of securi= ty automation involves identifying and addressing vulnerabilities on endpoi= nts.  [etc.]

This is more food f= or thought than a suggestion for the actual wording.

There is one other issue with the above paragraph, however (I have not h= ad a chance to review the full document).  I notice that we're trying = to pick up both software vulnerabilities and vulnerabilities that require a= questionnaire or other human workflow of some kind to identify.  This= is analogous to the division of labor between OVAL and OCIL, to give two e= xamples.  I am sure that there is a need for a way to systematically i= dentify and address vulnerabilities that require some kind of human-driven = workflow, and that this is a pressing one.  But the two sets of proces= ses work on very different timescales and have somewhat different needs. &n= bsp;It was an architectural mistake, in my opinion, for XCCDF to attempt to= include reference to both OVAL and OCIL in the same benchmark and for the = SCAP program to hang the possibility at one point that vendors would need t= o provide support for both sets of processes in their tools.  I would = urge this group to consider pushing the human-driven identification and rem= ediation workflows out of the scope of SACM, at least initially, while tryi= ng to provide suitable hooks for interoperability.

Eric


-----David Harrington= <ietfdbh@comcast.net> wrote: -----
To: Eric Walker/San Francisco/IBM@IBMUS, Chris Inacio <inacio@= cert.org>, Joe Marcus Clarke <jclarke@cisco.com>, "<sacm@ietf.o= rg>" <sacm@ietf.org>
From: David Harrington <ietfdbh@comcast= .net>
Date: 08/14/2013 02:11PM
Subject: Re: [sacm] Feedback on vul= nerability management use case

Can you provide proposed text for the document?
= --
David Harrington
Ietfdbh@comcast.net
+1-603-828-1401




On 8/13/13 12:42 PM, "Eric Walker" <eric.walker@us.ibm.com&= gt; wrote:

>Hi,
>
>It is easy to split hairs on the d= istinction between a "vulnerability," a
>"misconfiguration," a patch = check, and other, similar concepts.  There
>are good reasons for= distinguishing these things -- a vulnerability can
>be addressed in = any number of ways, e.g., by removing the host from the
>network, by = blocking a port in the firewall, etc., so detecting or
>addressing a = vulnerability is not always a simple matter of applying a
>patch, upd= ating software or toggling a security-related setting.
>
>But w= e know from experience that many vulnerabilities that go back to the
>= ;state of an endpoint can be detected using the same means that are used>to detect deviations from security policy or missing OS patches or
= >out-of-date software.  I'm concerned that if we make too fine a>distinction between these different use cases, we'll set ourselves up = for
>parallel standards that overlap in important ways.  This is= something to
>be avoided.
>
>Eric
>
>
>= ;
>>On Aug 2, 2013, at 8:27 PM, Joe Marcus Clarke <jclarke@cisc= o.com>
>>wrote:
>
>[...]
>>> I am not a= sking to standardize vulnerability assessment per se (meaning
>>&g= t; standardize IPS signatures).  What I am asking is whether or not SA= CM
>>> needs to define a new (or standardize an existing) data = model to
>>> describe a vulnerability for purposes of efficient= interchange?
>>>
>>> My argument for "yes" is tha= t if I am to learn about things like device
>>> type, hardware = version, software version, place in network,
>>> configuration,= etc. how can I effectively build a policy around
>>>security>>> posture if I do not know what vulnerabilities exist?  I= f we have a way
>>> to exchange descriptions of vulnerabilities= , it would enable consistent
>>> communication to a vulnerabili= ty repository as described in the
>>>charter.
>>> T= o me, this directly goes towards posture assessment.
>>>
&g= t;>> I don't see this as being in scope for MILE, so I wonder if this= is out
>>> of scope for SACM, would SACM disregard this type o= f model, point to an
>>> existing, non-IETF model, look to tack= le this in a future re-charter,
>>>or
>>> ...?
&= gt;
>
>
>
>
>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>sacm mailing list
>sacm@i= etf.org
>https= ://www.ietf.org/mailman/listinfo/sacm


= From jarrett.lu@oracle.com Thu Aug 15 10:33:07 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33C511E81DE for ; Thu, 15 Aug 2013 10:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AsFE1-SkUan for ; Thu, 15 Aug 2013 10:33:02 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 651D011E80AD for ; Thu, 15 Aug 2013 10:33:02 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7FHWuSR005756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 15 Aug 2013 17:32:56 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7FHWtN4011275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Aug 2013 17:32:55 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7FHWsWf019721 for ; Thu, 15 Aug 2013 17:32:55 GMT Received: from [10.132.148.74] (/10.132.148.74) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Aug 2013 10:32:54 -0700 Message-ID: <520D137E.20902@oracle.com> Date: Thu, 15 Aug 2013 10:44:30 -0700 From: Jarrett Lu User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sacm@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040204040503020704030506" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [sacm] FW: New Version Notification for draft-dbh-sacm-terminology-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jarrett.lu@oracle.com List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 17:33:07 -0000 This is a multi-part message in MIME format. --------------040204040503020704030506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A nit: under "asset" definition, "to be*protect* by a countermeasure"should be"to be*protected* by a countermeasure".RFC4949 had it right. Thanks. - Jarrett On 08/10/13 08:50 AM, David Harrington wrote: > Hi, > > I cut the terminology from use-cases and created a terminology doc. > This is an individual draft; the WG will need to decide whether to accept > it as a wg draft to start the wg's terminology doc. > > > -- > David Harrington > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > On 8/10/13 3:11 PM, "internet-drafts@ietf.org" > wrote: > >> A new version of I-D, draft-dbh-sacm-terminology-00.txt >> has been successfully submitted by David Waltermire and posted to the >> IETF repository. >> >> Filename: draft-dbh-sacm-terminology >> Revision: 00 >> Title: Terminology for Security Assessment >> Creation date: 2013-08-10 >> Group: Individual Submission >> Number of pages: 7 >> URL: >> http://www.ietf.org/internet-drafts/draft-dbh-sacm-terminology-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-dbh-sacm-terminology >> Htmlized: http://tools.ietf.org/html/draft-dbh-sacm-terminology-00 >> >> >> Abstract: >> This memo documents terminology used in the documents produced by the >> SACM WG (Security Automation and Continuous Monitoring). >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm --------------040204040503020704030506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
A nit: under "asset" definition, 
"to be protect by a countermeasure" should be "to be protected by a countermeasure". RFC4949 had it right.

Thanks.
- Jarrett


On 08/10/13 08:50 AM, David Harrington wrote:
Hi,

I cut the terminology from use-cases and created a terminology doc.
This is an individual draft; the WG will need to decide whether to accept
it as a wg draft to start the wg's terminology doc.


--
David Harrington
Ietfdbh@comcast.net
+1-603-828-1401





On 8/10/13 3:11 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:


A new version of I-D, draft-dbh-sacm-terminology-00.txt
has been successfully submitted by David Waltermire and posted to the
IETF repository.

Filename:	 draft-dbh-sacm-terminology
Revision:	 00
Title:		 Terminology for Security Assessment
Creation date:	 2013-08-10
Group:		 Individual Submission
Number of pages: 7
URL:             
http://www.ietf.org/internet-drafts/draft-dbh-sacm-terminology-00.txt
Status:          
http://datatracker.ietf.org/doc/draft-dbh-sacm-terminology
Htmlized:        http://tools.ietf.org/html/draft-dbh-sacm-terminology-00


Abstract:
  This memo documents terminology used in the documents produced by the
  SACM WG (Security Automation and Continuous Monitoring).

                 
       


Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm

--------------040204040503020704030506-- From inacio@cert.org Thu Aug 15 11:42:58 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEEF11E8182 for ; Thu, 15 Aug 2013 11:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol2i0t29X4ME for ; Thu, 15 Aug 2013 11:42:54 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id ABD1611E8179 for ; Thu, 15 Aug 2013 11:42:54 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7FIgjj2028146; Thu, 15 Aug 2013 14:42:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1376592165; bh=21jSZxg/IXU5o1/GZZoERebM8TLvK6IKdssmrHl/DXQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=bh9O+su485bQVps5y3ueGMfm6LfxrsRxXs1axhd0ERRi7u+x3NERM4yUbWkx6PH5x cHzkrjrigfZx8DDngW8iWuN7fTfgJA6dRqg2u6cLsJQDzGRk1FfdGCpEv4pPPWH+jV nL1xIO9AlJTjzfe5vbCVDz5qcN77oW9WLrzah9wc= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7FIgiOk009912; Thu, 15 Aug 2013 14:42:44 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0318.004; Thu, 15 Aug 2013 14:42:44 -0400 From: Chris Inacio To: Eric Walker Thread-Topic: [sacm] Feedback on vulnerability management use case Thread-Index: AQHOj+BS7Qmkha6vB0q7G2752tLnJJmToIMAgAAK2gCAAd0sAIABQcCAgAAneQA= Date: Thu, 15 Aug 2013 18:42:44 +0000 Message-ID: <4AE532C8B0B4B548AF47570D250D81741421F99F@marathon> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.51.92] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Joe Marcus Clarke , David Harrington , "" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 18:42:58 -0000 Can't we get a definition of vulnerability that is more basic, and then exp= and from there on what it means to manage and remediate? A vulnerability is a state of configuration or defect in a system which all= ows an unintended and unauthorized party to violate the security or policie= s of the system. Therefore, vulnerability management is the process of mitigating the abilit= y to exploit a vulnerability, via defect removal or protective measures suc= h that exploitation becomes impossible or highly unlikely. So then, the job in SACM is to cover the use cases of doing vulnerability m= anagement: software patching, configuration modification, or various prote= ctive measures. Obviously, this is the *really* hard part. :) -- Chris Inacio inacio@cert.org On Aug 15, 2013, at 12:21 PM, Eric Walker wrote: > My comments were of a general nature and were addressing points raised by= Joe Marcus Clark, below, and others. I assume this thread is commenting o= n the use cases, but I'm not sure. >=20 > There is this paragraph in version 5 of the use cases: >=20 > Vulnerability management involves identifying the patch level of software= installed on the device and the identification of insecure custom code (e.= g. web vulnerabilities). All vulnerabilities need to be addressed as part = of a comprehensive risk management program, which is a superset of software= vulnerabilities. Thus, the capability of assessing non-software vulnerabi= lities applicable to the system is required. Additionally, it may be neces= sary to support non-technical assessment of data relating to assets such as= aspects related to operational and management controls. >=20 > The first sentence seems fine to me if we understand SACM's scope to be r= estricted to vulnerabilities that go back to the state of an endpoint. To = capture the recent thread, perhaps we would want something like this: >=20 > A vulnerability is generally understood to refer to a situation that will= facilitate the compromise of a network or an endpoint. Some vulnerabiliti= es relate to processes and network topologies, while others go back to the = state of individual endpoints and can be inferred from their patch level, w= hether they have up-to-date software, and so on. A comprehensive risk mana= gement program may try to take into account all of these kinds of vulnerabi= lities, and effort should be made to anticipate how such a program might wo= rk in the real world so that the SACM work will integrate well with such ef= forts. In the context of software running on an endpoint, a "vulnerability= " is often closely related to the operating system patch level, the version= s of programs installed and the configuration of settings. While it would = be difficult to define the term precisely, an important area of security au= tomation involves identifying and addressing vulnerabilities on endpoints. = [etc.] >=20 > This is more food for thought than a suggestion for the actual wording. >=20 > There is one other issue with the above paragraph, however (I have not ha= d a chance to review the full document). I notice that we're trying to pic= k up both software vulnerabilities and vulnerabilities that require a quest= ionnaire or other human workflow of some kind to identify. This is analogo= us to the division of labor between OVAL and OCIL, to give two examples. I= am sure that there is a need for a way to systematically identify and addr= ess vulnerabilities that require some kind of human-driven workflow, and th= at this is a pressing one. But the two sets of processes work on very diff= erent timescales and have somewhat different needs. It was an architectura= l mistake, in my opinion, for XCCDF to attempt to include reference to both= OVAL and OCIL in the same benchmark and for the SCAP program to hang the p= ossibility at one point that vendors would need to provide support for both= sets of processes in their tools. I would urge this group to consider pus= hing the human-driven identification and remediation workflows out of the s= cope of SACM, at least initially, while trying to provide suitable hooks fo= r interoperability. >=20 > Eric >=20 >=20 > -----David Harrington wrote: ----- > To: Eric Walker/San Francisco/IBM@IBMUS, Chris Inacio , = Joe Marcus Clarke , "" > From: David Harrington > Date: 08/14/2013 02:11PM > Subject: Re: [sacm] Feedback on vulnerability management use case >=20 > Can you provide proposed text for the document? > -- > David Harrington > Ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 >=20 >=20 >=20 > On 8/13/13 12:42 PM, "Eric Walker" wrote: >=20 > >Hi, > > > >It is easy to split hairs on the distinction between a "vulnerability," = a > >"misconfiguration," a patch check, and other, similar concepts. There > >are good reasons for distinguishing these things -- a vulnerability can > >be addressed in any number of ways, e.g., by removing the host from the > >network, by blocking a port in the firewall, etc., so detecting or > >addressing a vulnerability is not always a simple matter of applying a > >patch, updating software or toggling a security-related setting. > > > >But we know from experience that many vulnerabilities that go back to th= e > >state of an endpoint can be detected using the same means that are used > >to detect deviations from security policy or missing OS patches or > >out-of-date software. I'm concerned that if we make too fine a > >distinction between these different use cases, we'll set ourselves up fo= r > >parallel standards that overlap in important ways. This is something to > >be avoided. > > > >Eric > > > > > > > >>On Aug 2, 2013, at 8:27 PM, Joe Marcus Clarke > >>wrote: > > > >[...] > >>> I am not asking to standardize vulnerability assessment per se (meani= ng > >>> standardize IPS signatures). What I am asking is whether or not SACM > >>> needs to define a new (or standardize an existing) data model to > >>> describe a vulnerability for purposes of efficient interchange? > >>>=20 > >>> My argument for "yes" is that if I am to learn about things like devi= ce > >>> type, hardware version, software version, place in network, > >>> configuration, etc. how can I effectively build a policy around > >>>security > >>> posture if I do not know what vulnerabilities exist? If we have a wa= y > >>> to exchange descriptions of vulnerabilities, it would enable consiste= nt > >>> communication to a vulnerability repository as described in the > >>>charter. > >>> To me, this directly goes towards posture assessment. > >>>=20 > >>> I don't see this as being in scope for MILE, so I wonder if this is o= ut > >>> of scope for SACM, would SACM disregard this type of model, point to = an > >>> existing, non-IETF model, look to tackle this in a future re-charter, > >>>or > >>> ...? > > > > > > > > > > > >_______________________________________________ > >sacm mailing list > >sacm@ietf.org > >https://www.ietf.org/mailman/listinfo/sacm >=20 >=20 From gunnar.engelbach@threatguard.com Thu Aug 15 12:22:43 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CF911E8156 for ; Thu, 15 Aug 2013 12:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss-4-OR0dFFm for ; Thu, 15 Aug 2013 12:22:36 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id AC83511E80AD for ; Thu, 15 Aug 2013 12:22:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=DscHEkA3v9+MoyTCAhzNM23UhiHz3qYIzdqjYwTdBft9Ew24A8Oo+4i8mR4tKvNugdOIJuhUSJQF/qE9tpRTd15tDxt1dtScYqWJxoOzVgTI/Xp5qA/XdGcD780hp2OM; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 31250 invoked from network); 15 Aug 2013 12:21:49 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Aug 2013 12:21:48 -0700 Message-ID: <520D2A84.6050807@ThreatGuard.com> Date: Thu, 15 Aug 2013 15:22:44 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Chris Inacio References: <4AE532C8B0B4B548AF47570D250D81741421F99F@marathon> In-Reply-To: <4AE532C8B0B4B548AF47570D250D81741421F99F@marathon> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Eric Walker , Joe Marcus Clarke , David Harrington , "" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 19:22:43 -0000 +1 Good definition. On 8/15/2013 2:42 PM, Chris Inacio wrote: > Can't we get a definition of vulnerability that is more basic, and then expand from there on what it means to manage and remediate? > > A vulnerability is a state of configuration or defect in a system which allows an unintended and unauthorized party to violate the security or policies of the system. > > > Therefore, vulnerability management is the process of mitigating the ability to exploit a vulnerability, via defect removal or protective measures such that exploitation becomes impossible or highly unlikely. > > So then, the job in SACM is to cover the use cases of doing vulnerability management: software patching, configuration modification, or various protective measures. Obviously, this is the *really* hard part. :) > > -- > Chris Inacio > inacio@cert.org > > > > On Aug 15, 2013, at 12:21 PM, Eric Walker wrote: > >> My comments were of a general nature and were addressing points raised by Joe Marcus Clark, below, and others. I assume this thread is commenting on the use cases, but I'm not sure. >> >> There is this paragraph in version 5 of the use cases: >> >> Vulnerability management involves identifying the patch level of software installed on the device and the identification of insecure custom code (e.g. web vulnerabilities). All vulnerabilities need to be addressed as part of a comprehensive risk management program, which is a superset of software vulnerabilities. Thus, the capability of assessing non-software vulnerabilities applicable to the system is required. Additionally, it may be necessary to support non-technical assessment of data relating to assets such as aspects related to operational and management controls. >> >> The first sentence seems fine to me if we understand SACM's scope to be restricted to vulnerabilities that go back to the state of an endpoint. To capture the recent thread, perhaps we would want something like this: >> >> A vulnerability is generally understood to refer to a situation that will facilitate the compromise of a network or an endpoint. Some vulnerabilities relate to processes and network topologies, while others go back to the state of individual endpoints and can be inferred from their patch level, whether they have up-to-date software, and so on. A comprehensive risk management program may try to take into account all of these kinds of vulnerabilities, and effort should be made to anticipate how such a program might work in the real world so that the SACM work will integrate well with such efforts. In the context of software running on an endpoint, a "vulnerability" is often closely related to the operating system patch level, the versions of programs installed and the configuration of settings. While it would be difficult to define the term precisely, an important area of security automation involves identifying and addressing vulnerabilities on endpoints. [etc.] >> >> This is more food for thought than a suggestion for the actual wording. >> >> There is one other issue with the above paragraph, however (I have not had a chance to review the full document). I notice that we're trying to pick up both software vulnerabilities and vulnerabilities that require a questionnaire or other human workflow of some kind to identify. This is analogous to the division of labor between OVAL and OCIL, to give two examples. I am sure that there is a need for a way to systematically identify and address vulnerabilities that require some kind of human-driven workflow, and that this is a pressing one. But the two sets of processes work on very different timescales and have somewhat different needs. It was an architectural mistake, in my opinion, for XCCDF to attempt to include reference to both OVAL and OCIL in the same benchmark and for the SCAP program to hang the possibility at one point that vendors would need to provide support for both sets of processes in their tools. I would urge this group to consider pushing the human - > driven identification and remediation workflows out of the scope of SACM, at least initially, while trying to provide suitable hooks for interoperability. >> >> Eric >> >> >> -----David Harrington wrote: ----- >> To: Eric Walker/San Francisco/IBM@IBMUS, Chris Inacio , Joe Marcus Clarke , "" >> From: David Harrington >> Date: 08/14/2013 02:11PM >> Subject: Re: [sacm] Feedback on vulnerability management use case >> >> Can you provide proposed text for the document? >> -- >> David Harrington >> Ietfdbh@comcast.net >> +1-603-828-1401 >> >> >> >> >> >> On 8/13/13 12:42 PM, "Eric Walker" wrote: >> >>> Hi, >>> >>> It is easy to split hairs on the distinction between a "vulnerability," a >>> "misconfiguration," a patch check, and other, similar concepts. There >>> are good reasons for distinguishing these things -- a vulnerability can >>> be addressed in any number of ways, e.g., by removing the host from the >>> network, by blocking a port in the firewall, etc., so detecting or >>> addressing a vulnerability is not always a simple matter of applying a >>> patch, updating software or toggling a security-related setting. >>> >>> But we know from experience that many vulnerabilities that go back to the >>> state of an endpoint can be detected using the same means that are used >>> to detect deviations from security policy or missing OS patches or >>> out-of-date software. I'm concerned that if we make too fine a >>> distinction between these different use cases, we'll set ourselves up for >>> parallel standards that overlap in important ways. This is something to >>> be avoided. >>> >>> Eric >>> >>> >>> >>>> On Aug 2, 2013, at 8:27 PM, Joe Marcus Clarke >>>> wrote: >>> >>> [...] >>>>> I am not asking to standardize vulnerability assessment per se (meaning >>>>> standardize IPS signatures). What I am asking is whether or not SACM >>>>> needs to define a new (or standardize an existing) data model to >>>>> describe a vulnerability for purposes of efficient interchange? >>>>> >>>>> My argument for "yes" is that if I am to learn about things like device >>>>> type, hardware version, software version, place in network, >>>>> configuration, etc. how can I effectively build a policy around >>>>> security >>>>> posture if I do not know what vulnerabilities exist? If we have a way >>>>> to exchange descriptions of vulnerabilities, it would enable consistent >>>>> communication to a vulnerability repository as described in the >>>>> charter. >>>>> To me, this directly goes towards posture assessment. >>>>> >>>>> I don't see this as being in scope for MILE, so I wonder if this is out >>>>> of scope for SACM, would SACM disregard this type of model, point to an >>>>> existing, non-IETF model, look to tackle this in a future re-charter, >>>>> or >>>>> ...? >>> >>> >>> >>> >>> >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >> >> > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From bakerj@mitre.org Thu Aug 15 12:46:56 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B274611E815E for ; Thu, 15 Aug 2013 12:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtsIX82ALtQJ for ; Thu, 15 Aug 2013 12:46:51 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D75B311E8151 for ; Thu, 15 Aug 2013 12:46:50 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3AF901F09DC; Thu, 15 Aug 2013 15:46:50 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2246D1F06D6; Thu, 15 Aug 2013 15:46:50 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.165]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0342.003; Thu, 15 Aug 2013 15:46:49 -0400 From: "Baker, Jon" To: Gunnar Engelbach , Chris Inacio Thread-Topic: [sacm] Feedback on vulnerability management use case Thread-Index: AQHOj+BOGTiVm0cd20ur711JXUkg/pmToIMAgAAK2gCAAd0sAIABQcCAgAAneQCAAAstAP//whDg Date: Thu, 15 Aug 2013 19:46:49 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651304D4296E@IMCMBX03.MITRE.ORG> References: <4AE532C8B0B4B548AF47570D250D81741421F99F@marathon> <520D2A84.6050807@ThreatGuard.com> In-Reply-To: <520D2A84.6050807@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Eric Walker , Joe Marcus Clarke , David Harrington , "" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 19:46:56 -0000 CVE has some pretty widely accepted definitions for vulnerability and expos= ure: http://cve.mitre.org/about/terminology.html Of course, these are based= upon the software vulnerability analysis domain that CVE supports.=20 The definition below that includes configuration aligns fairly well with th= e NIST definition: http://nvlpubs.nist.gov/nistpubs/ir/2013/NIST.IR.7298r2.= pdf Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org >-----Original Message----- >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Gunnar Engelbach >Sent: Thursday, August 15, 2013 3:23 PM >To: Chris Inacio >Cc: Eric Walker; Joe Marcus Clarke; David Harrington; >Subject: Re: [sacm] Feedback on vulnerability management use case > > >+1 > >Good definition. > > > >On 8/15/2013 2:42 PM, Chris Inacio wrote: >> Can't we get a definition of vulnerability that is more basic, and then = expand >from there on what it means to manage and remediate? >> >> A vulnerability is a state of configuration or defect in a system which = allows >an unintended and unauthorized party to violate the security or policies o= f the >system. >> >> >> Therefore, vulnerability management is the process of mitigating the abi= lity >to exploit a vulnerability, via defect removal or protective measures such= that >exploitation becomes impossible or highly unlikely. >> >> So then, the job in SACM is to cover the use cases of doing vulnerabilit= y >management: software patching, configuration modification, or various >protective measures. Obviously, this is the *really* hard part. :) >> >> -- >> Chris Inacio >> inacio@cert.org >> >> >> >> On Aug 15, 2013, at 12:21 PM, Eric Walker >wrote: >> >>> My comments were of a general nature and were addressing points raised >by Joe Marcus Clark, below, and others. I assume this thread is commentin= g >on the use cases, but I'm not sure. >>> >>> There is this paragraph in version 5 of the use cases: >>> >>> Vulnerability management involves identifying the patch level of softwa= re >installed on the device and the identification of insecure custom code (e.= g. >web vulnerabilities). All vulnerabilities need to be addressed as part of= a >comprehensive risk management program, which is a superset of software >vulnerabilities. Thus, the capability of assessing non-software vulnerabi= lities >applicable to the system is required. Additionally, it may be necessary t= o >support non-technical assessment of data relating to assets such as aspect= s >related to operational and management controls. >>> >>> The first sentence seems fine to me if we understand SACM's scope to be >restricted to vulnerabilities that go back to the state of an endpoint. T= o >capture the recent thread, perhaps we would want something like this: >>> >>> A vulnerability is generally understood to refer to a situation that wi= ll >facilitate the compromise of a network or an endpoint. Some vulnerabiliti= es >relate to processes and network topologies, while others go back to the st= ate >of individual endpoints and can be inferred from their patch level, whethe= r >they have up-to-date software, and so on. A comprehensive risk management >program may try to take into account all of these kinds of vulnerabilities= , and >effort should be made to anticipate how such a program might work in the >real world so that the SACM work will integrate well with such efforts. I= n the >context of software running on an endpoint, a "vulnerability" is often clo= sely >related to the operating system patch level, the versions of programs inst= alled >and the configuration of settings. While it would be difficult to define = the >term precisely, an important area of security automation involves identify= ing >and addressing vulnerabilities on endpoints. [etc.] >>> >>> This is more food for thought than a suggestion for the actual wording. >>> >>> There is one other issue with the above paragraph, however (I have not = had >a chance to review the full document). I notice that we're trying to pick= up >both software vulnerabilities and vulnerabilities that require a questionn= aire >or other human workflow of some kind to identify. This is analogous to th= e >division of labor between OVAL and OCIL, to give two examples. I am sure >that there is a need for a way to systematically identify and address >vulnerabilities that require some kind of human-driven workflow, and that = this >is a pressing one. But the two sets of processes work on very different >timescales and have somewhat different needs. It was an architectural >mistake, in my opinion, for XCCDF to attempt to include reference to both >OVAL and OCIL in the same benchmark and for the SCAP program to hang the >possibility at one point that vendors would need to provide support for bo= th >sets of processes in their tools. I would urge this group to consider pus= hing >the human > - >> driven identification and remediation workflows out of the scope of SA= CM, >at least initially, while trying to provide suitable hooks for interoperab= ility. >>> >>> Eric >>> >>> >>> -----David Harrington wrote: ----- >>> To: Eric Walker/San Francisco/IBM@IBMUS, Chris Inacio >, Joe Marcus Clarke , >"" >>> From: David Harrington >>> Date: 08/14/2013 02:11PM >>> Subject: Re: [sacm] Feedback on vulnerability management use case >>> >>> Can you provide proposed text for the document? >>> -- >>> David Harrington >>> Ietfdbh@comcast.net >>> +1-603-828-1401 >>> >>> >>> >>> >>> >>> On 8/13/13 12:42 PM, "Eric Walker" wrote: >>> >>>> Hi, >>>> >>>> It is easy to split hairs on the distinction between a "vulnerability,= " a >>>> "misconfiguration," a patch check, and other, similar concepts. There >>>> are good reasons for distinguishing these things -- a vulnerability ca= n >>>> be addressed in any number of ways, e.g., by removing the host from th= e >>>> network, by blocking a port in the firewall, etc., so detecting or >>>> addressing a vulnerability is not always a simple matter of applying a >>>> patch, updating software or toggling a security-related setting. >>>> >>>> But we know from experience that many vulnerabilities that go back to >the >>>> state of an endpoint can be detected using the same means that are use= d >>>> to detect deviations from security policy or missing OS patches or >>>> out-of-date software. I'm concerned that if we make too fine a >>>> distinction between these different use cases, we'll set ourselves up = for >>>> parallel standards that overlap in important ways. This is something = to >>>> be avoided. >>>> >>>> Eric >>>> >>>> >>>> >>>>> On Aug 2, 2013, at 8:27 PM, Joe Marcus Clarke >>>>> wrote: >>>> >>>> [...] >>>>>> I am not asking to standardize vulnerability assessment per se (mean= ing >>>>>> standardize IPS signatures). What I am asking is whether or not SAC= M >>>>>> needs to define a new (or standardize an existing) data model to >>>>>> describe a vulnerability for purposes of efficient interchange? >>>>>> >>>>>> My argument for "yes" is that if I am to learn about things like dev= ice >>>>>> type, hardware version, software version, place in network, >>>>>> configuration, etc. how can I effectively build a policy around >>>>>> security >>>>>> posture if I do not know what vulnerabilities exist? If we have a w= ay >>>>>> to exchange descriptions of vulnerabilities, it would enable consist= ent >>>>>> communication to a vulnerability repository as described in the >>>>>> charter. >>>>>> To me, this directly goes towards posture assessment. >>>>>> >>>>>> I don't see this as being in scope for MILE, so I wonder if this is = out >>>>>> of scope for SACM, would SACM disregard this type of model, point to >an >>>>>> existing, non-IETF model, look to tackle this in a future re-charter= , >>>>>> or >>>>>> ...? >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>> >>> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From jclarke@cisco.com Thu Aug 15 14:02:30 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E185411E818F for ; Thu, 15 Aug 2013 14:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErDncN6VgwZV for ; Thu, 15 Aug 2013 14:02:26 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB8521F9D11 for ; Thu, 15 Aug 2013 14:02:26 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7FL2Ih6006490; Fri, 16 Aug 2013 06:02:19 +0900 (JST) Received: from dhcp-10-150-54-67.cisco.com (dhcp-10-150-54-67.cisco.com [10.150.54.67]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7FL2A53002401; Thu, 15 Aug 2013 17:02:10 -0400 (EDT) Message-ID: <520D41D2.4020508@cisco.com> Date: Thu, 15 Aug 2013 17:02:10 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Chris Inacio References: <51FC4E85.8010501@cisco.com> <4AE532C8B0B4B548AF47570D250D81741421ACB5@marathon> In-Reply-To: <4AE532C8B0B4B548AF47570D250D81741421ACB5@marathon> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [sacm] Feedback on vulnerability management use case X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 21:02:31 -0000 On 8/13/13 12:03 PM, Chris Inacio wrote: > > On Aug 2, 2013, at 8:27 PM, Joe Marcus Clarke wrote: > >> After talking with Eliot today after the WG meeting, I think my comments >> regarding vulnerability management were unclear. I'd like to clarify >> and still see if people think this is out of scope. >> >> I am not asking to standardize vulnerability assessment per se (meaning >> standardize IPS signatures). What I am asking is whether or not SACM >> needs to define a new (or standardize an existing) data model to >> describe a vulnerability for purposes of efficient interchange? >> >> My argument for "yes" is that if I am to learn about things like device >> type, hardware version, software version, place in network, >> configuration, etc. how can I effectively build a policy around security >> posture if I do not know what vulnerabilities exist? If we have a way >> to exchange descriptions of vulnerabilities, it would enable consistent >> communication to a vulnerability repository as described in the charter. >> To me, this directly goes towards posture assessment. >> >> I don't see this as being in scope for MILE, so I wonder if this is out >> of scope for SACM, would SACM disregard this type of model, point to an >> existing, non-IETF model, look to tackle this in a future re-charter, or >> ...? >> >> Joe >> >> -- >> Joe Marcus Clarke, CCIE #5384, | | >> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >> Phone: +1 (919) 392-2867 c i s c o S y s t e m s >> Email: jclarke@cisco.com >> >> ---------------------------------------------------------------------------- >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > > > Joe, > > Let me attempt to inject a little more context, and you can tell me if I'm off track, because I'm trying to understand your original comments. > > Is what you are looking to accomplish is a little more complex than just saying "X has vulnerability Y" such that you can understand that "Windows Server 2008 R2 has a *remotely exploitable* software vulnerability on port 12345" such that you can include within the framework a mitigation that might include say putting a Cisco :) firewall in front of said Windows Server in the network to remediate the said vulnerability? So that SACM supports not just saying "patch X with software level N+1", but that "Vuln Y on X is mitigated by device P"? > > Is that the intent? Yes, that is my intent. If a vulnerability, mitigation, remediation is properly described then SACM can take the asset and config data together with the vulnerability data and provide a posture assessment. Joe > > I like the idea of the generic IDS/IPS language though… :) > > > -- > Chris Inacio > inacio@cert.org > > > > > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From gunnar.engelbach@threatguard.com Fri Aug 16 09:46:25 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACDA11E8165 for ; Fri, 16 Aug 2013 09:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsFd4fTGMsHV for ; Fri, 16 Aug 2013 09:46:15 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 39D6121F92C2 for ; Fri, 16 Aug 2013 09:46:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=o4rP9C9LKGiv+e9QLJS0jFjrxORxQISp7k9c/oWsQs5CEnIVm41NsDgdrI3CBWC0nojtPdcn8whbrkC2wLQib/SGCiwQVTG01PInaoqBX80s+LcHJeti7BZj2go5XT7o; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Forwarded-Message-Id:Content-Type:Content-Transfer-Encoding; Received: (qmail 19724 invoked from network); 16 Aug 2013 09:45:30 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Aug 2013 09:45:30 -0700 Message-ID: <520E5767.80606@ThreatGuard.com> Date: Fri, 16 Aug 2013 12:46:31 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "sacm@ietf.org" References: <520D68E8.2090206@ThreatGuard.com> In-Reply-To: <520D68E8.2090206@ThreatGuard.com> X-Forwarded-Message-Id: <520D68E8.2090206@ThreatGuard.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sacm] Use Case: Asynchronous Assessment X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 16:46:25 -0000 I put together the following use case description to highlight the unique challenges we've had accommodating some customers: -------------===========================------------- Asynchronous Compliance/Vulnerability Assessment at Ice Station Zebra A university team receives a grant to do research at a government facility in the arctic. The only network communications will be via an intermittent low-speed high-latency high-cost satellite link. During their extended expedition they will need to show continue compliance with the security policies of the university, the government, and the provider of the satellite network as well as keep current on vulnerability testing. Interactive assessments are therefore not reliable, and since the researchers have very limited funding they need to minimize how much money they spend on network data. Prior to departure they register all equipment with an asset management system owned by the university, which will also initiate and track assessments. On a periodic basis -- either after a maximum time delta or when the content repository has received a threshold level of new vulnerability definitions -- the university uses the information in the asset management system to put together a collection request for all of the deployed assets that encompasses the minimal set of artifacts necessary to evaluate all three security policies as well as vulnerability testing. In the case of new critical vulnerabilities this collection request consists only of the artifacts necessary for those vulnerabilities and collection is only initiated for those assets that could potentially have a new vulnerability. [Optional] Asset artifacts are cached in a local CMDB. When new vulnerabilities are reported to the content repository, a request to the live asset is only done if the artifacts in the CMDB are incomplete and/or not current enough. The collection request is queued for the next window of connectivity. The deployed assets eventually receive the request, fulfill it, and queue the results for the next return opportunity. The collected artifacts eventually make it back to the university where the level of compliance and vulnerability expose is calculated and asset characteristics are compared to what is in the asset management system for accuracy and completeness. ---------------------------------------- I brought up this scenario because it highlights a few requirements: * A measured reaction to updates to the content repository * Unable to do collection interactively * Minimize total network traffic (enhanced by use of CMDB) * Active network discovery infeasible: using asset management system instead * A single collection is used for multiple policies * Multiple policies may apply, depending on current context of asset From david.waltermire@nist.gov Sun Aug 18 15:48:32 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4987511E815B for ; Sun, 18 Aug 2013 15:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPEFh1cIrwHC for ; Sun, 18 Aug 2013 15:48:25 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id E421011E8140 for ; Sun, 18 Aug 2013 15:48:24 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 18 Aug 2013 18:48:17 -0400 Received: from wsget1.nist.gov (129.6.13.150) by WSXGHUB2.xchange.nist.gov (129.6.18.19) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sun, 18 Aug 2013 18:48:18 -0400 Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 18 Aug 2013 18:48:15 -0400 Received: from na01-bl2-obe.outbound.protection.outlook.com (207.46.163.210) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 18 Aug 2013 18:48:17 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB040.namprd09.prod.outlook.com (10.255.211.154) with Microsoft SMTP Server (TLS) id 15.0.731.16; Sun, 18 Aug 2013 22:48:04 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.168]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.73]) with mapi id 15.00.0731.000; Sun, 18 Aug 2013 22:48:04 +0000 From: "Waltermire, David A." To: "Nancy Cam-Winget (ncamwing) (ncamwing@cisco.com)" Thread-Topic: Requirements Removed from the SACM Use Cases Draft Thread-Index: Ac6cZP2Wu4rAENFJSkKj8EI2mwZWxg== Date: Sun, 18 Aug 2013 22:48:03 +0000 Message-ID: <34f1402202cc4af0a9a63d24ffc7a4f0@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 094213BFEA x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(16236675002)(80976001)(46102001)(81542001)(74502001)(56816003)(15202345003)(31966008)(74706001)(81686001)(49866001)(47446002)(81342001)(74876001)(19300405004)(74662001)(50986001)(4396001)(47736001)(83072001)(69226001)(76786001)(65816001)(81816001)(76576001)(63696002)(47976001)(83322001)(77096001)(76796001)(54316002)(33646001)(51856001)(53806001)(79102001)(54356001)(76482001)(74316001)(19580395003)(77982001)(76176001)(59766001)(80022001)(74366001)(56776001)(19580385001)(66066001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB040; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_34f1402202cc4af0a9a63d24ffc7a4f0BLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Cc: "sacm@ietf.org" Subject: [sacm] Requirements Removed from the SACM Use Cases Draft X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 22:48:32 -0000 --_000_34f1402202cc4af0a9a63d24ffc7a4f0BLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nancy, The following are requirements from the Use Cases document that I removed. = They should be added to your requirements document draft instead. I left th= e XML tags in place to make them easier to drop in your draft. >From the section titled "data collection": One or more data formats MUST be identified to describe instru= ctions, data collection methods, to drive data collection (e.g. technical, interrogativ= e). One or more data formats MUST be identified to instruct what p= osture attributes need to be collected for a specific set of endpoints. A method MUST be provided to include OPTIONAL instructions= on describing what content must be run on the endpoint. A method MUST be provided to include OPTIONAL instructions= that determine how to collect data supporting any particular test for that endpoi= nt. A method MUST be provided for retrieving data collection instr= uctions from a remote host (see Section ). One or more data formats MUST be identified to capture the res= ults of data collection. This expression MUST be capable of supporting the characte= rization of assets and any related configuration settings that together compose an= endpoint. A mechanism MUST be provided to identify the software = and hardware asset instances that compose an endpoint. An asset identifier SHOULD be able to be determine= d in an automated manner An asset identifier, as communicated between entit= ies, SHOULD be held to a minimal size. An asset identifier SHOULD be able to represented = in a simple unambiguous manner, such as a reference, so that its embedded u= se in places like applicability clauses for individual benchmark test= s can be kept from making their usage unwieldy. A mechanism MUST be provided to associate configuratio= n settings values to the installed software. A mechanism MUST be provided to identify additional co= llected posture attribute/value pairs related to an endpoint. A mechanism MUST be provided to identify the endpoint the = results pertain to (see Section .= A mechanism MUST be provided to associate the data collect= ion method with the collected value. A mechanism MUST be provided to include provenance informa= tion describing what sensor of software collected the data. A mechanism MUST be provided to include entailment informa= tion, perhaps by reference, describing the methodology used to collect the d= ata. A method of communicating data collection results to another s= ystem for further analysis MUST be identified. TODO: Communicate, unambiguously and to the necessary level of= detail**, the asset details between software components >From the section titled "Assessment Result Analysis": A method MUST be provided for selecting acceptable state polic= y, describing how to evaluate collected information, based on characteristics of the= endpoint and organizational policy. A method MUST be provided for comparing collected data to expe= cted state values (test evaluation). Any results produced by analysis processes MUST be capable of = being transformed into a human-readable format. >From the section titled "Content Management": A protocol MUST be identified for retrieving SACM content from= a content repository A protocol MUST be identified for querying SACM content held i= n a content repository. The protocol MUST support querying content by applicability to = asset characteristics. TODO: Determine what content can or must be run on the end= point A protocol MUST be identified for curating SACM content in a c= ontent repository. Note: This might be an area where we can limit the scope of work rela= tive to the initial SACM charter. --_000_34f1402202cc4af0a9a63d24ffc7a4f0BLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nancy,

 

The following are requirements from the Use Cases do= cument that I removed. They should be added to your requirements document d= raft instead. I left the XML tags in place to make them easier to drop in y= our draft.

 

From the section titled “data collection”= ;:

 

 

    =       <t>One or more data formats MUST be identified to describe instructions,= data collection
            methods,= to drive data collection (e.g. technical, interrogative).</t>
          <t>One or more = data formats MUST be identified to instruct what posture attributes need to
            be colle= cted for a specific set of endpoints. = <list>
            &nb= sp; <t>A method MUST be provided to include OPTIONAL instructions on describing what
            &nb= sp;   content must be run on the endpoint.</t>
            &nb= sp; <t>A method MUST be provided to include OPTIONAL instructions that determine how to
            &nb= sp;   collect data supporting any particular test for that endpoi= nt.</t>
            <= span style=3D"font-size:12.0pt;font-family:"Times New Roman",&quo= t;serif";color:#000096"></list></t>
          <t>A method MUS= T be provided for retrieving data collection instructions from a remote
            host (se= e Section <xref target=3D"sec-capability-content-management"/>= ).</t>
          <t>One or more = data formats MUST be identified to capture the results of data collection. <list>
            &nb= sp; <t>This expression MUST be capable of supporting the characterizatio= n of assets and
            &nb= sp;   any related configuration settings that together compose an= endpoint. <list>
            &nb= sp;     <t><= /span>A mechanism MUST be provided to identify = the software and hardware asset
            &nb= sp;       instances that compose an endpoint.= <list>
            &nb= sp;         <t>An asset identifi= er SHOULD be able to be determined in an automated
            &nb= sp;           manner</t><t>An asset identifi= er, as communicated between entities, SHOULD be held to a
            &nb= sp;           minimal siz= e.</t>
            &nb= sp;         <t>An asset identifi= er SHOULD be able to represented in a simple unambiguous
            &nb= sp;           manner, suc= h as a reference, so that its embedded use in places like
            &nb= sp;           applicabili= ty clauses for individual benchmark tests can be kept from making
            &nb= sp;           their usage= unwieldy.</t>
            &nb= sp;      
            &nb= sp;     </t>=
            &nb= sp;     <t><= /span>A mechanism MUST be provided to associate= configuration settings values to the
            &nb= sp;       installed software.</t>
            &nb= sp;     <t><= /span>A mechanism MUST be provided to identify = additional collected posture
            &nb= sp;       attribute/value pairs related to an= endpoint.</t>
            &nb= sp;   </list>
            &nb= sp; </t>
            &nb= sp; <t>A mechanism MUST be provided to identify the endpoint the results pertain to (see
            &nb= sp;   Section <xref target= =3D"sec-capability-asset-manageme= nt"/>.</t>
            &nb= sp; <t>A mechanism MUST be provided to associate the data collection method with the
            &nb= sp;   collected value.</t= >
            &nb= sp; <t>A mechanism MUST be provided to include provenance information describing what
            &nb= sp;   sensor of software collected the data.</t>
            &nb= sp; <t>A mechanism MUST be provided to include entailment information, perhaps by
            &nb= sp;   reference, describing the methodology used to collect the d= ata.</t>
            <= span style=3D"font-size:12.0pt;font-family:"Times New Roman",&quo= t;serif";color:#000096"></list></t>
          <t>A method of = communicating data collection results to another system for further
            analysis= MUST be identified.</t><= span style=3D"font-size:12.0pt;font-family:"Times New Roman",&quo= t;serif";color:black">
          <t>TODO: Commun= icate, unambiguously and to the necessary level of detail**, the asset
            details = between software components</t><= /span>

From the section titled “Assessment Result Ana= lysis”:

 

    =       <!-- TODO: Use of an applicabilit= y concept, against a collection of assets to determine what policies (test = expressions) are suitable for collection and evaluation. -->
          <t>A method MUS= T be provided for selecting acceptable state policy, describing how to
            evaluate= collected information, based on characteristics of the endpoint and
            organiza= tional policy.</t>
          <t>A method MUS= T be provided for comparing collected data to expected state values (test
            evaluati= on).</t>
          <t>Any results = produced by analysis processes MUST be capable of being transformed into a
            human-re= adable format.</t>

 

From the section titled “Content Management= 221;:

 

    =       <t>A protocol MUST be identified for retrieving SACM content from a cont= ent repository</t>
          <t>A protocol M= UST be identified for querying SACM content held in a content repository.
            The prot= ocol MUST support querying content by applicability to asset characteristic= s. <list>
            &nb= sp; <t>TODO: Determine what content can or must be run on the endpoint</t>
            <= span style=3D"font-size:12.0pt;font-family:"Times New Roman",&quo= t;serif";color:#000096"></list></t>
          <t>A protocol M= UST be identified for curating SACM content in a content repository. Note:
            This mig= ht be an area where we can limit the scope of work relative to the initial = SACM
            charter.= </t>

--_000_34f1402202cc4af0a9a63d24ffc7a4f0BLUPR09MB038namprd09pro_-- From david.waltermire@nist.gov Sun Aug 18 17:05:34 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A950321F8EFE for ; Sun, 18 Aug 2013 17:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyi3nX8mlZZg for ; Sun, 18 Aug 2013 17:05:19 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id E443511E80F7 for ; Sun, 18 Aug 2013 17:05:18 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 18 Aug 2013 20:05:15 -0400 Received: from wsget1.nist.gov (129.6.13.150) by WSXGHUB2.xchange.nist.gov (129.6.18.19) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sun, 18 Aug 2013 20:05:17 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 18 Aug 2013 20:05:14 -0400 Received: from na01-bl2-obe.outbound.protection.outlook.com (207.46.163.204) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 18 Aug 2013 20:05:16 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB040.namprd09.prod.outlook.com (10.255.211.154) with Microsoft SMTP Server (TLS) id 15.0.731.16; Mon, 19 Aug 2013 00:05:03 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.168]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.73]) with mapi id 15.00.0731.000; Mon, 19 Aug 2013 00:05:03 +0000 From: "Waltermire, David A." To: "sacm@ietf.org" Thread-Topic: SACM Terminology - Vulnerability Thread-Index: Ac6cUYLIFWEENTLjQEiP7lr5g1Je1Q== Date: Mon, 19 Aug 2013 00:05:03 +0000 Message-ID: <4f808cc201f0458d9c93aa3bdce0b4a6@BLUPR09MB038.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 09435FCA72 x-forefront-antispam-report: SFV:NSPM; SFS:(15404003)(199002)(189002)(69226001)(54316002)(33646001)(47976001)(63696002)(76576001)(81816001)(65816001)(76786001)(77096001)(76796001)(83322001)(56776001)(19580385001)(76176001)(59766001)(74366001)(80022001)(66066001)(76482001)(54356001)(79102001)(74316001)(51856001)(53806001)(77982001)(19580395003)(56816003)(74502001)(15202345003)(81542001)(74706001)(31966008)(80976001)(16236675002)(46102001)(50986001)(47736001)(4396001)(83072001)(81686001)(47446002)(49866001)(74662001)(19300405004)(74876001)(81342001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB040; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_4f808cc201f0458d9c93aa3bdce0b4a6BLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: [sacm] SACM Terminology - Vulnerability X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 00:05:34 -0000 --_000_4f808cc201f0458d9c93aa3bdce0b4a6BLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are many terms in this space that are overloaded with meaning to the = point that the terms are less than useful (e.g., asset, vulnerability, poli= cy). For these terms, it might be best to use more specific terms in our do= cuments as a general practice. Here are some vulnerability-related terms w= ith potential definitions from various sources: Comments/preferences/alternate definitions are appreciated. Dave Vulnerability: ---------------- A vulnerability is a state of configuration or defect in a system which all= ows an unintended and unauthorized party to violate the security or policie= s of the system. (from Chris Inacio) A weakness in an information system, system security procedures, internal c= ontrols, or implementation that is subject to exploitation or misuse. This = includes flaws in software and processes, and misconfiguration of hardware = or software. (derived from NIST definitions) >From RFC4949: (I) A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy. (See: harden.) Tutorial: A system can have three types of vulnerabilities: (a) vulnerabilities in design or specification; (b) vulnerabilities in implementation; and (c) vulnerabilities in operation and management. Most systems have one or more vulnerabilities, but this does not mean that the systems are too flawed to use. Not every threat results in an attack, and not every attack succeeds. Success depends on the degree of vulnerability, the strength of attacks, and the effectiveness of any countermeasures in use. If the attacks needed to exploit a vulnerability are very difficult to carry out, then the vulnerability may be tolerable. If the perceived benefit to an attacker is small, then even an easily exploited vulnerability may be tolerable. However, if the attacks are well understood and easily made, and if the vulnerable system is employed by a wide range of users, then it is likely that there will be enough motivation for someone to launch an attack. * Software flaw: A weakness in software that is subject to exploitation or misuse. A softwar= e flaw can be used by an attacker to gain access to a system or network, an= d/or materially affect the confidentiality, integrity or availability of in= formation hosted by an endpoint or exchanged over a network. Such a flaw ma= y allow an attacker to execute commands as another user, access data that i= s contrary to specified access controls, pose as another entity, or to cond= uct a denial of service. (derived from CVE vulnerability definition) * Misconfiguration: A misconfiguration is a configuration setting that violates organizational = security policies, introduces a possible security weakness in a system, or = permits or causes unintended behavior that may impact the security posture = of a system. (from NIST IR 7670) The misalignment of a unit of endpoint configuration posture relative to or= ganizational expectations that is subject to exploitation or misuse. * Exposure: An endpoint misconfiguration or software flaw that allows access to informa= tion or capabilities that can be used by an attacker as a means to compromi= se an endpoint or network. (derived from CVE exposure definition) >From RFC4949: (I) A type of threat action whereby sensitive data is directly released to an unauthorized entity. (See: unauthorized disclosure.) Usage: This type of threat action includes the following subtypes: - "Deliberate Exposure": Intentional release of sensitive data to an unauthorized entity. - "Scavenging": Searching through data residue in a system to gain unauthorized knowledge of sensitive data. - "Human error": /exposure/ Human action or inaction that unintentionally results in an entity gaining unauthorized knowledge of sensitive data. (Compare: corruption, incapacitation.) - "Hardware or software error": /exposure/ System failure that unintentionally results in an entity gaining unauthorized knowledge of sensitive data. (Compare: corruption, incapacitation.) Vulnerability Management: ---------------------------------- The process of mitigating the ability to exploit a vulnerability, via defec= t removal or protective measures such that exploitation becomes impossible = or highly unlikely. (from Chris Inacio) Remediation (sometimes the term "remedy" is less contentious): ---------------------------------------------------------------------------= ---- A remediation is defined as a security-related set of actions that results = in a change to a computer's state and may consist of changes motivated by t= he need to enforce organizational security policies, address discovered vul= nerabilities, or correct misconfigurations. (from NIST IR 7670) --_000_4f808cc201f0458d9c93aa3bdce0b4a6BLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are many terms in this space that are overload= ed with meaning to the point that the terms are less than useful (e.g., ass= et, vulnerability, policy). For these terms, it might be best to use more s= pecific terms in our documents as a general practice.  Here are some vulnerability-related terms with p= otential definitions from various sources:

 

Comments/preferences/alternate definitions are appre= ciated.

 

Dave

 

Vulnerability:

----------------

A vulnerability is a state of configuration or defec= t in a system which allows an unintended and unauthorized party to violate = the security or policies of the system. (from Chris Inacio)

 

A weakness in an information system, system security= procedures, internal controls, or implementation that is subject to exploi= tation or misuse. This includes flaws in software and processes, and miscon= figuration of hardware or software. (derived from NIST definitions)

 

From RFC4949:

 

(I) A flaw or weakness in a system's design, implementation, or
      operation and management that coul=
d be exploited to violate the
      system's security policy. (See: ha=
rden.)
 
      Tutorial: A system can have three =
types of vulnerabilities: (a)
      vulnerabilities in design or speci=
fication; (b) vulnerabilities in
      implementation; and (c) vulnerabil=
ities in operation and
      management. Most systems have one =
or more vulnerabilities, but
      this does not mean that the system=
s are too flawed to use. Not
      every threat results in an attack,=
 and not every attack succeeds.
      Success depends on the degree of v=
ulnerability, the strength of
      attacks, and the effectiveness of =
any countermeasures in use. If
      the attacks needed to exploit a vu=
lnerability are very difficult
      to carry out, then the vulnerabili=
ty may be tolerable. If the
      perceived benefit to an attacker i=
s small, then even an easily
      exploited vulnerability may be tol=
erable. However, if the attacks
      are well understood and easily mad=
e, and if the vulnerable system
      is employed by a wide range of use=
rs, then it is likely that there
      will be enough motivation for some=
one to launch an attack.

 

* Software flaw:

 

A weakness in software that is subject to exploitati= on or misuse. A software flaw can be used by an attacker to gain access to = a system or network, and/or materially affect the confidentiality, integrit= y or availability of information hosted by an endpoint or exchanged over a network. Such a flaw may allow an attac= ker to execute commands as another user, access data that is contrary to sp= ecified access controls, pose as another entity, or to conduct a denial of = service. (derived from CVE vulnerability definition)

 

* Misconfiguration:

 

A misconfiguration is a configuration setting tha= t violates organizational security policies, introduces a possible security= weakness in a system, or permits or causes unintended behavior that may im= pact the security posture of a system. (from NIST IR 7670)

 

The misalignment of a unit of endpoint configuration= posture relative to organizational expectations that is subject to exploit= ation or misuse.

 

* Exposure:

 

An endpoint misconfiguration or software flaw that a= llows access to information or capabilities that can be used by an attacker= as a means to compromise  an endpoint or network. (derived from CVE e= xposure definition)

 

From RFC4949:

 

(I) A type of threat action whereby sensitive data is directly
      released to an unauthorized entity=
. (See: unauthorized
      disclosure.)

 


      Usage: This type of threat action =
includes the following subtypes:


      -  "Deliberate Exposure&=
quot;: Intentional release of sensitive data to


         an unauthorized =
entity.


      -  "Scavenging": Se=
arching through data residue in a system to


         gain unauthorize=
d knowledge of sensitive data.


      -  "Human error": /=
exposure/ Human action or inaction that


         unintentionally =
results in an entity gaining unauthorized


         knowledge of sen=
sitive data. (Compare: corruption,


         incapacitation.)=



      -  "Hardware or software=
 error": /exposure/ System failure that


         unintentionally =
results in an entity gaining unauthorized


         knowledge of sen=
sitive data. (Compare: corruption,


         incapacitation.)=



 


Vulnerability Management:


----------------------------------


The process of mitigating the ability to exploit a v=
ulnerability, via defect removal or protective measures such that exploitat=
ion becomes impossible or highly unlikely. (from Chris Inacio)

 


Remediation (sometimes the term “remedyR=
21; is less contentious):



-------------------------------------------------=
------------------------------


A remediation is defined as a security-related se=
t of actions that results in a change to a computer's state and may consist=
 of changes motivated by the need to enforce organizational security polici=
es, address discovered vulnerabilities,
 or correct misconfigurations. (from NIST IR 7670)


 
--_000_4f808cc201f0458d9c93aa3bdce0b4a6BLUPR09MB038namprd09pro_-- From david.waltermire@nist.gov Sun Aug 18 17:07:45 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AE921F994C for ; Sun, 18 Aug 2013 17:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeQvjTFnB4kA for ; Sun, 18 Aug 2013 17:07:16 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 22A2311E81A3 for ; Sun, 18 Aug 2013 17:07:05 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 18 Aug 2013 20:06:59 -0400 Received: from wsget2.nist.gov (129.6.13.151) by WSXGHUB2.xchange.nist.gov (129.6.18.19) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sun, 18 Aug 2013 20:07:00 -0400 Received: from WSGHUB2.xchange.nist.gov (129.6.16.197) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 18 Aug 2013 20:06:59 -0400 Received: from na01-by2-obe.outbound.protection.outlook.com (207.46.163.238) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 18 Aug 2013 20:06:57 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) with Microsoft SMTP Server (TLS) id 15.0.731.16; Mon, 19 Aug 2013 00:06:55 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.168]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.73]) with mapi id 15.00.0731.000; Mon, 19 Aug 2013 00:06:55 +0000 From: "Waltermire, David A." To: "sacm@ietf.org" Thread-Topic: SACM Vulnerability Management Thread-Index: Ac6cQ81FoxalN6LaRfSMzhSGxulqSg== Date: Mon, 19 Aug 2013 00:06:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 09435FCA72 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(56816003)(50986001)(16236675002)(69226001)(81816001)(47736001)(77096001)(47976001)(19580395003)(74876001)(49866001)(81542001)(79102001)(56776001)(19300405004)(63696002)(53806001)(15202345003)(81686001)(4396001)(74662001)(76176001)(31966008)(33646001)(83322001)(19580385001)(74706001)(74366001)(76796001)(46102001)(74502001)(51856001)(76786001)(81342001)(59766001)(54316002)(558084003)(65816001)(54356001)(83072001)(76482001)(76576001)(74316001)(80022001)(77982001)(47446002)(80976001)(66066001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB038; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_d031400b0b75464a85d064c45e6c69a2BLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 00:07:47 -0000 --_000_d031400b0b75464a85d064c45e6c69a2BLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm working on updates to the use cases based on feedback received and ther= e is an outstanding question that was not addressed based on what I can fin= d. Is standardizing IDS/IPS signatures in scope? For network-based tools? For = host-based tools? Any thoughts? Dave --_000_d031400b0b75464a85d064c45e6c69a2BLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m working on updates to the use cases based = on feedback received and there is an outstanding question that was not addr= essed based on what I can find.

 

Is standardizing IDS/IPS signatures in scope? For ne= twork-based tools? For host-based tools?

 

Any thoughts?

 

Dave

--_000_d031400b0b75464a85d064c45e6c69a2BLUPR09MB038namprd09pro_-- From jclarke@cisco.com Sun Aug 18 21:29:28 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC0311E80FE for ; Sun, 18 Aug 2013 21:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5bhq668XKka for ; Sun, 18 Aug 2013 21:29:23 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id A979711E81CD for ; Sun, 18 Aug 2013 21:29:23 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7J4TJEW006184; Mon, 19 Aug 2013 13:29:20 +0900 (JST) Received: from rtp-jclarke-8912.cisco.com (rtp-jclarke-8912.cisco.com [10.117.46.163]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7J4TBbW016060; Mon, 19 Aug 2013 00:29:12 -0400 (EDT) Message-ID: <52119F15.1000908@cisco.com> Date: Mon, 19 Aug 2013 00:29:09 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Waltermire, David A." References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 04:29:29 -0000 On 8/18/13 8:06 PM, Waltermire, David A. wrote: > I’m working on updates to the use cases based on feedback received and > there is an outstanding question that was not addressed based on what I > can find. > > > > Is standardizing IDS/IPS signatures in scope? For network-based tools? > For host-based tools? > > > > Any thoughts? I mentioned this as a counter argument to what I was trying to raise asking about vulnerability management. I was asking more about defining a common way to describe a vulnerability, remediation, etc for purposes of interchange. I don't think trying to come up with a standard IPS signature definition should be in the initial SACM scope. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From dromasca@avaya.com Mon Aug 19 03:55:28 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDDB11E823C for ; Mon, 19 Aug 2013 03:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.382 X-Spam-Level: X-Spam-Status: No, score=-103.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-vAVXQncDT5 for ; Mon, 19 Aug 2013 03:55:21 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 9133721F9A70 for ; Mon, 19 Aug 2013 03:55:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcGAOn4EVLGmAcV/2dsb2JhbABbgmYhgQa/MoEhFm0HgiYBAQMSKFEBFQUQFEIXDwEEGxqHbgGVP4REmzaPI4EMg1N3A54yiweDHIFxOQ X-IronPort-AV: E=Sophos;i="4.89,912,1367985600"; d="scan'208";a="24118143" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Aug 2013 06:55:20 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Aug 2013 06:51:19 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0146.000; Mon, 19 Aug 2013 06:55:19 -0400 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: consensus on 'Way Forward' Thread-Index: Ac6cype7fT8LIbmNQ52AXuqFwj50pQ== Date: Mon, 19 Aug 2013 10:55:19 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128B14AA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] consensus on 'Way Forward' X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 10:55:28 -0000 At the SACM WG meeting at IETF-88 the participants in the room did not rais= e any objection on the 'Way Forward' plan of action between now and IETF-88= presented by Adam Montville on behalf of the chairs. The plan included the= following: 8/16: Agreement on way forward on list 8/31: Adopt Use Case I-D as WG doc 9/13: Initial Requirements I-D submitted 9/30: Adopt Requirements I-D as WG doc 10/15: Initial Architecture I-Ds submitted IETF 88: Discuss architecture contributions and work for consensus We have asked the WG to confirm this consensus on the mail list. Thanks to = all who answered. There was strong consensus in favor of the plan.=20 Regards, Adam and Dan From dromasca@avaya.com Mon Aug 19 04:00:49 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B8021F9991 for ; Mon, 19 Aug 2013 04:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.413 X-Spam-Level: X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBFhSEB4iwIW for ; Mon, 19 Aug 2013 04:00:42 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1575C21F9928 for ; Mon, 19 Aug 2013 04:00:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcGAJH5EVKHCzI1/2dsb2JhbABbgmYhgQa/MoEhFm0HgiYBAQMSKFEBFRUUQiYBBBsah24BlUCERJs2jyOBDINTdwOeMosHgxyBcTk X-IronPort-AV: E=Sophos;i="4.89,912,1367985600"; d="scan'208";a="20448673" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Aug 2013 07:00:39 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Aug 2013 06:53:26 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Mon, 19 Aug 2013 07:00:36 -0400 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: consensus on defining SACM terminology in a separate document Thread-Index: Ac6cy1UBsEpx1iVzSmmoz1PKqi4k9w== Date: Mon, 19 Aug 2013 11:00:36 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128B14BF@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 11:00:49 -0000 Hi, At the SACM WG meeting at IETF-87 the participants in the room did not rais= e any objection to the proposal to separate the terminology section from dr= aft-waltermire-sacm-use-cases and make of it a separate document that defin= es the SACM terms in one place and can be referred by all other SACM docume= nts.=20 We have asked the WG to confirm this consensus on the mail list. Thanks to = all who answered. There was strong consensus in favor of the proposal.=20 There were some discussions about the format and methods of collaboration. = We suggest that the editors of the use cases document discuss and decide am= ong them on this issue.=20 Regards, Adam and Dan From dromasca@avaya.com Mon Aug 19 04:06:52 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4851711E8238 for ; Mon, 19 Aug 2013 04:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.437 X-Spam-Level: X-Spam-Status: No, score=-103.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlKwk2mDiK8X for ; Mon, 19 Aug 2013 04:06:45 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 83F2611E80DF for ; Mon, 19 Aug 2013 04:06:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIGAOX7EVKHCzI1/2dsb2JhbABbgmYhgQa+JQGBDIEhFm0HgiYBAQMSKFEBFRUUQiYBBBsah24BlT+ERJs4jyOBDINTdwOeMosHgWGBO4FxOQ X-IronPort-AV: E=Sophos;i="4.89,912,1367985600"; d="scan'208";a="20449324" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Aug 2013 07:06:29 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Aug 2013 06:59:16 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Mon, 19 Aug 2013 13:06:26 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases Thread-Index: Ac6czCVz4BNxi+uhQ062F/QGFC1UNQ== Date: Mon, 19 Aug 2013 11:06:26 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128B14D4@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] Consensus on adopting draft-waltermire-sacm-use-cases as start point for WG I-D for use cases X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 11:06:52 -0000 At the SACM WG meeting at IETF-87 the participants in the room did not rais= e any objection on the proposal to adopt draft-waltermire-sacm-use-cases as= start point for WG I-D for use cases.=20 We have asked the WG to confirm this consensus on the mail list. Thanks to = all who answered. There was strong consensus in favor of the proposal.=20 Regards, Dan From aawoland@cisco.com Mon Aug 19 04:58:15 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E848311E824A for ; Mon, 19 Aug 2013 04:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDQIjQIV6htf for ; Mon, 19 Aug 2013 04:58:11 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 19B1E11E8227 for ; Mon, 19 Aug 2013 04:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1516; q=dns/txt; s=iport; t=1376913491; x=1378123091; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BLa02/0RqG8jVdbgdzm1c2/pbnVDmqwNUwtGQeuixwA=; b=iOaFiHD+c+hbzybktg2VW71RLR08/4o9Ps5fNEN4Z8tHZLx2Ss+LDQF9 6NU3bohmL1T/GzIoA7bzgpE39Rp3JOa88b3PGPgKuv0fAZgbK44v/wu68 If8Jof57fZ3B8sMl/d3JD9bhilwqNuklldJNe2rT4/btzNq9xymSr6esz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACgHElKtJXG9/2dsb2JhbABYA4MHNUW/PIEhFnSCJAEBAQMBAQEBawsFCQICAQgYLhsMCyUBAQQOBYgKBgy1NAQEjw+BGiMQBxGDCncDl2SRVYMcgXE X-IronPort-AV: E=Sophos;i="4.89,913,1367971200"; d="scan'208";a="248950719" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 19 Aug 2013 11:58:08 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7JBw8Vg013998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Aug 2013 11:58:08 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.80]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 19 Aug 2013 06:58:07 -0500 From: "Aaron Woland (aawoland)" To: "Joe Clarke (jclarke)" Thread-Topic: [sacm] SACM Vulnerability Management Thread-Index: Ac6cQ81FoxalN6LaRfSMzhSGxulqSgAesFOAAAUz0ms= Date: Mon, 19 Aug 2013 11:58:07 +0000 Message-ID: <2D4B81AA-6007-4B25-A1F3-DD9FBF91A128@cisco.com> References: , <52119F15.1000908@cisco.com> In-Reply-To: <52119F15.1000908@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 11:58:16 -0000 +1 (Deftly typed with big thumbs and a small keyboard on my iPhone. Please ex= cuse spelling errors, brevity or words that were "autocorrected" incorrectl= y!!!)=20 On Aug 19, 2013, at 12:29 AM, "Joe Clarke (jclarke)" wr= ote: > On 8/18/13 8:06 PM, Waltermire, David A. wrote: >> I=92m working on updates to the use cases based on feedback received and >> there is an outstanding question that was not addressed based on what I >> can find. >>=20 >>=20 >>=20 >> Is standardizing IDS/IPS signatures in scope? For network-based tools? >> For host-based tools? >>=20 >>=20 >>=20 >> Any thoughts? >=20 > I mentioned this as a counter argument to what I was trying to raise > asking about vulnerability management. I was asking more about defining > a common way to describe a vulnerability, remediation, etc for purposes > of interchange. I don't think trying to come up with a standard IPS > signature definition should be in the initial SACM scope. >=20 > Joe >=20 > --=20 > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > -------------------------------------------------------------------------= --- > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Mon Aug 19 07:26:34 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CC221F9AB4 for ; Mon, 19 Aug 2013 07:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlAjBgyYxYJk for ; Mon, 19 Aug 2013 07:26:29 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 92BB311E8112 for ; Mon, 19 Aug 2013 07:26:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=TpHn23lzwkj2p9UBHo+sr6lrk6Tqo6lu5BzIMgKdz6mxOrXRk8f56VkslROlHdxCZQCYryVP69cMp00MDXL/nuEhwL1JgfFHwRDQ7ga8M6xMVJmpIWwljCPdloi14l1P; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 14850 invoked from network); 19 Aug 2013 07:25:52 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Aug 2013 07:25:52 -0700 Message-ID: <52122B14.4050302@ThreatGuard.com> Date: Mon, 19 Aug 2013 10:26:28 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Joe Marcus Clarke References: <52119F15.1000908@cisco.com> In-Reply-To: <52119F15.1000908@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 14:26:34 -0000 Standardizing IPS/IDS signature definitions is beyond the current scope of this WG, but standardizing the ability to communicate a detected IDS signature would be very useful in conjunction with known vulnerabilities/misconfigured items -- something akin to CVE/CVSS. Same for routing rules, firewall rule sets, VLAN settings, et al. I'd like to see a convergence where all of this information can be communicated in a standardized way, but I think that's too much for this working group right now. --gun On 8/19/2013 12:29 AM, Joe Marcus Clarke wrote: > On 8/18/13 8:06 PM, Waltermire, David A. wrote: >> I’m working on updates to the use cases based on feedback received and >> there is an outstanding question that was not addressed based on what I >> can find. >> >> >> >> Is standardizing IDS/IPS signatures in scope? For network-based tools? >> For host-based tools? >> >> >> >> Any thoughts? > > I mentioned this as a counter argument to what I was trying to raise > asking about vulnerability management. I was asking more about defining > a common way to describe a vulnerability, remediation, etc for purposes > of interchange. I don't think trying to come up with a standard IPS > signature definition should be in the initial SACM scope. > > Joe > From david.waltermire@nist.gov Mon Aug 19 07:59:50 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2F011E82A0 for ; Mon, 19 Aug 2013 07:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cz0n6G5CkKs for ; Mon, 19 Aug 2013 07:59:44 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id E088A21F9B10 for ; Mon, 19 Aug 2013 07:59:03 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 19 Aug 2013 10:58:48 -0400 Received: from wsget1.nist.gov (129.6.13.150) by WSXGHUB2.xchange.nist.gov (129.6.18.19) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 19 Aug 2013 10:58:51 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 19 Aug 2013 10:58:48 -0400 Received: from na01-bl2-obe.outbound.protection.outlook.com (207.46.163.212) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 19 Aug 2013 10:58:50 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB040.namprd09.prod.outlook.com (10.255.211.154) with Microsoft SMTP Server (TLS) id 15.0.731.16; Mon, 19 Aug 2013 14:58:43 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.168]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.73]) with mapi id 15.00.0731.000; Mon, 19 Aug 2013 14:58:43 +0000 From: "Waltermire, David A." To: Gunnar Engelbach , Joe Marcus Clarke Thread-Topic: [sacm] SACM Vulnerability Management Thread-Index: Ac6cQ81FoxalN6LaRfSMzhSGxulqSgAUNh2AABTcbgAAAN0a8A== Date: Mon, 19 Aug 2013 14:58:42 +0000 Message-ID: References: <52119F15.1000908@cisco.com> <52122B14.4050302@ThreatGuard.com> In-Reply-To: <52122B14.4050302@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 09435FCA72 x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(51444003)(24454002)(377454003)(479174003)(199002)(189002)(51704005)(69226001)(54316002)(19580405001)(33646001)(76576001)(76482001)(63696002)(81816001)(77982001)(65816001)(76796001)(76786001)(83322001)(77096001)(53806001)(59766001)(74366001)(66066001)(79102001)(56776001)(47976001)(54356001)(51856001)(74316001)(80022001)(19580395003)(56816003)(83072001)(81542001)(74706001)(74502001)(80976001)(4396001)(46102001)(47736001)(50986001)(74876001)(49866001)(47446002)(81686001)(81342001)(74662001)(31966008)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB040; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 14:59:51 -0000 Just to summarize what I am hearing, the following is true: - Defining a format for IDS/IPS signature is not in scope. - Supporting format agnostic publication and retrieval of IDS/IPS signature= s in a content repository is in scope. - Supporting the exchange of IDS/IPS signature is in scope allowing any arb= itrary model to be used for the exchange. - Reporting detected IDS/IPS signatures is in scope. Is this true for both = network-based AND host-based IDS/IPS components? Is this correct? Dave > -----Original Message----- > From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > Sent: Monday, August 19, 2013 10:26 AM > To: Joe Marcus Clarke > Cc: Waltermire, David A.; sacm@ietf.org > Subject: Re: [sacm] SACM Vulnerability Management >=20 >=20 > Standardizing IPS/IDS signature definitions is beyond the current scope o= f > this WG, but standardizing the ability to communicate a detected IDS > signature would be very useful in conjunction with known > vulnerabilities/misconfigured items -- something akin to CVE/CVSS. >=20 > Same for routing rules, firewall rule sets, VLAN settings, et al. >=20 > I'd like to see a convergence where all of this information can be > communicated in a standardized way, but I think that's too much for this > working group right now. >=20 >=20 > --gun >=20 >=20 > On 8/19/2013 12:29 AM, Joe Marcus Clarke wrote: > > On 8/18/13 8:06 PM, Waltermire, David A. wrote: > >> I'm working on updates to the use cases based on feedback received > >> and there is an outstanding question that was not addressed based on > >> what I can find. > >> > >> > >> > >> Is standardizing IDS/IPS signatures in scope? For network-based tools? > >> For host-based tools? > >> > >> > >> > >> Any thoughts? > > > > I mentioned this as a counter argument to what I was trying to raise > > asking about vulnerability management. I was asking more about > > defining a common way to describe a vulnerability, remediation, etc > > for purposes of interchange. I don't think trying to come up with a > > standard IPS signature definition should be in the initial SACM scope. > > > > Joe > > From gunnar.engelbach@threatguard.com Mon Aug 19 11:24:42 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF9711E814E for ; Mon, 19 Aug 2013 11:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRvT5tRqnncj for ; Mon, 19 Aug 2013 11:24:38 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 81B2111E814F for ; Mon, 19 Aug 2013 11:24:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=lt8EMzy81Hp4hI7zZNrbMwo5OxKYz4zhGCkjhTBUy1z9lDBU4M5+WSu+DwlJ3ZhHOLsu1oQ3x0q122+rHTkaTTEz6zWuUYkq02otumEEVU+KbkK0E2PovY1Bf9ffiTJF; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 28479 invoked from network); 19 Aug 2013 11:24:02 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Aug 2013 11:24:01 -0700 Message-ID: <521262E5.4040608@ThreatGuard.com> Date: Mon, 19 Aug 2013 14:24:37 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Waltermire, David A." References: <52119F15.1000908@cisco.com> <52122B14.4050302@ThreatGuard.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joe Marcus Clarke , "sacm@ietf.org" Subject: Re: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:24:43 -0000 Standardizing the characteristics necessary to identify known IDS/IPS events is a reasonable next step beyond identifying configuration items, known vulnerabilities, and malware. And, to me, that certainly falls within the purview of "Security Automation and Continuous Monitoring." I'd like to see it addressed, but as much as this WG has been whittled down to its current focus I don't see it as sensible trying to address it at this time. An abstraction step removed from IPS/IDS signatures is standardizing how to communicate detected events with enough information to make security decisions. That would be a good first step, but even that much I'm not convinced SACM has the resources to address at this time. Querying a content repository for signatures is a good point. I already think the query/retrieval mechanism for content repositories needs to be very open-ended, so I don't see why they couldn't also be used for proprietary content -- as long as the minimal set of SACM requirements are also met. So I guess what I'm saying is that I see all of this as in scope, but none of it will be able to be addressed in this iteration. Anyone else? On 8/19/2013 10:58 AM, Waltermire, David A. wrote: > Just to summarize what I am hearing, the following is true: > - Defining a format for IDS/IPS signature is not in scope. > - Supporting format agnostic publication and retrieval of IDS/IPS signatures in a content repository is in scope. > - Supporting the exchange of IDS/IPS signature is in scope allowing any arbitrary model to be used for the exchange. > - Reporting detected IDS/IPS signatures is in scope. Is this true for both network-based AND host-based IDS/IPS components? > > Is this correct? > > Dave > >> -----Original Message----- >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >> Sent: Monday, August 19, 2013 10:26 AM >> To: Joe Marcus Clarke >> Cc: Waltermire, David A.; sacm@ietf.org >> Subject: Re: [sacm] SACM Vulnerability Management >> >> >> Standardizing IPS/IDS signature definitions is beyond the current scope of >> this WG, but standardizing the ability to communicate a detected IDS >> signature would be very useful in conjunction with known >> vulnerabilities/misconfigured items -- something akin to CVE/CVSS. >> >> Same for routing rules, firewall rule sets, VLAN settings, et al. >> >> I'd like to see a convergence where all of this information can be >> communicated in a standardized way, but I think that's too much for this >> working group right now. >> >> >> --gun >> >> >> On 8/19/2013 12:29 AM, Joe Marcus Clarke wrote: >>> On 8/18/13 8:06 PM, Waltermire, David A. wrote: >>>> I'm working on updates to the use cases based on feedback received >>>> and there is an outstanding question that was not addressed based on >>>> what I can find. >>>> >>>> >>>> >>>> Is standardizing IDS/IPS signatures in scope? For network-based tools? >>>> For host-based tools? >>>> >>>> >>>> >>>> Any thoughts? >>> >>> I mentioned this as a counter argument to what I was trying to raise >>> asking about vulnerability management. I was asking more about >>> defining a common way to describe a vulnerability, remediation, etc >>> for purposes of interchange. I don't think trying to come up with a >>> standard IPS signature definition should be in the initial SACM scope. >>> >>> Joe >>> > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From jclarke@cisco.com Mon Aug 19 13:47:47 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9855C21F9AD8 for ; Mon, 19 Aug 2013 13:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok-Cv01OZFaX for ; Mon, 19 Aug 2013 13:47:42 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id A1F8411E82DD for ; Mon, 19 Aug 2013 13:47:41 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7JKlcJ2006501; Tue, 20 Aug 2013 05:47:39 +0900 (JST) Received: from prosciutto.local ([10.154.66.189]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7JKlb0G014264; Mon, 19 Aug 2013 13:47:37 -0700 (PDT) Message-ID: <52128469.4040209@cisco.com> Date: Mon, 19 Aug 2013 16:47:37 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Gunnar Engelbach References: <52119F15.1000908@cisco.com> <52122B14.4050302@ThreatGuard.com> <521262E5.4040608@ThreatGuard.com> In-Reply-To: <521262E5.4040608@ThreatGuard.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:47:47 -0000 On 8/19/13 2:24 PM, Gunnar Engelbach wrote: > > Standardizing the characteristics necessary to identify known IDS/IPS > events is a reasonable next step beyond identifying configuration items, > known vulnerabilities, and malware. And, to me, that certainly falls > within the purview of "Security Automation and Continuous Monitoring." > I'd like to see it addressed, but as much as this WG has been whittled > down to its current focus I don't see it as sensible trying to address > it at this time. > > An abstraction step removed from IPS/IDS signatures is standardizing how > to communicate detected events with enough information to make security > decisions. That would be a good first step, but even that much I'm not > convinced SACM has the resources to address at this time. > > Querying a content repository for signatures is a good point. I already > think the query/retrieval mechanism for content repositories needs to be > very open-ended, so I don't see why they couldn't also be used for > proprietary content -- as long as the minimal set of SACM requirements > are also met. > > > So I guess what I'm saying is that I see all of this as in scope, but > none of it will be able to be addressed in this iteration. > > Anyone else? I would agree, but I thought David's question dealt with scope of this charter? Joe > > > > On 8/19/2013 10:58 AM, Waltermire, David A. wrote: >> Just to summarize what I am hearing, the following is true: >> - Defining a format for IDS/IPS signature is not in scope. >> - Supporting format agnostic publication and retrieval of IDS/IPS >> signatures in a content repository is in scope. >> - Supporting the exchange of IDS/IPS signature is in scope allowing >> any arbitrary model to be used for the exchange. >> - Reporting detected IDS/IPS signatures is in scope. Is this true for >> both network-based AND host-based IDS/IPS components? >> >> Is this correct? >> >> Dave >> >>> -----Original Message----- >>> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >>> Sent: Monday, August 19, 2013 10:26 AM >>> To: Joe Marcus Clarke >>> Cc: Waltermire, David A.; sacm@ietf.org >>> Subject: Re: [sacm] SACM Vulnerability Management >>> >>> >>> Standardizing IPS/IDS signature definitions is beyond the current >>> scope of >>> this WG, but standardizing the ability to communicate a detected IDS >>> signature would be very useful in conjunction with known >>> vulnerabilities/misconfigured items -- something akin to CVE/CVSS. >>> >>> Same for routing rules, firewall rule sets, VLAN settings, et al. >>> >>> I'd like to see a convergence where all of this information can be >>> communicated in a standardized way, but I think that's too much for this >>> working group right now. >>> >>> >>> --gun >>> >>> >>> On 8/19/2013 12:29 AM, Joe Marcus Clarke wrote: >>>> On 8/18/13 8:06 PM, Waltermire, David A. wrote: >>>>> I'm working on updates to the use cases based on feedback received >>>>> and there is an outstanding question that was not addressed based on >>>>> what I can find. >>>>> >>>>> >>>>> >>>>> Is standardizing IDS/IPS signatures in scope? For network-based tools? >>>>> For host-based tools? >>>>> >>>>> >>>>> >>>>> Any thoughts? >>>> >>>> I mentioned this as a counter argument to what I was trying to raise >>>> asking about vulnerability management. I was asking more about >>>> defining a common way to describe a vulnerability, remediation, etc >>>> for purposes of interchange. I don't think trying to come up with a >>>> standard IPS signature definition should be in the initial SACM scope. >>>> >>>> Joe >>>> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From david.waltermire@nist.gov Mon Aug 19 13:52:58 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CFD21F9EA9 for ; Mon, 19 Aug 2013 13:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpBPRW6QGlqu for ; Mon, 19 Aug 2013 13:52:43 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id ACFEE21F89D8 for ; Mon, 19 Aug 2013 13:52:43 -0700 (PDT) Received: from WSGHUB2.xchange.nist.gov (129.6.16.197) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 19 Aug 2013 16:52:37 -0400 Received: from wsget2.nist.gov (129.6.13.151) by wsghub2.xchange.nist.gov (129.6.16.197) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 19 Aug 2013 16:52:39 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 19 Aug 2013 16:52:36 -0400 Received: from na01-bl2-obe.outbound.protection.outlook.com (207.46.163.212) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 19 Aug 2013 16:52:38 -0400 Received: from BL2PR09MB036.namprd09.prod.outlook.com (10.255.229.156) by BL2PR09MB036.namprd09.prod.outlook.com (10.255.229.156) with Microsoft SMTP Server (TLS) id 15.0.745.25; Mon, 19 Aug 2013 20:52:32 +0000 Received: from BL2PR09MB036.namprd09.prod.outlook.com ([169.254.3.85]) by BL2PR09MB036.namprd09.prod.outlook.com ([169.254.3.85]) with mapi id 15.00.0745.000; Mon, 19 Aug 2013 20:52:32 +0000 From: "Waltermire, David A." To: Joe Marcus Clarke , Gunnar Engelbach Thread-Topic: [sacm] SACM Vulnerability Management Thread-Index: Ac6cQ81FoxalN6LaRfSMzhSGxulqSgAUNh2AABTcbgAAAN0a8AAHdCCAAAT+hYAAABNAUA== Date: Mon, 19 Aug 2013 20:52:32 +0000 Message-ID: References: <52119F15.1000908@cisco.com> <52122B14.4050302@ThreatGuard.com> <521262E5.4040608@ThreatGuard.com> <52128469.4040209@cisco.com> In-Reply-To: <52128469.4040209@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 09435FCA72 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(199002)(189002)(51704005)(51444003)(377454003)(479174003)(13464003)(252514010)(74876001)(76576001)(74316001)(74706001)(76786001)(76796001)(81686001)(74366001)(53806001)(56816003)(77096001)(81816001)(47446002)(74502001)(74662001)(83072001)(47976001)(80022001)(65816001)(50986001)(47736001)(49866001)(81542001)(4396001)(69226001)(19580385001)(19580405001)(19580395003)(83322001)(46102001)(80976001)(63696002)(33646001)(31966008)(81342001)(77982001)(59766001)(56776001)(76482001)(54316002)(51856001)(66066001)(79102001)(54356001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR09MB036; H:BL2PR09MB036.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Cc: "sacm@ietf.org" Subject: Re: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:52:58 -0000 That was the intent of my questions. I am trying to work out what we want = to capture use cases around in the area of vulnerability management. I am t= rying to develop a sense of what aspect of the use cases are in scope for t= he current charter and what should be documented in the use case draft. Dave > -----Original Message----- > From: Joe Marcus Clarke [mailto:jclarke@cisco.com] > Sent: Monday, August 19, 2013 4:48 PM > To: Gunnar Engelbach > Cc: Waltermire, David A.; sacm@ietf.org > Subject: Re: [sacm] SACM Vulnerability Management >=20 > On 8/19/13 2:24 PM, Gunnar Engelbach wrote: > > > > Standardizing the characteristics necessary to identify known IDS/IPS > > events is a reasonable next step beyond identifying configuration > > items, known vulnerabilities, and malware. And, to me, that certainly > > falls within the purview of "Security Automation and Continuous > Monitoring." > > I'd like to see it addressed, but as much as this WG has been whittled > > down to its current focus I don't see it as sensible trying to address > > it at this time. > > > > An abstraction step removed from IPS/IDS signatures is standardizing > > how to communicate detected events with enough information to make > > security decisions. That would be a good first step, but even that > > much I'm not convinced SACM has the resources to address at this time. > > > > Querying a content repository for signatures is a good point. I > > already think the query/retrieval mechanism for content repositories > > needs to be very open-ended, so I don't see why they couldn't also be > > used for proprietary content -- as long as the minimal set of SACM > > requirements are also met. > > > > > > So I guess what I'm saying is that I see all of this as in scope, but > > none of it will be able to be addressed in this iteration. > > > > Anyone else? >=20 > I would agree, but I thought David's question dealt with scope of this > charter? >=20 > Joe >=20 > > > > > > > > On 8/19/2013 10:58 AM, Waltermire, David A. wrote: > >> Just to summarize what I am hearing, the following is true: > >> - Defining a format for IDS/IPS signature is not in scope. > >> - Supporting format agnostic publication and retrieval of IDS/IPS > >> signatures in a content repository is in scope. > >> - Supporting the exchange of IDS/IPS signature is in scope allowing > >> any arbitrary model to be used for the exchange. > >> - Reporting detected IDS/IPS signatures is in scope. Is this true for > >> both network-based AND host-based IDS/IPS components? > >> > >> Is this correct? > >> > >> Dave > >> > >>> -----Original Message----- > >>> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > >>> Sent: Monday, August 19, 2013 10:26 AM > >>> To: Joe Marcus Clarke > >>> Cc: Waltermire, David A.; sacm@ietf.org > >>> Subject: Re: [sacm] SACM Vulnerability Management > >>> > >>> > >>> Standardizing IPS/IDS signature definitions is beyond the current > >>> scope of this WG, but standardizing the ability to communicate a > >>> detected IDS signature would be very useful in conjunction with > >>> known vulnerabilities/misconfigured items -- something akin to > >>> CVE/CVSS. > >>> > >>> Same for routing rules, firewall rule sets, VLAN settings, et al. > >>> > >>> I'd like to see a convergence where all of this information can be > >>> communicated in a standardized way, but I think that's too much for > >>> this working group right now. > >>> > >>> > >>> --gun > >>> > >>> > >>> On 8/19/2013 12:29 AM, Joe Marcus Clarke wrote: > >>>> On 8/18/13 8:06 PM, Waltermire, David A. wrote: > >>>>> I'm working on updates to the use cases based on feedback received > >>>>> and there is an outstanding question that was not addressed based > >>>>> on what I can find. > >>>>> > >>>>> > >>>>> > >>>>> Is standardizing IDS/IPS signatures in scope? For network-based > tools? > >>>>> For host-based tools? > >>>>> > >>>>> > >>>>> > >>>>> Any thoughts? > >>>> > >>>> I mentioned this as a counter argument to what I was trying to > >>>> raise asking about vulnerability management. I was asking more > >>>> about defining a common way to describe a vulnerability, > >>>> remediation, etc for purposes of interchange. I don't think trying > >>>> to come up with a standard IPS signature definition should be in the > initial SACM scope. > >>>> > >>>> Joe > >>>> > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > >> > > >=20 >=20 > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > -------------------------------------------------------------------------= --- From jclarke@cisco.com Mon Aug 19 13:59:52 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B503721F9D04 for ; Mon, 19 Aug 2013 13:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUl9H+ZrXyuO for ; Mon, 19 Aug 2013 13:59:40 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8270711E82F3 for ; Mon, 19 Aug 2013 13:57:20 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7JKutlV007769; Tue, 20 Aug 2013 05:56:56 +0900 (JST) Received: from prosciutto.local ([10.154.66.189]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7JKunnw024778; Mon, 19 Aug 2013 13:56:49 -0700 (PDT) Message-ID: <52128691.2010502@cisco.com> Date: Mon, 19 Aug 2013 16:56:49 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Waltermire, David A." References: <52119F15.1000908@cisco.com> <52122B14.4050302@ThreatGuard.com> <521262E5.4040608@ThreatGuard.com> <52128469.4040209@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Gunnar Engelbach , "sacm@ietf.org" Subject: Re: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:59:52 -0000 On 8/19/13 4:52 PM, Waltermire, David A. wrote: > That was the intent of my questions. I am trying to work out what we want to capture use cases around in the area of vulnerability management. I am trying to develop a sense of what aspect of the use cases are in scope for the current charter and what should be documented in the use case draft. Then to answer your question speaking for myself, I would say that the points in your email are in scope for both host and network IPS/IDS (noting that the first item in your list around defining a format is out of scope). Joe > > Dave > >> -----Original Message----- >> From: Joe Marcus Clarke [mailto:jclarke@cisco.com] >> Sent: Monday, August 19, 2013 4:48 PM >> To: Gunnar Engelbach >> Cc: Waltermire, David A.; sacm@ietf.org >> Subject: Re: [sacm] SACM Vulnerability Management >> >> On 8/19/13 2:24 PM, Gunnar Engelbach wrote: >>> >>> Standardizing the characteristics necessary to identify known IDS/IPS >>> events is a reasonable next step beyond identifying configuration >>> items, known vulnerabilities, and malware. And, to me, that certainly >>> falls within the purview of "Security Automation and Continuous >> Monitoring." >>> I'd like to see it addressed, but as much as this WG has been whittled >>> down to its current focus I don't see it as sensible trying to address >>> it at this time. >>> >>> An abstraction step removed from IPS/IDS signatures is standardizing >>> how to communicate detected events with enough information to make >>> security decisions. That would be a good first step, but even that >>> much I'm not convinced SACM has the resources to address at this time. >>> >>> Querying a content repository for signatures is a good point. I >>> already think the query/retrieval mechanism for content repositories >>> needs to be very open-ended, so I don't see why they couldn't also be >>> used for proprietary content -- as long as the minimal set of SACM >>> requirements are also met. >>> >>> >>> So I guess what I'm saying is that I see all of this as in scope, but >>> none of it will be able to be addressed in this iteration. >>> >>> Anyone else? >> >> I would agree, but I thought David's question dealt with scope of this >> charter? >> >> Joe >> >>> >>> >>> >>> On 8/19/2013 10:58 AM, Waltermire, David A. wrote: >>>> Just to summarize what I am hearing, the following is true: >>>> - Defining a format for IDS/IPS signature is not in scope. >>>> - Supporting format agnostic publication and retrieval of IDS/IPS >>>> signatures in a content repository is in scope. >>>> - Supporting the exchange of IDS/IPS signature is in scope allowing >>>> any arbitrary model to be used for the exchange. >>>> - Reporting detected IDS/IPS signatures is in scope. Is this true for >>>> both network-based AND host-based IDS/IPS components? >>>> >>>> Is this correct? >>>> >>>> Dave >>>> >>>>> -----Original Message----- >>>>> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >>>>> Sent: Monday, August 19, 2013 10:26 AM >>>>> To: Joe Marcus Clarke >>>>> Cc: Waltermire, David A.; sacm@ietf.org >>>>> Subject: Re: [sacm] SACM Vulnerability Management >>>>> >>>>> >>>>> Standardizing IPS/IDS signature definitions is beyond the current >>>>> scope of this WG, but standardizing the ability to communicate a >>>>> detected IDS signature would be very useful in conjunction with >>>>> known vulnerabilities/misconfigured items -- something akin to >>>>> CVE/CVSS. >>>>> >>>>> Same for routing rules, firewall rule sets, VLAN settings, et al. >>>>> >>>>> I'd like to see a convergence where all of this information can be >>>>> communicated in a standardized way, but I think that's too much for >>>>> this working group right now. >>>>> >>>>> >>>>> --gun >>>>> >>>>> >>>>> On 8/19/2013 12:29 AM, Joe Marcus Clarke wrote: >>>>>> On 8/18/13 8:06 PM, Waltermire, David A. wrote: >>>>>>> I'm working on updates to the use cases based on feedback received >>>>>>> and there is an outstanding question that was not addressed based >>>>>>> on what I can find. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is standardizing IDS/IPS signatures in scope? For network-based >> tools? >>>>>>> For host-based tools? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Any thoughts? >>>>>> >>>>>> I mentioned this as a counter argument to what I was trying to >>>>>> raise asking about vulnerability management. I was asking more >>>>>> about defining a common way to describe a vulnerability, >>>>>> remediation, etc for purposes of interchange. I don't think trying >>>>>> to come up with a standard IPS signature definition should be in the >> initial SACM scope. >>>>>> >>>>>> Joe >>>>>> >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>>> >>> >> >> >> -- >> Joe Marcus Clarke, CCIE #5384, | | >> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >> Phone: +1 (919) 392-2867 c i s c o S y s t e m s >> Email: jclarke@cisco.com >> >> ---------------------------------------------------------------------------- > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From inacio@cert.org Tue Aug 20 06:21:30 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143B611E8100 for ; Tue, 20 Aug 2013 06:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKrumQPDEAl8 for ; Tue, 20 Aug 2013 06:21:26 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id E525011E80D9 for ; Tue, 20 Aug 2013 06:21:17 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7KDLE1O015184; Tue, 20 Aug 2013 09:21:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1377004875; bh=z67Wnn8UQCOLi6kkoWIy7xKH03wwX/FOf0/OXyBbFTU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=FqM7xBBtyuLLlbKALiwDckQTEPTL6DRMHtCpN6nxGAGEtsUCk2FdOf8kApin2xhuE eXHfOMA1p9SjqudhqFZyVBIvx1JY1cSk174XeKEPHhZWLbQcp0z6L/L+LpIatN2nkI uXyXz1PQ2A6Q04cGSmbIctFDxDNrfSv8nJ4XjxqY= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7KDLNQQ004236; Tue, 20 Aug 2013 09:21:23 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0318.004; Tue, 20 Aug 2013 09:21:12 -0400 From: Chris Inacio To: "Waltermire, David A." Thread-Topic: [sacm] SACM Vulnerability Management Thread-Index: Ac6cQ81FoxalN6LaRfSMzhSGxulqSgAcl+KAABTcbQAAASAwAAAu4uMA Date: Tue, 20 Aug 2013 13:21:12 +0000 Message-ID: <4AE532C8B0B4B548AF47570D250D81741422983C@marathon> References: <52119F15.1000908@cisco.com> <52122B14.4050302@ThreatGuard.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.51.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <15B155A0D11A994FA97E43069B4DAFB9@sei.cmu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gunnar Engelbach , Joe Marcus Clarke , "sacm@ietf.org" Subject: Re: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 13:21:30 -0000 -- Chris Inacio inacio@cert.org On Aug 19, 2013, at 10:58 AM, "Waltermire, David A." wrote: > Just to summarize what I am hearing, the following is true: > - Defining a format for IDS/IPS signature is not in scope. Not in scope. This is a huge project/effort unto itself. > - Supporting format agnostic publication and retrieval of IDS/IPS signatu= res in a content repository is in scope. > - Supporting the exchange of IDS/IPS signature is in scope allowing any a= rbitrary model to be used for the exchange. I still think that we should be defining the exchange only; How / if there= is a repository is up to implementors. > - Reporting detected IDS/IPS signatures is in scope. Is this true for bot= h network-based AND host-based IDS/IPS components? >=20 Yes & Yes. > Is this correct? >=20 > Dave >=20 >> -----Original Message----- >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >> Sent: Monday, August 19, 2013 10:26 AM >> To: Joe Marcus Clarke >> Cc: Waltermire, David A.; sacm@ietf.org >> Subject: Re: [sacm] SACM Vulnerability Management >>=20 >>=20 >> Standardizing IPS/IDS signature definitions is beyond the current scope = of >> this WG, but standardizing the ability to communicate a detected IDS >> signature would be very useful in conjunction with known >> vulnerabilities/misconfigured items -- something akin to CVE/CVSS. >>=20 >> Same for routing rules, firewall rule sets, VLAN settings, et al. >>=20 >> I'd like to see a convergence where all of this information can be >> communicated in a standardized way, but I think that's too much for this >> working group right now. >>=20 >>=20 >> --gun >>=20 >>=20 >> On 8/19/2013 12:29 AM, Joe Marcus Clarke wrote: >>> On 8/18/13 8:06 PM, Waltermire, David A. wrote: >>>> I'm working on updates to the use cases based on feedback received >>>> and there is an outstanding question that was not addressed based on >>>> what I can find. >>>>=20 >>>>=20 >>>>=20 >>>> Is standardizing IDS/IPS signatures in scope? For network-based tools? >>>> For host-based tools? >>>>=20 >>>>=20 >>>>=20 >>>> Any thoughts? >>>=20 >>> I mentioned this as a counter argument to what I was trying to raise >>> asking about vulnerability management. I was asking more about >>> defining a common way to describe a vulnerability, remediation, etc >>> for purposes of interchange. I don't think trying to come up with a >>> standard IPS signature definition should be in the initial SACM scope. >>>=20 >>> Joe >>>=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From shanna@juniper.net Tue Aug 20 06:31:47 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A7521F9929 for ; Tue, 20 Aug 2013 06:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7BB7KnwXZqi for ; Tue, 20 Aug 2013 06:31:42 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id DBF3621F9590 for ; Tue, 20 Aug 2013 06:31:41 -0700 (PDT) Received: from mail100-db9-R.bigfish.com (10.174.16.226) by DB9EHSOBE028.bigfish.com (10.174.14.91) with Microsoft SMTP Server id 14.1.225.22; Tue, 20 Aug 2013 13:31:40 +0000 Received: from mail100-db9 (localhost [127.0.0.1]) by mail100-db9-R.bigfish.com (Postfix) with ESMTP id CB0C03A01C8; Tue, 20 Aug 2013 13:31:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371I542I1432I1418Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail100-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51444003)(199002)(13464003)(24454002)(377454003)(479174003)(51704005)(189002)(69226001)(74876001)(53806001)(79102001)(4396001)(47736001)(49866001)(74316001)(81542001)(74502001)(81342001)(76482001)(31966008)(47446002)(74662001)(54356001)(74706001)(56816003)(54316002)(77096001)(80976001)(56776001)(66066001)(80022001)(65816001)(77982001)(59766001)(74366001)(51856001)(47976001)(50986001)(46102001)(63696002)(76576001)(19580385001)(19580405001)(19580395003)(76796001)(76786001)(83072001)(33646001)(81686001)(81816001)(83322001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB056; H:BLUPR05MB053.namprd05.prod.outlook.com; CLIP:66.129.224.51; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail100-db9 (localhost.localdomain [127.0.0.1]) by mail100-db9 (MessageSwitch) id 1377005499205684_9795; Tue, 20 Aug 2013 13:31:39 +0000 (UTC) Received: from DB9EHSMHS019.bigfish.com (unknown [10.174.16.238]) by mail100-db9.bigfish.com (Postfix) with ESMTP id 2C1F02004E; Tue, 20 Aug 2013 13:31:39 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS019.bigfish.com (10.174.14.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 20 Aug 2013 13:31:38 +0000 Received: from BLUPR05MB056.namprd05.prod.outlook.com (10.255.210.151) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.347.3; Tue, 20 Aug 2013 13:31:37 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) by BLUPR05MB056.namprd05.prod.outlook.com (10.255.210.151) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 20 Aug 2013 13:31:36 +0000 Received: from BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.177]) by BLUPR05MB053.namprd05.prod.outlook.com ([169.254.3.177]) with mapi id 15.00.0745.000; Tue, 20 Aug 2013 13:31:36 +0000 From: Stephen Hanna To: Chris Inacio , "Waltermire, David A." Thread-Topic: [sacm] SACM Vulnerability Management Thread-Index: Ac6cQ81FoxalN6LaRfSMzhSGxulqSgAcl+KAABTcbQAAASAwAAAu4uMAAAgFjxA= Date: Tue, 20 Aug 2013 13:31:36 +0000 Message-ID: References: <52119F15.1000908@cisco.com> <52122B14.4050302@ThreatGuard.com> <4AE532C8B0B4B548AF47570D250D81741422983C@marathon> In-Reply-To: <4AE532C8B0B4B548AF47570D250D81741422983C@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.51] x-forefront-prvs: 09443CAA7E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Gunnar Engelbach , Joe Marcus Clarke , "sacm@ietf.org" Subject: Re: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 13:31:47 -0000 +1 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Chris Inacio > Sent: Tuesday, August 20, 2013 9:21 AM > To: Waltermire, David A. > Cc: Gunnar Engelbach; Joe Marcus Clarke; sacm@ietf.org > Subject: Re: [sacm] SACM Vulnerability Management >=20 >=20 > -- > Chris Inacio > inacio@cert.org >=20 >=20 >=20 > On Aug 19, 2013, at 10:58 AM, "Waltermire, David A." > wrote: >=20 > > Just to summarize what I am hearing, the following is true: > > - Defining a format for IDS/IPS signature is not in scope. >=20 > Not in scope. This is a huge project/effort unto itself. >=20 > > - Supporting format agnostic publication and retrieval of IDS/IPS > signatures in a content repository is in scope. > > - Supporting the exchange of IDS/IPS signature is in scope allowing > any arbitrary model to be used for the exchange. >=20 > I still think that we should be defining the exchange only; How / if > there is a repository is up to implementors. >=20 > > - Reporting detected IDS/IPS signatures is in scope. Is this true for > both network-based AND host-based IDS/IPS components? > > > Yes & Yes. >=20 > > Is this correct? > > > > Dave > > > >> -----Original Message----- > >> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] > >> Sent: Monday, August 19, 2013 10:26 AM > >> To: Joe Marcus Clarke > >> Cc: Waltermire, David A.; sacm@ietf.org > >> Subject: Re: [sacm] SACM Vulnerability Management > >> > >> > >> Standardizing IPS/IDS signature definitions is beyond the current > scope of > >> this WG, but standardizing the ability to communicate a detected IDS > >> signature would be very useful in conjunction with known > >> vulnerabilities/misconfigured items -- something akin to CVE/CVSS. > >> > >> Same for routing rules, firewall rule sets, VLAN settings, et al. > >> > >> I'd like to see a convergence where all of this information can be > >> communicated in a standardized way, but I think that's too much for > this > >> working group right now. > >> > >> > >> --gun > >> > >> > >> On 8/19/2013 12:29 AM, Joe Marcus Clarke wrote: > >>> On 8/18/13 8:06 PM, Waltermire, David A. wrote: > >>>> I'm working on updates to the use cases based on feedback received > >>>> and there is an outstanding question that was not addressed based > on > >>>> what I can find. > >>>> > >>>> > >>>> > >>>> Is standardizing IDS/IPS signatures in scope? For network-based > tools? > >>>> For host-based tools? > >>>> > >>>> > >>>> > >>>> Any thoughts? > >>> > >>> I mentioned this as a counter argument to what I was trying to > raise > >>> asking about vulnerability management. I was asking more about > >>> defining a common way to describe a vulnerability, remediation, etc > >>> for purposes of interchange. I don't think trying to come up with > a > >>> standard IPS signature definition should be in the initial SACM > scope. > >>> > >>> Joe > >>> > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From jclarke@cisco.com Tue Aug 20 08:04:55 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126C211E824E for ; Tue, 20 Aug 2013 08:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VbeBu3CmRmj for ; Tue, 20 Aug 2013 08:04:51 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id DF23211E8258 for ; Tue, 20 Aug 2013 08:04:44 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7KF4SnV017911; Wed, 21 Aug 2013 00:04:29 +0900 (JST) Received: from prosciutto.local ([10.154.88.79]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7KF4DBo019743; Tue, 20 Aug 2013 08:04:14 -0700 (PDT) Message-ID: <5213856D.8030101@cisco.com> Date: Tue, 20 Aug 2013 11:04:13 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Chris Inacio References: <52119F15.1000908@cisco.com> <52122B14.4050302@ThreatGuard.com> <4AE532C8B0B4B548AF47570D250D81741422983C@marathon> In-Reply-To: <4AE532C8B0B4B548AF47570D250D81741422983C@marathon> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Gunnar Engelbach , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 15:04:55 -0000 On 8/20/13 9:21 AM, Chris Inacio wrote: >> - Supporting format agnostic publication and retrieval of IDS/IPS signatures in a content repository is in scope. >> - Supporting the exchange of IDS/IPS signature is in scope allowing any arbitrary model to be used for the exchange. > > I still think that we should be defining the exchange only; How / if there is a repository is up to implementors. I think I'm seeing a repository as a natural extension of the exchange (i.e., there may be a collection of these things in a common place from which the exchange takes place). Joe > >> - Reporting detected IDS/IPS signatures is in scope. Is this true for both network-based AND host-based IDS/IPS components? >> > Yes & Yes. > >> Is this correct? >> >> Dave >> >>> -----Original Message----- >>> From: Gunnar Engelbach [mailto:Gunnar.Engelbach@ThreatGuard.com] >>> Sent: Monday, August 19, 2013 10:26 AM >>> To: Joe Marcus Clarke >>> Cc: Waltermire, David A.; sacm@ietf.org >>> Subject: Re: [sacm] SACM Vulnerability Management >>> >>> >>> Standardizing IPS/IDS signature definitions is beyond the current scope of >>> this WG, but standardizing the ability to communicate a detected IDS >>> signature would be very useful in conjunction with known >>> vulnerabilities/misconfigured items -- something akin to CVE/CVSS. >>> >>> Same for routing rules, firewall rule sets, VLAN settings, et al. >>> >>> I'd like to see a convergence where all of this information can be >>> communicated in a standardized way, but I think that's too much for this >>> working group right now. >>> >>> >>> --gun >>> >>> >>> On 8/19/2013 12:29 AM, Joe Marcus Clarke wrote: >>>> On 8/18/13 8:06 PM, Waltermire, David A. wrote: >>>>> I'm working on updates to the use cases based on feedback received >>>>> and there is an outstanding question that was not addressed based on >>>>> what I can find. >>>>> >>>>> >>>>> >>>>> Is standardizing IDS/IPS signatures in scope? For network-based tools? >>>>> For host-based tools? >>>>> >>>>> >>>>> >>>>> Any thoughts? >>>> >>>> I mentioned this as a counter argument to what I was trying to raise >>>> asking about vulnerability management. I was asking more about >>>> defining a common way to describe a vulnerability, remediation, etc >>>> for purposes of interchange. I don't think trying to come up with a >>>> standard IPS signature definition should be in the initial SACM scope. >>>> >>>> Joe >>>> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From inacio@cert.org Wed Aug 21 06:42:39 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD99811E83AD for ; Wed, 21 Aug 2013 06:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pjz2ueoIgMvy for ; Wed, 21 Aug 2013 06:42:35 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6F72911E83B8 for ; Wed, 21 Aug 2013 06:42:32 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7LDgUeH021786; Wed, 21 Aug 2013 09:42:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1377092550; bh=NC3bd+ABqeE4FSXfx1ee/1PPov3jvFctoahuemSBFIg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=Jk+PHeQeT9krSx9CyfZNEQaWACnwoeqOoJzbBMvBlIZLWzIZmgqEbkYCH0+Ms4t4c TF+p3P0TPC9TQDcIr8Uqlzo9AMuCGpkJaB9hMH/bkbY9H6xcPEYvhoDocT8/OC5wf5 IqMb0+wNsNV3hL5tJkn2SrDrRo0uuXOnQdysaLIA= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r7LDgekS028038; Wed, 21 Aug 2013 09:42:40 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0318.004; Wed, 21 Aug 2013 09:42:29 -0400 From: Chris Inacio To: Joe Marcus Clarke Thread-Topic: [sacm] SACM Vulnerability Management Thread-Index: Ac6cQ81FoxalN6LaRfSMzhSGxulqSgAcl+KAABTcbQAAASAwAAAu4uMAAAOZCoAAL2+0AA== Date: Wed, 21 Aug 2013 13:42:28 +0000 Message-ID: <4AE532C8B0B4B548AF47570D250D81741422CEB4@marathon> References: <52119F15.1000908@cisco.com> <52122B14.4050302@ThreatGuard.com> <4AE532C8B0B4B548AF47570D250D81741422983C@marathon> <5213856D.8030101@cisco.com> In-Reply-To: <5213856D.8030101@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.100.21] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0A76B25B992F04488D2077FA47FADAB0@sei.cmu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gunnar Engelbach , "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 13:42:39 -0000 On Aug 20, 2013, at 11:04 AM, Joe Marcus Clarke wrote: > On 8/20/13 9:21 AM, Chris Inacio wrote: >>> - Supporting format agnostic publication and retrieval of IDS/IPS signa= tures in a content repository is in scope. >>> - Supporting the exchange of IDS/IPS signature is in scope allowing any= arbitrary model to be used for the exchange. >>=20 >> I still think that we should be defining the exchange only; How / if th= ere is a repository is up to implementors. >=20 > I think I'm seeing a repository as a natural extension of the exchange > (i.e., there may be a collection of these things in a common place from > which the exchange takes place). >=20 > Joe >=20 +1 Exactly my thought. But, the braindead implementation doesn't have a repository and always answ= ers back "I don't know." Presumably, the market doesn't want that solution= =85but, I'm not the market. -- Chris Inacio inacio@cert.org From ietf@rozanak.com Wed Aug 21 07:37:58 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB03811E8210 for ; Wed, 21 Aug 2013 07:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JXljZKytiln for ; Wed, 21 Aug 2013 07:37:54 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 31C7211E83B3 for ; Wed, 21 Aug 2013 07:37:47 -0700 (PDT) Received: from kopoli ([141.89.226.146]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M1WYz-1W5EA63cU5-00tlh8; Wed, 21 Aug 2013 10:37:38 -0400 From: "Hosnieh Rafiee" To: "'Chris Inacio'" , "'Joe Marcus Clarke'" References: <52119F15.1000908@cisco.com> <52122B14.4050302@ThreatGuard.com> <4AE532C8B0B4B548AF47570D250D81741422983C@marathon> <5213856D.8030101@cisco.com> <4AE532C8B0B4B548AF47570D250D81741422CEB4@marathon> In-Reply-To: <4AE532C8B0B4B548AF47570D250D81741422CEB4@marathon> Date: Wed, 21 Aug 2013 16:37:26 +0200 Message-ID: <000c01ce9e7b$f9edf290$edc9d7b0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIJOUhpufPNlXAVdPm++Mk1ARKCpAK9eQ7OAWH+NlICZIElDAJZ+WDxAXBj/H8B3mXwAJjJHnsg Content-Language: en-us X-Provags-ID: V02:K0:rqJKl10jMyyRIETfosJ+kThyqwP2o2binDo9qwxJowr bYCnzGny9aygml7lcY8TDRRXwwziEGaQ8lYM0BrbVsLRcXWluT kp1vboX2eA2i2RtgdBpzRbdBdyZ+I6F+Mtt+YI8rp5p6qyormV oqqaYvycYTRIEDq+jnsqGA1Cvcif5sL/cHQO8Lqmyio/eQzbaV 3RoM12urItOXQEbwcsKctY1N0gQoPWgsG61rfWuq8CPF+boeie y6vMeJMEoHWoIs/AaQ3b0P8XRx6ae7lw7DTSlOhTJ6td+DMQBU aC/QJfM6TeJ1VVPlSuEUo0v6DkLFbKUK1kt5U04Fb1Kuvt7I2k pk889I1eFsDt1D34Y7b4= Cc: 'Gunnar Engelbach' , "'Waltermire, David A.'" , sacm@ietf.org Subject: Re: [sacm] SACM Vulnerability Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 14:37:58 -0000 If you are looking for an implementation of vulnerability models and a repository where keeps all the vulnerability, we already have a running system. But I am not quite sure how this can be helpful. Hosnieh > > On Aug 20, 2013, at 11:04 AM, Joe Marcus Clarke wrote: > > > On 8/20/13 9:21 AM, Chris Inacio wrote: > >>> - Supporting format agnostic publication and retrieval of IDS/IPS signatures > in a content repository is in scope. > >>> - Supporting the exchange of IDS/IPS signature is in scope allowing any > arbitrary model to be used for the exchange. > >> > >> I still think that we should be defining the exchange only; How / if there is a > repository is up to implementors. > > > > I think I'm seeing a repository as a natural extension of the exchange > > (i.e., there may be a collection of these things in a common place > > from which the exchange takes place). > > > > Joe > > > > +1 > > Exactly my thought. > > But, the braindead implementation doesn't have a repository and always > answers back "I don't know." Presumably, the market doesn't want that > solution.but, I'm not the market. > > -- > Chris Inacio > inacio@cert.org > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From internet-drafts@ietf.org Thu Aug 22 14:12:36 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C2D21F896D; Thu, 22 Aug 2013 14:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfPlMJw6JkEB; Thu, 22 Aug 2013 14:12:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD9F21F8904; Thu, 22 Aug 2013 14:12:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130822211236.14832.81258.idtracker@ietfa.amsl.com> Date: Thu, 22 Aug 2013 14:12:36 -0700 X-Mailman-Approved-At: Fri, 23 Aug 2013 01:50:01 -0700 Cc: sacm@ietf.org Subject: [sacm] I-D Action: draft-ietf-sacm-use-cases-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 21:12:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Security Automation and Continuous Monito= ring Working Group of the IETF. Title : Using Security Posture Assessment to Grant Access to Ent= erprise Network Resources Author(s) : David Waltermire David Harrington Filename : draft-ietf-sacm-use-cases-00.txt Pages : 18 Date : 2013-08-22 Abstract: This memo documents a sampling of use cases for securely aggregating configuration and operational data and assessing that data to determine an organization's security posture. From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and assessing data relevant to security posture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dromasca@avaya.com Fri Aug 23 01:58:01 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EDE21F9D38 for ; Fri, 23 Aug 2013 01:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.184 X-Spam-Level: X-Spam-Status: No, score=-102.184 tagged_above=-999 required=5 tests=[AWL=-0.984, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRJj+y-A7eKC for ; Fri, 23 Aug 2013 01:57:55 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 571D721F9D2C for ; Fri, 23 Aug 2013 01:57:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4JAKwjF1LGmAcV/2dsb2JhbABagmYhNVGDG6gwlDQXgQgWbQeCJAEBAQEDEhERMh8GAQgNBAQBAQMCBgsBAg8DAgQfERQBBgEBBQUEEwgBCw6HXAMPAQuVWIREijuIQw2BIogvF4EpjESBQIEIDy8ECAYGgkozewOVfAGIOYVhhSmDH4FyOQ X-IronPort-AV: E=Sophos;i="4.89,940,1367985600"; d="scan'208";a="25224784" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Aug 2013 04:57:53 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Aug 2013 04:53:39 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Fri, 23 Aug 2013 10:57:52 +0200 From: "Romascanu, Dan (Dan)" To: "sacm@ietf.org" Thread-Topic: 88th IETF - Working Group/BOF/IRTF Scheduling Thread-Index: AQHOn5Mbg0HEW5h6oEGtOQFVeWVZgpmifOng Date: Fri, 23 Aug 2013 08:57:51 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128B6669@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sacm] FW: 88th IETF - Working Group/BOF/IRTF Scheduling X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 08:58:01 -0000 DQpIaSwNCg0KSUVURiA4OCBpcyBub3QgdGhhdCBmYXIuIFJlcXVlc3RzIGZvciBtZWV0aW5nIHNj aGVkdWxpbmcgYXJlIG5vdyBhY2NlcHRlZC4gDQoNCldlIHBsYW4gdG8gcmVxdWVzdCBhIDIgaG91 cnMgbWVldGluZyBzbG90IGxpa2Ugd2UgZGlkIGxhc3QgdGltZS4gDQoNClByaW5jaXBhbCBjb250 cmlidXRvcnMgYW5kIGVzcGVjaWFsbHkgZG9jdW1lbnQgYXV0aG9ycyBhcmUgd2VsY29tZSB0byBz ZW5kIHVzIHRoZWlyIHBlcnNvbmFsIGxpc3RzIG9mIGNyaXRpY2FsIGNvbmZsaWN0cy4gDQoNCldl IHBsYW4gdG8gYXNrIGZvciBNZWV0ZWNobyBzdXBwb3J0LiBXZSBzaGFsbCBhbHNvIGFzayBub3Qg dG8gYmUgc2NoZWR1bGVkIG9uIEZyaWRheSwgYXMgd2UgZGlkIG91ciB0b3VyIG9mIGR1dHkgb24g dGhpcyByZXNwZWN0IGF0IElFVEYtODcgaW4gQmVybGluLiBIb3dldmVyLCBwbGVhc2UgdGFrZSBp bnRvIGNvbnNpZGVyYXRpb24gdGhhdCBub3QgYWxsIHNjaGVkdWxpbmcgcmVxdWVzdHMgY2FuIGFu ZCB3aWxsIGJlIGdyYW50ZWQsIGFuZCB0aGF0IHNjaGVkdWxpbmcgaXMgZmluYWwgb25seSB3aGVu IHRoZSBmaW5hbCBhZ2VuZGEgd2lsbCBiZSBwdWJsaXNoZWQgKG9uIDEwLzExKS4gDQoNClRoYW5r cyBhbmQgUmVnYXJkcywNCg0KQWRhbSBhbmQgRGFuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogd2djaGFpcnMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOndnY2hhaXJz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJRVRGIEFnZW5kYQ0KU2VudDogRnJpZGF5 LCBBdWd1c3QgMjMsIDIwMTMgMjo1NSBBTQ0KVG86IFdvcmtpbmcgR3JvdXAgQ2hhaXJzDQpDYzog aXJzZ0BpcnRmLm9yZw0KU3ViamVjdDogODh0aCBJRVRGIC0gV29ya2luZyBHcm91cC9CT0YvSVJU RiBTY2hlZHVsaW5nDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCjg4dGggSUVURiDigJMgVmFuY291dmVyLCBCQywg Q2FuYWRhDQpNZWV0aW5nIERhdGVzOiBOb3ZlbWJlciAzIOKAkyA4LCAyMDEzDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K SUVURiBtZWV0aW5ncyBzdGFydCBNb25kYXkgbW9ybmluZyBhbmQgcnVuIHRocm91Z2ggRnJpZGF5 IGFmdGVybm9vbiAoMTM6MzApLg0KDQpXZSBhcmUgYWNjZXB0aW5nIHNjaGVkdWxpbmcgcmVxdWVz dHMgZm9yIGFsbCBXb3JraW5nIEdyb3VwcywgQk9GcywgYW5kIFJlc2VhcmNoIEdyb3VwcyBzdGFy dGluZyB0b2RheS4gIFRoZSBtaWxlc3RvbmVzIGFuZCBkZWFkbGluZXMgZm9yIHNjaGVkdWxpbmct cmVsYXRlZCBhY3Rpdml0aWVzIGFyZSBhcyBmb2xsb3dzOg0KDQpOT1RFOiBjdXRvZmYgZGF0ZXMg YXJlIHN1YmplY3QgdG8gY2hhbmdlLg0KDQotIDIwMTMtMDgtMTkgKFdlZWsgb2YpOiBXb3JraW5n IEdyb3VwIGFuZCBCT0Ygc2NoZWR1bGluZyBiZWdpbnMuIFRvIHJlcXVlc3QgYSBXb3JraW5nIEdy b3VwIHNlc3Npb24sIHVzZSB0aGUgSUVURiBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBUb29sLiAo dXBkYXRlZCBmcm9tIDUgQXVndXN0KS4NCi0gMjAxMy0wOS0yMyAoTW9uZGF5KTogQ3V0b2ZmIGRh dGUgZm9yIHJlcXVlc3RzIHRvIHNjaGVkdWxlIFdvcmtpbmcgR3JvdXAgbWVldGluZ3MgYXQgVVRD IDI0OjAwLiBUbyByZXF1ZXN0IGEgV29ya2luZyBHcm91cCBzZXNzaW9uLCB1c2UgdGhlIElFVEYg TWVldGluZyBTZXNzaW9uIFJlcXVlc3QgVG9vbC4NCi0gMjAxMy0wOS0yMyAoTW9uZGF5KTogQ3V0 b2ZmIGRhdGUgZm9yIEJPRiBwcm9wb3NhbCByZXF1ZXN0cyB0byBBcmVhIERpcmVjdG9ycyBhdCBV VEMgMjQ6MDAuIFRvIHJlcXVlc3QgYSBCT0YsIHBsZWFzZSBzZWUgaW5zdHJ1Y3Rpb25zIG9uIFJl cXVlc3RpbmcgYSBCT0YuDQotIDIwMTMtMDktMjYgKFRodXJzZGF5KTogQ3V0b2ZmIGRhdGUgZm9y IEFyZWEgRGlyZWN0b3JzIHRvIGFwcHJvdmUgQk9GcyBhdCBVVEMgMjQ6MDAuDQotIDIwMTMtMTAt MDMgKFRodXJzZGF5KTogUHJlbGltaW5hcnkgYWdlbmRhIHB1Ymxpc2hlZCBmb3IgY29tbWVudC4N Ci0gMjAxMy0xMC0wNyAoTW9uZGF5KTogQ3V0b2ZmIGRhdGUgZm9yIHJlcXVlc3RzIHRvIHJlc2No ZWR1bGUgV29ya2luZyBHcm91cCBhbmQgQk9GIG1lZXRpbmdzIFVUQyAyNDowMC4NCi0gMjAxMy0x MC0xMSAoRnJpZGF5KTogRmluYWwgYWdlbmRhIHRvIGJlIHB1Ymxpc2hlZC4NCi0gMjAxMy0xMC0y MyAoV2VkbmVzZGF5KTogRHJhZnQgV29ya2luZyBHcm91cCBhZ2VuZGFzIGR1ZSBieSBVVEMgMjQ6 MDAsIHVwbG9hZCB1c2luZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbC4N Ci0gMjAxMy0xMC0yOCAoTW9uZGF5KTogUmV2aXNlZCBXb3JraW5nIEdyb3VwIGFnZW5kYXMgZHVl IGJ5IFVUQyAyNDowMCwgdXBsb2FkIHVzaW5nIElFVEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdl bWVudCBUb29sLg0KLSAyMDEzLTEyLTA2IChGcmlkYXkpOiBQcm9jZWVkaW5ncyBzdWJtaXNzaW9u IGN1dG9mZiBkYXRlIGJ5IFVUQyAyNDowMCwgdXBsb2FkIHVzaW5nIElFVEYgTWVldGluZyBNYXRl cmlhbHMgTWFuYWdlbWVudCBUb29sLg0KLSAyMDEzLTEyLTI1IChXZWRuZXNkYXkpOiBQcm9jZWVk aW5ncyBzdWJtaXNzaW9uIGNvcnJlY3Rpb25zIGN1dG9mZiBkYXRlIGJ5IFVUQyAyNDowMCwgdXBs b2FkIHVzaW5nIElFVEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBUb29sLg0KDQpTdWJt aXR0aW5nIFJlcXVlc3RzIGZvciBXb3JraW5nIEdyb3VwIGFuZCBCT0YgU2Vzc2lvbnMNCg0KUGxl YXNlIHN1Ym1pdCByZXF1ZXN0cyB0byBzY2hlZHVsZSB5b3VyIFdvcmtpbmcgR3JvdXAgc2Vzc2lv bnMgdXNpbmcgdGhlICJJRVRGIE1lZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0IFRvb2wsIiBhIFdlYi1i YXNlZCB0b29sIGZvciBzdWJtaXR0aW5nIGFsbCBvZiB0aGUgaW5mb3JtYXRpb24gdGhhdCB0aGUg U2VjcmV0YXJpYXQgcmVxdWlyZXMgdG8gc2NoZWR1bGUgeW91ciBzZXNzaW9ucy4NCg0KVGhlIFVS TCBmb3IgdGhlIHRvb2wgaXM6DQoNCmh0dHBzOi8vcHViLmlldGYub3JnL3NyZXEvDQoNClBsZWFz ZSBzZW5kIHJlcXVlc3RzIHRvIHNjaGVkdWxlIHlvdXIgQk9GIHNlc3Npb25zIHRvIGFnZW5kYUBp ZXRmLm9yZy4gIFBsZWFzZSBpbmNsdWRlIHRoZSBhY3JvbnltIG9mIHlvdXIgQk9GIGluIHRoZSBz dWJqZWN0IGxpbmUgb2YgdGhlIG1lc3NhZ2UsIGFuZCBpbmNsdWRlIGFsbCBvZiB0aGUgaW5mb3Jt YXRpb24gc3BlY2lmaWVkIGluIGl0ZW0gKDQpIG9mICJSZXF1ZXN0aW5nIE1lZXRpbmcgU2Vzc2lv bnMgYXQgSUVURiBNZWV0aW5ncyIgaW4gdGhlIGJvZHkuICAoVGhpcyBkb2N1bWVudCBpcyBpbmNs dWRlZCBiZWxvdy4pDQoNClN1Ym1pdHRpbmcgU2Vzc2lvbiBBZ2VuZGFzDQoNCkZvciB0aGUgY29u dmVuaWVuY2Ugb2YgbWVldGluZyBhdHRlbmRlZXMsIHdlIGFzayB0aGF0IHlvdSBzdWJtaXQgdGhl IGFnZW5kYXMgZm9yIHlvdXIgV29ya2luZyBHcm91cCBzZXNzaW9ucyBhcyBlYXJseSBhcyBwb3Nz aWJsZS4gIERyYWZ0IFdvcmtpbmcgR3JvdXAgYWdlbmRhcyBhcmUgZHVlIFdlZG5lc2RheSwgT2N0 b2JlciAyM3JkLCAyMDEzIGF0IFVUQyAyNDowMC4gIFJldmlzZWQgV29ya2luZyBHcm91cCBhZ2Vu ZGFzIGFyZSBkdWUgbm8gbGF0ZXIgdGhhbiBNb25kYXksIE9jdG9iZXIgMjgsIDIwMTMgYXQgVVRD IDI0OjAwLiAgVGhlIHByb3Bvc2VkIGFnZW5kYSBmb3IgYSBCT0Ygc2Vzc2lvbiBzaG91bGQgYmUg c3VibWl0dGVkIGFsb25nIHdpdGggeW91ciByZXF1ZXN0IGZvciBhIHNlc3Npb24uICBQbGVhc2Ug YmUgc3VyZSB0byBjb3B5IHlvdXIgQXJlYSBEaXJlY3RvciBvbiB0aGF0IG1lc3NhZ2UuDQoNClBs ZWFzZSBzdWJtaXQgdGhlIGFnZW5kYXMgZm9yIHlvdXIgV29ya2luZyBHcm91cCBzZXNzaW9ucyB1 c2luZyB0aGUgIklFVEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBUb29sLCIgYSBXZWIt YmFzZWQgdG9vbCBmb3IgbWFraW5nIHlvdXIgbWVldGluZyBhZ2VuZGEsIG1pbnV0ZXMsIGFuZCBw cmVzZW50YXRpb24gc2xpZGVzIGF2YWlsYWJsZSB0byB0aGUgY29tbXVuaXR5IGJlZm9yZSwgZHVy aW5nLCBhbmQgYWZ0ZXIgYW4gSUVURiBtZWV0aW5nLiAgSWYgeW91IGFyZSBhIEJPRiBjaGFpciwg dGhlbiB5b3UgbWF5IHVzZSB0aGUgdG9vbCB0byBzdWJtaXQgYSByZXZpc2VkIGFnZW5kYSBhcyB3 ZWxsIGFzIG90aGVyIG1hdGVyaWFscyBmb3IgeW91ciBCT0Ygb25jZSB0aGUgQk9GIGhhcyBiZWVu IGFwcHJvdmVkLg0KDQpUaGUgVVJMIGZvciB0aGUgdG9vbCBpczoNCg0KaHR0cHM6Ly9wdWIuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvDQoNCkFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhpcyB0 b29sIGlzIGF2YWlsYWJsZSBhdDoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnN0cnVjdGlvbnMv bWVldGluZ19tYXRlcmlhbHNfdG9vbC5odG1sDQoNCkFnZW5kYXMgc3VibWl0dGVkIHZpYSB0aGUg dG9vbCB3aWxsIGJlIGF2YWlsYWJsZSB0byB0aGUgcHVibGljIG9uIHRoZSAiSUVURiBNZWV0aW5n IE1hdGVyaWFscyIgd2VicGFnZSBhcyBzb29uIGFzIHRoZXkgYXJlIHN1Ym1pdHRlZC4NCg0KVGhl IFVSTCBmb3IgdGhlICJJRVRGIDg4IE1lZXRpbmcgTWF0ZXJpYWxzIiBXZWIgcGFnZSBpczoNCg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzg4L21hdGVyaWFscy5odG1sDQoN CklmIHlvdSBhcmUgYSBXb3JraW5nIEdyb3VwIGNoYWlyLCB0aGVuIHlvdSBhbHJlYWR5IGhhdmUg YWNjb3VudHMgb24gdGhlICJJRVRGIE1lZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0IFRvb2wiIGFuZCB0 aGUgIklFVEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBUb29sLiIgIFRoZSBzYW1lIFVz ZXIgSUQgYW5kIHBhc3N3b3JkIHdpbGwgd29yayBmb3IgYm90aCB0b29scy4gIElmIHlvdSBhcmUg YSBCT0YgY2hhaXIgd2hvIGlzIG5vdCBhbHNvIGEgV29ya2luZyBHcm91cCBjaGFpciwgdGhlbiB5 b3Ugd2lsbCBiZSBnaXZlbiBhbiBhY2NvdW50IG9uIHRoZSAiSUVURiBNZWV0aW5nIE1hdGVyaWFs cyBNYW5hZ2VtZW50IFRvb2wiIHdoZW4geW91ciBCT0YgaGFzIGJlZW4gYXBwcm92ZWQuICBJZiB5 b3UgcmVxdWlyZSBhc3Npc3RhbmNlIGluIHVzaW5nIGVpdGhlciB0b29sLCBvciB3aXNoIHRvIHJl cG9ydCBhIGJ1ZywgdGhlbiBwbGVhc2Ugc2VuZCBhIG1lc3NhZ2UgdG86DQppZXRmLWFjdGlvbkBp ZXRmLm9yZy4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KRm9yIHlvdXIgY29udmVuaWVuY2UsIGNvbXByZWhlbnNpdmUgaW5m b3JtYXRpb24gb24gcmVxdWVzdGluZyBtZWV0aW5nIHNlc3Npb25zIGF0IElFVEYgODggaXMgcHJl c2VudGVkIGJlbG93Og0KDQoxLiBSZXF1ZXN0cyB0byBzY2hlZHVsZSBXb3JraW5nIEdyb3VwIHNl c3Npb25zIHNob3VsZCBiZSBzdWJtaXR0ZWQgdXNpbmcgdGhlICJJRVRGIE1lZXRpbmcgU2Vzc2lv biBSZXF1ZXN0IFRvb2wsIiBhIFdlYi1iYXNlZCB0b29sIGZvciBzdWJtaXR0aW5nIGFsbCBvZiB0 aGUgaW5mb3JtYXRpb24gcmVxdWlyZWQgYnkgdGhlIFNlY3JldGFyaWF0IHRvIHNjaGVkdWxlIHlv dXIgc2Vzc2lvbnMuICBUaGUgVVJMIGZvciB0aGUgdG9vbCBpczoNCg0KaHR0cHM6Ly9wdWIuaWV0 Zi5vcmcvc3JlcS8NCg0KSW5zdHJ1Y3Rpb25zIGZvciB1c2luZyB0aGUgdG9vbCBhcmUgYXZhaWxh YmxlIGF0Og0KDQpodHRwOi8vd3d3LmlldGYub3JnL2luc3RydWN0aW9ucy9zZXNzaW9uX3JlcXVl c3RfdG9vbF9pbnN0cnVjdGlvbi5odG1sDQoNCklmIHlvdSByZXF1aXJlIGFuIGFjY291bnQgb24g dGhpcyB0b29sLCBvciBhc3Npc3RhbmNlIGluIHVzaW5nIGl0LCB0aGVuIHBsZWFzZSBzZW5kIGEg bWVzc2FnZSB0byBpZXRmLWFjdGlvbkBpZXRmLm9yZy4gIElmIHlvdSBhcmUgdW5hYmxlIHRvIHVz ZSB0aGUgdG9vbCwgdGhlbiB5b3UgbWF5IHNlbmQgeW91ciByZXF1ZXN0IHZpYSBlLW1haWwgdG8g YWdlbmRhQGlldGYub3JnLCB3aXRoIGEgY29weSB0byB0aGUgYXBwcm9wcmlhdGUgQXJlYSBEaXJl Y3RvcihzKS4NCg0KUmVxdWVzdHMgdG8gc2NoZWR1bGUgQk9GIHNlc3Npb25zIG11c3QgYmUgc2Vu dCB0byBhZ2VuZGFAaWV0Zi5vcmcgd2l0aCBhIGNvcHkgdG8gdGhlIGFwcHJvcHJpYXRlIEFyZWEg RGlyZWN0b3IocykuDQoNCldoZW4gc3VibWl0dGluZyBhIFdvcmtpbmcgR3JvdXAgb3IgQk9GIHNl c3Npb24gcmVxdWVzdCBieSBlLW1haWwsIHBsZWFzZSBpbmNsdWRlIHRoZSBXb3JraW5nIEdyb3Vw IG9yIEJPRiBhY3JvbnltIGluIHRoZSBTdWJqZWN0IGxpbmUuDQoNCjIuIEJPRnMgd2lsbCBOT1Qg YmUgc2NoZWR1bGVkIHVubGVzcyB0aGUgQXJlYSBEaXJlY3RvciBhcHByb3ZlcyB0aGUgQk9GLiBU aGUgcHJvcG9uZW50cyBiZWhpbmQgYSBCT0YgbmVlZCB0byBjb250YWN0IGEgcmVsZXZhbnQgQXJl YSBEaXJlY3RvciwgcHJlZmVyYWJseSB3ZWxsIGluIGFkdmFuY2Ugb2YgdGhlIEJPRiBhcHByb3Zh bCBkZWFkbGluZSBkYXRlLiBUaGUgQUQgbmVlZHMgdG8gaGF2ZSB0aGUgZnVsbCBuYW1lIG9mIHRo ZSBCT0YsIGl0cyBhY3JvbnltLCBzdWdnZXN0ZWQgbmFtZXMgb2YgY2hhaXJzLCBhbiBhZ2VuZGEs IGZ1bGwgZGVzY3JpcHRpb24gb2YgdGhlIEJPRiBhbmQgdGhlIGluZm9ybWF0aW9uIGNvdmVyZWQg aW4gaXRlbSA0LiBQbGVhc2UgcmVhZCBSRkMgNTQzNCBmb3IgaW5zdHJ1Y3Rpb25zIG9uIGhvdyB0 byBkcml2ZSBhIHN1Y2Nlc3NmdWwgQk9GIGVmZm9ydC4gVGhlIGFwcHJvdmFsIGRlcGVuZHMgb24s IGZvciBpbnN0YW5jZSwgSW50ZXJuZXQtRHJhZnRzIGFuZCBsaXN0IGRpc2N1c3Npb24gb24gdGhl IHN1Z2dlc3RlZCB0b3BpYy4gQk9GIGFnZW5kYSByZXF1ZXN0cywgaWYgYXBwcm92ZWQsIHdpbGwg YmUgc3VibWl0dGVkIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGJ5IHRoZSBBRHMuDQoNCjMuIEEg V29ya2luZyBHcm91cCBtYXkgcmVxdWVzdCBlaXRoZXIgb25lIG9yIHR3byBzZXNzaW9ucy4gIElm IHlvdXIgV29ya2luZyBHcm91cCByZXF1aXJlcyBtb3JlIHRoYW4gdHdvIHNlc3Npb25zLCB0aGVu IHlvdXIgcmVxdWVzdCBtdXN0IGJlIGFwcHJvdmVkIGJ5IGFuIEFyZWEgRGlyZWN0b3IuICBBZGRp dGlvbmFsIHNlc3Npb25zIHdpbGwgYmUgYXNzaWduZWQsIGJhc2VkIG9uIGF2YWlsYWJpbGl0eSwg YWZ0ZXIgTW9uZGF5LCBPY3RvYmVyIDcsIDIwMTMsIHRoZSBjdXQtb2ZmIGRhdGUgZm9yIHJlcXVl c3RzIHRvIHJlc2NoZWR1bGUgYSBzZXNzaW9uLg0KDQo0LiBZb3UgTVVTVCBwcm92aWRlIHRoZSBm b2xsb3dpbmcgaW5mb3JtYXRpb24gYmVmb3JlIGEgV29ya2luZyBHcm91cCBvciBCT0Ygc2Vzc2lv biB3aWxsIGJlIHNjaGVkdWxlZDoNCg0KICAgIGEuIFdvcmtpbmcgR3JvdXAgb3IgQk9GIGZ1bGwg bmFtZSB3aXRoIGFjcm9ueW0gaW4gYnJhY2tldHM6IA0KDQogICAgYi4gQVJFQSB1bmRlciB3aGlj aCBXb3JraW5nIEdyb3VwIG9yIEJPRiBhcHBlYXJzOg0KDQogICAgYy4gQ09ORkxJQ1RTIHlvdSB3 aXNoIHRvIGF2b2lkLCBwbGVhc2UgYmUgYXMgc3BlY2lmaWMgYXMgcG9zc2libGU6DQoNCiAgICBk LiBFeHBlY3RlZCBBdHRlbmRhbmNlOg0KDQogICAgZS4gU3BlY2lhbCByZXF1ZXN0czoNCg0KICAg IGYuIE51bWJlciBvZiBzZXNzaW9uczoNCg0KICAgIGcuIExlbmd0aCBvZiBzZXNzaW9uOiANCiAg ICAgICAtIDEgaG91ciANCiAgICAgICAtIDEgMS8yIGhvdXJzDQogICAgICAgLSAyIGhvdXJzIA0K ICAgICAgIC0gMiAxLzIgaG91cnMNCg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gb24gc2NoZWR1bGlu ZyBXb3JraW5nIEdyb3VwIGFuZCBCT0Ygc2Vzc2lvbnMsIHBsZWFzZSByZWZlciB0byBSRkMgMjQx OCAoQkNQIDI1KSwgIklFVEYgV29ya2luZyBHcm91cCBHdWlkZWxpbmVzIGFuZCBQcm9jZWR1cmVz IiAoaHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjMjQxOC50eHQpLg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpGb3IgeW91 ciBjb252ZW5pZW5jZSBwbGVhc2UgZmluZCBoZXJlIGEgbGlzdCBvZiB0aGUgSUVURiBBcmVhIERp cmVjdG9ycyB3aXRoIHRoZWlyIGUtbWFpbCBhZGRyZXNzZXM6DQoNCklFVEYgQ2hhaXINCkphcmkg QXJra28gPGphcmkuYXJra29AcGl1aGEubmV0Pg0KDQpBcHBsaWNhdGlvbnMgQXJlYSAoYXBwKQ0K ICAgICAgICBCYXJyeSBMZWliYSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+DQogICAgICAgIFBl dGUgUmVzbmljayA8cHJlc25pY2tAcXVhbGNvbW0uY29tPg0KDQpJbnRlcm5ldCBBcmVhIChpbnQp DQpCcmlhbiBIYWJlcm1hbiA8YnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0PiANCiAgICAgICAgVGVk IExlbW9uIDx0ZWQubGVtb25Abm9taW51bS5jb20+DQoNCk9wZXJhdGlvbnMgJiBNYW5hZ2VtZW50 IEFyZWEgKG9wcykNCkJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPg0KSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPg0KDQpSZWFsLXRpbWUgQXBwbGljYXRpb25zIGFuZCBJbmZy YXN0cnVjdHVyZSBBcmVhIChyYWkpIEdvbnphbG8gQ2FtYXJpbGxvIDxnb256YWxvLmNhbWFyaWxs b0Blcmljc3Nvbi5jb20+IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4PiAgDQoNClJvdXRpbmcg QXJlYSAocnRnKQ0KU3Rld2FydCBCcnlhbnQgPHN0YnJ5YW50QGNpc2NvLmNvbT4NCkFkcmlhbiBG YXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs+ICANCg0KU2VjdXJpdHkgQXJlYSAoc2VjKQ0KU3Rl cGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiBTZWFuIFR1cm5lciA8dHVy bmVyc0BpZWNhLmNvbT4gIA0KDQpUcmFuc3BvcnQgQXJlYSAodHN2KQ0KTWFydGluIFN0aWVtZXJs aW5nIDxtYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1PiBTcGVuY2VyIERhd2tpbnMgIDxzcGVu Y2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4gID09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo4N3RoIElFVEYgTWVldGluZyBBdHRlbmRh bmNlIE51bWJlcnMNCg0KNmxvIC0gMTI3DQo2bWFuIC0gMTY2DQo2dHNjaCBCb0YgLSAxMDENCmFi ZmFiIC0gMjINCmFsdG8gIC0gNzMNCmFwcHNhd2cgLSA5OA0KYXFtIEJvRiAtIDg2DQphdnRjb3Jl IC0gNjQNCmF2dGV4dCAtIDM3DQpiZWhhdmUgLSA2MQ0KYm13ZyAtIDIwDQpjY2FtcCAtIDUzDQpj Y2FtcCAoMm5kIHNlc3Npb24pIC0gNTkNCmNkbmkgLSA3Mw0KY2RuaSAoMm5kIHNlc3Npb24pIC0g MzgNCmNmcmcgKFJHKSAtIDQwDQpjbHVlIC0gNDYNCmNsdWUgKDJuZCBzZXNzaW9uKSAtIDMzDQpj b25leCAtIDY3DQpjb3JlIC0gMTA3DQpjb3JlICgybmQgc2Vzc2lvbikgLSA0Ng0KZGFuZSAtIDky DQpkaGMgKGpvaW50IHNlc3Npb24gd2l0aCBzdW5zZXQ0KSAtIDExMA0KZGhjICgybmQgc2Vzc2lv bikgLSA1NA0KZGljZSBCb0YgLSAxMTINCmRpbWUgLSAxNw0KZG1hcmMgQm9GIC0gNDcNCmRtbSAt IDMwDQpkbnNvcCAtIDExNg0KZG5zc2RleHQgQm9GIC0gMTM3DQpkdG5yZyAoUkcpIC0gNDQNCmR0 bnJnIChSRykgKDJuZCBzZXNzaW9uKSAtIDQ0DQplY3JpdCAtIDQ1DQplbWFuIC0gNDMNCmVtdSAt IDM2DQpmb3JjZXMgLSA2OQ0KZ3JvdyAtIDYzDQpob21lbmV0IC0gMTI4DQpodHRwYXV0aCAtIDU5 DQpodHRwYmlzIC0gOTMNCmh0dHBiaXMgKDJuZCBzZXNzaW9uKSAtIDcyDQppMnJzIC0gMjU3DQpp Y2NyZyAoUkcpIC0gNjgNCmljY3JnIChSRykgKDJuZCBzZXNzaW9uKSAtIDc3DQppY25yZyAoUkcp IC0gODYNCmlkciAtIDY0DQppbnNpcGlkIC0gMzUNCmludGFyZWEgKEFHKSAtIDkzDQppcGZpeCAt IDM1DQppcHBtIC0gNjQNCmlwcmJpcyAoQm9GKSAtIDI2DQppcHNlY21lIC0gNDgNCklSVEYgT3Bl biBNZWV0aW5nIC0gMTIxDQppc2lzIC0gMjgNCmpvc2UgLSA1NQ0KanNvbiAtIDM2DQprYXJwIC0g MzENCmtpdHRlbiAtIDI1DQpsMnZwbiAtIDY0DQpsM3ZwbiAtIDgxDQpsbWFwIC0gNzYNCmx3aWcg LSA1NQ0KbWFuZXQgLSA0OQ0KbWJvbmVkIC0gMTINCm1pZiAtIDQxDQptaWxlIC0gNDMNCm1tdXNp YyAtIDc2DQptbXVzaWMgKDJuZCBzZXNzaW9uKSAtIDg1DQptcGxzIC0gMTI5DQptcGxzICgybmQg c2Vzc2lvbikgLSA3OA0KbXB0Y3AgLSAxMDgNCm11bHRpbW9iIC0gMjkNCm5jcmcgKFJHKSAtIDM4 DQpuZXRjb25mIC0gNTINCm5ldGV4dCAtIDQwDQpuZXRtb2QgLSA1Mg0KbmZzdjQgLSAyMg0Kbm1y ZyAoUkcpIC0gNTkNCm5zYyBCb0YgLSAyODENCm52bzMgLSAxODINCm53Y3JnIChQUkcpIC0gNDkN Cm9hdXRoIC0gNjINCm9wc2F3ZyAtIDYyDQpvcHNlYyAtIDUyDQpvc3BmIC0gMjENCnAycHNpcCAt IDIwDQpwYXdzIC0gMjINCnBjZSAtIDgyDQpwY3AgLSAyOQ0KcGNwICgybmQgc2Vzc2lvbikgLSA0 MA0KcGltIC0gMTgNCnBvc2ggQm9GIC0gODcNCnBwc3AgLSAxNA0KcHJlY2lzIC0gMTkNCnB3ZTMg LSAzMw0KcmFkZXh0IC0gMjINCnJtY2F0IC0gOTENCnJ0Y3dlYiAtIDEyNw0KcnRjd2ViICgybmQg c2Vzc2lvbikgLSAxMzINCnJ0Z2FyZWEgKEFHKSAtIDExOA0KcnRnd2cgLSA1MQ0Kc2FhZyAoQUcp IC0gMTQ4DQpzYWNtIC0gNDUNCnNjaW0gLSAyNg0Kc2RucmcgKFJHKSAtIDI4OA0Kc2lkciAtIDYy DQpzaWRyICgybmQgc2Vzc2lvbikgLSA1OA0Kc2lwcmVjIC0gMjcNCnNvZnR3aXJlIC0gNzgNCnN0 YXR1cyBCb0YgLSAyMTQNCnN0aXIgLSAxMjYNCnN0b3ggLSAzNA0Kc3Vuc2V0NCAtIDk5DQpzdW5z ZXQ0IChqb2ludCBzZXNzaW9uIHdpdGggZGhjKSAtIDExMA0KdGNtdGYgQm9GIC0gODkNCnRjcG0g LSA2OA0KdGljdG9jIC0gMjINCnRscyAtIDYzDQp0cmlsbCAtIDMxDQp0c3ZhcmVhIChBRykgLSAx MTINCnRzdndnIC0gNTkNCnRzdndnICgybmQgc2Vzc2lvbikgLSA1MA0KdXJuYmlzIC0gOQ0KdjZv cHMgLSAxMTANCnY2b3BzICgybmQgc2Vzc2lvbikgLSAxMTgNCndlYnNlYyAtIDY4DQp3ZWlyZHMg LSA2NQ0KeHJibG9jayAtIDI2DQo= From aawoland@cisco.com Sun Aug 25 05:00:42 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B803321F9BC3 for ; Sun, 25 Aug 2013 05:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojKrYrI5fYCZ for ; Sun, 25 Aug 2013 05:00:38 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id 4899A21F9BC1 for ; Sun, 25 Aug 2013 05:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2854; q=dns/txt; s=iport; t=1377432038; x=1378641638; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ZPNuiKKDfciko/X+qkDW8tJBSxw9pLxzSpc2/X2WPio=; b=mcQNAQ0xSTMhdPfRp5gGJXKTdBAFSL39uxfA25Gf5S623nDZbjjyE2/A 0RMMfPC7PmM2isUw5aHfEjcPkP8XdH/ZfyQQDYXioGDXRHJV8KRZcYP6T GbyC+LDkhkLI8zeqDpARgReO5/siwjb22XRtAp2HDcKxT7rXpQM518GID k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAOPwGVKtJXHA/2dsb2JhbABZgwc1UcAUgRoWdIIkAQEBBAEBATc0CwwGAQgRBAEBCxQJLgsUCQgCBAENBQgMh20MtiKQRQIxBwaDFn0DmRuQNIMegio X-IronPort-AV: E=Sophos;i="4.89,951,1367971200"; d="scan'208";a="239445529" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-1.cisco.com with ESMTP; 25 Aug 2013 12:00:35 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7PC0ZZx025659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 Aug 2013 12:00:35 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.31]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Sun, 25 Aug 2013 07:00:35 -0500 From: "Aaron Woland (aawoland)" To: "Romascanu, Dan (Dan)" , Michael Hammer , "kathleen.moriarty@emc.com" , "eric.walker@us.ibm.com" , "inacio@cert.org" Thread-Topic: [sacm] SACM - consensus on defining SACM terminology in a separate document Thread-Index: Ac6SpHgZAWpvrX0vRxuTXCLSjTwOnwAE6OWwAWomTwAAAvA2AAAAQ4GAAAB4/4AAIerCAAISYXKA Date: Sun, 25 Aug 2013 12:00:34 +0000 Message-ID: <862FA31948313540BD2843B1AA96F25C4707E919@xmb-rcd-x01.cisco.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128AAFA0@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.35.88.139] Content-Type: text/plain; charset="us-ascii" Content-ID: <2FCA39307555F34A936F4336D440FE6A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Adam.Montville@cisecurity.org" , "sacm@ietf.org" Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a separate document X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 12:00:42 -0000 Do we have an author for the separate terminology document? I have volunteered as I feel it will be a good way for me to start to get involved.=20 -Aaron --=20 Regards, Aaron T. Woland, CCIE #20113 Secure Access TME, SAMPG ciscoSystems, Inc. Check out my Secure Network Access Blog at Network World Author: Cisco ISE for BYOD and Secure Unified Access On 8/14/13 5:03 AM, "Romascanu, Dan (Dan)" wrote: >Indeed. What matters is the resulting document (Internet-Draft). How the >authors get there is completely up to them. > >Regards, > >Dan > > > >> -----Original Message----- >> From: Michael Hammer [mailto:michael.hammer@yaanatech.com] >> Sent: Tuesday, August 13, 2013 7:52 PM >> To: kathleen.moriarty@emc.com; eric.walker@us.ibm.com; inacio@cert.org >> Cc: Romascanu, Dan (Dan); Adam.Montville@cisecurity.org; sacm@ietf.org >> Subject: RE: [sacm] SACM - consensus on defining SACM terminology in a >> separate document >>=20 >> I don't think there are any restrictions on how a group of authors >> creates >> an ID. >> So long as the resulting ID has the correct boilerplate. >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >> Moriarty, Kathleen >> Sent: Tuesday, August 13, 2013 12:39 PM >> To: Eric Walker; Chris Inacio >> Cc: Romascanu, Dan (Dan); Adam Montville; sacm@ietf.org >> Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a >> separate document >>=20 >> That has been done for other working groups where they can edit the >> document >> and generate the updated draft in RFC format when ready for an update. >>=20 >> -Kathleen >> ________________________________________ >> From: sacm-bounces@ietf.org [sacm-bounces@ietf.org] On Behalf Of Eric >> Walker >> [eric.walker@us.ibm.com] >> Sent: Tuesday, August 13, 2013 12:31 PM >> To: Chris Inacio >> Cc: Romascanu, Dan (Dan); Adam Montville; sacm@ietf.org >> Subject: Re: [sacm] SACM - consensus on defining SACM terminology in a >> separate document >>=20 >> >Can we set up some type of wiki that might allow multiple folks >> >simultaneous editing so that people working on the various drafts that >> >would depend on this (use-cases, arch, requirements) can all work >> >unimpeded? >>=20 >> How about a Github repo? >>=20 >> Eric >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Tue Aug 27 11:00:48 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808E411E81D5 for ; Tue, 27 Aug 2013 11:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7ct218y7xXz for ; Tue, 27 Aug 2013 11:00:40 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 6389B21E8093 for ; Tue, 27 Aug 2013 11:00:27 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 27 Aug 2013 14:00:09 -0400 Received: from wsget1.nist.gov (129.6.13.150) by WSXGHUB2.xchange.nist.gov (129.6.18.19) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 27 Aug 2013 14:00:25 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 27 Aug 2013 14:00:08 -0400 Received: from na01-bn1-obe.outbound.protection.outlook.com (207.46.163.151) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Aug 2013 14:00:24 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 27 Aug 2013 18:00:22 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.203]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.203]) with mapi id 15.00.0745.000; Tue, 27 Aug 2013 18:00:21 +0000 From: "Waltermire, David A." To: "sacm@ietf.org" Thread-Topic: Use Cases: Asset Management Thread-Index: Ac6jS+SiTBbEy9ALTVebMV+UWgzW6A== Date: Tue, 27 Aug 2013 18:00:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 0951AB0A30 x-forefront-antispam-report: SFV:NSPM; SFS:(54534003)(189002)(199002)(59766001)(74502001)(54316002)(56776001)(77982001)(81686001)(31966008)(74662001)(47446002)(63696002)(79102001)(15202345003)(65816001)(80022001)(33646001)(76576001)(76796001)(74876001)(83072001)(76786001)(69226001)(66066001)(81816001)(76176001)(49866001)(81542001)(50986001)(47976001)(74316001)(83322001)(81342001)(47736001)(15975445006)(4396001)(19300405004)(19580395003)(46102001)(74706001)(16236675002)(74366001)(56816003)(77096001)(53806001)(54356001)(80976001)(76482001)(51856001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB038; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_b21457b8de5646a78221e0b35f044785BLUPR09MB038namprd09pro_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: [sacm] Use Cases: Asset Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 18:00:48 -0000 X-List-Received-Date: Tue, 27 Aug 2013 18:00:48 -0000 --_000_b21457b8de5646a78221e0b35f044785BLUPR09MB038namprd09pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Last week I posted the WG draft version of the use cases document (http://d= atatracker.ietf.org/doc/draft-ietf-sacm-use-cases/). Changes since the -05 = version are listing in the change log within the document (http://tools.iet= f.org/html/draft-ietf-sacm-use-cases-00#section-8). What I'd like to do next is focus the WGs attention on individual sections = of the use case document for a week or two each to work on wrapping up the = text and to develop overall consensus. Starting this week I would like to f= ocus on section 4.1 Asset Management (http://tools.ietf.org/html/draft-ietf= -sacm-use-cases-00#section-4.1). My hope is that this approach will lead us= through development of the document before the next draft submission deadl= ine. Based on the current text I have the following questions: 1) Is the current structure of this section acceptable? If not, what s= hould be done differently? 2) Are there key terms that should be defined in the terminology draft= ? If so, what terms and what definition should be used? 3) We currently have the following sub-sections that represent differe= nt lifecycle aspects related to Asset Management. Are these the best way to= break up asset management into discrete use cases? a. Asset Discovery b. Asset Identification c. Endpoint Components and Asset Composition d. Asset Characterization e. Asset Resources f. Asset Representation Reconciliation g. Asset Life Cycle 4) Do you agree with the current text in each sub-section? If not, wh= y not? Do you have alternate text to contribute? 5) Here are a few questions regarding some of the sub-sections: a. Asset Characterization - Are there other important characteristics= to list? b. Asset Resources - Should this be addressed under asset management o= r under data collection in a different section? Is the human- vs. machine-c= ollected distinction important here? c. Asset Representation Reconciliation - We need text to flesh this s= ection out. Any volunteers? d. Asset Life Cycle - Is this section needed? If so, what do we want t= o say? Any volunteers willing to contribute text? 6) Do you have any other general comments/questions on this section? Please let me know your thoughts on these questions. I'll make edits to th= e document as we agree on any changes that should be made. Sincerely, Dave --_000_b21457b8de5646a78221e0b35f044785BLUPR09MB038namprd09pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Last week I posted the WG draft version of the use c= ases document (http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/).= Changes since the -05 version are listing in the change log within the document (http://tools.ietf.org/html/draft= -ietf-sacm-use-cases-00#section-8).

 

What I’d like to do next is focus the WGs atte= ntion on individual sections of the use case document for a week or two eac= h to work on wrapping up the text and to develop overall consensus. Startin= g this week I would like to focus on section 4.1 Asset Management (http://tools.ietf.org/html/draft-ietf-sacm-use-= cases-00#section-4.1). My hope is that this approach will lead us throu= gh development of the document before the next draft submission deadline.

 

Based on the current text I have the following quest= ions:

 

1)      Is the current structure of this section acceptable= ? If not, what should be done differently?

2)      Are there key terms that should be defined in the t= erminology draft? If so, what terms and what definition should be used?

3)      We currently have the following sub-sections that r= epresent different lifecycle aspects related to Asset Management. Are these= the best way to break up asset management into discrete use cases?

a.       Asset Discovery

b.      Asset Identification

c.       Endpoint Components and Asset Composition

d.      Asset Characterization

e.      Asset Resources

f.      &nbs= p; Asset Representation Reconciliation

g.       Asset Life Cycle

4)      Do you agree with the current text in each sub-sect= ion?  If not, why not? Do you have alternate text to contribute?<= /o:p>

5)      Here are a few questions regarding some of the sub-= sections:

a.       Asset Characterization – Are there other impo= rtant characteristics to list?

b.      Asset Resources – Should this be addressed un= der asset management or under data collection in a different section? Is th= e human- vs. machine-collected distinction important here?

c.       Asset Representation Reconciliation – We need= text to flesh this section out. Any volunteers?

d.      Asset Life Cycle – Is this section needed? If= so, what do we want to say? Any volunteers willing to contribute text?

6)      Do you have any other general comments/questions on= this section?

 

Please let me know your thoughts on these questions.=   I’ll make edits to the document as we agree on any changes tha= t should be made.

 

Sincerely,

Dave

--_000_b21457b8de5646a78221e0b35f044785BLUPR09MB038namprd09pro_-- From gunnar.engelbach@threatguard.com Wed Aug 28 11:00:57 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A60E21F9EC9 for ; Wed, 28 Aug 2013 11:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tLABAfvSa7s for ; Wed, 28 Aug 2013 11:00:53 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6AC21F98AD for ; Wed, 28 Aug 2013 11:00:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=dBKI3sAqcbdGOcRkAXSWtwh+992uJVeLrBh56s8qm4yaXTXBtzzYivdQbyQY7I8u2duymCaYDw/7WerzRlT0dsKOSphBp6lj/W0riToRsH0n6DHhuq2OzJ3H/HwJCAy0; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 25384 invoked from network); 28 Aug 2013 11:00:38 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 28 Aug 2013 11:00:38 -0700 Message-ID: <521E3AD8.6070908@ThreatGuard.com> Date: Wed, 28 Aug 2013 14:00:56 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Waltermire, David A." References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "sacm@ietf.org" Subject: Re: [sacm] Use Cases: Asset Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 18:00:57 -0000 4.1.1 Asset Discovery, first paragraph: "alowing" could use another l. Now that you mention it, I found myself wondering of asset management is really a SCAM use case. Certainly the needs of SACM intersect with asset management, but is it really one of the goals of SACM that we produce standards for creating an asset management system? On 8/27/2013 2:00 PM, Waltermire, David A. wrote: > Last week I posted the WG draft version of the use cases document > (http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/). Changes > since the -05 version are listing in the change log within the document > (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-8). > > What I’d like to do next is focus the WGs attention on individual > sections of the use case document for a week or two each to work on > wrapping up the text and to develop overall consensus. Starting this > week I would like to focus on section 4.1 Asset Management > (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-4.1). > My hope is that this approach will lead us through development of the > document before the next draft submission deadline. > > Based on the current text I have the following questions: > > 1)Is the current structure of this section acceptable? If not, what > should be done differently? > > 2)Are there key terms that should be defined in the terminology draft? > If so, what terms and what definition should be used? > > 3)We currently have the following sub-sections that represent different > lifecycle aspects related to Asset Management. Are these the best way to > break up asset management into discrete use cases? > > a.Asset Discovery > > b.Asset Identification > > c.Endpoint Components and Asset Composition > > d.Asset Characterization > > e.Asset Resources > > f.Asset Representation Reconciliation > > g.Asset Life Cycle > > 4)Do you agree with the current text in each sub-section? If not, why > not? Do you have alternate text to contribute? > > 5)Here are a few questions regarding some of the sub-sections: > > a.Asset Characterization – Are there other important characteristics to > list? > > b.Asset Resources – Should this be addressed under asset management or > under data collection in a different section? Is the human- vs. > machine-collected distinction important here? > > c.Asset Representation Reconciliation – We need text to flesh this > section out. Any volunteers? > > d.Asset Life Cycle – Is this section needed? If so, what do we want to > say? Any volunteers willing to contribute text? > > 6)Do you have any other general comments/questions on this section? > > Please let me know your thoughts on these questions. I’ll make edits to > the document as we agree on any changes that should be made. > > Sincerely, > > Dave > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > From henk.birkholz@sit.fraunhofer.de Wed Aug 28 11:27:58 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22C421E808C for ; Wed, 28 Aug 2013 11:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snIIfNsYYM7a for ; Wed, 28 Aug 2013 11:27:52 -0700 (PDT) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB1B21E8050 for ; Wed, 28 Aug 2013 11:27:50 -0700 (PDT) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171] (may be forged)) by mailext.sit.fraunhofer.de (8.14.2/8.13.6/9.9.9) with ESMTP id r7SIRkBs000579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Wed, 28 Aug 2013 20:27:48 +0200 Received: from [192.168.0.71] (134.102.43.163) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 Aug 2013 20:27:40 +0200 Message-ID: <521E411B.70900@sit.fraunhofer.de> Date: Wed, 28 Aug 2013 20:27:39 +0200 From: Henk Birkholz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: References: <521E3AD8.6070908@ThreatGuard.com> In-Reply-To: <521E3AD8.6070908@ThreatGuard.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.43.163] Subject: Re: [sacm] Use Cases: Asset Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 18:27:58 -0000 Information about assets provides the link/relationship between monitoring techniques, services, vulnerabilities, etc. While Asset Management is indeed a quite general term, it incorperates the acquisition and provision of asset information which is an important prerequisite in sacm, I think. On 08/28/2013 08:00 PM, Gunnar Engelbach wrote: > > 4.1.1 Asset Discovery, first paragraph: "alowing" could use another l. > > > Now that you mention it, I found myself wondering of asset management is > really a SCAM use case. Certainly the needs of SACM intersect with > asset management, but is it really one of the goals of SACM that we > produce standards for creating an asset management system? > > > > > On 8/27/2013 2:00 PM, Waltermire, David A. wrote: >> Last week I posted the WG draft version of the use cases document >> (http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/). Changes >> since the -05 version are listing in the change log within the document >> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-8). >> >> What I’d like to do next is focus the WGs attention on individual >> sections of the use case document for a week or two each to work on >> wrapping up the text and to develop overall consensus. Starting this >> week I would like to focus on section 4.1 Asset Management >> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-4.1). >> My hope is that this approach will lead us through development of the >> document before the next draft submission deadline. >> >> Based on the current text I have the following questions: >> >> 1)Is the current structure of this section acceptable? If not, what >> should be done differently? >> >> 2)Are there key terms that should be defined in the terminology draft? >> If so, what terms and what definition should be used? >> >> 3)We currently have the following sub-sections that represent different >> lifecycle aspects related to Asset Management. Are these the best way to >> break up asset management into discrete use cases? >> >> a.Asset Discovery >> >> b.Asset Identification >> >> c.Endpoint Components and Asset Composition >> >> d.Asset Characterization >> >> e.Asset Resources >> >> f.Asset Representation Reconciliation >> >> g.Asset Life Cycle >> >> 4)Do you agree with the current text in each sub-section? If not, why >> not? Do you have alternate text to contribute? >> >> 5)Here are a few questions regarding some of the sub-sections: >> >> a.Asset Characterization – Are there other important characteristics to >> list? >> >> b.Asset Resources – Should this be addressed under asset management or >> under data collection in a different section? Is the human- vs. >> machine-collected distinction important here? >> >> c.Asset Representation Reconciliation – We need text to flesh this >> section out. Any volunteers? >> >> d.Asset Life Cycle – Is this section needed? If so, what do we want to >> say? Any volunteers willing to contribute text? >> >> 6)Do you have any other general comments/questions on this section? >> >> Please let me know your thoughts on these questions. I’ll make edits to >> the document as we agree on any changes that should be made. >> >> Sincerely, >> >> Dave >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Wed Aug 28 11:50:22 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A38721F99A1 for ; Wed, 28 Aug 2013 11:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV-yQk4V5Oxl for ; Wed, 28 Aug 2013 11:50:17 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id C6C8821F9962 for ; Wed, 28 Aug 2013 11:50:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=TkJ4e7ZeNgpQMwL87A6m0RIzWFgru7FXa//uEjW8/7fFVwLUx6CSKK2d/STCBswhtRx+wkMv4w3L/bAsV2cURQ7CRIaxT8AALthV42cpVkxXEwRC7rB2/EayNdMMr3CS; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 27273 invoked from network); 28 Aug 2013 11:50:03 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 28 Aug 2013 11:50:03 -0700 Message-ID: <521E466C.7070002@ThreatGuard.com> Date: Wed, 28 Aug 2013 14:50:20 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Henk Birkholz References: <521E3AD8.6070908@ThreatGuard.com> <521E411B.70900@sit.fraunhofer.de> In-Reply-To: <521E411B.70900@sit.fraunhofer.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: sacm@ietf.org Subject: Re: [sacm] Use Cases: Asset Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 18:50:22 -0000 Yes, the needs of SACM intersect with the realm of asset management. But, again, is standardizing asset management really a use case for SACM? Putting it another way, is it reasonable to think that somebody would deploy a SACM system for the sole purpose of doing asset management? On 8/28/2013 2:27 PM, Henk Birkholz wrote: > Information about assets provides the link/relationship between > monitoring techniques, services, vulnerabilities, etc. While Asset > Management is indeed a quite general term, it incorperates the > acquisition and provision of asset information which is an important > prerequisite in sacm, I think. > > On 08/28/2013 08:00 PM, Gunnar Engelbach wrote: >> >> 4.1.1 Asset Discovery, first paragraph: "alowing" could use another l. >> >> >> Now that you mention it, I found myself wondering of asset management is >> really a SCAM use case. Certainly the needs of SACM intersect with >> asset management, but is it really one of the goals of SACM that we >> produce standards for creating an asset management system? >> >> >> >> >> On 8/27/2013 2:00 PM, Waltermire, David A. wrote: >>> Last week I posted the WG draft version of the use cases document >>> (http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/). Changes >>> since the -05 version are listing in the change log within the document >>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-8). >>> >>> What I’d like to do next is focus the WGs attention on individual >>> sections of the use case document for a week or two each to work on >>> wrapping up the text and to develop overall consensus. Starting this >>> week I would like to focus on section 4.1 Asset Management >>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-4.1). >>> My hope is that this approach will lead us through development of the >>> document before the next draft submission deadline. >>> >>> Based on the current text I have the following questions: >>> >>> 1)Is the current structure of this section acceptable? If not, what >>> should be done differently? >>> >>> 2)Are there key terms that should be defined in the terminology draft? >>> If so, what terms and what definition should be used? >>> >>> 3)We currently have the following sub-sections that represent different >>> lifecycle aspects related to Asset Management. Are these the best way to >>> break up asset management into discrete use cases? >>> >>> a.Asset Discovery >>> >>> b.Asset Identification >>> >>> c.Endpoint Components and Asset Composition >>> >>> d.Asset Characterization >>> >>> e.Asset Resources >>> >>> f.Asset Representation Reconciliation >>> >>> g.Asset Life Cycle >>> >>> 4)Do you agree with the current text in each sub-section? If not, why >>> not? Do you have alternate text to contribute? >>> >>> 5)Here are a few questions regarding some of the sub-sections: >>> >>> a.Asset Characterization – Are there other important characteristics to >>> list? >>> >>> b.Asset Resources – Should this be addressed under asset management or >>> under data collection in a different section? Is the human- vs. >>> machine-collected distinction important here? >>> >>> c.Asset Representation Reconciliation – We need text to flesh this >>> section out. Any volunteers? >>> >>> d.Asset Life Cycle – Is this section needed? If so, what do we want to >>> say? Any volunteers willing to contribute text? >>> >>> 6)Do you have any other general comments/questions on this section? >>> >>> Please let me know your thoughts on these questions. I’ll make edits to >>> the document as we agree on any changes that should be made. >>> >>> Sincerely, >>> >>> Dave >>> >>> >>> >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm >>> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Wed Aug 28 13:34:00 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2D421E8063 for ; Wed, 28 Aug 2013 13:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl9uYXO3-0Fy for ; Wed, 28 Aug 2013 13:33:54 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id CFC8111E81B2 for ; Wed, 28 Aug 2013 13:33:53 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 28 Aug 2013 16:33:32 -0400 Received: from wsget1.nist.gov (129.6.13.150) by WSXGHUB2.xchange.nist.gov (129.6.18.19) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 28 Aug 2013 16:33:49 -0400 Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 28 Aug 2013 16:33:31 -0400 Received: from na01-bn1-obe.outbound.protection.outlook.com (207.46.163.153) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 Aug 2013 16:33:49 -0400 Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 28 Aug 2013 20:33:45 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.203]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.9.157]) with mapi id 15.00.0745.000; Wed, 28 Aug 2013 20:33:45 +0000 From: "Waltermire, David A." To: Gunnar Engelbach , Henk Birkholz Thread-Topic: [sacm] Use Cases: Asset Management Thread-Index: Ac6jS+SiTBbEy9ALTVebMV+UWgzW6AAzKZ0AAADu3YAAAMrOAAADKi2Q Date: Wed, 28 Aug 2013 20:33:45 +0000 Message-ID: <824fcf330d0945b6a97e63b80591720f@BLUPR09MB038.namprd09.prod.outlook.com> References: <521E3AD8.6070908@ThreatGuard.com> <521E411B.70900@sit.fraunhofer.de> <521E466C.7070002@ThreatGuard.com> In-Reply-To: <521E466C.7070002@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.152] x-forefront-prvs: 09525C61DB x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(54534003)(24454002)(189002)(199002)(51704005)(479174003)(377454003)(59766001)(77982001)(74502001)(56776001)(54316002)(81816001)(81686001)(31966008)(63696002)(74662001)(47446002)(79102001)(15202345003)(65816001)(80022001)(33646001)(76786001)(74876001)(83072001)(76796001)(66066001)(69226001)(76576001)(49866001)(81542001)(50986001)(74316001)(47976001)(83322001)(19580405001)(47736001)(81342001)(15975445006)(4396001)(19580395003)(46102001)(74706001)(74366001)(77096001)(56816003)(54356001)(53806001)(80976001)(76482001)(51856001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB038; H:BLUPR09MB038.namprd09.prod.outlook.com; CLIP:129.6.224.152; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Cc: "sacm@ietf.org" Subject: Re: [sacm] Use Cases: Asset Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:34:00 -0000 Gunnar, Are you suggesting that we remove the asset management section from the use= case draft? If not, what would you change? More comments below. > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Gunnar Engelbach > Sent: Wednesday, August 28, 2013 2:50 PM > To: Henk Birkholz > Cc: sacm@ietf.org > Subject: Re: [sacm] Use Cases: Asset Management >=20 >=20 > Yes, the needs of SACM intersect with the realm of asset management. Agreed. We need to focus use cases around this intersection. > But, again, is standardizing asset management really a use case for SACM? Strictly speaking, I would say no. But some aspects like asset discovery (i= dentifying new endpoints that join a network), asset identification (relati= ng collected data to assets), and asset representation reconciliation (sort= ing out different identification approaches) are aspects that we need to de= al with as a matter of the SACM scope. Asset characterization is a bit more= nuanced. I believe at minimum we need some capability to get data about an= asset that sets an expectation of its intended posture. For example, we ne= ed to know something about what the intended function of the device is to u= nderstand how to evaluate its posture. > Putting it another way, is it reasonable to think that somebody would dep= loy > a SACM system for the sole purpose of doing asset management? Possibly, but not likely. If we address asset discovery, which I believe we= should, this capability could be used standalone without any further data = collection.=20 >=20 >=20 >=20 >=20 > On 8/28/2013 2:27 PM, Henk Birkholz wrote: > > Information about assets provides the link/relationship between > > monitoring techniques, services, vulnerabilities, etc. While Asset > > Management is indeed a quite general term, it incorperates the > > acquisition and provision of asset information which is an important > > prerequisite in sacm, I think. > > > > On 08/28/2013 08:00 PM, Gunnar Engelbach wrote: > >> > >> 4.1.1 Asset Discovery, first paragraph: "alowing" could use another l= . > >> > >> > >> Now that you mention it, I found myself wondering of asset management > is > >> really a SCAM use case. Certainly the needs of SACM intersect with > >> asset management, but is it really one of the goals of SACM that we > >> produce standards for creating an asset management system? > >> > >> > >> > >> > >> On 8/27/2013 2:00 PM, Waltermire, David A. wrote: > >>> Last week I posted the WG draft version of the use cases document > >>> (http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/). Changes > >>> since the -05 version are listing in the change log within the docume= nt > >>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-8). > >>> > >>> What I'd like to do next is focus the WGs attention on individual > >>> sections of the use case document for a week or two each to work on > >>> wrapping up the text and to develop overall consensus. Starting this > >>> week I would like to focus on section 4.1 Asset Management > >>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-4.1)= . > >>> My hope is that this approach will lead us through development of the > >>> document before the next draft submission deadline. > >>> > >>> Based on the current text I have the following questions: > >>> > >>> 1)Is the current structure of this section acceptable? If not, what > >>> should be done differently? > >>> > >>> 2)Are there key terms that should be defined in the terminology draft= ? > >>> If so, what terms and what definition should be used? > >>> > >>> 3)We currently have the following sub-sections that represent differe= nt > >>> lifecycle aspects related to Asset Management. Are these the best way > to > >>> break up asset management into discrete use cases? > >>> > >>> a.Asset Discovery > >>> > >>> b.Asset Identification > >>> > >>> c.Endpoint Components and Asset Composition > >>> > >>> d.Asset Characterization > >>> > >>> e.Asset Resources > >>> > >>> f.Asset Representation Reconciliation > >>> > >>> g.Asset Life Cycle > >>> > >>> 4)Do you agree with the current text in each sub-section? If not, wh= y > >>> not? Do you have alternate text to contribute? > >>> > >>> 5)Here are a few questions regarding some of the sub-sections: > >>> > >>> a.Asset Characterization - Are there other important characteristics = to > >>> list? > >>> > >>> b.Asset Resources - Should this be addressed under asset management > or > >>> under data collection in a different section? Is the human- vs. > >>> machine-collected distinction important here? > >>> > >>> c.Asset Representation Reconciliation - We need text to flesh this > >>> section out. Any volunteers? > >>> > >>> d.Asset Life Cycle - Is this section needed? If so, what do we want t= o > >>> say? Any volunteers willing to contribute text? > >>> > >>> 6)Do you have any other general comments/questions on this section? > >>> > >>> Please let me know your thoughts on these questions. I'll make edits= to > >>> the document as we agree on any changes that should be made. > >>> > >>> Sincerely, > >>> > >>> Dave > >>> > >>> > >>> > >>> _______________________________________________ > >>> sacm mailing list > >>> sacm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sacm > >>> > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From ietfdbh@comcast.net Wed Aug 28 15:11:27 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3C021F9D95 for ; Wed, 28 Aug 2013 15:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e0XR4KT2XgB for ; Wed, 28 Aug 2013 15:11:22 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 6326321F9D35 for ; Wed, 28 Aug 2013 15:11:22 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta15.westchester.pa.mail.comcast.net with comcast id JBLM1m0051YDfWL5FNBMR5; Wed, 28 Aug 2013 22:11:21 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta20.westchester.pa.mail.comcast.net with comcast id JNBM1m00W2yZEBF3gNBMLv; Wed, 28 Aug 2013 22:11:21 +0000 From: "ietfdbh" To: "'Gunnar Engelbach'" , "'Henk Birkholz'" References: <521E3AD8.6070908@ThreatGuard.com> <521E411B.70900@sit.fraunhofer.de> <521E466C.7070002@ThreatGuard.com> In-Reply-To: <521E466C.7070002@ThreatGuard.com> Date: Wed, 28 Aug 2013 18:11:19 -0400 Message-ID: <00ab01cea43b$862f0fe0$928d2fa0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFdaWr8a8wmiAg+Wuy24swtgFnkaAMDqk02ARCmVWUC1AYIOJpWXpqg Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377727881; bh=fJI4cXg+ub/o3OWQJDTKXUARxIhqwTfsL5CM4j8HJ/U=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=pB76iRBFdAO98Cl2oq7X69/DU6pFKgF/3aZLCD6Y/6iirhqZtxwjTKGlHZJLUBDbc 71zZipSTFQ7xflcSqCxCi682tsSFSU25SIyySL/B6i1LX4uI9F+HP/RsgX1ec/2Me5 +7JW7bYUgn2d0lwWvnL9icvniIinkMQWNuzHN+SWlI+ZlcQjZCY7zkzzHzvNWuyMRS 5Dks7t0NXOT9vTJ4YEmesoUyVb+p6Mi/BVsUYp/r48krHNy7QqaWqKzDKyLUp+9k8n Re0gPCUod23fu0upXSlrMf4LxPCRKyLL1/jco0DRs3B0eAXrs5DaSSvwULgNV6roht CTfDT6Q4hMfZQ== Cc: sacm@ietf.org Subject: Re: [sacm] Use Cases: Asset Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 22:11:27 -0000 I find the term "security automation" overly broad. Personally I would have much preferred that the WG scope had been dramatically smaller and more focused. But our charter includes asset management. Given that that is what we have as a scope, then the intersection between security management and asset management seems in scope. >From an automated security management viewpoint, detecting that new nodes (possibly unauthorized) have appeared in the network would appear to be something important to automate for security purposes. Being able to understand the asset components, resources, services and so on, are important because they can impact the security of the asset and of the network in which the asset operates. Of course, I come from a network management background, and I think asset management intersects with network management. I think security management intersects with network management, for a number of aspects including asset management. I would like to see this WG not try to re-invent network management or asset management because there happens to be some overlap with security management. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Gunnar Engelbach > Sent: Wednesday, August 28, 2013 2:50 PM > To: Henk Birkholz > Cc: sacm@ietf.org > Subject: Re: [sacm] Use Cases: Asset Management > > > Yes, the needs of SACM intersect with the realm of asset management. > But, again, is standardizing asset management really a use case for SACM? > > Putting it another way, is it reasonable to think that somebody would deploy > a SACM system for the sole purpose of doing asset management? > > > > > On 8/28/2013 2:27 PM, Henk Birkholz wrote: > > Information about assets provides the link/relationship between > > monitoring techniques, services, vulnerabilities, etc. While Asset > > Management is indeed a quite general term, it incorperates the > > acquisition and provision of asset information which is an important > > prerequisite in sacm, I think. > > > > On 08/28/2013 08:00 PM, Gunnar Engelbach wrote: > >> > >> 4.1.1 Asset Discovery, first paragraph: "alowing" could use another l. > >> > >> > >> Now that you mention it, I found myself wondering of asset management > is > >> really a SCAM use case. Certainly the needs of SACM intersect with > >> asset management, but is it really one of the goals of SACM that we > >> produce standards for creating an asset management system? > >> > >> > >> > >> > >> On 8/27/2013 2:00 PM, Waltermire, David A. wrote: > >>> Last week I posted the WG draft version of the use cases document > >>> (http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/). Changes > >>> since the -05 version are listing in the change log within the document > >>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-8). > >>> > >>> What I'd like to do next is focus the WGs attention on individual > >>> sections of the use case document for a week or two each to work on > >>> wrapping up the text and to develop overall consensus. Starting this > >>> week I would like to focus on section 4.1 Asset Management > >>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-4.1). > >>> My hope is that this approach will lead us through development of the > >>> document before the next draft submission deadline. > >>> > >>> Based on the current text I have the following questions: > >>> > >>> 1)Is the current structure of this section acceptable? If not, what > >>> should be done differently? > >>> > >>> 2)Are there key terms that should be defined in the terminology draft? > >>> If so, what terms and what definition should be used? > >>> > >>> 3)We currently have the following sub-sections that represent different > >>> lifecycle aspects related to Asset Management. Are these the best way > to > >>> break up asset management into discrete use cases? > >>> > >>> a.Asset Discovery > >>> > >>> b.Asset Identification > >>> > >>> c.Endpoint Components and Asset Composition > >>> > >>> d.Asset Characterization > >>> > >>> e.Asset Resources > >>> > >>> f.Asset Representation Reconciliation > >>> > >>> g.Asset Life Cycle > >>> > >>> 4)Do you agree with the current text in each sub-section? If not, why > >>> not? Do you have alternate text to contribute? > >>> > >>> 5)Here are a few questions regarding some of the sub-sections: > >>> > >>> a.Asset Characterization - Are there other important characteristics to > >>> list? > >>> > >>> b.Asset Resources - Should this be addressed under asset management > or > >>> under data collection in a different section? Is the human- vs. > >>> machine-collected distinction important here? > >>> > >>> c.Asset Representation Reconciliation - We need text to flesh this > >>> section out. Any volunteers? > >>> > >>> d.Asset Life Cycle - Is this section needed? If so, what do we want to > >>> say? Any volunteers willing to contribute text? > >>> > >>> 6)Do you have any other general comments/questions on this section? > >>> > >>> Please let me know your thoughts on these questions. I'll make edits to > >>> the document as we agree on any changes that should be made. > >>> > >>> Sincerely, > >>> > >>> Dave > >>> > >>> > >>> > >>> _______________________________________________ > >>> sacm mailing list > >>> sacm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sacm > >>> > >> _______________________________________________ > >> sacm mailing list > >> sacm@ietf.org > >> https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From henk.birkholz@sit.fraunhofer.de Thu Aug 29 03:44:10 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AE421F9E3A for ; Thu, 29 Aug 2013 03:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqZp2IGxmydI for ; Thu, 29 Aug 2013 03:44:05 -0700 (PDT) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by ietfa.amsl.com (Postfix) with ESMTP id EE28621F9E0A for ; Thu, 29 Aug 2013 03:44:03 -0700 (PDT) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171] (may be forged)) by mailext.sit.fraunhofer.de (8.14.2/8.13.6/9.9.9) with ESMTP id r7TAhwG9009044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 29 Aug 2013 12:44:00 +0200 Received: from [192.168.250.116] (82.198.197.57) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Aug 2013 12:43:53 +0200 Message-ID: <521F25E8.5000109@sit.fraunhofer.de> Date: Thu, 29 Aug 2013 12:43:52 +0200 From: Henk Birkholz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gunnar Engelbach References: <521E3AD8.6070908@ThreatGuard.com> <521E411B.70900@sit.fraunhofer.de> <521E466C.7070002@ThreatGuard.com> <824fcf330d0945b6a97e63b80591720f@BLUPR09MB038.namprd09.prod.outlook.com> <521EB641.9000306@ThreatGuard.com> In-Reply-To: <521EB641.9000306@ThreatGuard.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [82.198.197.57] Cc: "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Use Cases: Asset Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 10:44:10 -0000 Another specific part of asset management as a requirement for SACM is the differentiation between live-cycle related changes and error related changes in the infrastructure, I think. Simple example: availability monitoring shows/raises a down-condition for a network endpoint. If the endpoint was removed due to the end of its live-cycle, this indicates a missing adaption of the monitoring configuration and an invalid alarm. Other reasons might result in a valid alarm. This scenario is strongly related with the whole asset management/live-cycle process and would need a corresponding use case to present the required context, correct? I agree with the opinion that nobody would deploy a SACM system for the sole purpose of doing asset management, and presenting asset management as a use case might be misleading somehow. Maybe the purpose of section 4.1 as a use case is still too fuzzy? Or a more specific section/use case title could help? Essentially, if all requirements must be based on a corresponding use case (is that the case?), something appropriate is needed in section 4. On 08/29/2013 04:47 AM, Gunnar Engelbach wrote: > > > On 8/28/2013 4:33 PM, Waltermire, David A. wrote: >> Gunnar, >> >> Are you suggesting that we remove the asset management section from >> the use case draft? If not, what would you change? > > > > Yes. I'm suggesting that, for SACM, asset management is not a use case, > but certain parts of asset management are requirements for SACM. > Specifically: > > 1) We need a taxonomy for determining what assessment content applies to > an endpoint > > 2) We need to be able to identify a particular asset when communicating > between SACM nodes > > 3) We need to be able to generate a list of endpoints to perform an > assessment against -- call that discovery* > > And for the assessment model that is driven by change event notification > pushed from endpoints, discovery is not needed. > > > Fleshing out all the requirements so that a SACM installation can be > used as an asset management system seems to go well beyond what is > needed. Given the near-ubiquity of existing asset management systems I > think we should be more interested in interacting with those than trying > to invent another one. > > > Now, with all of that said, there are going to be cases where a SACM > installation needs to include it's own asset management system. Allowing > for that possibility, is it within scope of this working group to also > define what that looks like, or can we take it as a given that such > things exist? I'd say that the furthest we want to go is to define our > own standardized way for interacting with an asset management system > that is just enough to fulfill the needs of SACM. > > > > > * Discovery in this case is extremely broad. It could be via manual > user interaction, enumeration of an LDAP/AD server, event notification > from a NAC system or DHCP server, ringing out a network, querying an > asset management system, enumeration of live targets via IPv6 > properties, and on and on. > > >> >> More comments below. >> >>> -----Original Message----- >>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>> Gunnar Engelbach >>> Sent: Wednesday, August 28, 2013 2:50 PM >>> To: Henk Birkholz >>> Cc: sacm@ietf.org >>> Subject: Re: [sacm] Use Cases: Asset Management >>> >>> >>> Yes, the needs of SACM intersect with the realm of asset management. >> >> Agreed. We need to focus use cases around this intersection. >> >>> But, again, is standardizing asset management really a use case for >>> SACM? >> >> Strictly speaking, I would say no. But some aspects like asset >> discovery (identifying new endpoints that join a network), asset >> identification (relating collected data to assets), and asset >> representation reconciliation (sorting out different identification >> approaches) are aspects that we need to deal with as a matter of the >> SACM scope. Asset characterization is a bit more nuanced. I believe at >> minimum we need some capability to get data about an asset that sets >> an expectation of its intended posture. For example, we need to know >> something about what the intended function of the device is to >> understand how to evaluate its posture. >> >>> Putting it another way, is it reasonable to think that somebody would >>> deploy >>> a SACM system for the sole purpose of doing asset management? >> >> Possibly, but not likely. If we address asset discovery, which I >> believe we should, this capability could be used standalone without >> any further data collection. >> >>> >>> >>> >>> >>> On 8/28/2013 2:27 PM, Henk Birkholz wrote: >>>> Information about assets provides the link/relationship between >>>> monitoring techniques, services, vulnerabilities, etc. While Asset >>>> Management is indeed a quite general term, it incorperates the >>>> acquisition and provision of asset information which is an important >>>> prerequisite in sacm, I think. >>>> >>>> On 08/28/2013 08:00 PM, Gunnar Engelbach wrote: >>>>> >>>>> 4.1.1 Asset Discovery, first paragraph: "alowing" could use >>>>> another l. >>>>> >>>>> >>>>> Now that you mention it, I found myself wondering of asset management >>> is >>>>> really a SCAM use case. Certainly the needs of SACM intersect with >>>>> asset management, but is it really one of the goals of SACM that we >>>>> produce standards for creating an asset management system? >>>>> >>>>> >>>>> >>>>> >>>>> On 8/27/2013 2:00 PM, Waltermire, David A. wrote: >>>>>> Last week I posted the WG draft version of the use cases document >>>>>> (http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/). Changes >>>>>> since the -05 version are listing in the change log within the >>>>>> document >>>>>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-8). >>>>>> >>>>>> What I'd like to do next is focus the WGs attention on individual >>>>>> sections of the use case document for a week or two each to work on >>>>>> wrapping up the text and to develop overall consensus. Starting this >>>>>> week I would like to focus on section 4.1 Asset Management >>>>>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-4.1). >>>>>> >>>>>> My hope is that this approach will lead us through development of the >>>>>> document before the next draft submission deadline. >>>>>> >>>>>> Based on the current text I have the following questions: >>>>>> >>>>>> 1)Is the current structure of this section acceptable? If not, what >>>>>> should be done differently? >>>>>> >>>>>> 2)Are there key terms that should be defined in the terminology >>>>>> draft? >>>>>> If so, what terms and what definition should be used? >>>>>> >>>>>> 3)We currently have the following sub-sections that represent >>>>>> different >>>>>> lifecycle aspects related to Asset Management. Are these the best way >>> to >>>>>> break up asset management into discrete use cases? >>>>>> >>>>>> a.Asset Discovery >>>>>> >>>>>> b.Asset Identification >>>>>> >>>>>> c.Endpoint Components and Asset Composition >>>>>> >>>>>> d.Asset Characterization >>>>>> >>>>>> e.Asset Resources >>>>>> >>>>>> f.Asset Representation Reconciliation >>>>>> >>>>>> g.Asset Life Cycle >>>>>> >>>>>> 4)Do you agree with the current text in each sub-section? If not, >>>>>> why >>>>>> not? Do you have alternate text to contribute? >>>>>> >>>>>> 5)Here are a few questions regarding some of the sub-sections: >>>>>> >>>>>> a.Asset Characterization - Are there other important >>>>>> characteristics to >>>>>> list? >>>>>> >>>>>> b.Asset Resources - Should this be addressed under asset management >>> or >>>>>> under data collection in a different section? Is the human- vs. >>>>>> machine-collected distinction important here? >>>>>> >>>>>> c.Asset Representation Reconciliation - We need text to flesh this >>>>>> section out. Any volunteers? >>>>>> >>>>>> d.Asset Life Cycle - Is this section needed? If so, what do we >>>>>> want to >>>>>> say? Any volunteers willing to contribute text? >>>>>> >>>>>> 6)Do you have any other general comments/questions on this section? >>>>>> >>>>>> Please let me know your thoughts on these questions. I'll make >>>>>> edits to >>>>>> the document as we agree on any changes that should be made. >>>>>> >>>>>> Sincerely, >>>>>> >>>>>> Dave >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sacm mailing list >>>>>> sacm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>> >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >>>> >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >>> _______________________________________________ >>> sacm mailing list >>> sacm@ietf.org >>> https://www.ietf.org/mailman/listinfo/sacm From gunnar.engelbach@threatguard.com Thu Aug 29 08:17:06 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A860711E8128 for ; Thu, 29 Aug 2013 08:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNbWl5hT2LXl for ; Thu, 29 Aug 2013 08:17:02 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id C665311E8120 for ; Thu, 29 Aug 2013 08:17:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=kPlWMGbBKXFaaZ5WDSFw7DdJ4K+zjTNeKfr4K1SLErcTQ+uwCBmkgEmeBRj5TsgocHaJDA1yTAn/3+RLNDnNvQKlVpRIyFrBzgo3dx/8pmJy34GYGzpD+oCHA5IrGpE2; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 5582 invoked from network); 29 Aug 2013 08:16:48 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 29 Aug 2013 08:16:47 -0700 Message-ID: <521F65F0.8080701@ThreatGuard.com> Date: Thu, 29 Aug 2013 11:17:04 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Henk Birkholz References: <521E3AD8.6070908@ThreatGuard.com> <521E411B.70900@sit.fraunhofer.de> <521E466C.7070002@ThreatGuard.com> <824fcf330d0945b6a97e63b80591720f@BLUPR09MB038.namprd09.prod.outlook.com> <521EB641.9000306@ThreatGuard.com> <521F25E8.5000109@sit.fraunhofer.de> In-Reply-To: <521F25E8.5000109@sit.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Use Cases: Asset Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 15:17:06 -0000 So, you'd like to use a SACM implementation to monitor liveness of network endpoints? Even if a SACM implementation included an asset management capability, I think it's not going to be ideal for performing this kind of function. You'd be better served using a network monitoring system that is built specifically for that purpose. On 8/29/2013 6:43 AM, Henk Birkholz wrote: > Another specific part of asset management as a requirement for SACM is > the differentiation between live-cycle related changes and error related > changes in the infrastructure, I think. > > Simple example: availability monitoring shows/raises a down-condition > for a network endpoint. If the endpoint was removed due to the end of > its live-cycle, this indicates a missing adaption of the monitoring > configuration and an invalid alarm. Other reasons might result in a > valid alarm. > > This scenario is strongly related with the whole asset > management/live-cycle process and would need a corresponding use case to > present the required context, correct? > > I agree with the opinion that nobody would deploy a SACM system for the > sole purpose of doing asset management, and presenting asset management > as a use case might be misleading somehow. Maybe the purpose of section > 4.1 as a use case is still too fuzzy? Or a more specific section/use > case title could help? Essentially, if all requirements must be based on > a corresponding use case (is that the case?), something appropriate is > needed in section 4. > > > On 08/29/2013 04:47 AM, Gunnar Engelbach wrote: >> >> >> On 8/28/2013 4:33 PM, Waltermire, David A. wrote: >>> Gunnar, >>> >>> Are you suggesting that we remove the asset management section from >>> the use case draft? If not, what would you change? >> >> >> >> Yes. I'm suggesting that, for SACM, asset management is not a use case, >> but certain parts of asset management are requirements for SACM. >> Specifically: >> >> 1) We need a taxonomy for determining what assessment content applies to >> an endpoint >> >> 2) We need to be able to identify a particular asset when communicating >> between SACM nodes >> >> 3) We need to be able to generate a list of endpoints to perform an >> assessment against -- call that discovery* >> >> And for the assessment model that is driven by change event notification >> pushed from endpoints, discovery is not needed. >> >> >> Fleshing out all the requirements so that a SACM installation can be >> used as an asset management system seems to go well beyond what is >> needed. Given the near-ubiquity of existing asset management systems I >> think we should be more interested in interacting with those than trying >> to invent another one. >> >> >> Now, with all of that said, there are going to be cases where a SACM >> installation needs to include it's own asset management system. Allowing >> for that possibility, is it within scope of this working group to also >> define what that looks like, or can we take it as a given that such >> things exist? I'd say that the furthest we want to go is to define our >> own standardized way for interacting with an asset management system >> that is just enough to fulfill the needs of SACM. >> >> >> >> >> * Discovery in this case is extremely broad. It could be via manual >> user interaction, enumeration of an LDAP/AD server, event notification >> from a NAC system or DHCP server, ringing out a network, querying an >> asset management system, enumeration of live targets via IPv6 >> properties, and on and on. >> >> >>> >>> More comments below. >>> >>>> -----Original Message----- >>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >>>> Gunnar Engelbach >>>> Sent: Wednesday, August 28, 2013 2:50 PM >>>> To: Henk Birkholz >>>> Cc: sacm@ietf.org >>>> Subject: Re: [sacm] Use Cases: Asset Management >>>> >>>> >>>> Yes, the needs of SACM intersect with the realm of asset management. >>> >>> Agreed. We need to focus use cases around this intersection. >>> >>>> But, again, is standardizing asset management really a use case for >>>> SACM? >>> >>> Strictly speaking, I would say no. But some aspects like asset >>> discovery (identifying new endpoints that join a network), asset >>> identification (relating collected data to assets), and asset >>> representation reconciliation (sorting out different identification >>> approaches) are aspects that we need to deal with as a matter of the >>> SACM scope. Asset characterization is a bit more nuanced. I believe at >>> minimum we need some capability to get data about an asset that sets >>> an expectation of its intended posture. For example, we need to know >>> something about what the intended function of the device is to >>> understand how to evaluate its posture. >>> >>>> Putting it another way, is it reasonable to think that somebody would >>>> deploy >>>> a SACM system for the sole purpose of doing asset management? >>> >>> Possibly, but not likely. If we address asset discovery, which I >>> believe we should, this capability could be used standalone without >>> any further data collection. >>> >>>> >>>> >>>> >>>> >>>> On 8/28/2013 2:27 PM, Henk Birkholz wrote: >>>>> Information about assets provides the link/relationship between >>>>> monitoring techniques, services, vulnerabilities, etc. While Asset >>>>> Management is indeed a quite general term, it incorperates the >>>>> acquisition and provision of asset information which is an important >>>>> prerequisite in sacm, I think. >>>>> >>>>> On 08/28/2013 08:00 PM, Gunnar Engelbach wrote: >>>>>> >>>>>> 4.1.1 Asset Discovery, first paragraph: "alowing" could use >>>>>> another l. >>>>>> >>>>>> >>>>>> Now that you mention it, I found myself wondering of asset management >>>> is >>>>>> really a SCAM use case. Certainly the needs of SACM intersect with >>>>>> asset management, but is it really one of the goals of SACM that we >>>>>> produce standards for creating an asset management system? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 8/27/2013 2:00 PM, Waltermire, David A. wrote: >>>>>>> Last week I posted the WG draft version of the use cases document >>>>>>> (http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/). >>>>>>> Changes >>>>>>> since the -05 version are listing in the change log within the >>>>>>> document >>>>>>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-8). >>>>>>> >>>>>>> What I'd like to do next is focus the WGs attention on individual >>>>>>> sections of the use case document for a week or two each to work on >>>>>>> wrapping up the text and to develop overall consensus. Starting this >>>>>>> week I would like to focus on section 4.1 Asset Management >>>>>>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-4.1). >>>>>>> >>>>>>> >>>>>>> My hope is that this approach will lead us through development of >>>>>>> the >>>>>>> document before the next draft submission deadline. >>>>>>> >>>>>>> Based on the current text I have the following questions: >>>>>>> >>>>>>> 1)Is the current structure of this section acceptable? If not, what >>>>>>> should be done differently? >>>>>>> >>>>>>> 2)Are there key terms that should be defined in the terminology >>>>>>> draft? >>>>>>> If so, what terms and what definition should be used? >>>>>>> >>>>>>> 3)We currently have the following sub-sections that represent >>>>>>> different >>>>>>> lifecycle aspects related to Asset Management. Are these the best >>>>>>> way >>>> to >>>>>>> break up asset management into discrete use cases? >>>>>>> >>>>>>> a.Asset Discovery >>>>>>> >>>>>>> b.Asset Identification >>>>>>> >>>>>>> c.Endpoint Components and Asset Composition >>>>>>> >>>>>>> d.Asset Characterization >>>>>>> >>>>>>> e.Asset Resources >>>>>>> >>>>>>> f.Asset Representation Reconciliation >>>>>>> >>>>>>> g.Asset Life Cycle >>>>>>> >>>>>>> 4)Do you agree with the current text in each sub-section? If not, >>>>>>> why >>>>>>> not? Do you have alternate text to contribute? >>>>>>> >>>>>>> 5)Here are a few questions regarding some of the sub-sections: >>>>>>> >>>>>>> a.Asset Characterization - Are there other important >>>>>>> characteristics to >>>>>>> list? >>>>>>> >>>>>>> b.Asset Resources - Should this be addressed under asset management >>>> or >>>>>>> under data collection in a different section? Is the human- vs. >>>>>>> machine-collected distinction important here? >>>>>>> >>>>>>> c.Asset Representation Reconciliation - We need text to flesh this >>>>>>> section out. Any volunteers? >>>>>>> >>>>>>> d.Asset Life Cycle - Is this section needed? If so, what do we >>>>>>> want to >>>>>>> say? Any volunteers willing to contribute text? >>>>>>> >>>>>>> 6)Do you have any other general comments/questions on this section? >>>>>>> >>>>>>> Please let me know your thoughts on these questions. I'll make >>>>>>> edits to >>>>>>> the document as we agree on any changes that should be made. >>>>>>> >>>>>>> Sincerely, >>>>>>> >>>>>>> Dave >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sacm mailing list >>>>>>> sacm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>>> >>>>>> _______________________________________________ >>>>>> sacm mailing list >>>>>> sacm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>> >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm > From aawoland@cisco.com Thu Aug 29 08:25:13 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7339321F9097 for ; Thu, 29 Aug 2013 08:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ-TooFSasVb for ; Thu, 29 Aug 2013 08:24:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA7021F8E70 for ; Thu, 29 Aug 2013 08:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11127; q=dns/txt; s=iport; t=1377789893; x=1378999493; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=oh+QxrQQ1aEf6KzdKAAn+RPpKKEEzekTo+sd5wYd1uk=; b=MrxDz2WlN8r5p+5sLh81HjWMfHRsfKmeDrr6oyBuwR+yP3GXvWV0Zk7w kMvwRXBOHad+bpmCPfT+T5W+q7mtKw+Vx/7foYEnA37p+M/+dqVYaMpwd OZqg/S3ocGmRjAyz6JlSSmbimHanbjoippNxlH9ckvKcYSJvTGdSk10Kk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAKpmH1KtJXG+/2dsb2JhbABQCoMHNVHAN4EnFnSCJAEBAQQBAQE3NAQBBgwGAQgRBAEBAQoUCS4LFAkIAgQBDQUIDAWHaAy5K44xgRACBisHAgSDFoEAA5kikDeDIIIq X-IronPort-AV: E=Sophos;i="4.89,984,1367971200"; d="scan'208";a="253167837" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 29 Aug 2013 15:24:50 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7TFOoAP021964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Aug 2013 15:24:50 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.31]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 29 Aug 2013 10:24:49 -0500 From: "Aaron Woland (aawoland)" To: Gunnar Engelbach , Henk Birkholz Thread-Topic: [sacm] Use Cases: Asset Management Thread-Index: AQHOpKSmTBbEy9ALTVebMV+UWgzW6JmsoCoA//+/GIA= Date: Thu, 29 Aug 2013 15:24:48 +0000 Message-ID: <862FA31948313540BD2843B1AA96F25C470D10E2@xmb-rcd-x01.cisco.com> In-Reply-To: <521F65F0.8080701@ThreatGuard.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.117.118.222] Content-Type: text/plain; charset="us-ascii" Content-ID: <96E7947A4A52794DAB5CC4876879A6A1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Use Cases: Asset Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 15:25:14 -0000 All, Maybe I am way off on this, but I interpret this as SACM should provide a way to communicate information about the endpoint liveliness from a network monitoring tool to a security tool, but that sacm should not be a tool that is monitoring this activity itself. Am I off base? Aaron --=20 Regards, Aaron T. Woland, CCIE #20113 Secure Access TME, SAMPG ciscoSystems, Inc. Check out my Secure Network Access Blog at Network World Author: Cisco ISE for BYOD and Secure Unified Access On 8/29/13 11:17 AM, "Gunnar Engelbach" wrote: > > >So, you'd like to use a SACM implementation to monitor liveness of >network endpoints? > >Even if a SACM implementation included an asset management capability, I >think it's not going to be ideal for performing this kind of function. >You'd be better served using a network monitoring system that is built >specifically for that purpose. > > > >On 8/29/2013 6:43 AM, Henk Birkholz wrote: >> Another specific part of asset management as a requirement for SACM is >> the differentiation between live-cycle related changes and error related >> changes in the infrastructure, I think. >> >> Simple example: availability monitoring shows/raises a down-condition >> for a network endpoint. If the endpoint was removed due to the end of >> its live-cycle, this indicates a missing adaption of the monitoring >> configuration and an invalid alarm. Other reasons might result in a >> valid alarm. >> >> This scenario is strongly related with the whole asset >> management/live-cycle process and would need a corresponding use case to >> present the required context, correct? >> >> I agree with the opinion that nobody would deploy a SACM system for the >> sole purpose of doing asset management, and presenting asset management >> as a use case might be misleading somehow. Maybe the purpose of section >> 4.1 as a use case is still too fuzzy? Or a more specific section/use >> case title could help? Essentially, if all requirements must be based on >> a corresponding use case (is that the case?), something appropriate is >> needed in section 4. >> >> >> On 08/29/2013 04:47 AM, Gunnar Engelbach wrote: >>> >>> >>> On 8/28/2013 4:33 PM, Waltermire, David A. wrote: >>>> Gunnar, >>>> >>>> Are you suggesting that we remove the asset management section from >>>> the use case draft? If not, what would you change? >>> >>> >>> >>> Yes. I'm suggesting that, for SACM, asset management is not a use >>>case, >>> but certain parts of asset management are requirements for SACM. >>> Specifically: >>> >>> 1) We need a taxonomy for determining what assessment content applies >>>to >>> an endpoint >>> >>> 2) We need to be able to identify a particular asset when communicating >>> between SACM nodes >>> >>> 3) We need to be able to generate a list of endpoints to perform an >>> assessment against -- call that discovery* >>> >>> And for the assessment model that is driven by change event >>>notification >>> pushed from endpoints, discovery is not needed. >>> >>> >>> Fleshing out all the requirements so that a SACM installation can be >>> used as an asset management system seems to go well beyond what is >>> needed. Given the near-ubiquity of existing asset management systems I >>> think we should be more interested in interacting with those than >>>trying >>> to invent another one. >>> >>> >>> Now, with all of that said, there are going to be cases where a SACM >>> installation needs to include it's own asset management system. >>>Allowing >>> for that possibility, is it within scope of this working group to also >>> define what that looks like, or can we take it as a given that such >>> things exist? I'd say that the furthest we want to go is to define our >>> own standardized way for interacting with an asset management system >>> that is just enough to fulfill the needs of SACM. >>> >>> >>> >>> >>> * Discovery in this case is extremely broad. It could be via manual >>> user interaction, enumeration of an LDAP/AD server, event notification >>> from a NAC system or DHCP server, ringing out a network, querying an >>> asset management system, enumeration of live targets via IPv6 >>> properties, and on and on. >>> >>> >>>> >>>> More comments below. >>>> >>>>> -----Original Message----- >>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf >>>>>Of >>>>> Gunnar Engelbach >>>>> Sent: Wednesday, August 28, 2013 2:50 PM >>>>> To: Henk Birkholz >>>>> Cc: sacm@ietf.org >>>>> Subject: Re: [sacm] Use Cases: Asset Management >>>>> >>>>> >>>>> Yes, the needs of SACM intersect with the realm of asset management. >>>> >>>> Agreed. We need to focus use cases around this intersection. >>>> >>>>> But, again, is standardizing asset management really a use case for >>>>> SACM? >>>> >>>> Strictly speaking, I would say no. But some aspects like asset >>>> discovery (identifying new endpoints that join a network), asset >>>> identification (relating collected data to assets), and asset >>>> representation reconciliation (sorting out different identification >>>> approaches) are aspects that we need to deal with as a matter of the >>>> SACM scope. Asset characterization is a bit more nuanced. I believe at >>>> minimum we need some capability to get data about an asset that sets >>>> an expectation of its intended posture. For example, we need to know >>>> something about what the intended function of the device is to >>>> understand how to evaluate its posture. >>>> >>>>> Putting it another way, is it reasonable to think that somebody would >>>>> deploy >>>>> a SACM system for the sole purpose of doing asset management? >>>> >>>> Possibly, but not likely. If we address asset discovery, which I >>>> believe we should, this capability could be used standalone without >>>> any further data collection. >>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 8/28/2013 2:27 PM, Henk Birkholz wrote: >>>>>> Information about assets provides the link/relationship between >>>>>> monitoring techniques, services, vulnerabilities, etc. While Asset >>>>>> Management is indeed a quite general term, it incorperates the >>>>>> acquisition and provision of asset information which is an important >>>>>> prerequisite in sacm, I think. >>>>>> >>>>>> On 08/28/2013 08:00 PM, Gunnar Engelbach wrote: >>>>>>> >>>>>>> 4.1.1 Asset Discovery, first paragraph: "alowing" could use >>>>>>> another l. >>>>>>> >>>>>>> >>>>>>> Now that you mention it, I found myself wondering of asset >>>>>>>management >>>>> is >>>>>>> really a SCAM use case. Certainly the needs of SACM intersect with >>>>>>> asset management, but is it really one of the goals of SACM that we >>>>>>> produce standards for creating an asset management system? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 8/27/2013 2:00 PM, Waltermire, David A. wrote: >>>>>>>> Last week I posted the WG draft version of the use cases document >>>>>>>> (http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/). >>>>>>>> Changes >>>>>>>> since the -05 version are listing in the change log within the >>>>>>>> document >>>>>>>>=20 >>>>>>>>(http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-8) >>>>>>>>. >>>>>>>> >>>>>>>> What I'd like to do next is focus the WGs attention on individual >>>>>>>> sections of the use case document for a week or two each to work >>>>>>>>on >>>>>>>> wrapping up the text and to develop overall consensus. Starting >>>>>>>>this >>>>>>>> week I would like to focus on section 4.1 Asset Management >>>>>>>>=20 >>>>>>>>(http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-4. >>>>>>>>1). >>>>>>>> >>>>>>>> >>>>>>>> My hope is that this approach will lead us through development of >>>>>>>> the >>>>>>>> document before the next draft submission deadline. >>>>>>>> >>>>>>>> Based on the current text I have the following questions: >>>>>>>> >>>>>>>> 1)Is the current structure of this section acceptable? If not, >>>>>>>>what >>>>>>>> should be done differently? >>>>>>>> >>>>>>>> 2)Are there key terms that should be defined in the terminology >>>>>>>> draft? >>>>>>>> If so, what terms and what definition should be used? >>>>>>>> >>>>>>>> 3)We currently have the following sub-sections that represent >>>>>>>> different >>>>>>>> lifecycle aspects related to Asset Management. Are these the best >>>>>>>> way >>>>> to >>>>>>>> break up asset management into discrete use cases? >>>>>>>> >>>>>>>> a.Asset Discovery >>>>>>>> >>>>>>>> b.Asset Identification >>>>>>>> >>>>>>>> c.Endpoint Components and Asset Composition >>>>>>>> >>>>>>>> d.Asset Characterization >>>>>>>> >>>>>>>> e.Asset Resources >>>>>>>> >>>>>>>> f.Asset Representation Reconciliation >>>>>>>> >>>>>>>> g.Asset Life Cycle >>>>>>>> >>>>>>>> 4)Do you agree with the current text in each sub-section? If not, >>>>>>>> why >>>>>>>> not? Do you have alternate text to contribute? >>>>>>>> >>>>>>>> 5)Here are a few questions regarding some of the sub-sections: >>>>>>>> >>>>>>>> a.Asset Characterization - Are there other important >>>>>>>> characteristics to >>>>>>>> list? >>>>>>>> >>>>>>>> b.Asset Resources - Should this be addressed under asset >>>>>>>>management >>>>> or >>>>>>>> under data collection in a different section? Is the human- vs. >>>>>>>> machine-collected distinction important here? >>>>>>>> >>>>>>>> c.Asset Representation Reconciliation - We need text to flesh this >>>>>>>> section out. Any volunteers? >>>>>>>> >>>>>>>> d.Asset Life Cycle - Is this section needed? If so, what do we >>>>>>>> want to >>>>>>>> say? Any volunteers willing to contribute text? >>>>>>>> >>>>>>>> 6)Do you have any other general comments/questions on this >>>>>>>>section? >>>>>>>> >>>>>>>> Please let me know your thoughts on these questions. I'll make >>>>>>>> edits to >>>>>>>> the document as we agree on any changes that should be made. >>>>>>>> >>>>>>>> Sincerely, >>>>>>>> >>>>>>>> Dave >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sacm mailing list >>>>>>>> sacm@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> sacm mailing list >>>>>>> sacm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>> >>>>>> _______________________________________________ >>>>>> sacm mailing list >>>>>> sacm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >> >_______________________________________________ >sacm mailing list >sacm@ietf.org >https://www.ietf.org/mailman/listinfo/sacm From henk.birkholz@sit.fraunhofer.de Thu Aug 29 09:12:46 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2689B11E811B for ; Thu, 29 Aug 2013 09:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYQQJkBTaXku for ; Thu, 29 Aug 2013 09:12:40 -0700 (PDT) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by ietfa.amsl.com (Postfix) with ESMTP id 8F20D21F841D for ; Thu, 29 Aug 2013 09:12:37 -0700 (PDT) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171] (may be forged)) by mailext.sit.fraunhofer.de (8.14.2/8.13.6/9.9.9) with ESMTP id r7TGCYV7012777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 29 Aug 2013 18:12:36 +0200 Received: from [134.102.43.164] (134.102.43.164) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Aug 2013 18:12:28 +0200 Message-ID: <521F72EB.7050807@sit.fraunhofer.de> Date: Thu, 29 Aug 2013 18:12:27 +0200 From: Henk Birkholz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gunnar Engelbach References: <521E3AD8.6070908@ThreatGuard.com> <521E411B.70900@sit.fraunhofer.de> <521E466C.7070002@ThreatGuard.com> <824fcf330d0945b6a97e63b80591720f@BLUPR09MB038.namprd09.prod.outlook.com> <521EB641.9000306@ThreatGuard.com> <521F25E8.5000109@sit.fraunhofer.de> <521F65F0.8080701@ThreatGuard.com> In-Reply-To: <521F65F0.8080701@ThreatGuard.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [134.102.43.164] Cc: "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Use Cases: Asset Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 16:12:46 -0000 Please excuse my brevity regarding the scenario example. Actual monitoring of liveness should be done with systems/senors built specifically for that purpose, of course. I was thinking more in the direction of supporting (and in some places partially automating) the configuration of monitoring systems, SIEM systems and such. Asset information derived from existing infrastructure (e.g. via asset discovery or existing meta-directories) that is aggregated in a Content Repository could be used as a basis to generate corresponding configuration for these system. SACM is a core mechanism to automatically distribute security-related metadata in order to enhance the awareness over the state of the infrastructure. Hence, some kind of asset management related information should be included, I think. I understand the drawbacks of maybe bloating the scope of SACM with "things that are already there", but separating asset management and security automation seems to be even worse. This typical separation and reliance on asset management implementations that should already be there is maybe one of the significant problems SACM could really improve. Also, I think the term asset management is still a bit fuzzy at the moment, and it might be confusing if presented as a use case. On 08/29/2013 05:17 PM, Gunnar Engelbach wrote: > > > So, you'd like to use a SACM implementation to monitor liveness of > network endpoints? > > Even if a SACM implementation included an asset management capability, I > think it's not going to be ideal for performing this kind of function. > You'd be better served using a network monitoring system that is built > specifically for that purpose. > > > > On 8/29/2013 6:43 AM, Henk Birkholz wrote: >> Another specific part of asset management as a requirement for SACM is >> the differentiation between live-cycle related changes and error related >> changes in the infrastructure, I think. >> >> Simple example: availability monitoring shows/raises a down-condition >> for a network endpoint. If the endpoint was removed due to the end of >> its live-cycle, this indicates a missing adaption of the monitoring >> configuration and an invalid alarm. Other reasons might result in a >> valid alarm. >> >> This scenario is strongly related with the whole asset >> management/live-cycle process and would need a corresponding use case to >> present the required context, correct? >> >> I agree with the opinion that nobody would deploy a SACM system for the >> sole purpose of doing asset management, and presenting asset management >> as a use case might be misleading somehow. Maybe the purpose of section >> 4.1 as a use case is still too fuzzy? Or a more specific section/use >> case title could help? Essentially, if all requirements must be based on >> a corresponding use case (is that the case?), something appropriate is >> needed in section 4. >> >> >> On 08/29/2013 04:47 AM, Gunnar Engelbach wrote: >>> >>> >>> On 8/28/2013 4:33 PM, Waltermire, David A. wrote: >>>> Gunnar, >>>> >>>> Are you suggesting that we remove the asset management section from >>>> the use case draft? If not, what would you change? >>> >>> >>> >>> Yes. I'm suggesting that, for SACM, asset management is not a use case, >>> but certain parts of asset management are requirements for SACM. >>> Specifically: >>> >>> 1) We need a taxonomy for determining what assessment content applies to >>> an endpoint >>> >>> 2) We need to be able to identify a particular asset when communicating >>> between SACM nodes >>> >>> 3) We need to be able to generate a list of endpoints to perform an >>> assessment against -- call that discovery* >>> >>> And for the assessment model that is driven by change event notification >>> pushed from endpoints, discovery is not needed. >>> >>> >>> Fleshing out all the requirements so that a SACM installation can be >>> used as an asset management system seems to go well beyond what is >>> needed. Given the near-ubiquity of existing asset management systems I >>> think we should be more interested in interacting with those than trying >>> to invent another one. >>> >>> >>> Now, with all of that said, there are going to be cases where a SACM >>> installation needs to include it's own asset management system. Allowing >>> for that possibility, is it within scope of this working group to also >>> define what that looks like, or can we take it as a given that such >>> things exist? I'd say that the furthest we want to go is to define our >>> own standardized way for interacting with an asset management system >>> that is just enough to fulfill the needs of SACM. >>> >>> >>> >>> >>> * Discovery in this case is extremely broad. It could be via manual >>> user interaction, enumeration of an LDAP/AD server, event notification >>> from a NAC system or DHCP server, ringing out a network, querying an >>> asset management system, enumeration of live targets via IPv6 >>> properties, and on and on. >>> >>> >>>> >>>> More comments below. >>>> >>>>> -----Original Message----- >>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >>>>> Behalf Of >>>>> Gunnar Engelbach >>>>> Sent: Wednesday, August 28, 2013 2:50 PM >>>>> To: Henk Birkholz >>>>> Cc: sacm@ietf.org >>>>> Subject: Re: [sacm] Use Cases: Asset Management >>>>> >>>>> >>>>> Yes, the needs of SACM intersect with the realm of asset management. >>>> >>>> Agreed. We need to focus use cases around this intersection. >>>> >>>>> But, again, is standardizing asset management really a use case for >>>>> SACM? >>>> >>>> Strictly speaking, I would say no. But some aspects like asset >>>> discovery (identifying new endpoints that join a network), asset >>>> identification (relating collected data to assets), and asset >>>> representation reconciliation (sorting out different identification >>>> approaches) are aspects that we need to deal with as a matter of the >>>> SACM scope. Asset characterization is a bit more nuanced. I believe at >>>> minimum we need some capability to get data about an asset that sets >>>> an expectation of its intended posture. For example, we need to know >>>> something about what the intended function of the device is to >>>> understand how to evaluate its posture. >>>> >>>>> Putting it another way, is it reasonable to think that somebody would >>>>> deploy >>>>> a SACM system for the sole purpose of doing asset management? >>>> >>>> Possibly, but not likely. If we address asset discovery, which I >>>> believe we should, this capability could be used standalone without >>>> any further data collection. >>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 8/28/2013 2:27 PM, Henk Birkholz wrote: >>>>>> Information about assets provides the link/relationship between >>>>>> monitoring techniques, services, vulnerabilities, etc. While Asset >>>>>> Management is indeed a quite general term, it incorperates the >>>>>> acquisition and provision of asset information which is an important >>>>>> prerequisite in sacm, I think. >>>>>> >>>>>> On 08/28/2013 08:00 PM, Gunnar Engelbach wrote: >>>>>>> >>>>>>> 4.1.1 Asset Discovery, first paragraph: "alowing" could use >>>>>>> another l. >>>>>>> >>>>>>> >>>>>>> Now that you mention it, I found myself wondering of asset >>>>>>> management >>>>> is >>>>>>> really a SCAM use case. Certainly the needs of SACM intersect with >>>>>>> asset management, but is it really one of the goals of SACM that we >>>>>>> produce standards for creating an asset management system? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 8/27/2013 2:00 PM, Waltermire, David A. wrote: >>>>>>>> Last week I posted the WG draft version of the use cases document >>>>>>>> (http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/). >>>>>>>> Changes >>>>>>>> since the -05 version are listing in the change log within the >>>>>>>> document >>>>>>>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-8). >>>>>>>> >>>>>>>> >>>>>>>> What I'd like to do next is focus the WGs attention on individual >>>>>>>> sections of the use case document for a week or two each to work on >>>>>>>> wrapping up the text and to develop overall consensus. Starting >>>>>>>> this >>>>>>>> week I would like to focus on section 4.1 Asset Management >>>>>>>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-4.1). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> My hope is that this approach will lead us through development of >>>>>>>> the >>>>>>>> document before the next draft submission deadline. >>>>>>>> >>>>>>>> Based on the current text I have the following questions: >>>>>>>> >>>>>>>> 1)Is the current structure of this section acceptable? If not, what >>>>>>>> should be done differently? >>>>>>>> >>>>>>>> 2)Are there key terms that should be defined in the terminology >>>>>>>> draft? >>>>>>>> If so, what terms and what definition should be used? >>>>>>>> >>>>>>>> 3)We currently have the following sub-sections that represent >>>>>>>> different >>>>>>>> lifecycle aspects related to Asset Management. Are these the best >>>>>>>> way >>>>> to >>>>>>>> break up asset management into discrete use cases? >>>>>>>> >>>>>>>> a.Asset Discovery >>>>>>>> >>>>>>>> b.Asset Identification >>>>>>>> >>>>>>>> c.Endpoint Components and Asset Composition >>>>>>>> >>>>>>>> d.Asset Characterization >>>>>>>> >>>>>>>> e.Asset Resources >>>>>>>> >>>>>>>> f.Asset Representation Reconciliation >>>>>>>> >>>>>>>> g.Asset Life Cycle >>>>>>>> >>>>>>>> 4)Do you agree with the current text in each sub-section? If not, >>>>>>>> why >>>>>>>> not? Do you have alternate text to contribute? >>>>>>>> >>>>>>>> 5)Here are a few questions regarding some of the sub-sections: >>>>>>>> >>>>>>>> a.Asset Characterization - Are there other important >>>>>>>> characteristics to >>>>>>>> list? >>>>>>>> >>>>>>>> b.Asset Resources - Should this be addressed under asset management >>>>> or >>>>>>>> under data collection in a different section? Is the human- vs. >>>>>>>> machine-collected distinction important here? >>>>>>>> >>>>>>>> c.Asset Representation Reconciliation - We need text to flesh this >>>>>>>> section out. Any volunteers? >>>>>>>> >>>>>>>> d.Asset Life Cycle - Is this section needed? If so, what do we >>>>>>>> want to >>>>>>>> say? Any volunteers willing to contribute text? >>>>>>>> >>>>>>>> 6)Do you have any other general comments/questions on this section? >>>>>>>> >>>>>>>> Please let me know your thoughts on these questions. I'll make >>>>>>>> edits to >>>>>>>> the document as we agree on any changes that should be made. >>>>>>>> >>>>>>>> Sincerely, >>>>>>>> >>>>>>>> Dave >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sacm mailing list >>>>>>>> sacm@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> sacm mailing list >>>>>>> sacm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>> >>>>>> _______________________________________________ >>>>>> sacm mailing list >>>>>> sacm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>> _______________________________________________ >>>>> sacm mailing list >>>>> sacm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sacm >> From gunnar.engelbach@threatguard.com Thu Aug 29 09:38:56 2013 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C09011E8128 for ; Thu, 29 Aug 2013 09:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxzsL1PKRALY for ; Thu, 29 Aug 2013 09:38:51 -0700 (PDT) Received: from server.threatguard.com (server.threatguard.com [207.55.247.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD4611E8130 for ; Thu, 29 Aug 2013 09:38:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=threatguard.com; b=pZvtYv3Pz1X+AH/sbG8mLJUV3erGuEhWbBS56sUuep//FC0l1nHxppt58grw4zYb8a9kCsQSVUc6qglyDpwsPRjxne9WR7Tg5SMYmAG0pFLRsM4JAJbUcJAkneOR/I1m; h=Received:Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 13416 invoked from network); 29 Aug 2013 09:38:34 -0700 Received: from h96-61-82-50.cntcnh.dsl.dynamic.tds.net (HELO ?172.16.1.22?) (96.61.82.50) by 207.55.247.241 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 29 Aug 2013 09:38:33 -0700 Message-ID: <521F791A.5000406@ThreatGuard.com> Date: Thu, 29 Aug 2013 12:38:50 -0400 From: Gunnar Engelbach Organization: ThreatGuard, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Henk Birkholz References: <521E3AD8.6070908@ThreatGuard.com> <521E411B.70900@sit.fraunhofer.de> <521E466C.7070002@ThreatGuard.com> <824fcf330d0945b6a97e63b80591720f@BLUPR09MB038.namprd09.prod.outlook.com> <521EB641.9000306@ThreatGuard.com> <521F25E8.5000109@sit.fraunhofer.de> <521F65F0.8080701@ThreatGuard.com> <521F72EB.7050807@sit.fraunhofer.de> In-Reply-To: <521F72EB.7050807@sit.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Waltermire, David A." , "sacm@ietf.org" Subject: Re: [sacm] Use Cases: Asset Management X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 16:38:56 -0000 Sorry that I wasn't grasping your example. Yes, some data collected in the process of doing security assessments would be useful to an asset management system, liveness being just one example. When I suggested that we focus more on the ability to interact with existing asset management systems, that would be a two-way interaction. Because of the diversity of asset management systems and their capabilities I don't see this as being a "MUST" requirement, but a "MAY." A sentence or two can be added to many of the existing use cases describing this. The question this brings up for me is: do we leave it up to vendors to work out how to talk to asset management systems, or do we try to define a standard for that? On 8/29/2013 12:12 PM, Henk Birkholz wrote: > Please excuse my brevity regarding the scenario example. Actual > monitoring of liveness should be done with systems/senors built > specifically for that purpose, of course. > > I was thinking more in the direction of supporting (and in some places > partially automating) the configuration of monitoring systems, SIEM > systems and such. Asset information derived from existing infrastructure > (e.g. via asset discovery or existing meta-directories) that is > aggregated in a Content Repository could be used as a basis to generate > corresponding configuration for these system. > > SACM is a core mechanism to automatically distribute security-related > metadata in order to enhance the awareness over the state of the > infrastructure. Hence, some kind of asset management related information > should be included, I think. > > I understand the drawbacks of maybe bloating the scope of SACM with > "things that are already there", but separating asset management and > security automation seems to be even worse. This typical separation and > reliance on asset management implementations that should already be > there is maybe one of the significant problems SACM could really improve. > > Also, I think the term asset management is still a bit fuzzy at the > moment, and it might be confusing if presented as a use case. > > On 08/29/2013 05:17 PM, Gunnar Engelbach wrote: >> >> >> So, you'd like to use a SACM implementation to monitor liveness of >> network endpoints? >> >> Even if a SACM implementation included an asset management capability, I >> think it's not going to be ideal for performing this kind of function. >> You'd be better served using a network monitoring system that is built >> specifically for that purpose. >> >> >> >> On 8/29/2013 6:43 AM, Henk Birkholz wrote: >>> Another specific part of asset management as a requirement for SACM is >>> the differentiation between live-cycle related changes and error related >>> changes in the infrastructure, I think. >>> >>> Simple example: availability monitoring shows/raises a down-condition >>> for a network endpoint. If the endpoint was removed due to the end of >>> its live-cycle, this indicates a missing adaption of the monitoring >>> configuration and an invalid alarm. Other reasons might result in a >>> valid alarm. >>> >>> This scenario is strongly related with the whole asset >>> management/live-cycle process and would need a corresponding use case to >>> present the required context, correct? >>> >>> I agree with the opinion that nobody would deploy a SACM system for the >>> sole purpose of doing asset management, and presenting asset management >>> as a use case might be misleading somehow. Maybe the purpose of section >>> 4.1 as a use case is still too fuzzy? Or a more specific section/use >>> case title could help? Essentially, if all requirements must be based on >>> a corresponding use case (is that the case?), something appropriate is >>> needed in section 4. >>> >>> >>> On 08/29/2013 04:47 AM, Gunnar Engelbach wrote: >>>> >>>> >>>> On 8/28/2013 4:33 PM, Waltermire, David A. wrote: >>>>> Gunnar, >>>>> >>>>> Are you suggesting that we remove the asset management section from >>>>> the use case draft? If not, what would you change? >>>> >>>> >>>> >>>> Yes. I'm suggesting that, for SACM, asset management is not a use >>>> case, >>>> but certain parts of asset management are requirements for SACM. >>>> Specifically: >>>> >>>> 1) We need a taxonomy for determining what assessment content >>>> applies to >>>> an endpoint >>>> >>>> 2) We need to be able to identify a particular asset when communicating >>>> between SACM nodes >>>> >>>> 3) We need to be able to generate a list of endpoints to perform an >>>> assessment against -- call that discovery* >>>> >>>> And for the assessment model that is driven by change event >>>> notification >>>> pushed from endpoints, discovery is not needed. >>>> >>>> >>>> Fleshing out all the requirements so that a SACM installation can be >>>> used as an asset management system seems to go well beyond what is >>>> needed. Given the near-ubiquity of existing asset management systems I >>>> think we should be more interested in interacting with those than >>>> trying >>>> to invent another one. >>>> >>>> >>>> Now, with all of that said, there are going to be cases where a SACM >>>> installation needs to include it's own asset management system. >>>> Allowing >>>> for that possibility, is it within scope of this working group to also >>>> define what that looks like, or can we take it as a given that such >>>> things exist? I'd say that the furthest we want to go is to define our >>>> own standardized way for interacting with an asset management system >>>> that is just enough to fulfill the needs of SACM. >>>> >>>> >>>> >>>> >>>> * Discovery in this case is extremely broad. It could be via manual >>>> user interaction, enumeration of an LDAP/AD server, event notification >>>> from a NAC system or DHCP server, ringing out a network, querying an >>>> asset management system, enumeration of live targets via IPv6 >>>> properties, and on and on. >>>> >>>> >>>>> >>>>> More comments below. >>>>> >>>>>> -----Original Message----- >>>>>> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On >>>>>> Behalf Of >>>>>> Gunnar Engelbach >>>>>> Sent: Wednesday, August 28, 2013 2:50 PM >>>>>> To: Henk Birkholz >>>>>> Cc: sacm@ietf.org >>>>>> Subject: Re: [sacm] Use Cases: Asset Management >>>>>> >>>>>> >>>>>> Yes, the needs of SACM intersect with the realm of asset management. >>>>> >>>>> Agreed. We need to focus use cases around this intersection. >>>>> >>>>>> But, again, is standardizing asset management really a use case for >>>>>> SACM? >>>>> >>>>> Strictly speaking, I would say no. But some aspects like asset >>>>> discovery (identifying new endpoints that join a network), asset >>>>> identification (relating collected data to assets), and asset >>>>> representation reconciliation (sorting out different identification >>>>> approaches) are aspects that we need to deal with as a matter of the >>>>> SACM scope. Asset characterization is a bit more nuanced. I believe at >>>>> minimum we need some capability to get data about an asset that sets >>>>> an expectation of its intended posture. For example, we need to know >>>>> something about what the intended function of the device is to >>>>> understand how to evaluate its posture. >>>>> >>>>>> Putting it another way, is it reasonable to think that somebody would >>>>>> deploy >>>>>> a SACM system for the sole purpose of doing asset management? >>>>> >>>>> Possibly, but not likely. If we address asset discovery, which I >>>>> believe we should, this capability could be used standalone without >>>>> any further data collection. >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 8/28/2013 2:27 PM, Henk Birkholz wrote: >>>>>>> Information about assets provides the link/relationship between >>>>>>> monitoring techniques, services, vulnerabilities, etc. While Asset >>>>>>> Management is indeed a quite general term, it incorperates the >>>>>>> acquisition and provision of asset information which is an important >>>>>>> prerequisite in sacm, I think. >>>>>>> >>>>>>> On 08/28/2013 08:00 PM, Gunnar Engelbach wrote: >>>>>>>> >>>>>>>> 4.1.1 Asset Discovery, first paragraph: "alowing" could use >>>>>>>> another l. >>>>>>>> >>>>>>>> >>>>>>>> Now that you mention it, I found myself wondering of asset >>>>>>>> management >>>>>> is >>>>>>>> really a SCAM use case. Certainly the needs of SACM intersect with >>>>>>>> asset management, but is it really one of the goals of SACM that we >>>>>>>> produce standards for creating an asset management system? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 8/27/2013 2:00 PM, Waltermire, David A. wrote: >>>>>>>>> Last week I posted the WG draft version of the use cases document >>>>>>>>> (http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/). >>>>>>>>> Changes >>>>>>>>> since the -05 version are listing in the change log within the >>>>>>>>> document >>>>>>>>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-8). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> What I'd like to do next is focus the WGs attention on individual >>>>>>>>> sections of the use case document for a week or two each to >>>>>>>>> work on >>>>>>>>> wrapping up the text and to develop overall consensus. Starting >>>>>>>>> this >>>>>>>>> week I would like to focus on section 4.1 Asset Management >>>>>>>>> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-4.1). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> My hope is that this approach will lead us through development of >>>>>>>>> the >>>>>>>>> document before the next draft submission deadline. >>>>>>>>> >>>>>>>>> Based on the current text I have the following questions: >>>>>>>>> >>>>>>>>> 1)Is the current structure of this section acceptable? If not, >>>>>>>>> what >>>>>>>>> should be done differently? >>>>>>>>> >>>>>>>>> 2)Are there key terms that should be defined in the terminology >>>>>>>>> draft? >>>>>>>>> If so, what terms and what definition should be used? >>>>>>>>> >>>>>>>>> 3)We currently have the following sub-sections that represent >>>>>>>>> different >>>>>>>>> lifecycle aspects related to Asset Management. Are these the best >>>>>>>>> way >>>>>> to >>>>>>>>> break up asset management into discrete use cases? >>>>>>>>> >>>>>>>>> a.Asset Discovery >>>>>>>>> >>>>>>>>> b.Asset Identification >>>>>>>>> >>>>>>>>> c.Endpoint Components and Asset Composition >>>>>>>>> >>>>>>>>> d.Asset Characterization >>>>>>>>> >>>>>>>>> e.Asset Resources >>>>>>>>> >>>>>>>>> f.Asset Representation Reconciliation >>>>>>>>> >>>>>>>>> g.Asset Life Cycle >>>>>>>>> >>>>>>>>> 4)Do you agree with the current text in each sub-section? If not, >>>>>>>>> why >>>>>>>>> not? Do you have alternate text to contribute? >>>>>>>>> >>>>>>>>> 5)Here are a few questions regarding some of the sub-sections: >>>>>>>>> >>>>>>>>> a.Asset Characterization - Are there other important >>>>>>>>> characteristics to >>>>>>>>> list? >>>>>>>>> >>>>>>>>> b.Asset Resources - Should this be addressed under asset >>>>>>>>> management >>>>>> or >>>>>>>>> under data collection in a different section? Is the human- vs. >>>>>>>>> machine-collected distinction important here? >>>>>>>>> >>>>>>>>> c.Asset Representation Reconciliation - We need text to flesh this >>>>>>>>> section out. Any volunteers? >>>>>>>>> >>>>>>>>> d.Asset Life Cycle - Is this section needed? If so, what do we >>>>>>>>> want to >>>>>>>>> say? Any volunteers willing to contribute text? >>>>>>>>> >>>>>>>>> 6)Do you have any other general comments/questions on this >>>>>>>>> section? >>>>>>>>> >>>>>>>>> Please let me know your thoughts on these questions. I'll make >>>>>>>>> edits to >>>>>>>>> the document as we agree on any changes that should be made. >>>>>>>>> >>>>>>>>> Sincerely, >>>>>>>>> >>>>>>>>> Dave >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sacm mailing list >>>>>>>>> sacm@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sacm mailing list >>>>>>>> sacm@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sacm mailing list >>>>>>> sacm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sacm >>>>>> _______________________________________________ >>>>>> sacm mailing list >>>>>> sacm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sacm >>> >