Re: [Gen-art] Genart telechat review of draft-ietf-sacm-nea-swima-patnc-02
Dan Romascanu <dromasca@gmail.com> Thu, 22 February 2018 08:35 UTC
Return-Path: <dromasca@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3384A1270A7; Thu, 22 Feb 2018 00:35:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jzVWjeDuKapK; Thu, 22 Feb 2018 00:35:09 -0800 (PST)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBED712704A; Thu, 22 Feb 2018 00:35:08 -0800 (PST)
Received: by mail-qt0-x22a.google.com with SMTP id f4so5347119qtj.6; Thu, 22 Feb 2018 00:35:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GCSiux6xQzEX5ojZ6/5IizKgJZdhIFUsvFlBzB7V3vU=; b=qkNAYGVaCBvHfN5OKypQWUAhnMrRNIjFcN1aF8o9Prun0PwLvtP6eR3D8CJPrDwkpY 4JIfzn9L4jGed10ZlRkKBpYs++Sc2kbPBERHNckCLZAWvjI24QfueI16SQW7Q62ltTyY tHLk5pBpEtURivcccyArhiCUntSiCmHldcpi/ocFi8fLYKku0BulS8bt1oeVWSh268rU 34JC7F/z/CVdJak/nEDiphr5D5laHYKxUfKSiXfm8C+9mKYMCVNno4bTcwYf0JQylvVN JTCtW7nTrjs3BB5mMQGubNlywJOGtWqnXd+fvyzFNlF/08PCvwptNLnDQ1G2aJNYhT/l 8Fcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GCSiux6xQzEX5ojZ6/5IizKgJZdhIFUsvFlBzB7V3vU=; b=JWAJPdKOkbRDXuWnlTAVxiywd9GdPJM2SzZBzobV7aEA9NG7FWUVn/A+21mR3GTIKt Oa7eiyIXsHNBZ4AmxLvJ7z1E4WglZzBzSZXItMY6PFcEXsowsJkGTYwKa1LimTUOGV82 I4GmWsv86Siq1IPBGFXte7n69sFZBhYsvMIXixAqQgnvUP/b3YyEdP5E8tnrpxzQreN2 dr5wbkU0aPrY4fafJPsx3SZCI6lFjfCANFr4pzaqXPUcgsEH8h8/oFNKBIAfxT7mVQ+y Ug7SeSL4spc/vjslm79mqf/P1CZuu144nY4ZIifmXEgHNJZJZLKklqygn8NkGiSsaDVh hcYw==
X-Gm-Message-State: APf1xPCGACHyguHqac1ncduzzKgu5vHpuMs48yGUBBS8UtGwgA3LaIww okWm/p0emeTEWOJ9xs0yrBP1y+PZUF3jPfEdSdQ=
X-Google-Smtp-Source: AH8x225dRzWJUR3ZCs0nIh3iNIGwQsIWspP+RII/DJtw7kV/x4hZiCVq1UlDLGMqUyeIZBhYyAkGf72A+JubPtF06+g=
X-Received: by 10.200.37.140 with SMTP id e12mr10080843qte.67.1519288507792; Thu, 22 Feb 2018 00:35:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.23.200 with HTTP; Thu, 22 Feb 2018 00:35:06 -0800 (PST)
In-Reply-To: <DM5PR0901MB2375FAE7907718165988294AABCE0@DM5PR0901MB2375.namprd09.prod.outlook.com>
References: <151898069815.27864.8612208400996416492@ietfa.amsl.com> <DM5PR0901MB237578DCF3767768F610B046ABCE0@DM5PR0901MB2375.namprd09.prod.outlook.com> <CAFgnS4Xh-93ANP++N7k=R3Go4ZpfLCwmYH17oddGuLGCXoevsg@mail.gmail.com> <DM5PR0901MB2375FAE7907718165988294AABCE0@DM5PR0901MB2375.namprd09.prod.outlook.com>
From: Dan Romascanu <dromasca@gmail.com>
Date: Thu, 22 Feb 2018 10:35:06 +0200
Message-ID: <CAFgnS4XkvzNGSKGH1aqOtoW1af0uv8uwHOx9+71=uxsCbuSrpg@mail.gmail.com>
To: "Schmidt, Charles M." <cmschmidt@mitre.org>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-sacm-nea-swima-patnc.all@ietf.org" <draft-ietf-sacm-nea-swima-patnc.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "sacm@ietf.org" <sacm@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c034d6d1812f0565c8eb3f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/ibetpvZSXyW7tKObHgO-wv9jbI4>
Subject: Re: [Gen-art] Genart telechat review of draft-ietf-sacm-nea-swima-patnc-02
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Feb 2018 08:35:12 -0000
Hi Charles. This paragraph is very reasonable and informative for all audiences. Thanks again. Dan On Thu, Feb 22, 2018 at 12:23 AM, Schmidt, Charles M. <cmschmidt@mitre.org> wrote: > Hi Dan, > > > > Thanks for your response. I agree on all points. I'll add the following > paragraph to the end of the introduction: > > > > "Part of the motivation for the development of SWIMA was to support the > IETF’s Security Automation and Continuous Monitoring (SACM) architecture. > More details about SWIMA’s role in SACM appear in <xref > target=”Relationship”/>. However, SWIMA has no dependencies on any part of > SACM and is usable wherever the NEA architecture is employed." > > > > Does this seem reasonable? (I agree that we need to address the > expectation that people will have to see SACM mentioned in a SACM WG > document, but I also want to make very sure that people don't see SWIMA as > only being applicable in that context.) > > > > Thanks, > > Charles > > > > *From:* Dan Romascanu [mailto:dromasca@gmail.com] > *Sent:* Wednesday, February 21, 2018 4:11 PM > *To:* Schmidt, Charles M. <cmschmidt@mitre.org> > *Cc:* gen-art@ietf.org; draft-ietf-sacm-nea-swima-patnc.all@ietf.org; > ietf@ietf.org; sacm@ietf.org > *Subject:* Re: Genart telechat review of draft-ietf-sacm-nea-swima- > patnc-02 > > > > Hi Charles, > > Thank you for your response and for addressing my comments. I feel that > they are largely addressed by your proposed resolution. See also in-line. > > Regards, > > Dan > > > > On Wed, Feb 21, 2018 at 10:50 PM, Schmidt, Charles M. <cmschmidt@mitre.org> > wrote: > > Hello, > > Thanks a bunch for the comments. I'm glad that you feel that it looks like > a solid contribution. > > With regard to your feedback, I have developed wording to address both > your major concerns and wanted to run it by you: > > --- > With regard to the lack of mention of SACM, I agree that it was an > oversight not to mention it in the Relationship to Other Standards section. > I propose adding the following paragraph at the end of that section: > > "The NEA architecture is intended to support a broad range of activities > and, as such, might be employed by other specifications. For example, > requirement T-001 in the SACM Requirements document (RFC 8248) notes that > NEA can support data collection from endpoints within the broader SACM > architecture. (Other parts of the NEA architecture, which SWIMA uses, meet > the other SACM data transport requirements.) In the SACM architecture, a > SWIMA-PV corresponds to a “SACM Collector” and a SWIMA-PC is a “SACM > Internal Collector”. In the SACM architecture, the SWIMA specification can > support activities relating to software inventory collection. Specifically, > SWIMA supports the SACM “Endpoint Posture Attribute Value Collection” use > case (section 2.1.3 or RFC 7632) by describing a collection mechanism that > enables event driven, scheduled, and ad-hoc data collection of software > inventory information. SWIMA’s flexibility with regard to the format of > inventory data records means that it is compatible with virtually any data > format that implements SACM’s “Define, Publish, Query, and Retrieve > Security Automation Data” (section 2.1.1 in RFC 7632). This is just one > example of how SWIMA can support broader security solution standards. Note > that, while SWIMA can support these SACM use cases, SWIMA has no > dependencies upon the SACM architecture or any other context in which NEA > might reasonably be applied." > > > > This looks good. I would also suggest to add a sentence or paragraph > describing for short the relationship to SACM in the Introduction. As this > is a SACM WG document, some readers would probably expect to see this > relationship mentioned earlier than in Section 9. > > > > > I believe this addresses most of the specific points you wanted to > include. I did not include a terminology mapping to "evidence record" and > "software identifier" because the SACM Terminology definition of > "attribute" is not internally consistent: it states "Attribute - Is a data > element, as defined in [RFC5209], that is > atomic" and "equivalent to attribute-value-pairs". However, RFC 5209 (NEA) > attributes are not atomic in nature, and will consist of many name-value > pairs. (I'll send a separate comment to the SACM list regarding this.) As > such, I'm not sure the terminology draft has a good parallel at this time > and I stuck to the clearer mappings. > > > > I understand your point. Please continue the discussion with the SACM > terminology authors to try to reach consistency. > > > > > > > ----- > > With regard to firmware and OS information, I added the following to the > introduction: > > " Note that while this specification focuses on “software inventory”, the > mechanisms it describes could also be used to convey information about > firmware and operating systems associated with an endpoint. The focus on > software throughout this document should not be read as excluding the use > of SWIMA for these other purposes." > > > > Fine - this is exactly what I was looking for. > > > --------- > > Do these additions adequately address your concerns? > > Finally, with regard to the following question: > > > 2. Section 3.3 > > ' In the case that it is possible to do so, the SWIMA-PC SHOULD send > > its SWIMA Response attribute to the SWIMA-PV that requested it using > > exclusive delivery ...' > > Assuming that 'it is possible to do so' means support for the mechanism, > why > > is this a SHOULD, and not a MUST? > > In the NEA specification, the EXCL flag is only a recommendation to the > Posture Broker Server/Client, and the recipient of a message with the flag > set only "SHOULD" deliver it to a single party. (I realize that, in > retrospect, my assertion that exclusive delivery "ensures" a behavior is > incorrect and will fix that.) As such, saying that implementations MUST set > a flag that only SHOULD be obeyed seems to be of questionable use, > especially given that the specification clearly describes what to do if > messages are not exclusively delivered. > > Let me know if you disagree - I don't feel too strongly about this, but > wanted to explain my thoughts. > > > > Makes sense. > > > > ---- > > Thanks again for the comments. > > Charles > > > > -----Original Message----- > > From: Dan Romascanu [mailto:dromasca@gmail.com] > > Sent: Sunday, February 18, 2018 1:05 PM > > To: gen-art@ietf.org > > Cc: draft-ietf-sacm-nea-swima-patnc.all@ietf.org; ietf@ietf.org; > > sacm@ietf.org; dromasca@gmail.com > > Subject: Genart telechat review of draft-ietf-sacm-nea-swima-patnc-02 > > > > Reviewer: Dan Romascanu > > Review result: Almost Ready > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please wait for direction from your > > document shepherd or AD before posting a new version of the draft. > > > > For more information, please see the FAQ at > > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > > > Document: draft-ietf-sacm-nea-swima-patnc-02 > > Reviewer: Dan Romascanu > > Review Date: 2018-02-18 > > IETF LC End Date: 2018-02-21 > > IESG Telechat date: 2018-02-22 > > > > Summary: > > > > This is a solid and detailed specification, which extends PA-TNS with > specific > > attributes and message exchanges to allow endpoints to report their > > installed > > software inventory information to a NEA server. It is Almost Ready from a > > Gen-ART point of view, but there are some problems that I recommend to > > be > > addressed before approval. The major problem is related to the complete > > lack of > > information about how this specification fits into SACM, which SACM > > requirements are addressed, how terminologies are made consistent and > > how > > entities are mapped. > > > > Major issues: > > > > 1. The document is labeled as a SACM document, but the text never > explains > > the > > connection with the SACM work, or the relation with the SACM architecture > > and > > framework. There is no reference to SACM documents either. Section 9 > > 'Relationship with other specifications' does not mention SACM either. > > > > At a minimum, I believe that the document should: > > - relate to the use cases of SACM - RFC 7632 (it does this for NEA, but > this is > > not sufficient for a SACM document) - ensure consistency, refer to the > > terminology of SACM (draft-ietf-sacm-terminology), and provide a mapping > > between the terms and entities defined in this document (e.g. SWIMA-PC, > > SWIMA-PV, Evidence Record, Software Identifier) and the SACM > > terminology - > > explain how the message exchanges fit in a SACM solution to meet the > > requirements defined by RFC 8248. As an example, RFC 5792 has a detailed > > appendix that evaluates the specifications against the requirements in > RFC > > 5209 > > (NEA requirements). > > > > 2. The charter item that this WG falls under reads: > > > > '- Define an extension of IETF NEA [https://ietf.org/wg/ > concluded/nea.html] > > to > > collect and deliver information about firmware, operating systems, and > > software > > installed on an endpoint.' > > > > The document covers in detail software inventory, but is mute about > > firmware > > and operating systems. Arguably these two would fall under a broad > > interpretation of 'software' but it would be better - at least - to > provide an > > explanation about these being covered and how, if not specific attributes > > related to the types of software specified in the charter. > > > > Minor issues: > > > > 1.Section 2.3: > > > > I believe that the 'Interoperable' requirement is trivial and > unnecessary in > > the text of a Standards-Track document. > > > > ' Interoperable: This specification defines the protocol for how PCs > > and PVs can exchange and use software information to provide a NEA > > Server with information about an endpoint’s software inventory. > > Therefore, a key goal for this specification is ensuring that all > > SWIMA PCs and PVs, regardless of the vendor who created them, are > > able to interoperate in their performance of these duties.' > > > > Interoperability is the obvious goal of any IETF standards-track > document. > > There is no need to repeat such an obvious statement. > > > > 2. Section 3.3 > > > > ' In the case that it is possible to do so, the SWIMA-PC SHOULD send > > its SWIMA Response attribute to the SWIMA-PV that requested it using > > exclusive delivery ...' > > > > Assuming that 'it is possible to do so' means support for the mechanism, > why > > is > > this a SHOULD, and not a MUST? > > > > Nits/editorial comments: > > > > 1. The Abstract section - quotation marks are open around the first > > document > > name and never closed. > > > > > > >
- [Gen-art] Genart telechat review of draft-ietf-sa… Dan Romascanu
- Re: [Gen-art] Genart telechat review of draft-iet… Schmidt, Charles M.
- Re: [Gen-art] Genart telechat review of draft-iet… Dan Romascanu
- Re: [Gen-art] Genart telechat review of draft-iet… Schmidt, Charles M.
- Re: [Gen-art] Genart telechat review of draft-iet… Alissa Cooper
- Re: [Gen-art] Genart telechat review of draft-iet… Dan Romascanu