From nobody Tue Aug 5 11:56:10 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D521A0110 for ; Tue, 5 Aug 2014 11:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.102 X-Spam-Level: X-Spam-Status: No, score=-13.102 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 EAu56HaxkxuT for ; Tue, 5 Aug 2014 11:56:04 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF921A010D for ; Tue, 5 Aug 2014 11:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4021; q=dns/txt; s=iport; t=1407264964; x=1408474564; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZcTmiywhjGmt6Bg9szObDx77wNUsJZGdzx4EXG/Rgdw=; b=kl+RfJNxu9OFV6qkWxrabrhXubafEgzlTxrYj72jHTYaTcyNEqawB+zh vpJot4n3X9lUO6ZnD+Q7ALGa8Pec0nGpFEFfJDW2kP+UKSJC3CFFkkVPN Y6/EsoMWSXfGqzB3g/v5k0ocHc3wNBSCrUJqUxA4hUkVupJoB9g6dR0Uw o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAJEo4VOtJV2Y/2dsb2JhbABbgw1SVwTFVIYUCodIAYEWFneEAwEBAQQBAQE3HxUXBAIBCBEEAQELFAkHJwsUCQgBAQQBEggBiDkNw2kXjnsBAR4zBQaDKYEcBY57oXODTWwBgQw5 X-IronPort-AV: E=Sophos;i="5.01,806,1400025600"; d="scan'208";a="66742729" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 05 Aug 2014 18:55:51 +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 s75Itpst010083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 18:55:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 5 Aug 2014 13:55:51 -0500 From: "Panos Kampanakis (pkampana)" To: "Roman D. Danyliw" , "mile@ietf.org" , "Martin Murillo" Thread-Topic: [mile] Feedback on draft-murillo-mile-cps-00 and implications for 5070bis Thread-Index: Ac+s5TljEUtloCIDQM6/AmC2E3H3/wD+SYeQ Date: Tue, 5 Aug 2014 18:55:50 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A7513C2AFBE@xmb-rcd-x10.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFCA4236C93@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCA4236C93@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.29.124] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/hXYcPUiIdES1Sp_teJVTZCxW5gE Subject: Re: [mile] Feedback on draft-murillo-mile-cps-00 and implications for 5070bis X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 18:56:10 -0000 Hi Roman, Comments below.=20 For 1) I think it would be worth of having a free form summary. For 2), I think it could help to have free text field for course of action.= I don't think IODEF was intended to focus on mitigations, but a free text = field that is option could benefit the receiving parties. For 3) I think two more attack-categorization enumeration values for System= @category and NodeRole@attack-type would also not be a problem. Agreed on the data from cps that can already be described in IODEF. Panos -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Thursday, July 31, 2014 2:32 PM To: mile@ietf.org; Martin Murillo Subject: [mile] Feedback on draft-murillo-mile-cps-00 and implications for = 5070bis Hello! The presentation on draft-multillo-mile-cps-00 at IETF 90 started a discuss= ion on identifying data elements described by cps-00 that might also be rel= evant to enterprise incident reports. In my judgment they are at least as = follows: (1) IncidentTitle (Section 5.6) and BriefDescriptionOfIncident (5.23) -- th= ese are classes that quickly summarize the document. A similar idea was pr= oposed in the bullet #4 of the feedback from the NATO implementation by Lag= adec Philippe (http://www.ietf.org/mail-archive/web/mile/current/msg01503.h= tml). Should we add a "Summary" class similarly defined as the Description= class to IODEF-Document, Incident, and EventData? (2) RecurrencePreventionMeasures (Section 5.22) -- should a free-form text = description be added to describe future measures that should be taken to pr= event the class of activity described in the document from occurring the fu= ture? (3) EntryPoint (Section 5.15) and CommandAndControlCenters (Section 5.18) -= - both of these classes attempt to categorize a system as having a given ro= le in the incident -- entry point into a network by the attacker and the C2= servers of the attacker. System@category in 5070bis also tries to categor= ize systems but with these enumerated values: source, target, intermediate,= sensor, or infrastructure. Only one category can be assigned per system. = NodeRole@attack-type is poorly documented (see Issue #40) but it allows fo= r values of c2-server, sink-hole, malware-distribution, phishing, spear-phi= shing, recruiting, fraudulent-site, and dns-spoof. =20 There appears to be a need to classify the intended role victim system inde= pendent of the incident, NodeRole@category, but also the role it played in = an incident/event especially in categorizing the attacker infrastructure, N= odeRole@attack-type/EntryPoint/CommandAndControlCenters. It seems like we = should reconcile these. In 5070bis, there appears to be overlap between Sy= stem@category and NodeRole@attack-type. EntryPoint and CommandAndControlCe= nters from cps-00 suggest new enumerated values for these attributes (or pe= rhaps for a new one)? Any strong feelings for adopting these concepts into 5070bis? I'm thinking= all three are useful and easy to implement. It was also suggested that certain overlap might exist. Comparing cps-00 w= ith 5070bis-07, I believe certain cps data elements can already be represen= ted without an extension. They are as follows: ** ReportingParty (Section 5.7) =3D Incident/Contact@role=3D{reporter, crea= tor} ** ReportReliability (Section 5.8) =3D {Incident,EventData}/Confidence ** TargetSystem (Section 5.11) =3D EventData/Flow/System@category=3D"target= "/Node/NodeRole ** Exploit (Section 5.14) =3D Incident/Method ** PerpetratingParty (Section 5.16) =3D Incident/RelatedActivity ** DetectioMethod (Section 5.17) =3D EventData/Discovery ** OrganizationalImpact (Section 5.21) =3D Assessment/{BusinessImpact,Monet= aryImpact} ** Logs (Section 5.24) =3D RecordData _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From nobody Tue Aug 5 12:10:43 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B8A1B2B3F for ; Tue, 5 Aug 2014 12:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 uLGoaRGhmb5e for ; Tue, 5 Aug 2014 12:10:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6257D1B2B1B for ; Tue, 5 Aug 2014 12:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1192; q=dns/txt; s=iport; t=1407265779; x=1408475379; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ahmsm/b8XgUsfTMa++RJ5XzMdLoKFspGCxp3+Bkjeg4=; b=Ev8ku6goHe6E7/YF/5njsxmPqitaq1Xef8/2/VvF7+Pl9clEWpLucM3M PPJSrLQg5mxyjhZbefCGOZozLOzZ9wlIBUy/T69B+wkgIUNElVXrw9UVR rqco3R5REMOYE3R0kkzD4+CAlzQtipuvLQA3Yz+TyYk7t3VN+3WE69rid I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAGIr4VOtJA2K/2dsb2JhbABbgw2BKQTTOgGBFhZ3hAMBAQEEOksEAgEIEQQBAQsUCQcyFAkIAgQBEgiIOsN3F45pMjgGgymBHAWwboNNbIFG X-IronPort-AV: E=Sophos;i="5.01,807,1400025600"; d="scan'208";a="345304622" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP; 05 Aug 2014 19:09:38 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s75J9cCF000744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 19:09:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 5 Aug 2014 14:09:38 -0500 From: "Panos Kampanakis (pkampana)" To: "Adam W. Montville" , MILE IETF Thread-Topic: [mile] EnumRef Format to IODEF Extension Suggestion Thread-Index: AQHPp/vReIwwh6QOe0eMSzN0+8dFbpvCcQFA Date: Tue, 5 Aug 2014 19:09:37 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A7513C2B0D5@xmb-rcd-x10.cisco.com> References: <2E4C41BB-5AA0-4493-8D25-5F036F02C1E3@gmail.com> In-Reply-To: <2E4C41BB-5AA0-4493-8D25-5F036F02C1E3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.29.124] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/lYLAYoU6a-_RY_tfIoaMynMWwOo Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 19:10:31 -0000 I support this effort, even though it will delay the enum document adoption= . Backwards compatibility is an issue, but give all the updates of IODEF-bis = this does not pose a huge concern. Panos -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Adam W. Montville Sent: Friday, July 25, 2014 7:30 AM To: MILE IETF Subject: [mile] EnumRef Format to IODEF Extension Suggestion Hello, During MILE's session this week at IETF 90, Roman suggested that the enum r= eference format be changed from an update to 5070 to an IODEF extension. T= his would require that the enum reference format draft be updated according= ly and that a full schema and namespace be considered for the format itself= , rather than simply updating the IODEF schema. The obvious drawback is that the enum reference document backpedals a bit a= nd will take longer to complete. A benefit is that this method of referenc= ing enumeration identifier formats can be reused by other efforts (I'm conf= ident that SACM could make use of the draft if we change it, for example). = =20 What are your thoughts/reactions to this proposal? =20 Regards, Adam From nobody Tue Aug 5 13:34:11 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE0F1B2B81; Tue, 5 Aug 2014 13:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.088 X-Spam-Level: ** X-Spam-Status: No, score=2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988] autolearn=no 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 Z4i9r6MTtcZQ; Tue, 5 Aug 2014 13:34:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD7A1B2B78; Tue, 5 Aug 2014 13:34:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140805203408.4058.78498.idtracker@ietfa.amsl.com> Date: Tue, 05 Aug 2014 13:34:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/oRBQI2tkfzz0MOiT7HlNSsL1h8o Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-08.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 20:34:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Managed Incident Lightweight Exchange Working Group of the IETF. Title : The Incident Object Description Exchange Format v2 Authors : Roman Danyliw Paul Stoecker Filename : draft-ietf-mile-rfc5070-bis-08.txt Pages : 140 Date : 2014-08-05 Abstract: The Incident Object Description Exchange Format (IODEF) defines a data representation for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mile-rfc5070-bis-08 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 nobody Tue Aug 5 13:35:51 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA5D1A02DC for ; Tue, 5 Aug 2014 13:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no 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 AAZMkzKPUARN for ; Tue, 5 Aug 2014 13:35:48 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F141A0202 for ; Tue, 5 Aug 2014 13:35:47 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s75KZlkB025131 for ; Tue, 5 Aug 2014 16:35:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1407270947; bh=mZh5euBB0UKOEG6tW5WGa157tZcLbMU9a4JgmqgknaY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=jMyjMxMg7rr9p2lJs2JvPsDDpn5emMQ2/CgPp/7kICeP0Q1dCZ9dQ8C5QfsAT4d8A LY9A5HfD4U4Kl+keV70ONEfN6fix7JHFx+djg9LFNmyR7U0mFLHJndAPFc7m216EEV LVHqdKPWN8zIhaK2HJM64W7hdHuX3sEZuI0UUsqM= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s75KZkuQ017724 for ; Tue, 5 Aug 2014 16:35:46 -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.0347.000; Tue, 5 Aug 2014 16:35:45 -0400 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-08.txt Thread-Index: AQHPsOyhNJhctIW9a0+ArKhavAkMYJvCd5PQ Date: Tue, 5 Aug 2014 20:35:45 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCA423DA91@marathon> References: <20140805203408.4058.78498.idtracker@ietfa.amsl.com> In-Reply-To: <20140805203408.4058.78498.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/80o7a7jQInpXCYSFuk--Kb7cOLI Subject: Re: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-08.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 20:35:50 -0000 A -08 version of draft-ietf-mile-rfc5070-bis has been released. The change= log is as follows: ** (text) Added improved language to HashData to described how the file and= email hashes should be computed ** (schema) Added HashData@type=3D{email-headers-hash, email-body-hash} (Is= sue #45) ** (schema) Added NodeRole@category=3D"webmail" to address feedback from dr= aft-mile-implementationreport-00 ** (text) Replaced RFC 4646 reference to be RFC 5646 (per Alexey review) ** (schema) Removed ReportID class ** (text) Changed the default value of Impact@type to be consistent with th= e schema (i.e., "unknown") (per NATO feedback) ** (text) Corrected HistoryItem@action text to reference Expectation@action= (per NATO feedback) ** (text) Corrected documentation of PostalAddress@meaning to have a data t= ype of STRING (per NATO feedback)=20 ** (schema) added Assessment/MitigatingFactor (Issue #45, sub-issue #3) Roman > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, August 05, 2014 4:34 PM > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Managed Incident Lightweight Exchange > Working Group of the IETF. >=20 > Title : The Incident Object Description Exchange Format= v2 > Authors : Roman Danyliw > Paul Stoecker > Filename : draft-ietf-mile-rfc5070-bis-08.txt > Pages : 140 > Date : 2014-08-05 >=20 > Abstract: > The Incident Object Description Exchange Format (IODEF) defines a > data representation for sharing information commonly exchanged by > Computer Security Incident Response Teams (CSIRTs) about computer > security incidents. This document describes the information model > for the IODEF and provides an associated data model specified with > XML Schema. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-rfc5070-bis-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From nobody Tue Aug 5 16:28:57 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8761A0320 for ; Tue, 5 Aug 2014 16:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 OPJ0gTYb70KV for ; Tue, 5 Aug 2014 16:28:52 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0ACA1A0328 for ; Tue, 5 Aug 2014 16:28:51 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s75NSglA027975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Aug 2014 19:28:43 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s75NSglA027975 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1407281323; bh=tw+jYCyX/OYFbtsJXKuqPOpof8g=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=l0wNR66NEYkSGYFYpRLd9sJUXm5/iECPcOGzqqX3zzt03He+FJGtrOfntkaCk+Iuu /j8poRyB6LQpdJL4EcCCJTyKfszyzG1pQCzWq6Casc6eeAyRExU6cU+aJ3HL2/6BZX UCDBrxcbKakw+lpyJxm5zCwFY19YQuAq/DS1ZBjg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s75NSglA027975 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd51.lss.emc.com (RSA Interceptor); Tue, 5 Aug 2014 19:28:29 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s75NSRFL030666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 19:28:28 -0400 Received: from mx15a.corp.emc.com ([169.254.1.206]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Tue, 5 Aug 2014 19:28:27 -0400 From: "Black, David" To: "Roman D. Danyliw" , MILE IETF Date: Tue, 5 Aug 2014 19:28:26 -0400 Thread-Topic: [mile] EnumRef Format to IODEF Extension Suggestion Thread-Index: AQHPp/vPeBk/3KyQQkqz05MK0UUJcJuxpzmAgAKHuTCABmQYQIAIIULA Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120779DE6F01@MX15A.corp.emc.com> References: <2E4C41BB-5AA0-4493-8D25-5F036F02C1E3@gmail.com> <359EC4B99E040048A7131E0F4E113AFCA4230360@marathon> <8D3D17ACE214DC429325B2B98F3AE712077860DE29@MX15A.corp.emc.com> <359EC4B99E040048A7131E0F4E113AFCA4236D2A@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCA4236D2A@marathon> 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-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/mile/Xmt1AqzvZIh0COzInBrBJXpHbA4 Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 23:28:56 -0000 Hello Roman, This is helpful (thanks): > I hadn't been thinking along these lines. To use a software analogy, I d= idn't > envision that we'd back-port the fix to a legacy version of the software > (IODEFv1, RFC 5070). Instead I figured we should make a library (an iode= f > enum extension) that the new version (IODEF v2, 5070bis) and alternate > software (SACM) could use. My thinking was if v1 is broken, upgrade to v= 2, > not v1.01. Well, the current draft is an incompatible back-port because it updates the IODEFv1 schema version to "1.01". I understand both you and Panos to be characterizing that as a bad idea (on which I defer to your expertise), so I'd like to explore alternatives. My next question is "what sort of library?". The email below proposes what is effectively a reusable XML (sub-schema) that can be included in other XML schemas. I wonder whether instead of supplying the (sub-)schema as a "library" that can be used at runtime, can we supply the XML schema snippet for enum reference formats for use in XML schema design along with the IANA registry= . One more question: Is there a case to be made for use of the same XML (sub-)schema (iodef-enum below) in multiple containing schemas, e.g., IODEFv2, SACM, etc., or is it sufficient to use the same XML syntax to represent the enumeration values? For "same XML syntax", the draft could recommend that anyone who wants to u= se an enumeration reference value put the following XML snippet in their schem= a: [NB: I changed "ReferenceName" to "SpecReferenceName" with the intent of enabling use of an unconstrained "ReferenceName" element for other purposes= .] The enum-reference-format draft could further recommend that documentation of any schema that includes that snippet include a reference to the IANA registry (created by the enum-reference-format draft) that defines the specIndex values. That ought to simplify adding this to the IODEFv2 (5070bis) schema. Thoughts? Thanks, --David > -----Original Message----- > From: Roman D. Danyliw [mailto:rdd@cert.org] > Sent: Thursday, July 31, 2014 3:34 PM > To: Black, David; MILE IETF > Subject: RE: [mile] EnumRef Format to IODEF Extension Suggestion > > Hello David! > > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: Sunday, July 27, 2014 1:47 PM > > To: Roman D. Danyliw; MILE IETF > > Cc: Black, David > > Subject: RE: [mile] EnumRef Format to IODEF Extension Suggestion > > > > Hello Roman, > > > > This approach is interesting, although it looks like it would still req= uire > a > > change to the IODEF Schema version. I wonder whether we can go further > > than arrange for the 5070bis draft to contain the only new version of t= he > > IODEF schema beyond RFC 5070. Towards that end, I have a couple of > > questions: > > I hadn't been thinking along these lines. To use a software analogy, I d= idn't > envision that we'd back-port the fix to a legacy version of the software > (IODEFv1, RFC 5070). Instead I figured we should make a library (an iode= f > enum extension) that the new version (IODEF v2, 5070bis) and alternate > software (SACM) could use. My thinking was if v1 is broken, upgrade to v= 2, > not v1.01. > > > (1) Could the SpecIndex attribute be added to the ReferenceName class i= n > > the IODEF v2 schema in 5070bis, as an optional attribute? My thinking = is > that > > having this new attribute be optional allows the IODEF v2 Reference cla= ss to > > continue to be used for everything that it's used for in IODEF v1, but = when > > the SpecIndex attribute is present, it constrains the ReferenceName to > > follow the format in the enumeration reference draft - the latter > > requirement would be imposed by additional text in the 5070bis draft. > > That does provide maximum flexibility. The thinking would be if you see = the > SpecIndex reference the enum draft to understand the semantics. If there= is > not SpecIndex reference 5070. This switch could also be handle with > namespaces by defining a schema of "choice ( iodef-1.0:Reference, iodef- > enum:Reference)". > > We have to decide whether to specify a stand-alone schema, an IODEF exten= sion, > or both? Would SACM only use the newer SpecIndex-based Reference class? > > I feel that the implementers need to tell us how much backward compatibil= ity > needs to be maintained. We've already broken compatibility in 5070bis on > Node/Name, Node/DateTime, and Service@ip_protocol. My feeling is that we > should break it here again and force the "new improved" Reference in v2. > Perhaps we can add some escape value into SpecIndex to make the new > ReferenceName/ID behave like a Description class. > > > (2) The Reference class in the IODEF v1 schema (RFC 5070) is not extens= ible > in > > that schema, but that Reference class is contained in the Method class = which > > can be extended via use of the (optional) AdditionalData class. Is the= re a > > reasonably acceptable/usable approach to use of AdditionalData with > > Method to pull the enumeration references into IODEF v1 without creatin= g a > > new schema version, or is this just asking for confusion? > > If the enum draft was published to include an iodef extension no change a= t > would be required to RFC5070. An implementer would simply drop in the en= um > extension into Method/AdditionalData. The only challenge would be that a > Reference or Description child class are required. Therefore to use > AdditionalData you would have to " ...>". > > Roman > > > > -----Original Message----- > > > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. > > > Danyliw > > > Sent: Friday, July 25, 2014 10:51 PM > > > To: 'Adam W. Montville'; MILE IETF > > > Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion > > > > > > Hello! > > > > > > To be more specific about what was proposed at IETF 90, please find > > > inline a rough draft of modifications agathe -07 draft. Beyond the > > > boiler-plate, only sections with modified text are listed. > > > > > > ---[ snip ]-- > > > > > > MILE Working Group A. Montvi= lle > > > Internet-Draft Tripw= ire > > > Obsoletes: D. B= lack > > > Intended status: Standards Track = EMC > > > Expires: January 31, 2015 August 2= 014 > > > > > > IODEF Enumeration Reference Format > > > draft-ietf-mile-enum-reference-format-07-bis > > > > > > Abstract > > > > > > [Keep first paragraph] > > > > > > [Modified second paragraph] This memo provides an extension to RFC > > > 5070 to include both the external specification and specific > > > enumeration value in the IODEF Reference class. This memo also > > > establishes an IANA registry to manage external enumeration > > > specifications for use by IODEF. > > > > > > The IETF has been notified of intellectual property rights claimed= in > > > regard to some or all of the specification contained in this > > > document. For more information consult the online list of claimed > > > rights. > > > > > > Status of this Memo > > > > > > This Internet-Draft is submitted in full conformance with the > > > provisions of BCP 78 and BCP 79. > > > > > > Internet-Drafts are working documents of the Internet Engineering > > > Task Force (IETF). Note that other groups may also distribute > > > working documents as Internet-Drafts. The list of current Interne= t- > > > Drafts is at http://datatracker.ietf.org/drafts/current/. > > > > > > Internet-Drafts are draft documents valid for a maximum of six mon= ths > > > and may be updated, replaced, or obsoleted by other documents at a= ny > > > time. It is inappropriate to use Internet-Drafts as reference > > > material or to cite them other than as "work in progress." > > > > > > This Internet-Draft will expire on January 31, 2015. > > > > > > Copyright Notice > > > > > > Copyright (c) 2014 IETF Trust and the persons identified as the > > > document authors. All rights reserved. > > > > > > > > > > > > > > > > > > > > > > > > > > > Montville & Black Expires January 31, 2015 [Page= 1] > > > > > > > > > Internet-Draft IODEFv2 ENUM August 2= 014 > > > > > > > > > This document is subject to BCP 78 and the IETF Trust's Legal > > > Provisions Relating to IETF Documents (http://trustee.ietf.org/ > > > license-info) in effect on the date of publication of this documen= t. > > > Please review these documents carefully, as they describe your rig= hts > > > and restrictions with respect to this document. Code Components > > > extracted from this document must include Simplified BSD License t= ext > > > as described in Section 4.e of the Trust Legal Provisions and are > > > provided without warranty as described in the Simplified BSD Licen= se. > > > > > > This document may contain material from IETF Documents or IETF > > > Contributions published or made publicly available before November > > > 10, 2008. The person(s) controlling the copyright in some of this > > > material may not have granted the IETF Trust the right to allow > > > modifications of such material outside the IETF Standards Process. > > > Without obtaining an adequate license from the person(s) controlli= ng > > > the copyright in such materials, this document may not be modified > > > outside the IETF Standards Process, and derivative works of it may > > > not be created outside the IETF Standards Process, except to forma= t > > > it for publication as an RFC or to translate it into languages oth= er > > > than English. > > > > > > Table of Contents > > > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .= 2 > > > 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . .= 2 > > > 2. Referencing External Enumerations . . . . . . . . . . . . . .= 2 > > > 2.1. ReferenceName Class . . . . . . . . . . . . . . . . . . .= 2 > > > 2.2. Reference Method Applicability . . . . . . . . . . . . . .= 3 > > > 3. Security Considerations . . . . . . . . . . . . . . . . . . .= 3 > > > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . .= 4 > > > 5. The ReferenceName Schema . . . . . . . . . . . . . . . . . . .= 4 > > > 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .= 5 > > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . > > > 5 > > > > > > 1. Introduction > > > > > > No change. > > > > > > 1.1. Terminology > > > > > > No change. > > > > > > 2. Referencing External Enumerations > > > > > > No change. > > > > > > 2.1. ReferenceName Class > > > > > > > > > > > > > > > > > > > > > > > > Montville & Black Expires January 31, 2015 [Page= 2] > > > > > > > > > Internet-Draft IODEFv2 ENUM August 2= 014 > > > > > > > > > The ReferenceName class provides the XML representation for > > > identifying an enumeration and specifying a value from it. A give= n > > > enumeration is uniquely identified by the specIndex attribute. Ea= ch > > > specIndex value corresponds to an entry in the "Enumeration Refere= nce > > > Type Identifiers" IANA registry (see Section 4). The child ID > > > element represents a particular value from the corresponding > > > enumeration identified by the specIndex attribute. The format of = the > > > ID element is described in the IANA registry entry of the > > > enumeration. > > > > > > +-------------------------+ > > > | ReferenceName | > > > +-------------------------+ > > > | INTEGER specIndex |<>----------[ ID ] > > > +-------------------------+ > > > > > > The aggregate classes that constitute ReferenceName: > > > > > > ID > > > One. ID. Name of the reference. > > > > > > The ReferenceName class has 1 attribute. > > > > > > specIndex > > > Required. INTEGER. Enumeration identifier. This value > > > corresponds to an entry in the "Enumeration Reference Type > > > Identifiers" IANA registry with an identical SpecIndex value. > > > > > > An example of such a reference is as follows: > > > > > > > > > > > > CXI-1234-XYZ > > > > > > http://cxi.example.com > > > Foo > > > > > > > > > The corresponding information in the IANA table (see Section 4) wo= uld > > > include: > > > > > > Full Name: Concept X Identifier > > > SpecIndex: 1 > > > Version: any > > > Specification URI: http://cxi.example.com/spec_url > > > > > > 2.2. Reference Method Applicability > > > > > > No change, but this should should be numbered 2.2 not 2.3 as in th= e > > > -07 draft. > > > > > > 3. Security Considerations > > > > > > > > > Montville & Black Expires January 31, 2015 [Page= 3] > > > > > > > > > Internet-Draft IODEFv2 ENUM August 2= 014 > > > > > > > > > No change. > > > > > > 4. IANA Considerations > > > > > > [after the existing text, the following should be added ...] > > > > > > This document uses URNs to describe XML namespaces and XML schemas > > > conforming to a registry mechanism described in [RFC3688]. > > > > > > Registration request for the IODEF enumeration reference format > > > namespace: > > > > > > URI : urn:ietf:params:xml:ns:iodef-enum-1.0 > > > > > > Registrant Contact : See the "Authors' Addresses" section of this > > > document. > > > > > > XML : None. > > > > > > Registration request for the IODEF enumeration reference format XM= L > > > schema: > > > > > > URI : urn:ietf:params:xml:schema:iodef-enum-1.0 > > > > > > Registrant Contact See the "Authors' Addresses" section of this > > > document. > > > > > > XML : See Section 6, "XML Schema", of this document. > > > > > > 5. The ReferenceName Schema > > > > > > > > > > > elementFormDefault=3D"qualified" > > > targetNamespace=3D"urn:ietf:params:xml:ns:iodef-enum-1.0" > > > xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" > > > xmlns:enum=3D"urn:ietf:params:xml:ns:iodef-enum-1.0"> > > > > > > > > > > > > > > > > > > > > > > > > > > type=3D"xs:integer" use=3D"required"/> > > > > > > > > > > > > > > > Montville & Black Expires January 31, 2015 [Page= 4] > > > > > > > > > Internet-Draft IODEFv2 ENUM August 2= 014 > > > > > > > > > 6. References > > > > > > Authors' Addresses > > > > > > Adam W. Montville > > > Tripwire > > > USA > > > > > > Email: Adam's email > > > > > > > > > David Black > > > EMC > > > USA > > > > > > Email: David's email > > > > > > > > > Montville & Black Expires January 31, 2015 [Page= 5] > > > > > > --[ end ]-- > > > > > > Roman > > > > > > -----Original Message----- > > > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Adam W. > > > Montville > > > Sent: Friday, July 25, 2014 7:30 AM > > > To: MILE IETF > > > Subject: [mile] EnumRef Format to IODEF Extension Suggestion > > > > > > Hello, > > > > > > During MILE's session this week at IETF 90, Roman suggested that the > > > enum reference format be changed from an update to 5070 to an IODEF > > extension. > > > This would require that the enum reference format draft be updated > > > accordingly and that a full schema and namespace be considered for th= e > > > format itself, rather than simply updating the IODEF schema. > > > > > > The obvious drawback is that the enum reference document backpedals a > > > bit and will take longer to complete. A benefit is that this method > > > of referencing enumeration identifier formats can be reused by other > > > efforts (I'm confident that SACM could make use of the draft if we ch= ange > > it, for example). > > > > > > What are your thoughts/reactions to this proposal? > > > > > > Regards, > > > > > > Adam > > > > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile From nobody Wed Aug 6 08:00:40 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD601B281A for ; Wed, 6 Aug 2014 08:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 IyR-xh-FvOXT for ; Wed, 6 Aug 2014 08:00:33 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF55F1B2810 for ; Wed, 6 Aug 2014 08:00:32 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id vb8so1893837obc.4 for ; Wed, 06 Aug 2014 08:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=EHch2PcJC7XLorDHFHx4Na1d/ovxol4MJWNkARom0yA=; b=RGRAjM3f9xy8Wpj6VtNMmcUCovyMkl+b7mTn1iChuJSOgaaZMZbXXJ/dD4yvlt5+0Q L+RP2/EFsyWzeIfMm5kRb2SsgKzNGC6B0vWjsyajl+a7vi4gz7ZFLJFVqGgnLL0Tdal+ ruKnJDAIMeeoAPcgUMCxc/lyJtjYWpusHbo7WUzfv+BevZRQ9uF3veBkjHyHnWhP4ZCi qg/XQu28WRMQt6blZXtGh+qPE6PdKw9uQ/OF++Jmv0X676QDFAj3ZUl/YmJztSFUYQg7 /B1MhrCmboJRy4kEDgMxCrlh5xt/u3G7yiZdh/Yy/toOfmJz1tJR/W8k4zz22OyjSWS6 77+Q== X-Received: by 10.182.20.177 with SMTP id o17mr15994009obe.59.1407337232273; Wed, 06 Aug 2014 08:00:32 -0700 (PDT) Received: from [192.168.1.60] (99-64-100-240.lightspeed.austtx.sbcglobal.net. [99.64.100.240]) by mx.google.com with ESMTPSA id oj7sm2447593obc.19.2014.08.06.08.00.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 08:00:31 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3DA43735-9533-44D0-B0E7-7C48C5C739A3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Adam W. Montville" In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120779DE6F01@MX15A.corp.emc.com> Date: Wed, 6 Aug 2014 10:00:28 -0500 Message-Id: References: <2E4C41BB-5AA0-4493-8D25-5F036F02C1E3@gmail.com> <359EC4B99E040048A7131E0F4E113AFCA4230360@marathon> <8D3D17ACE214DC429325B2B98F3AE712077860DE29@MX15A.corp.emc.com> <359EC4B99E040048A7131E0F4E113AFCA4236D2A@marathon> <8D3D17ACE214DC429325B2B98F3AE7120779DE6F01@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mile/g2EdLhI2WL_RKXwVTm83hcp9fm4 Cc: MILE IETF Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 15:00:38 -0000 --Apple-Mail=_3DA43735-9533-44D0-B0E7-7C48C5C739A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 5, 2014, at 6:28 PM, Black, David wrote: > Hello Roman, >=20 > This is helpful (thanks): >=20 >> I hadn't been thinking along these lines. To use a software analogy, = I didn't >> envision that we'd back-port the fix to a legacy version of the = software >> (IODEFv1, RFC 5070). Instead I figured we should make a library (an = iodef >> enum extension) that the new version (IODEF v2, 5070bis) and = alternate >> software (SACM) could use. My thinking was if v1 is broken, upgrade = to v2, >> not v1.01. >=20 > Well, the current draft is an incompatible back-port because it = updates > the IODEFv1 schema version to "1.01". I understand both you and Panos = to > be characterizing that as a bad idea (on which I defer to your = expertise), > so I'd like to explore alternatives. >=20 > My next question is "what sort of library?". The email below proposes = what > is effectively a reusable XML (sub-schema) that can be included in = other > XML schemas. >=20 > I wonder whether instead of supplying the (sub-)schema as a "library" = that > can be used at runtime, can we supply the XML schema snippet for enum > reference formats for use in XML schema design along with the IANA = registry. >=20 > One more question: >=20 > Is there a case to be made for use of the same XML (sub-)schema = (iodef-enum > below) in multiple containing schemas, e.g., IODEFv2, SACM, etc., or = is it > sufficient to use the same XML syntax to represent the enumeration = values? >=20 > For "same XML syntax", the draft could recommend that anyone who wants = to use > an enumeration reference value put the following XML snippet in their = schema: >=20 > > > > > > > > >=20 > [NB: I changed "ReferenceName" to "SpecReferenceName" with the intent = of > enabling use of an unconstrained "ReferenceName" element for other = purposes.] >=20 > The enum-reference-format draft could further recommend that = documentation > of any schema that includes that snippet include a reference to the = IANA > registry (created by the enum-reference-format draft) that defines the > specIndex values. >=20 > That ought to simplify adding this to the IODEFv2 (5070bis) schema. >=20 > Thoughts? If we encourage pasting the above into other schemas, is there then a = policing effort to ensure that documentation references are correct and = that the schema is correct? It seems better for wider adoption to go = with the inbuilt XML constructs of namespaces to allow IODEFv2 to simply = reference an enum ref namespace at the appropriate location, then define = the enum ref schema once, which will be associated with just one = document detailing the IANA registry and the expert review, etc. >=20 > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: Roman D. Danyliw [mailto:rdd@cert.org] >> Sent: Thursday, July 31, 2014 3:34 PM >> To: Black, David; MILE IETF >> Subject: RE: [mile] EnumRef Format to IODEF Extension Suggestion >>=20 >> Hello David! >>=20 >>> -----Original Message----- >>> From: Black, David [mailto:david.black@emc.com] >>> Sent: Sunday, July 27, 2014 1:47 PM >>> To: Roman D. Danyliw; MILE IETF >>> Cc: Black, David >>> Subject: RE: [mile] EnumRef Format to IODEF Extension Suggestion >>>=20 >>> Hello Roman, >>>=20 >>> This approach is interesting, although it looks like it would still = require >> a >>> change to the IODEF Schema version. I wonder whether we can go = further >>> than arrange for the 5070bis draft to contain the only new version = of the >>> IODEF schema beyond RFC 5070. Towards that end, I have a couple of >>> questions: >>=20 >> I hadn't been thinking along these lines. To use a software analogy, = I didn't >> envision that we'd back-port the fix to a legacy version of the = software >> (IODEFv1, RFC 5070). Instead I figured we should make a library (an = iodef >> enum extension) that the new version (IODEF v2, 5070bis) and = alternate >> software (SACM) could use. My thinking was if v1 is broken, upgrade = to v2, >> not v1.01. >>=20 >>> (1) Could the SpecIndex attribute be added to the ReferenceName = class in >>> the IODEF v2 schema in 5070bis, as an optional attribute? My = thinking is >> that >>> having this new attribute be optional allows the IODEF v2 Reference = class to >>> continue to be used for everything that it's used for in IODEF v1, = but when >>> the SpecIndex attribute is present, it constrains the ReferenceName = to >>> follow the format in the enumeration reference draft - the latter >>> requirement would be imposed by additional text in the 5070bis = draft. >>=20 >> That does provide maximum flexibility. The thinking would be if you = see the >> SpecIndex reference the enum draft to understand the semantics. If = there is >> not SpecIndex reference 5070. This switch could also be handle with >> namespaces by defining a schema of "choice ( iodef-1.0:Reference, = iodef- >> enum:Reference)". >>=20 >> We have to decide whether to specify a stand-alone schema, an IODEF = extension, >> or both? Would SACM only use the newer SpecIndex-based Reference = class? >>=20 >> I feel that the implementers need to tell us how much backward = compatibility >> needs to be maintained. We've already broken compatibility in = 5070bis on >> Node/Name, Node/DateTime, and Service@ip_protocol. My feeling is = that we >> should break it here again and force the "new improved" Reference in = v2. >> Perhaps we can add some escape value into SpecIndex to make the new >> ReferenceName/ID behave like a Description class. >>=20 >>> (2) The Reference class in the IODEF v1 schema (RFC 5070) is not = extensible >> in >>> that schema, but that Reference class is contained in the Method = class which >>> can be extended via use of the (optional) AdditionalData class. Is = there a >>> reasonably acceptable/usable approach to use of AdditionalData with >>> Method to pull the enumeration references into IODEF v1 without = creating a >>> new schema version, or is this just asking for confusion? >>=20 >> If the enum draft was published to include an iodef extension no = change at >> would be required to RFC5070. An implementer would simply drop in = the enum >> extension into Method/AdditionalData. The only challenge would be = that a >> Reference or Description child class are required. Therefore to use >> AdditionalData you would have to = "> ...>". >>=20 >> Roman >>=20 >>>> -----Original Message----- >>>> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. >>>> Danyliw >>>> Sent: Friday, July 25, 2014 10:51 PM >>>> To: 'Adam W. Montville'; MILE IETF >>>> Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion >>>>=20 >>>> Hello! >>>>=20 >>>> To be more specific about what was proposed at IETF 90, please find >>>> inline a rough draft of modifications agathe -07 draft. Beyond the >>>> boiler-plate, only sections with modified text are listed. >>>>=20 >>>> ---[ snip ]-- >>>>=20 >>>> MILE Working Group A. = Montville >>>> Internet-Draft = Tripwire >>>> Obsoletes: D. = Black >>>> Intended status: Standards Track = EMC >>>> Expires: January 31, 2015 August = 2014 >>>>=20 >>>> IODEF Enumeration Reference Format >>>> draft-ietf-mile-enum-reference-format-07-bis >>>>=20 >>>> Abstract >>>>=20 >>>> [Keep first paragraph] >>>>=20 >>>> [Modified second paragraph] This memo provides an extension to = RFC >>>> 5070 to include both the external specification and specific >>>> enumeration value in the IODEF Reference class. This memo also >>>> establishes an IANA registry to manage external enumeration >>>> specifications for use by IODEF. >>>>=20 >>>> The IETF has been notified of intellectual property rights = claimed in >>>> regard to some or all of the specification contained in this >>>> document. For more information consult the online list of = claimed >>>> rights. >>>>=20 >>>> Status of this Memo >>>>=20 >>>> This Internet-Draft is submitted in full conformance with the >>>> provisions of BCP 78 and BCP 79. >>>>=20 >>>> Internet-Drafts are working documents of the Internet Engineering >>>> Task Force (IETF). Note that other groups may also distribute >>>> working documents as Internet-Drafts. The list of current = Internet- >>>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>>=20 >>>> Internet-Drafts are draft documents valid for a maximum of six = months >>>> and may be updated, replaced, or obsoleted by other documents at = any >>>> time. It is inappropriate to use Internet-Drafts as reference >>>> material or to cite them other than as "work in progress." >>>>=20 >>>> This Internet-Draft will expire on January 31, 2015. >>>>=20 >>>> Copyright Notice >>>>=20 >>>> Copyright (c) 2014 IETF Trust and the persons identified as the >>>> document authors. All rights reserved. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Montville & Black Expires January 31, 2015 = [Page 1] >>>>=20 >>>>=20 >>>> Internet-Draft IODEFv2 ENUM August = 2014 >>>>=20 >>>>=20 >>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>> Provisions Relating to IETF Documents (http://trustee.ietf.org/ >>>> license-info) in effect on the date of publication of this = document. >>>> Please review these documents carefully, as they describe your = rights >>>> and restrictions with respect to this document. Code Components >>>> extracted from this document must include Simplified BSD License = text >>>> as described in Section 4.e of the Trust Legal Provisions and are >>>> provided without warranty as described in the Simplified BSD = License. >>>>=20 >>>> This document may contain material from IETF Documents or IETF >>>> Contributions published or made publicly available before = November >>>> 10, 2008. The person(s) controlling the copyright in some of = this >>>> material may not have granted the IETF Trust the right to allow >>>> modifications of such material outside the IETF Standards = Process. >>>> Without obtaining an adequate license from the person(s) = controlling >>>> the copyright in such materials, this document may not be = modified >>>> outside the IETF Standards Process, and derivative works of it = may >>>> not be created outside the IETF Standards Process, except to = format >>>> it for publication as an RFC or to translate it into languages = other >>>> than English. >>>>=20 >>>> Table of Contents >>>>=20 >>>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = . 2 >>>> 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . = . 2 >>>> 2. Referencing External Enumerations . . . . . . . . . . . . . = . 2 >>>> 2.1. ReferenceName Class . . . . . . . . . . . . . . . . . . = . 2 >>>> 2.2. Reference Method Applicability . . . . . . . . . . . . . = . 3 >>>> 3. Security Considerations . . . . . . . . . . . . . . . . . . = . 3 >>>> 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . = . 4 >>>> 5. The ReferenceName Schema . . . . . . . . . . . . . . . . . . = . 4 >>>> 6. References . . . . . . . . . . . . . . . . . . . . . . . . . = . 5 >>>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . = . >>>> 5 >>>>=20 >>>> 1. Introduction >>>>=20 >>>> No change. >>>>=20 >>>> 1.1. Terminology >>>>=20 >>>> No change. >>>>=20 >>>> 2. Referencing External Enumerations >>>>=20 >>>> No change. >>>>=20 >>>> 2.1. ReferenceName Class >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Montville & Black Expires January 31, 2015 = [Page 2] >>>>=20 >>>>=20 >>>> Internet-Draft IODEFv2 ENUM August = 2014 >>>>=20 >>>>=20 >>>> The ReferenceName class provides the XML representation for >>>> identifying an enumeration and specifying a value from it. A = given >>>> enumeration is uniquely identified by the specIndex attribute. = Each >>>> specIndex value corresponds to an entry in the "Enumeration = Reference >>>> Type Identifiers" IANA registry (see Section 4). The child ID >>>> element represents a particular value from the corresponding >>>> enumeration identified by the specIndex attribute. The format of = the >>>> ID element is described in the IANA registry entry of the >>>> enumeration. >>>>=20 >>>> +-------------------------+ >>>> | ReferenceName | >>>> +-------------------------+ >>>> | INTEGER specIndex |<>----------[ ID ] >>>> +-------------------------+ >>>>=20 >>>> The aggregate classes that constitute ReferenceName: >>>>=20 >>>> ID >>>> One. ID. Name of the reference. >>>>=20 >>>> The ReferenceName class has 1 attribute. >>>>=20 >>>> specIndex >>>> Required. INTEGER. Enumeration identifier. This value >>>> corresponds to an entry in the "Enumeration Reference Type >>>> Identifiers" IANA registry with an identical SpecIndex value. >>>>=20 >>>> An example of such a reference is as follows: >>>>=20 >>>> >>>> >>>> CXI-1234-XYZ >>>> >>>> http://cxi.example.com >>>> Foo >>>> >>>>=20 >>>> The corresponding information in the IANA table (see Section 4) = would >>>> include: >>>>=20 >>>> Full Name: Concept X Identifier >>>> SpecIndex: 1 >>>> Version: any >>>> Specification URI: http://cxi.example.com/spec_url >>>>=20 >>>> 2.2. Reference Method Applicability >>>>=20 >>>> No change, but this should should be numbered 2.2 not 2.3 as in = the >>>> -07 draft. >>>>=20 >>>> 3. Security Considerations >>>>=20 >>>>=20 >>>> Montville & Black Expires January 31, 2015 = [Page 3] >>>>=20 >>>>=20 >>>> Internet-Draft IODEFv2 ENUM August = 2014 >>>>=20 >>>>=20 >>>> No change. >>>>=20 >>>> 4. IANA Considerations >>>>=20 >>>> [after the existing text, the following should be added ...] >>>>=20 >>>> This document uses URNs to describe XML namespaces and XML = schemas >>>> conforming to a registry mechanism described in [RFC3688]. >>>>=20 >>>> Registration request for the IODEF enumeration reference format >>>> namespace: >>>>=20 >>>> URI : urn:ietf:params:xml:ns:iodef-enum-1.0 >>>>=20 >>>> Registrant Contact : See the "Authors' Addresses" section of this >>>> document. >>>>=20 >>>> XML : None. >>>>=20 >>>> Registration request for the IODEF enumeration reference format = XML >>>> schema: >>>>=20 >>>> URI : urn:ietf:params:xml:schema:iodef-enum-1.0 >>>>=20 >>>> Registrant Contact See the "Authors' Addresses" section of this >>>> document. >>>>=20 >>>> XML : See Section 6, "XML Schema", of this document. >>>>=20 >>>> 5. The ReferenceName Schema >>>>=20 >>>> >>>> >>> elementFormDefault=3D"qualified" >>>> targetNamespace=3D"urn:ietf:params:xml:ns:iodef-enum-1.0" >>>> xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" >>>> xmlns:enum=3D"urn:ietf:params:xml:ns:iodef-enum-1.0"> >>>>=20 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> type=3D"xs:integer" use=3D"required"/> >>>> >>>> >>>> >>>>=20 >>>> Montville & Black Expires January 31, 2015 = [Page 4] >>>>=20 >>>>=20 >>>> Internet-Draft IODEFv2 ENUM August = 2014 >>>>=20 >>>>=20 >>>> 6. References >>>>=20 >>>> Authors' Addresses >>>>=20 >>>> Adam W. Montville >>>> Tripwire >>>> USA >>>>=20 >>>> Email: Adam's email >>>>=20 >>>>=20 >>>> David Black >>>> EMC >>>> USA >>>>=20 >>>> Email: David's email >>>>=20 >>>>=20 >>>> Montville & Black Expires January 31, 2015 = [Page 5] >>>>=20 >>>> --[ end ]-- >>>>=20 >>>> Roman >>>>=20 >>>> -----Original Message----- >>>> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Adam W. >>>> Montville >>>> Sent: Friday, July 25, 2014 7:30 AM >>>> To: MILE IETF >>>> Subject: [mile] EnumRef Format to IODEF Extension Suggestion >>>>=20 >>>> Hello, >>>>=20 >>>> During MILE's session this week at IETF 90, Roman suggested that = the >>>> enum reference format be changed from an update to 5070 to an IODEF >>> extension. >>>> This would require that the enum reference format draft be updated >>>> accordingly and that a full schema and namespace be considered for = the >>>> format itself, rather than simply updating the IODEF schema. >>>>=20 >>>> The obvious drawback is that the enum reference document backpedals = a >>>> bit and will take longer to complete. A benefit is that this = method >>>> of referencing enumeration identifier formats can be reused by = other >>>> efforts (I'm confident that SACM could make use of the draft if we = change >>> it, for example). >>>>=20 >>>> What are your thoughts/reactions to this proposal? >>>>=20 >>>> Regards, >>>>=20 >>>> Adam >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_3DA43735-9533-44D0-B0E7-7C48C5C739A3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT4kMMAAoJEILmIVe/2cgGHTUH/iFqiIA9gSUmk9hGrm9VjLxV PdSZFV12N0g/aIIYwi619As0NRHSIlXexIBqwPkVBHdIy8MtgH4/GycZl8NTIDvh 9jfIVGppU8kSHNg+ggCxkpLdpY4xm6nnlc+HKjX8UC3vr5f1bPri4CE+3c6/ZFvR s+ceJckV2z4AWnBmR6N4yaJe6j6rI5ShMFqox3xg8BqqOmpsOT1H/+svjZsYD1IP zgEXkqtooEhC2uCwkDl3QJLLXH6QIYlBmyyWex441m3PYzLWIhWw9WwgjIzuztDH /W6p9G6tFZHV5mAwxOz+GLdKWmra5N96fb5SKiOMbnhD5Idc1JGcIpodplcGNGA= =AVSN -----END PGP SIGNATURE----- --Apple-Mail=_3DA43735-9533-44D0-B0E7-7C48C5C739A3-- From nobody Thu Aug 7 16:46:03 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD0F1A0046 for ; Thu, 7 Aug 2014 16:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 r4PLEQ5kq-wO for ; Thu, 7 Aug 2014 16:45:58 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C2B1A01F6 for ; Thu, 7 Aug 2014 16:45:58 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id rd18so5574999iec.0 for ; Thu, 07 Aug 2014 16:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9os/xC42FN2vh3Li+AWnaZ1cnq8SZRKo8YJxyVVVR/k=; b=YX/uDpVAriz+W8hZ+YBMpUeTK5f+c35WvJpU7/VaFO5iKJLaeC2GDJze1u1dkMHwQv tpY3W4NO5MO5N2sIJxHdagwvT0d9zNtLHmI7frHy/FDc/OzqIo5cI9AsTeCw41OGMxPw hvGXu/4CB+EW7W0Qm0+8Uxg0vLxPiWUd1oCxNlnpKhgEUWgRf09sTTR8GAj+a50gsCDI /n9R9LgCXba/pYRFK9wM3NMNxM5RXj1qtb61KQ8bxPJW1A2FMt3TnU6/4GnBSrFcZnh3 JK4AO4kZuUl/h31CyJyWZpiIX6cMV0diRA7xhWwrf7RFl3NPIfeRs/rQ5e2zaprDLQMA 9kqw== X-Received: by 10.42.207.68 with SMTP id fx4mr7901481icb.67.1407455157583; Thu, 07 Aug 2014 16:45:57 -0700 (PDT) Received: from ?IPv6:2601:d:2880:38b:39b5:e940:3342:d0b6? ([2601:d:2880:38b:39b5:e940:3342:d0b6]) by mx.google.com with ESMTPSA id b8sm1733284igl.5.2014.08.07.16.45.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Aug 2014 16:45:56 -0700 (PDT) Sender: "Martin J. Murillo" Message-ID: <53E40FB4.5080501@ieee.org> Date: Thu, 07 Aug 2014 19:45:56 -0400 From: Martin Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Roman D. Danyliw" , "mile@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFCA4236C93@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCA4236C93@marathon> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mile/7qbu-kbIAC9ZdNiKc-Tlym0Oxvc Subject: Re: [mile] Feedback on draft-murillo-mile-cps-00 and implications for 5070bis X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: murillo@ieee.org List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 23:46:00 -0000 I second Panos in his reply to this thread. Some comments below: On 7/31/2014 2:31 PM, Roman D. Danyliw wrote: > Hello! > > The presentation on draft-multillo-mile-cps-00 at IETF 90 started a discussion on identifying data elements described by cps-00 that might also be relevant to enterprise incident reports. In my judgment they are at least as follows: > > (1) IncidentTitle (Section 5.6) and BriefDescriptionOfIncident (5.23) -- these are classes that quickly summarize the document. A similar idea was proposed in the bullet #4 of the feedback from the NATO implementation by Lagadec Philippe (http://www.ietf.org/mail-archive/web/mile/current/msg01503.html). Should we add a "Summary" class similarly defined as the Description class to IODEF-Document, Incident, and EventData? Doing it would certainly make IODEF richer w/o being too specific. It looks that there's the need of that addition. > > (2) RecurrencePreventionMeasures (Section 5.22) -- should a free-form text description be added to describe future measures that should be taken to prevent the class of activity described in the document from occurring the future? I think this is applicable to all systems/reports and will make IODEF richer. > > (3) EntryPoint (Section 5.15) and CommandAndControlCenters (Section 5.18) -- both of these classes attempt to categorize a system as having a given role in the incident -- entry point into a network by the attacker and the C2 servers of the attacker. System@category in 5070bis also tries to categorize systems but with these enumerated values: source, target, intermediate, sensor, or infrastructure. Only one category can be assigned per system. NodeRole@attack-type is poorly documented (see Issue #40) but it allows for values of c2-server, sink-hole, malware-distribution, phishing, spear-phishing, recruiting, fraudulent-site, and dns-spoof. > > There appears to be a need to classify the intended role victim system independent of the incident, NodeRole@category, but also the role it played in an incident/event especially in categorizing the attacker infrastructure, NodeRole@attack-type/EntryPoint/CommandAndControlCenters. It seems like we should reconcile these. In 5070bis, there appears to be overlap between System@category and NodeRole@attack-type. EntryPoint and CommandAndControlCenters from cps-00 suggest new enumerated values for these attributes (or perhaps for a new one)? > > Any strong feelings for adopting these concepts into 5070bis? I'm thinking all three are useful and easy to implement. > > It was also suggested that certain overlap might exist. Comparing cps-00 with 5070bis-07, I believe certain cps data elements can already be represented without an extension. They are as follows: > > ** ReportingParty (Section 5.7) = Incident/Contact@role={reporter, creator} > ** ReportReliability (Section 5.8) = {Incident,EventData}/Confidence > ** TargetSystem (Section 5.11) = EventData/Flow/System@category="target"/Node/NodeRole > ** Exploit (Section 5.14) = Incident/Method > ** PerpetratingParty (Section 5.16) = Incident/RelatedActivity > ** DetectioMethod (Section 5.17) = EventData/Discovery > ** OrganizationalImpact (Section 5.21) = Assessment/{BusinessImpact,MonetaryImpact} > ** Logs (Section 5.24) = RecordData Indeed, overlaps exist and CPS needs to make further use of the already existing elements. The items above need to be definitely reused. However some type of extension will still need to be done to express the CPS incident in machine readable format. For instance, TargetSystem might actually be a PLC that does not have an IP address but an ID or node address; it might be communicating through a protocol such as HART, etc. Or, in an extreme scenario when the attacker knows how to cause damage gradually, the target will be the actual variable of an algorithm that is running in a RTU/PLC or control system. The specification of these will need an extension of appropriate elements that are contextually valid. That aside, I believe that the more rich 5070 is, the more it will leverage the work to be done in other extensions. This will also leverage development time. With regards to CPS, when 5070 can, for example, describe the malfunction of a computer/CPU/etc and a subsequent smoke and the automatic enabling of fire extinguishers, all due to the reaching of a threshold temperature due to the reconfiguration of the BIOS or drivers by a hacker, it will be start being more applicable to CPS systems. Martin > From nobody Thu Aug 14 08:29:42 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2E71A09F8 for ; Thu, 14 Aug 2014 08:29:39 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 2tYqYwsn4jTI for ; Thu, 14 Aug 2014 08:29:38 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625291A6F14 for ; Thu, 14 Aug 2014 08:29:19 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id c11so967073lbj.23 for ; Thu, 14 Aug 2014 08:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=l0u+13KiSZjVW9jY6+YhwvA7XnzRyZnaGjgw7z68OCE=; b=roru/urvnyftGgNFG8alc+AE1Iy32xc5Bv4IaKwWMKKIcjSQnsqpVQWB0P+pBaZ+xN Ho13Ac5NsbM/Mw2n7cGZm45gwwmGPMk/iECtwo0AV588d0oFTanoN5k/VqeBc5+y59NL GUk3FKZ2BYGDE2K3expAv/AcdX2kKbxdBWidp1bXKeAKmWboa2wn7erC77pbLsXWNk+z Hdjfyuv3qRYGnolcpMunBCuTFFMqBAprPLF4N5zKI+/mX9It+WNu5s1EvuPurGsoP0Mh ewthfLi4k5tEHaH/zYx0YowalqFFyNzt+HOdNfETaSmSXaWKy4l3tl5o1iiamXsuTmNI /FLA== MIME-Version: 1.0 X-Received: by 10.152.8.82 with SMTP id p18mr4739025laa.83.1408030157325; Thu, 14 Aug 2014 08:29:17 -0700 (PDT) Received: by 10.112.147.168 with HTTP; Thu, 14 Aug 2014 08:29:17 -0700 (PDT) Date: Thu, 14 Aug 2014 11:29:17 -0400 Message-ID: From: Kathleen Moriarty To: MILE IETF Content-Type: multipart/alternative; boundary=001a11c3561e5c4b4d0500989165 Archived-At: http://mailarchive.ietf.org/arch/msg/mile/5HAR35g8UOmo1eMkUh42rrww7iU Cc: "adrian@olddog.co.uk" Subject: [mile] Threat model draft review request X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 15:29:39 -0000 --001a11c3561e5c4b4d0500989165 Content-Type: text/plain; charset=UTF-8 Hello, Additional review has been requested on a draft describing threat models for the Routing Protocol for Low-power and lossy networks (RPL, ROLL) by the Routing AD, Adrian Farrel. The draft is in last call and comments should go to ietf@ietf.org, but can also go to roll@ietf.org or get channeled through Adrian or me. Since there are many people in this group who do threat modeling work, I am hoping that a few of you could assist. Please let me know if you would like to help out or just provide comments on the draft. https://datatracker.ietf.org/doc/draft-ietf-roll-security-threats/ Abstract This document presents a security threat analysis for the Routing Protocol for Low-power and lossy networks (RPL, ROLL). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. Thank you! -- Best regards, Kathleen --001a11c3561e5c4b4d0500989165 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Additional review has been reque= sted on a draft describing threat models for the Routing Protocol for Low-p= ower and lossy networks (RPL, ROLL) by the Routing AD, Adrian Farrel. =C2= =A0The draft is in last call and comments should go to ietf@ietf.org, but can also go to roll@ietf.org or get channeled through Adrian or me.

Since there are many people in this group who do threat= modeling work, I am hoping that a few of you could assist. =C2=A0Please le= t me know if you would like to help out or just provide comments on the dra= ft.


Abstract

   This document presents a security threat analysis for the Routing
   Protocol for Low-power and lossy networks (RPL, ROLL).  The
   development builds upon previous work on routing security and adapts
   the assessments to the issues and constraints specific to low-power
   and lossy networks.  A systematic approach is used in defining and
   evaluating the security threats.  Applicable countermeasures are
   application specific and are addressed in relevant applicability
   statements.

Thank you!
--

Best regards,
<= div>Kathleen
--001a11c3561e5c4b4d0500989165-- From nobody Mon Aug 18 10:28:13 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597371A0700 for ; Mon, 18 Aug 2014 10:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 y0Yjhog_T5Fk for ; Mon, 18 Aug 2014 10:27:57 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD3D1A03EA for ; Mon, 18 Aug 2014 10:27:56 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7IHRl9C027055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2014 13:27:48 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s7IHRl9C027055 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408382868; bh=ik2s8jFJSNzezquMHYt/1RIy+dU=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=RFVVEjsQtq5Mba9inl4fp2Rpho7vqGuDZ2vnLUAOUjUyB3234H7OWqD37pzV19Upn 5XpwRHeWeNLWwF9cqzanFmtg2SFulHISQMMDJxFOpEModt/EZEL6L1Pqpx2h7gV32Z FrtSQoMRsDz6/3+sdCY1Yonnhn1EOG8MvSVMSyrs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s7IHRl9C027055 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd06.lss.emc.com (RSA Interceptor); Mon, 18 Aug 2014 13:27:30 -0400 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7IHRUGg030450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 13:27:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Mon, 18 Aug 2014 13:27:30 -0400 From: "Black, David" To: "Adam W. Montville" Date: Mon, 18 Aug 2014 13:27:28 -0400 Thread-Topic: [mile] EnumRef Format to IODEF Extension Suggestion Thread-Index: Ac+xhy59YdbIaKSxSCiK5Zrda/BAQwJfSUqQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB4228E@MX15A.corp.emc.com> References: <2E4C41BB-5AA0-4493-8D25-5F036F02C1E3@gmail.com> <359EC4B99E040048A7131E0F4E113AFCA4230360@marathon> <8D3D17ACE214DC429325B2B98F3AE712077860DE29@MX15A.corp.emc.com> <359EC4B99E040048A7131E0F4E113AFCA4236D2A@marathon> <8D3D17ACE214DC429325B2B98F3AE7120779DE6F01@MX15A.corp.emc.com> 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-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/mile/2IzKbFlVuFXN5a9eksOjfUoyEZs Cc: MILE IETF Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 17:28:06 -0000 On XML snippet vs. schema: > If we encourage pasting the above [XML snippet] into other schemas, is th= ere > then a policing > effort to ensure that documentation references are correct and that the s= chema > is correct? It seems better for wider adoption to go with the inbuilt XM= L > constructs of namespaces to allow IODEFv2 to simply reference an enum ref > namespace at the appropriate location, then define the enum ref schema on= ce, > which will be associated with just one document detailing the IANA regist= ry > and the expert review, etc. Well, the IANA registry and its associated review procedures get defined on= ce in one document, independent of what we do. OTOH, the namespace separation and related discipline of using a separate s= chema for the enumeration references are useful and the proverbial "right thing t= o do," plus Roman's provided much (if not all of the text) needed, so I'm fine wit= h that approach. Thanks, --David > -----Original Message----- > From: Adam W. Montville [mailto:adam.w.montville@gmail.com] > Sent: Wednesday, August 06, 2014 11:00 AM > To: Black, David > Cc: Roman D. Danyliw; MILE IETF > Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion > > > On Aug 5, 2014, at 6:28 PM, Black, David wrote: > > > Hello Roman, > > > > This is helpful (thanks): > > > >> I hadn't been thinking along these lines. To use a software analogy, = I didn't > >> envision that we'd back-port the fix to a legacy version of the softwa= re > >> (IODEFv1, RFC 5070). Instead I figured we should make a library (an i= odef > >> enum extension) that the new version (IODEF v2, 5070bis) and alternate > >> software (SACM) could use. My thinking was if v1 is broken, upgrade t= o v2, > >> not v1.01. > > > > Well, the current draft is an incompatible back-port because it updates > > the IODEFv1 schema version to "1.01". I understand both you and Panos = to > > be characterizing that as a bad idea (on which I defer to your expertis= e), > > so I'd like to explore alternatives. > > > > My next question is "what sort of library?". The email below proposes = what > > is effectively a reusable XML (sub-schema) that can be included in othe= r > > XML schemas. > > > > I wonder whether instead of supplying the (sub-)schema as a "library" t= hat > > can be used at runtime, can we supply the XML schema snippet for enum > > reference formats for use in XML schema design along with the IANA regi= stry. > > > > One more question: > > > > Is there a case to be made for use of the same XML (sub-)schema (iodef-= enum > > below) in multiple containing schemas, e.g., IODEFv2, SACM, etc., or is= it > > sufficient to use the same XML syntax to represent the enumeration valu= es? > > > > For "same XML syntax", the draft could recommend that anyone who wants = to use > > an enumeration reference value put the following XML snippet in their s= chema: > > > > > > > > > > > > > > > > > > > > > > [NB: I changed "ReferenceName" to "SpecReferenceName" with the intent o= f > > enabling use of an unconstrained "ReferenceName" element for other > purposes.] > > > > The enum-reference-format draft could further recommend that documentat= ion > > of any schema that includes that snippet include a reference to the IAN= A > > registry (created by the enum-reference-format draft) that defines the > > specIndex values. > > > > That ought to simplify adding this to the IODEFv2 (5070bis) schema. > > > > Thoughts? > > If we encourage pasting the above into other schemas, is there then a pol= icing > effort to ensure that documentation references are correct and that the s= chema > is correct? It seems better for wider adoption to go with the inbuilt XM= L > constructs of namespaces to allow IODEFv2 to simply reference an enum ref > namespace at the appropriate location, then define the enum ref schema on= ce, > which will be associated with just one document detailing the IANA regist= ry > and the expert review, etc. > > > > > > Thanks, > > --David > > > > > >> -----Original Message----- > >> From: Roman D. Danyliw [mailto:rdd@cert.org] > >> Sent: Thursday, July 31, 2014 3:34 PM > >> To: Black, David; MILE IETF > >> Subject: RE: [mile] EnumRef Format to IODEF Extension Suggestion > >> > >> Hello David! > >> > >>> -----Original Message----- > >>> From: Black, David [mailto:david.black@emc.com] > >>> Sent: Sunday, July 27, 2014 1:47 PM > >>> To: Roman D. Danyliw; MILE IETF > >>> Cc: Black, David > >>> Subject: RE: [mile] EnumRef Format to IODEF Extension Suggestion > >>> > >>> Hello Roman, > >>> > >>> This approach is interesting, although it looks like it would still > require > >> a > >>> change to the IODEF Schema version. I wonder whether we can go furth= er > >>> than arrange for the 5070bis draft to contain the only new version of= the > >>> IODEF schema beyond RFC 5070. Towards that end, I have a couple of > >>> questions: > >> > >> I hadn't been thinking along these lines. To use a software analogy, = I > didn't > >> envision that we'd back-port the fix to a legacy version of the softwa= re > >> (IODEFv1, RFC 5070). Instead I figured we should make a library (an i= odef > >> enum extension) that the new version (IODEF v2, 5070bis) and alternate > >> software (SACM) could use. My thinking was if v1 is broken, upgrade t= o v2, > >> not v1.01. > >> > >>> (1) Could the SpecIndex attribute be added to the ReferenceName class= in > >>> the IODEF v2 schema in 5070bis, as an optional attribute? My thinkin= g is > >> that > >>> having this new attribute be optional allows the IODEF v2 Reference c= lass > to > >>> continue to be used for everything that it's used for in IODEF v1, bu= t > when > >>> the SpecIndex attribute is present, it constrains the ReferenceName t= o > >>> follow the format in the enumeration reference draft - the latter > >>> requirement would be imposed by additional text in the 5070bis draft. > >> > >> That does provide maximum flexibility. The thinking would be if you s= ee > the > >> SpecIndex reference the enum draft to understand the semantics. If th= ere > is > >> not SpecIndex reference 5070. This switch could also be handle with > >> namespaces by defining a schema of "choice ( iodef-1.0:Reference, iode= f- > >> enum:Reference)". > >> > >> We have to decide whether to specify a stand-alone schema, an IODEF > extension, > >> or both? Would SACM only use the newer SpecIndex-based Reference clas= s? > >> > >> I feel that the implementers need to tell us how much backward > compatibility > >> needs to be maintained. We've already broken compatibility in 5070bis= on > >> Node/Name, Node/DateTime, and Service@ip_protocol. My feeling is that= we > >> should break it here again and force the "new improved" Reference in v= 2. > >> Perhaps we can add some escape value into SpecIndex to make the new > >> ReferenceName/ID behave like a Description class. > >> > >>> (2) The Reference class in the IODEF v1 schema (RFC 5070) is not > extensible > >> in > >>> that schema, but that Reference class is contained in the Method clas= s > which > >>> can be extended via use of the (optional) AdditionalData class. Is t= here > a > >>> reasonably acceptable/usable approach to use of AdditionalData with > >>> Method to pull the enumeration references into IODEF v1 without creat= ing a > >>> new schema version, or is this just asking for confusion? > >> > >> If the enum draft was published to include an iodef extension no chang= e at > >> would be required to RFC5070. An implementer would simply drop in the= enum > >> extension into Method/AdditionalData. The only challenge would be tha= t a > >> Reference or Description child class are required. Therefore to use > >> AdditionalData you would have to " >> ...>". > >> > >> Roman > >> > >>>> -----Original Message----- > >>>> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. > >>>> Danyliw > >>>> Sent: Friday, July 25, 2014 10:51 PM > >>>> To: 'Adam W. Montville'; MILE IETF > >>>> Subject: Re: [mile] EnumRef Format to IODEF Extension Suggestion > >>>> > >>>> Hello! > >>>> > >>>> To be more specific about what was proposed at IETF 90, please find > >>>> inline a rough draft of modifications agathe -07 draft. Beyond the > >>>> boiler-plate, only sections with modified text are listed. > >>>> > >>>> ---[ snip ]-- > >>>> > >>>> MILE Working Group A. Montv= ille > >>>> Internet-Draft Trip= wire > >>>> Obsoletes: D. = Black > >>>> Intended status: Standards Track = EMC > >>>> Expires: January 31, 2015 August = 2014 > >>>> > >>>> IODEF Enumeration Reference Format > >>>> draft-ietf-mile-enum-reference-format-07-bis > >>>> > >>>> Abstract > >>>> > >>>> [Keep first paragraph] > >>>> > >>>> [Modified second paragraph] This memo provides an extension to RFC > >>>> 5070 to include both the external specification and specific > >>>> enumeration value in the IODEF Reference class. This memo also > >>>> establishes an IANA registry to manage external enumeration > >>>> specifications for use by IODEF. > >>>> > >>>> The IETF has been notified of intellectual property rights claimed= in > >>>> regard to some or all of the specification contained in this > >>>> document. For more information consult the online list of claimed > >>>> rights. > >>>> > >>>> Status of this Memo > >>>> > >>>> This Internet-Draft is submitted in full conformance with the > >>>> provisions of BCP 78 and BCP 79. > >>>> > >>>> Internet-Drafts are working documents of the Internet Engineering > >>>> Task Force (IETF). Note that other groups may also distribute > >>>> working documents as Internet-Drafts. The list of current Interne= t- > >>>> Drafts is at http://datatracker.ietf.org/drafts/current/. > >>>> > >>>> Internet-Drafts are draft documents valid for a maximum of six mon= ths > >>>> and may be updated, replaced, or obsoleted by other documents at a= ny > >>>> time. It is inappropriate to use Internet-Drafts as reference > >>>> material or to cite them other than as "work in progress." > >>>> > >>>> This Internet-Draft will expire on January 31, 2015. > >>>> > >>>> Copyright Notice > >>>> > >>>> Copyright (c) 2014 IETF Trust and the persons identified as the > >>>> document authors. All rights reserved. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Montville & Black Expires January 31, 2015 [Pag= e 1] > >>>> > >>>> > >>>> Internet-Draft IODEFv2 ENUM August = 2014 > >>>> > >>>> > >>>> This document is subject to BCP 78 and the IETF Trust's Legal > >>>> Provisions Relating to IETF Documents (http://trustee.ietf.org/ > >>>> license-info) in effect on the date of publication of this documen= t. > >>>> Please review these documents carefully, as they describe your rig= hts > >>>> and restrictions with respect to this document. Code Components > >>>> extracted from this document must include Simplified BSD License t= ext > >>>> as described in Section 4.e of the Trust Legal Provisions and are > >>>> provided without warranty as described in the Simplified BSD Licen= se. > >>>> > >>>> This document may contain material from IETF Documents or IETF > >>>> Contributions published or made publicly available before November > >>>> 10, 2008. The person(s) controlling the copyright in some of this > >>>> material may not have granted the IETF Trust the right to allow > >>>> modifications of such material outside the IETF Standards Process. > >>>> Without obtaining an adequate license from the person(s) controlli= ng > >>>> the copyright in such materials, this document may not be modified > >>>> outside the IETF Standards Process, and derivative works of it may > >>>> not be created outside the IETF Standards Process, except to forma= t > >>>> it for publication as an RFC or to translate it into languages oth= er > >>>> than English. > >>>> > >>>> Table of Contents > >>>> > >>>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .= 2 > >>>> 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . .= 2 > >>>> 2. Referencing External Enumerations . . . . . . . . . . . . . .= 2 > >>>> 2.1. ReferenceName Class . . . . . . . . . . . . . . . . . . .= 2 > >>>> 2.2. Reference Method Applicability . . . . . . . . . . . . . .= 3 > >>>> 3. Security Considerations . . . . . . . . . . . . . . . . . . .= 3 > >>>> 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . .= 4 > >>>> 5. The ReferenceName Schema . . . . . . . . . . . . . . . . . . .= 4 > >>>> 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .= 5 > >>>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . > >>>> 5 > >>>> > >>>> 1. Introduction > >>>> > >>>> No change. > >>>> > >>>> 1.1. Terminology > >>>> > >>>> No change. > >>>> > >>>> 2. Referencing External Enumerations > >>>> > >>>> No change. > >>>> > >>>> 2.1. ReferenceName Class > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Montville & Black Expires January 31, 2015 [Pag= e 2] > >>>> > >>>> > >>>> Internet-Draft IODEFv2 ENUM August = 2014 > >>>> > >>>> > >>>> The ReferenceName class provides the XML representation for > >>>> identifying an enumeration and specifying a value from it. A give= n > >>>> enumeration is uniquely identified by the specIndex attribute. Ea= ch > >>>> specIndex value corresponds to an entry in the "Enumeration Refere= nce > >>>> Type Identifiers" IANA registry (see Section 4). The child ID > >>>> element represents a particular value from the corresponding > >>>> enumeration identified by the specIndex attribute. The format of = the > >>>> ID element is described in the IANA registry entry of the > >>>> enumeration. > >>>> > >>>> +-------------------------+ > >>>> | ReferenceName | > >>>> +-------------------------+ > >>>> | INTEGER specIndex |<>----------[ ID ] > >>>> +-------------------------+ > >>>> > >>>> The aggregate classes that constitute ReferenceName: > >>>> > >>>> ID > >>>> One. ID. Name of the reference. > >>>> > >>>> The ReferenceName class has 1 attribute. > >>>> > >>>> specIndex > >>>> Required. INTEGER. Enumeration identifier. This value > >>>> corresponds to an entry in the "Enumeration Reference Type > >>>> Identifiers" IANA registry with an identical SpecIndex value. > >>>> > >>>> An example of such a reference is as follows: > >>>> > >>>> > >>>> > >>>> CXI-1234-XYZ > >>>> > >>>> http://cxi.example.com > >>>> Foo > >>>> > >>>> > >>>> The corresponding information in the IANA table (see Section 4) wo= uld > >>>> include: > >>>> > >>>> Full Name: Concept X Identifier > >>>> SpecIndex: 1 > >>>> Version: any > >>>> Specification URI: http://cxi.example.com/spec_url > >>>> > >>>> 2.2. Reference Method Applicability > >>>> > >>>> No change, but this should should be numbered 2.2 not 2.3 as in th= e > >>>> -07 draft. > >>>> > >>>> 3. Security Considerations > >>>> > >>>> > >>>> Montville & Black Expires January 31, 2015 [Pag= e 3] > >>>> > >>>> > >>>> Internet-Draft IODEFv2 ENUM August = 2014 > >>>> > >>>> > >>>> No change. > >>>> > >>>> 4. IANA Considerations > >>>> > >>>> [after the existing text, the following should be added ...] > >>>> > >>>> This document uses URNs to describe XML namespaces and XML schemas > >>>> conforming to a registry mechanism described in [RFC3688]. > >>>> > >>>> Registration request for the IODEF enumeration reference format > >>>> namespace: > >>>> > >>>> URI : urn:ietf:params:xml:ns:iodef-enum-1.0 > >>>> > >>>> Registrant Contact : See the "Authors' Addresses" section of this > >>>> document. > >>>> > >>>> XML : None. > >>>> > >>>> Registration request for the IODEF enumeration reference format XM= L > >>>> schema: > >>>> > >>>> URI : urn:ietf:params:xml:schema:iodef-enum-1.0 > >>>> > >>>> Registrant Contact See the "Authors' Addresses" section of this > >>>> document. > >>>> > >>>> XML : See Section 6, "XML Schema", of this document. > >>>> > >>>> 5. The ReferenceName Schema > >>>> > >>>> > >>>> >>>> elementFormDefault=3D"qualified" > >>>> targetNamespace=3D"urn:ietf:params:xml:ns:iodef-enum-1.0" > >>>> xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" > >>>> xmlns:enum=3D"urn:ietf:params:xml:ns:iodef-enum-1.0"> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >>>> type=3D"xs:integer" use=3D"required"/> > >>>> > >>>> > >>>> > >>>> > >>>> Montville & Black Expires January 31, 2015 [Pag= e 4] > >>>> > >>>> > >>>> Internet-Draft IODEFv2 ENUM August = 2014 > >>>> > >>>> > >>>> 6. References > >>>> > >>>> Authors' Addresses > >>>> > >>>> Adam W. Montville > >>>> Tripwire > >>>> USA > >>>> > >>>> Email: Adam's email > >>>> > >>>> > >>>> David Black > >>>> EMC > >>>> USA > >>>> > >>>> Email: David's email > >>>> > >>>> > >>>> Montville & Black Expires January 31, 2015 [Pag= e 5] > >>>> > >>>> --[ end ]-- > >>>> > >>>> Roman > >>>> > >>>> -----Original Message----- > >>>> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Adam W. > >>>> Montville > >>>> Sent: Friday, July 25, 2014 7:30 AM > >>>> To: MILE IETF > >>>> Subject: [mile] EnumRef Format to IODEF Extension Suggestion > >>>> > >>>> Hello, > >>>> > >>>> During MILE's session this week at IETF 90, Roman suggested that the > >>>> enum reference format be changed from an update to 5070 to an IODEF > >>> extension. > >>>> This would require that the enum reference format draft be updated > >>>> accordingly and that a full schema and namespace be considered for t= he > >>>> format itself, rather than simply updating the IODEF schema. > >>>> > >>>> The obvious drawback is that the enum reference document backpedals = a > >>>> bit and will take longer to complete. A benefit is that this method > >>>> of referencing enumeration identifier formats can be reused by other > >>>> efforts (I'm confident that SACM could make use of the draft if we c= hange > >>> it, for example). > >>>> > >>>> What are your thoughts/reactions to this proposal? > >>>> > >>>> Regards, > >>>> > >>>> Adam > >>>> > >>>> _______________________________________________ > >>>> mile mailing list > >>>> mile@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile