Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability

"Haynes, Dan" <dhaynes@mitre.org> Tue, 28 June 2016 12:06 UTC

Return-Path: <dhaynes@mitre.org>
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 461D312DE48 for <sacm@ietfa.amsl.com>; Tue, 28 Jun 2016 05:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.625
X-Spam-Level:
X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrezAkN1gpc4 for <sacm@ietfa.amsl.com>; Tue, 28 Jun 2016 05:06:04 -0700 (PDT)
Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id C87D412DE16 for <sacm@ietf.org>; Tue, 28 Jun 2016 05:06:03 -0700 (PDT)
Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5F94E6C03AE; Tue, 28 Jun 2016 08:06:03 -0400 (EDT)
Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 3D4BB6C043C; Tue, 28 Jun 2016 08:06:03 -0400 (EDT)
Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 28 Jun 2016 08:06:02 -0400
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Tue, 28 Jun 2016 08:06:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QDmwgNxx2MmsR06UX1KShMDkgXAVw74SMqWwEPflYqw=; b=IWpkXWa6RUJ+lC4aSCGKkdiayrl7dhMF2uoFYoyHkIUF9HZEodkqerFzLLWjRdGu6agTjitnLWod3yAEA+6GGBEwzHlDoEo0uJKihnbPE8TjtFVKCAcBnmgCVIoVaBZ/zgTqa4iVzEfR9zRRp07PE0s9Z8hr76foKlRlbXDuMlw=
Received: from BY2PR09MB1078.namprd09.prod.outlook.com (10.166.116.10) by BY2PR09MB1079.namprd09.prod.outlook.com (10.166.116.11) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 28 Jun 2016 12:05:55 +0000
Received: from BY2PR09MB1078.namprd09.prod.outlook.com ([10.166.116.10]) by BY2PR09MB1078.namprd09.prod.outlook.com ([10.166.116.10]) with mapi id 15.01.0523.024; Tue, 28 Jun 2016 12:05:56 +0000
From: "Haynes, Dan" <dhaynes@mitre.org>
To: Adam Montville <adam.w.montville@gmail.com>, Ira McDonald <blueroofmusic@gmail.com>
Thread-Topic: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability
Thread-Index: AdGwcFvLuy7EoIEtTYaAcqw7unANPgNvMHSAAHxc8hAAFObXAAHecrngAD5pOoAAIGDrgAAILXcAASCK9UAAAvzEgACnP6gAACCKZiA=
Date: Tue, 28 Jun 2016 12:05:55 +0000
Message-ID: <BY2PR09MB107882EB6572D4BE51F32C4BA5220@BY2PR09MB1078.namprd09.prod.outlook.com>
References: <BY2PR09MB107855437DBFE3B22987B6A0A5490@BY2PR09MB1078.namprd09.prod.outlook.com> <CAA=AuEe8VpnAKZ7u5NMpK5O4qU8JWnoJsqTRhP9KjbC8bgACpQ@mail.gmail.com> <BY2PR09MB107834DEC2DE93DC7495740CA55D0@BY2PR09MB1078.namprd09.prod.outlook.com> <CAA=AuEfUJeUfmQ00pC1x1Pdtbog=qkfk=Lzyp6DpR4OKW4NPAA@mail.gmail.com> <BY2PR09MB1078CAB1881C9EF7E1106407A5560@BY2PR09MB1078.namprd09.prod.outlook.com> <69E56E0A-36E1-4529-B192-EDE4AE58E4DD@gmail.com> <CAN40gSuZ1+6-psCOEcbq-iDrOz2iReKLxmRv5QAkYNLx2FtwEw@mail.gmail.com> <F7FF0658-85D0-4FF6-B477-9C988E2912FA@gmail.com> <BY2PR09MB107887CC0CC80F1687967863A52E0@BY2PR09MB1078.namprd09.prod.outlook.com> <CAN40gSu9zngd0FSRUZwyNyY+x1P6YwZQEO4fReOunanWi66mjQ@mail.gmail.com> <F7FFDC3F-537F-4FBE-B379-79C56676AC64@gmail.com>
In-Reply-To: <F7FFDC3F-537F-4FBE-B379-79C56676AC64@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dhaynes@mitre.org;
x-originating-ip: [192.160.51.86]
x-ms-office365-filtering-correlation-id: fafa8919-f734-4d82-c9c5-08d39f4c8f6f
x-microsoft-exchange-diagnostics: 1; BY2PR09MB1079; 6:nwmx2xpFkhMAdeuvEY6fQwrpO45p0ERfJ6eBiDQf/3TtORFYFRn1RXqLIeN66yIF7bSuUIRNYBGZ9pVDyRRjpjkg65ezPQlYF3FyPvMYbnuQcliDTxMYQ5CzpWJOxA0lw77GXP3/kFDqwaGptwLrdvu6RYdPTalKsUJRkl1HibUaNlXaxUEIg5ZlYCmPiXbs+KbyaoQTbnuuqVa9Z0XLPRLSR89Ld54J5lmqx4sDcUHO5/DPj5a+jm9WCL77bvBEXjtfE/XPUwKC/la8YwDjRJcDzae2HyhRR0gBeVGPo8lbRBTIe0Dz+C5JPyPJeA3kxj6AwWV+QCkee9xNxbd88HIuYfFeMKT9TC6i8gqLpaQ=; 5:1QtwZEitafX4DnTwR7y3uBLxBUnyPy2tZI8M7RIi0LVjjtJHbaVdjj9eEZPuMzfbtN3Eiy5n+Y+V1D7qEv3XSiL4bD2QNIqR9Tfc4hCb7QfK3/PTwe2qzxyI6IYgnIrw+5Qd/9hAeatufXRYte4p+Q==; 24:L+K+mxO00NIIJIxaGaFtBcg9rz7VvgbdqTtvhrgrNvTX8siVlT8n5KPGfhF+D8/OXsm26XUGbeObhKD+m5O7Qmsg7y1IE06bJmob2keW+MU=; 7:1ZzltHgtVqVJS37+n1xO647NM4iBaV4vhAirydlYL1O+tTYyZDCLXxU6MzHoJ4dUbL0B5YqrBYtLWAuemXjNYEwulf0tvqlLhulioD5Lg25E2et4iuHIAtWSxCIX5yNsRaMEr4gSCp228+0JaL24wn9BASMi+yKh81Lt05NmYU6imilSORqKA7qb8HurYijcOmEX0mk+LbFVIDnimEuBh2oELnbYP6LI97WUDU9ySPkzyDDyebdPn6g6+8okCnIlNM0UhFVulJsWt86BwPzW7Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR09MB1079;
x-microsoft-antispam-prvs: <BY2PR09MB10793C95FD5F0F74EFD12E07A5220@BY2PR09MB1079.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(166708455590820)(111039206520245)(211936372134217)(100405760836317)(21748063052155)(211171220733660);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BY2PR09MB1079; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB1079;
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(76104003)(377424004)(5383002)(189002)(24454002)(51914003)(13464003)(377454003)(199003)(57704003)(478694002)(586003)(87936001)(76576001)(19625215002)(7846002)(68736007)(189998001)(8936002)(77096005)(790700001)(99286002)(101416001)(3846002)(76176999)(33656002)(102836003)(86362001)(19273905006)(2950100001)(2900100001)(19300405004)(122556002)(16236675004)(6116002)(10400500002)(50986999)(5001770100001)(7736002)(97736004)(92566002)(5003600100003)(7696003)(9686002)(7906003)(19580395003)(8676002)(81166006)(81156014)(19609705001)(105586002)(19580405001)(19617315012)(66066001)(74316001)(2906002)(5002640100001)(54356999)(3280700002)(15975445007)(106356001)(93886004)(3660700001)(4326007)(16351025005)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR09MB1079; H:BY2PR09MB1078.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR09MB107882EB6572D4BE51F32C4BA5220BY2PR09MB1078namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2016 12:05:55.9848 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB1079
X-OriginatorOrg: mitre.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/Di014n1Wawa-fA__T2FsVYwG1w4>
Cc: Jerome Athias <athiasjerome@gmail.com>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jun 2016 12:06:07 -0000

Thanks for the feedback Jerome, Ira, and Adam!

If anyone else has thoughts on this change, please let me know.  Otherwise, based on the feedback so far, I am planning to pull in the changes at the end of the week.

Thanks,

Danny

From: Adam Montville [mailto:adam.w.montville@gmail.com]
Sent: Monday, June 27, 2016 4:32 PM
To: Ira McDonald <blueroofmusic@gmail.com>
Cc: Haynes, Dan <dhaynes@mitre.org>; Jerome Athias <athiasjerome@gmail.com>; sacm@ietf.org
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability

+1 (contributor)

On Jun 24, 2016, at 7:43 AM, Ira McDonald <blueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com>> wrote:

Hi Danny,

+1
Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
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<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 Fri, Jun 24, 2016 at 7:19 AM, Haynes, Dan <dhaynes@mitre.org<mailto:dhaynes@mitre.org>> wrote:
I just reviewed the latest version of the I-D and found only one occurrence of “pre-assessment” in Appendix I.3 which says:

“Within the SACM Architecture, the assessment task would be handled by the Evaluator component.  If pre-assessment data is used, this would be stored on and obtained from a Data Store component.”

I think this could easily be re-written to remove “pre-assessment” and say:

“Within the SACM Architecture, the assessment task would be handled by the Evaluator component. If previously collected data is used, it would be obtained from a Data Store component.”

I think we could also rewrite the latest revision of the text (from my Jun 16th message) to read as follows (which also makes use of SACM tasks which was suggested at the last virtual interim meeting).

"The collection of additional endpoint information for the purpose of vulnerability assessment does not necessarily need to be a pull by the vulnerability assessment capability.  Over time, some new pieces of information that are needed during common types of assessments might be identified. An endpoint management capability can be reconfigured to have this information delivered automatically. This avoids the need to trigger additional Collection Tasks to gather this information during assessments, streamlining the assessment process. Likewise, it might be observed that certain information delivered by an endpoint management capability is rarely used. In this case, it might be useful to re-configure the endpoint management capability to no longer collect this information to reduce network and processing overhead. Instead, a new Collection Task can be triggered to gather this data on the rare occasions when it is needed."
Let me know what you think of these changes.  If they seem reasonable, I can integrate them into the next revision of the I-D and we can close out this issue.

Thanks,

Danny

From: Adam Montville [mailto:adam.w.montville@gmail.com<mailto:adam.w.montville@gmail.com>]
Sent: Saturday, June 18, 2016 1:36 PM
To: Ira McDonald <blueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com>>
Cc: Haynes, Dan <dhaynes@mitre.org<mailto:dhaynes@mitre.org>>; Jerome Athias <athiasjerome@gmail.com<mailto:athiasjerome@gmail.com>>; sacm@ietf.org<mailto:sacm@ietf.org>

Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability


My concern does not stem from using the prefix “pre”, as much as it is about the definition of the term assessment and how we’re using pre-assessment often, which turns into “collecting before the process of collecting”, which is confusing at best.

The situation we are looking at feels very much like a cache miss.  We look for some information in one place and don’t find it, so we have to go fetch it from somewhere else.



On Jun 18, 2016, at 8:41 AM, Ira McDonald <blueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com>> wrote:

Hi,

I share Adam's distaste for "pre-" anything.

Perhaps "external collection" - defined as simply using any non-SACM
protocol to forward endpoint posture to a SACM Collector (in this case,
e.g., a NEA Server)?

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
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<mailto:blueroofmusic@gmail.com>
Winter  579 Park Place  Saline, MI  48176  734-944-0094<tel:734-944-0094>
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434<tel:906-494-2434>


On Fri, Jun 17, 2016 at 6:14 PM, Adam Montville <adam.w.montville@gmail.com<mailto:adam.w.montville@gmail.com>>
wrote:

I really don’t want to be the one to bring this up, but are we forgetting
our definition of “assessment”?  We borrow, and expand upon, the term from
RFC5209.  Here’s what our terminology draft says:

Assessment: Defined in [RFC5209] as “the process of collecting posture for
a set of capabilities on the endpoint (e.g. host-based firewall) such that
the appropriate validators may evaluate the posture against compliance
policy.”  Within SACM the use of the term is expanded to support other uses
of collected posture (e.g. reporting, network enforcement, vulnerability
detection, license management).  The phrase “set of capabilities on the
endpoint” includes: hardware and software installed on the endpoint.

But, in the text proposed, and in general, we are talking about collection
in the context of *pre*-assessment.  So, a collection before “the process
of collecting posture…”, which seems off to me.

Do we really mean to say, pre-evaluation?  Or, do we need “pre” anything?
There is data available at the time of evaluation or there is not.  If
there is not, we go grab it, or indicate that it needs to be grabbed during
the next collection opportunity, and we indicate whether it’s something we
need to grab all the time, or just this once.

Thoughts?

Adam



On Jun 16, 2016, at 12:15 PM, Haynes, Dan <dhaynes@mitre.org<mailto:dhaynes@mitre.org>> wrote:

Off list, I received a suggested update to this text from Charles.  I was
hoping to discuss it at yesterday’s virtual interim meeting, however, I ran
out of time.  As a result, I would like to propose the updated text as it
seemed clearer and more concise than what I had proposed, but, says the
same thing.

The new text would read as follows (based on the updated draft posted on
6/8/16 [1]).

"Supplemental collection of endpoint information for the purposes of…Over
time, some new pieces of information that are needed during common types of
assessments might be identified. Pre-assessment collection can be
reconfigured to have this information delivered automatically. This avoids
the need for regular supplemental collections to gather this information
during assessments, streamlining the assessment process. Likewise, it might
be observed that certain information delivered during pre-assessment
collection is rarely used. In this case, it might be useful to stop
pre-assessment collection of this information to reduce network and
processing overhead. Instead, supplemental collection can be used to gather
this data on the rare occasions when it is needed."

Please let me know your thoughts on this proposed text by Tuesday July 21
st.

Thanks,

Danny

[1] https://www.ietf.org/id/draft-ietf-sacm-vuln-scenario-00.txt



*From:* Jerome Athias [mailto:athiasjerome@gmail.com
<athiasjerome@gmail.com<mailto:athiasjerome@gmail.com>>]
*Sent:* Tuesday, June 07, 2016 12:08 AM
*To:* Haynes, Dan <dhaynes@mitre.org<mailto:dhaynes@mitre.org>>
*Cc:* sacm@ietf.org<mailto:sacm@ietf.org>
*Subject:* Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue
#5 - Change Detection with an Endpoint Management Capability

This rewrite is imho better
Thanks

On Tuesday, 7 June 2016, Haynes, Dan <dhaynes@mitre.org<mailto:dhaynes@mitre.org>> wrote:

Based on the feedback, would the following rewrite of the paragraph help
clarify things?

"In many cases, the endpoint information...Under certain deployment
scenarios, as
the vulnerability management capability processes vulnerability detection
data over
time, the endpoint management capability may learn about additional
detection
information that it was previously not collecting and push that
information to the
vulnerability management capability where it can support future
assessments. The
pushing of this data may potentially be driven by some trigger (e.g.,
change
in software inventory, policy, network connectivity status, etc.)."

While this potentially creates a coupling between the vulnerability
management capability and the endpoint management capability, as written, I
think it will be left to the implementer of those capabilities to decide.
I think the point is just that you could do something like this to improve
the vulnerability assessment.

If we still don't have consensus on this, another approach might be to
just remove this text all together as I don't think doing so would preclude
an implementer from supporting functionality like this in their product.

Thoughts?

Thanks,

Danny

-----Original Message-----
From: Jerome Athias [mailto:athiasjerome@gmail.com]
Sent: Saturday, June 04, 2016 2:49 AM
To: Haynes, Dan <dhaynes@mitre.org<mailto:dhaynes@mitre.org>>
Cc: sacm@ietf.org<mailto:sacm@ietf.org>
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue
#5
- Change Detection with an Endpoint Management Capability

While the scenario provided by Adam is valid, if your concern is that
"the
information beyond that" would be "supplemental endpoint
information":
I don't see a scenario where an endpoint management capability would have
to push -supplemental- information to the vulnerability assessment
capability (what would the vulnerability assessment capability do with
'unknown' additional information)

So I think the issue is to change "the information beyond that" to
something
like "the updated information"



2016-05-18 16:15 GMT+03:00 Haynes, Dan <dhaynes@mitre.org<mailto:dhaynes@mitre.org>>:
During yesterday’s virtual interim meeting, we discussed various open
issues with respect to the Vulnerability Assessment Scenario [1] as a
result of feedback that we received on the draft which you can see
here [2][3].  The slide’s from the meeting can be found here [4].



One issue that we didn’t have a chance to discuss because we ran out
of time was whether or not an endpoint management capability has the
ability to push supplemental endpoint information to the vulnerability
assessment capability.  This question came out of a review of the
following text from the Vulnerability Assessment Scenario
(specifically the
last sentence).



“In many cases, the endpoint information needed to determine an
endpoint’s vulnerability status will have been previously

collected by the Endpoint Management Capability and available in a
Repository. However, in other cases, the necessary

endpoint information will not be readily available in a Repository and
a targeted collection will be necessary.  Of course,

an implementation of an endpoint management capability may prefer to
enable operators to perform targeted collection under

certain circumstances, even when sufficient information can be
provided by the endpoint management capability (e.g. there

may be freshness requirements for information). Targeted collection of
endpoint information for the purpose of vulnerability

assessment does not necessarily need to be a pull by the vulnerability
assessment capability.  Under certain deployment

scenarios, once the necessary detection information is known, the
information beyond that which is available in the endpoint

management capability can be pushed to the vulnerability assessment
capability by the endpoint whenever that information

changes.”



Our main question is whether or not pushing information from the
endpoint management capability to the vulnerability assessment
capability is actually possible because it would not necessarily know
what information it needs to push prior to the server requesting it
(in which case it is probably considered a pull)?  Is there a
situation where the endpoint would know, in advance, what additional
information is needed for an assessment without a server requesting it?



If you have any thoughts on this issue, please provide feedback by May
31st.
We are planning to have an updated version of the scenario for June
8th.



Thanks,

Danny



[1] https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/

[2] https://github.com/sacmwg/vulnerability-scenario/pull/3

[3] https://www.ietf.org/mail-archive/web/sacm/current/msg03958.html

[4] https://datatracker.ietf.org/doc/slides-interim-2016-sacm-3-1/
(looks like the slides are not available just yet, but, I suspect they
should be
soon)




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

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



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