From kathleen.moriarty@emc.com Wed May 2 06:56:08 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6F421F8565 for ; Wed, 2 May 2012 06:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.55 X-Spam-Level: X-Spam-Status: No, score=-10.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYJqzs4Mf1cM for ; Wed, 2 May 2012 06:56:07 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0C21F854F for ; Wed, 2 May 2012 06:56:07 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q42Du54C030144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 09:56:06 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 2 May 2012 09:55:42 -0400 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q42DtgHg004799; Wed, 2 May 2012 09:55:42 -0400 Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub10.corp.emc.com (10.254.92.105) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 2 May 2012 09:55:42 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Wed, 2 May 2012 09:55:10 -0400 From: To: , Date: Wed, 2 May 2012 09:55:40 -0400 Thread-Topic: WGLC: Review of draft-ietf-mile-template-03 Thread-Index: Ac0oa0I88z8Jd9gQSYuaK56Q0gOXWA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] WGLC: Review of draft-ietf-mile-template-03 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 13:56:08 -0000 Hi Brian & MILE members, Thank you very much for setting up the template, I think this has been and = will continue to be helpful to draft editors and implementers! I have a few comments on the draft. If others on the list have comments, p= lease chime in TODAY as the WGLC is supposed to end. THANK YOU! Section 2: In #1, it is not entirely clear that IODEF can represent incomplete informa= tion about an incident. The terms used these days are indicators and obser= vables. It is not necessary to use those terms, but leaving this open to u= se cases covered in IODEF and RID where we are just sharing information tha= t could help prevent an attack after that was detected at another site is u= seful. Having some way to include this could be important for people to un= derstand the full set of use cases for IODEF. The IODEF and RID RFCs have = examples and text descriptions (sharing reduced information sets), like the= watch-lists to demonstrate this. Bulleted section: Can you extend the non-exhaustive list to include representing information = about incidents that are not covered by the base IODEF specification? We w= ant to leave this open for extensions like the anti-phishing where indicato= r information is represented in the extension. The information might not b= e in another schema or about an entity, so I don't want people to get confu= sed. Bottom of Page 4: Typo: RecordPattern@type>, Should be: RecordPattern@type, This list does not include "restriction'. I know it is not currently liste= d as one that can be extended, but I suspect that may change in and RFC5070= -bis from comments I have heard on difficulties with the limited set... or = it may get solved with an extension that enables additional ways to mark da= ta. I am not sure there is a way to do this, but if we added something tha= t said updated versions of IODEF may change this list so that folks not as = familiar with following references to the updates and then understanding th= at the change is possible with new versions of IODEF. The end of section 3 talks about the use of formatid, I think we should exp= lore that on list a bit more, separate from this document. It should proba= bly be in the context of updated IODEF guidance as a table or way to regist= er formatids could be very helpful since they are 'negotiated out-of-band' = per RFC5070, but could be really useful to reduce context in exchanges. Appendix: A2: Do you want to reference the requirements for IODEF RFC? It = is informational, but could be helpful. RFC3067 Appendix B: How do we get new enumerated Type extensions and new attribute= values into the schema? Do we also need a table where these get added so = that they can be included in the current schema version, then where there a= re updates, if they have been useful, we pull them into the new IODEF schem= a version? We may need to set that up here? Any thoughts? Or is this hand= led some other way? I had a table created for RID to serve this purpose. = DO we want to do the same thing here? Sorry I didn't catch it sooner. Appendix C: Suggest changing the last sentence of the second paragraph to = cover incomplete incident information when you are exchanging indicator inf= ormation via IODEF: From: "If a Test element is present, it indicates that an IODEF Document contains test data, not a reference to a real incident." To: "If a Test element is present, it indicates that an IODEF Document contains test data, not a reference or = information about a real incident." Appendix C: The test marker is interesting and could be useful, we may want= to talk about that more with a revision of IODEF to see if people want to = see something like that added since this is just an example. Thank you for all of your hard work on these documents! Best regards, Kathleen From kathleen.moriarty@emc.com Wed May 2 07:32:36 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A9721F85F6 for ; Wed, 2 May 2012 07:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjABDRpFJ8lT for ; Wed, 2 May 2012 07:32:35 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7508D21F85D9 for ; Wed, 2 May 2012 07:32:35 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q42EWUNp024920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 May 2012 10:32:33 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 2 May 2012 10:32:17 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q42EWG0H009432 for ; Wed, 2 May 2012 10:32:16 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub22.corp.emc.com ([128.222.70.134]) with mapi; Wed, 2 May 2012 10:32:16 -0400 From: To: Date: Wed, 2 May 2012 10:32:15 -0400 Thread-Topic: WGLC review of draft-ietf-mile-iodef-xmlreg-00 Thread-Index: Ac0ocF7RqqTkaNj7Rpqg/aqtOr9iBQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] WGLC review of draft-ietf-mile-iodef-xmlreg-00 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 14:32:36 -0000 Hi Brian & MILE members, Thank you for splitting out the two document again. I do not have any comm= ents on draft-ietf-mile-iodef-xmlreg-00. This looks pretty straightforward= from the combined version to this document. If anyone else has a comment, please have it in today as I will close out l= ast call later today. Best regards, Kathleen From kathleen.moriarty@emc.com Thu May 3 05:46:58 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A63C21F8568 for ; Thu, 3 May 2012 05:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sutrOA9qccAF for ; Thu, 3 May 2012 05:46:57 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id A2C0021F855A for ; Thu, 3 May 2012 05:46:57 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q43Cktnj014586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 May 2012 08:46:55 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Thu, 3 May 2012 08:46:48 -0400 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q43CkmmR027719 for ; Thu, 3 May 2012 08:46:48 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Thu, 3 May 2012 08:46:47 -0400 From: To: Date: Thu, 3 May 2012 08:46:45 -0400 Thread-Topic: WGLC on draft-ietf-mile-iodef-xmlreg-00.txt Thread-Index: AQHNHWbe0n+3SP4XhE21f+ph9oW8u5a2nYEQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] WGLC on draft-ietf-mile-iodef-xmlreg-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 12:46:58 -0000 The WGLC has ended on draft-ietf-mile-iodef-xmlreg-00.txt. Thank you for y= our time and consideration in reviewing this draft! Best regards, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of kat= hleen.moriarty@emc.com Sent: Wednesday, April 18, 2012 9:27 AM To: mile@ietf.org Subject: [mile] WGLC on draft-ietf-mile-iodef-xmlreg-00.txt Hello, The Working Group Last Call (WGLC) for the mile-iodef-xmlreg document will = take place over the next 2 weeks, ending the morning of 2 May 2012. Please review the document and post any questions to the MILE mailing list. http://tools.ietf.org/id/draft-ietf-mile-iodef-xmlreg-00.txt Thank you in advance! Best regards, Kathleen _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Thu May 3 05:47:29 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75CA21F8592 for ; Thu, 3 May 2012 05:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.557 X-Spam-Level: X-Spam-Status: No, score=-10.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEEBSDuKJsmA for ; Thu, 3 May 2012 05:47:29 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9AB21F855A for ; Thu, 3 May 2012 05:47:29 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q43ClQK8015383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 May 2012 08:47:27 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Thu, 3 May 2012 08:47:13 -0400 Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q43ClCKb025254 for ; Thu, 3 May 2012 08:47:12 -0400 Received: from mxhub37.corp.emc.com (128.222.70.104) by mxhub35.corp.emc.com (10.254.93.83) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 3 May 2012 08:47:12 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Thu, 3 May 2012 08:47:11 -0400 From: To: Date: Thu, 3 May 2012 08:47:09 -0400 Thread-Topic: WGLC on draft-ietf-mile-template Thread-Index: AQHNHWaScgOiCegkwUKlCWorIwe55Za2nH2w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] WGLC on draft-ietf-mile-template X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 12:47:29 -0000 The WGLC has ended on draft-ietf-mile-template. Thank you for your time an= d consideration in reviewing this draft! Best regards, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of kat= hleen.moriarty@emc.com Sent: Wednesday, April 18, 2012 9:24 AM To: mile@ietf.org Subject: [mile] WGLC on draft-ietf-mile-template Hello, The Working Group Last Call (WGLC) for the mile-template document will take= place over the next 2 weeks, ending the morning of 2 May 2012. Please review the document and post any questions to the MILE mailing list. https://datatracker.ietf.org/doc/draft-ietf-mile-template/ Thank you in advance! Best regards, Kathleen _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From rossella.mattioli@gmail.com Fri May 4 07:23:34 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF1921F8685 for ; Fri, 4 May 2012 07:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN3PKwJ8x898 for ; Fri, 4 May 2012 07:23:29 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E72E21F8624 for ; Fri, 4 May 2012 07:23:29 -0700 (PDT) Received: by bkty8 with SMTP id y8so2717427bkt.31 for ; Fri, 04 May 2012 07:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=+y9P29hb4954YfTk1bMTdubQYbOptcra9oVgKmm6FkY=; b=Z3ueFn/t5m8W949X8gDg3t37yzCUyGONHZaIGJfOXzmo9XSxXBh567By6Z0wsont7q W0j3YgKlRsQCu2X6poMbvzDw+KvOXsv1uADfuiNbMCzdZvAhf67t81qD+o28P6rWV0Qm Yeda5fospl87d6q6O0+wpXBOgSEXQw974H6M01ymIJD85sMuUtqL2oo2ZCWp3R9CX7kJ VoE9XdB/GesFwtWL7jd8rBzGjBTOXCteoP18fd1Nd5PLvTSe7FXi+ioVwhw4FpvbBOfr XjnPsUS4xGpNlmuN1l5slBL+U7ccBvA41TtgmF4Ksh90hNCmbxqD1jlpAFooahuKEYaM 6cTA== Received: by 10.204.152.75 with SMTP id f11mr2232813bkw.136.1336141408460; Fri, 04 May 2012 07:23:28 -0700 (PDT) Received: from [10.1.13.147] ([193.40.56.10]) by mx.google.com with ESMTPS id c28sm17370157bkv.4.2012.05.04.07.23.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 07:23:27 -0700 (PDT) From: Rossella Mattioli Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 4 May 2012 17:23:26 +0300 Message-Id: <3437BBA5-0941-40BE-A966-4FC1882E3686@gmail.com> To: mile@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [mile] considerations on RFC5070 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 04 May 2012 14:23:34 -0000 Greetings all, considering the recent drafts and the thread regarding IODEF = enumerations I would like to submit to the list some considerations = related to RFC 5070. My name is Rossella Mattioli and I recently joined this working group. I am currently completing my MSc in Cyber Security at Tallinn University = of Technology in Estonia with a thesis on a framework for CERTs incident = information exchange. This will be also my PhD research due to the extension of this topic . = Prior to join the academic world I worked for 9 years as the intranet = manager of a major italian financial group where I was also in charge of = content management and coordination of over two hundred contributors and = a very articulated restriction based content policy. I joined MILE because IODEF is an important part of my research where I = am investigating how to use it as a baseline for an interoperability = framework. I am still learning how this working group operates but at the same time = I would like to raise some questions. My initial research included mapping all solutions available, analyzing = 100 publicly available data feeds and try to use IODEF as a parsing = model. In doing this I developed some considerations which I try to summarize = here and that I would like to share with you: - Would you consider beneficial to have some classes with enumerated = category values regarding attack and malware type in IODEF ? This could = give at first sight a high level categorization of the attack/malware = type to the handler and prompt to future aggregation for comparison and = statistics.=20 - Domain data is usually an important part of an incident and I wonder = if a IODEF document could not benefit on how this information is handled = in RFC5901? Considering the DomainData, DomainContacts and Nameservers = elements, maybe it could be useful to insert this information also in = IODEF as a more generic class regarding domain data. - It is not straightforward how to use IODEF to describe some important = threats that are subjected to everyday data exchange like sinkholes and = C&C data feeds. How would you express this kind of data with the current = data schema ? I give you a short example taken from = http://www.shadowserver.org/wiki/pmwiki.php/Services/Sinkhole-HTTP-Referer= . =46rom RFC5070 it is clear how to describe =20 ReportTime - 2010-06-10 23:55:29 Address category=3Dipv4-addr - 200.234.220.51 Address category=3DASN - 27715 but it is not straightforward how to describe the following data: Infection type - iframe exploit=20 The URL or http host visited - ww.robint.us=20 The actual referral URL - = http://www.maispaulista.com.br/visualizar.asp?idMenu=3D22&idSubMenu=3D115 Country where the IP is located - BR - last but not least, I was wondering if the WG has statistics or has = done a survey regarding the actual usage of IODEF by CSIRTs around the = world. This could show which classes are considered more/less fulfilling = the everyday needs of response teams and also eventual gaps/evolution = they would underline. Any suggestion/ comment/advice is more than appreciated since I am = totally new to the IETF environment . Best regards, Rossella Mattioli= From Thomas.Millar@us-cert.gov Fri May 4 08:37:56 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D7821E8018 for ; Fri, 4 May 2012 08:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.555 X-Spam-Level: X-Spam-Status: No, score=-9.555 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_05=-1.11, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huh5WqTX97up for ; Fri, 4 May 2012 08:37:52 -0700 (PDT) Received: from shaggy.brass.us-cert.gov (shaggy.brass.us-cert.gov [208.73.184.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD93521E8013 for ; Fri, 4 May 2012 08:37:52 -0700 (PDT) Received: from shaggy.brass.us-cert.gov (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 8F1A850831; Fri, 4 May 2012 15:37:51 +0000 (UTC) Received: from yabba.bronze.us-cert.gov (yabba.bronze.us-cert.gov [192.168.2.22]) by shaggy.brass.us-cert.gov (Postfix) with ESMTP id 78DFC50830; Fri, 4 May 2012 15:37:51 +0000 (UTC) Received: from needle.bronze.us-cert.gov (needle.bronze.us-cert.gov [192.168.16.109]) by yabba.bronze.us-cert.gov (Postfix) with ESMTP id 60C3430070; Fri, 4 May 2012 15:37:51 +0000 (UTC) Received: from hive.bronze.us-cert.gov ([192.168.16.108]) by needle.bronze.us-cert.gov with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 May 2012 10:37:48 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 4 May 2012 10:37:48 -0500 Message-ID: In-Reply-To: <3437BBA5-0941-40BE-A966-4FC1882E3686@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mile] considerations on RFC5070 Thread-Index: Ac0qAYKk7LtqnRZgTbKQa5NQonu9lAABfweQ References: <3437BBA5-0941-40BE-A966-4FC1882E3686@gmail.com> From: To: , X-OriginalArrivalTime: 04 May 2012 15:37:48.0844 (UTC) FILETIME=[DC0CB6C0:01CD2A0B] X-TM-AS-Product-Ver: IMSS-7.1.0.1350-6.8.0.1017-18886.000 X-TM-AS-Result: No--21.928-5.0-31-10 X-imss-scan-details: No--21.928-5.0-31-10 X-TMASE-MatchedRID: TmlY9+XBoTm1c2BpM+uFbdh3b7/zBhN1baH3VbOE/Tl0TRq4bcxmH4AH BPmVHmpkpoTMZ7Xrlz57ijbu3LkNFmwigk/EVUD66rBZUF8y6+iP/EshoNKyEfTCq1LILNRVKDk R2MDyn9zuJ+sGu8sb5ylPtp/qf/NI3iNKzW39nxFhHpATwph+yARRdP/MSdUTDYbe/PyX8gQzR9 38MITop9/yNnbhIISMJwLG/lT65mp2Rany8ZWn3gu8ZZ1LOcwGSiV8TkZKsPn4JyR+b5tvoB0pL /mXqs2GWTO3XyA6o/n7psjgv3jTHFuK9PbhoyLt/uhIgJI5n7rgYKfhtyF8a8fvhKO/ikcNIwg3 Vd+9mjBLNEpO0vc+Zrpi5OKnHGjPKLEOdMizMM63UCG/IQp2PhEB3boGtIzCAVscD1Oo0tD5tGE /m3Vqru7bcAGPzEVMxVkn6xAnmq5md03XlK+nb4oFxrBKEta+oKO8hENbdcvqLnOUXH9QdIUMfY eeuwxLTVrI3aLNMN+b6hD7vtZ9dgtBO/n2Et0nEzQnFLEeMUndB/CxWTRRuyUIayx+Skid X-IMSS-DKIM-White-List: No Subject: Re: [mile] considerations on RFC5070 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 04 May 2012 15:37:56 -0000 Welcome aboard! One of the things I hope to do in this WG - time permitting - is to = contribute to a guidance draft to advance the potential adoption of = IODEF and your questions are all good ones to start the conversation = around what RFC 5070 currently lacks. >> Would you consider beneficial to have some classes with enumerated = category values regarding attack and malware type in IODEF ? This could = give at first sight a high level categorization of the attack/malware = type to the handler and prompt to future aggregation for comparison and = statistics.=20 =09 TM: I think that there is certainly room for some additional guidance = about utilizing the Method class of IODEF to indicate these types of = characteristics.=20 The trick is that there are not (and may never will be) globally = accepted taxonomies for attack types and malware characterization, so = this would have to be a pointer to a local registry of enumerations and = definitions - hopefully tailored from a common framework like CAPEC, but = every CSIRT and CSIRT-like organization has need for individualized = vocabularies. The Reference class under Method allows for a solution to = this, but it seems like adopters want to include their name for the kind = of attack or malware inline as an attribute, like the Impact class does = with type. =09 I would also humbly suggest that conflating things by including attack = vectors or types as enumerated values under the Impact class - as 5070 = does - creates confusion in this area. >> Domain data is usually an important part of an incident and I wonder = if a IODEF document could not benefit on how this information is handled = in RFC5901? Considering the DomainData, DomainContacts and Nameservers = elements, maybe it could be useful to insert this information also in = IODEF as a more generic class regarding domain data. TM: I do not disagree. The issue may be where to put it. At first glance = I would think those classes would look nice under the System or Node = classes but that is not how 5901 does it. >> It is not straightforward how to use IODEF to describe some important = threats that are subjected to everyday data exchange like sinkholes and = C&C data feeds. How would you express this kind of data with the current = data schema ? I give you a short example taken from = http://www.shadowserver.org/wiki/pmwiki.php/Services/Sinkhole-HTTP-Refere= r. >From RFC5070 it is clear how to describe ReportTime - 2010-06-10 = 23:55:29 Address category=3Dipv4-addr - 200.234.220.51 Address = category=3DASN - 27715 but it is not straightforward how to describe the = following data: Infection type - iframe exploit The URL or http host visited - ww.robint.us The actual referral URL - = http://www.maispaulista.com.br/visualizar.asp?idMenu=3D22&idSubMenu=3D115= Country where the IP is located - BR TM: Agreed. There are various places those things could be placed but it = is not clear from 5070 on which class or where they should be put. It = seems like this is something important enough that there should be some = additional guidance on it rather than leaving it for local definition. >> last but not least, I was wondering if the WG has statistics or has = done a survey regarding the actual usage of IODEF by CSIRTs around the = world. This could show which classes are considered more/less fulfilling = the everyday needs of response teams and also eventual gaps/evolution = they would underline. TM: I am not aware of any such statistics but I agree that they would be = useful. I am aware of only a very small number of operational = implementations of IODEF "in the wild" and I believe the APWG's version, = incorporating the 5901 extensions, is probably the most comprehensive in = terms of the number of classes it actually utilizes. =A0- Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 From kathleen.moriarty@emc.com Fri May 4 11:15:03 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E7621F8575 for ; Fri, 4 May 2012 11:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.263 X-Spam-Level: X-Spam-Status: No, score=-10.263 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N27OGbu7ba8V for ; Fri, 4 May 2012 11:14:59 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 32BDD21F853C for ; Fri, 4 May 2012 11:14:58 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q44IEmSY007309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 14:14:52 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 4 May 2012 14:14:25 -0400 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q44IEPvc021598; Fri, 4 May 2012 14:14:25 -0400 Received: from mx06a.corp.emc.com ([169.254.1.116]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Fri, 4 May 2012 14:14:25 -0400 From: To: , , Date: Fri, 4 May 2012 14:14:23 -0400 Thread-Topic: [mile] considerations on RFC5070 Thread-Index: Ac0qAYKk7LtqnRZgTbKQa5NQonu9lAABfweQAAZQZVA= Message-ID: References: <3437BBA5-0941-40BE-A966-4FC1882E3686@gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] considerations on RFC5070 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 04 May 2012 18:15:03 -0000 Rosella, welcome and thank you for kicking off this conversation! It sound= s like your experience will be very helpful to the WG! I'll keep my response light and hope other list participants, implementers,= or CSIRT operators chime in. We could see if we need to open up IODEF in = an RFC5070-bis in addition to a separate guidance document. This would let= us correct issues like the ones you have identified and then develop guida= nce that may go deeper than what is needed in the base structure document s= eparately (just a thought). It would be great to have a survey of implementations, I am not aware of on= e either. Other international CSIRTs use IODEF, such as JPCERT, the Brazil= CERT, Aus CERT (I think), and some in Europe (Terena started IODEF). Addi= tionally DFLabs has a product that is based on IODEF and it looks like HP A= rcsite supports IODEF. There was also a recent effort to include IODEF for= incident exchange via XMPP via IODEF. There are probably others and it wo= uld be really nice to have their collective input on any proposed improveme= nts to the format or guidance. Thank you! Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Tho= mas.Millar@us-cert.gov Sent: Friday, May 04, 2012 11:38 AM To: rossella.mattioli@gmail.com; mile@ietf.org Subject: Re: [mile] considerations on RFC5070 Welcome aboard! One of the things I hope to do in this WG - time permitting - is to contrib= ute to a guidance draft to advance the potential adoption of IODEF and your= questions are all good ones to start the conversation around what RFC 5070= currently lacks. >> Would you consider beneficial to have some classes with enumerated categ= ory values regarding attack and malware type in IODEF ? This could give at = first sight a high level categorization of the attack/malware type to the h= andler and prompt to future aggregation for comparison and statistics.=20 =09 TM: I think that there is certainly room for some additional guidance about= utilizing the Method class of IODEF to indicate these types of characteris= tics.=20 The trick is that there are not (and may never will be) globally accepted t= axonomies for attack types and malware characterization, so this would have= to be a pointer to a local registry of enumerations and definitions - hope= fully tailored from a common framework like CAPEC, but every CSIRT and CSIR= T-like organization has need for individualized vocabularies. The Reference= class under Method allows for a solution to this, but it seems like adopte= rs want to include their name for the kind of attack or malware inline as a= n attribute, like the Impact class does with type. =09 I would also humbly suggest that conflating things by including attack vect= ors or types as enumerated values under the Impact class - as 5070 does - c= reates confusion in this area. >> Domain data is usually an important part of an incident and I wonder if = a IODEF document could not benefit on how this information is handled in RF= C5901? Considering the DomainData, DomainContacts and Nameservers elements,= maybe it could be useful to insert this information also in IODEF as a mo= re generic class regarding domain data. TM: I do not disagree. The issue may be where to put it. At first glance I = would think those classes would look nice under the System or Node classes = but that is not how 5901 does it. >> It is not straightforward how to use IODEF to describe some important th= reats that are subjected to everyday data exchange like sinkholes and C&C d= ata feeds. How would you express this kind of data with the current data sc= hema ? I give you a short example taken from http://www.shadowserver.org/wi= ki/pmwiki.php/Services/Sinkhole-HTTP-Referer. >From RFC5070 it is clear how to describe ReportTime - 2010-06-10 23:55:29 A= ddress category=3Dipv4-addr - 200.234.220.51 Address category=3DASN - 27715= but it is not straightforward how to describe the following data: Infection type - iframe exploit The URL or http host visited - ww.robint.us The actual referral URL - htt= p://www.maispaulista.com.br/visualizar.asp?idMenu=3D22&idSubMenu=3D115 Country where the IP is located - BR TM: Agreed. There are various places those things could be placed but it is= not clear from 5070 on which class or where they should be put. It seems l= ike this is something important enough that there should be some additional= guidance on it rather than leaving it for local definition. >> last but not least, I was wondering if the WG has statistics or has done= a survey regarding the actual usage of IODEF by CSIRTs around the world. T= his could show which classes are considered more/less fulfilling the everyd= ay needs of response teams and also eventual gaps/evolution they would unde= rline. TM: I am not aware of any such statistics but I agree that they would be us= eful. I am aware of only a very small number of operational implementations= of IODEF "in the wild" and I believe the APWG's version, incorporating the= 5901 extensions, is probably the most comprehensive in terms of the number= of classes it actually utilizes. =A0- Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From sm@resistor.net Fri May 4 14:03:35 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF8321F847E for ; Fri, 4 May 2012 14:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56oF5lC7aNc7 for ; Fri, 4 May 2012 14:03:32 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F4021F847C for ; Fri, 4 May 2012 14:03:31 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q44L3OGl029491; Fri, 4 May 2012 14:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1336165410; i=@resistor.net; bh=JOTwmXfxz0yjb/MC/3MWUN5gU++vYScDpCaB3hXiJIE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ct7ppmXbZ4Smf2Sc8sHOxAtVl5MnFAxXxCYuluChbRqirCSLDnX2pBKI7ieUb+f5v 7E95iFD/zYSM1sF4lmDLl0nXsmbD/JUCd8nebSYUV9c6CSVSE8WAIDes6yVK9pykJE HDukpSMjZBzSEaRaHY/9/Sa3EvVY/ueV2bYNMjvw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1336165410; i=@resistor.net; bh=JOTwmXfxz0yjb/MC/3MWUN5gU++vYScDpCaB3hXiJIE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NXLnXhfbCba6zFxwKxTq/sholTqZixOaoXYBbbfm1ehSR6rv4Hdo9hs+2YXSkmiUX rCRdeNEZjcZLiScyx/XwzwjN1ZGMnBr1THcZtqkh/eDRihfgpIPLYE0V70tc7dCtPP 25DvtU7mo/3OIrG8hLQldl9oIQwSGUBH5KdttCEQ= Message-Id: <6.2.5.6.2.20120504135254.0a89f828@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 04 May 2012 13:56:05 -0700 To: Rossella Mattioli From: SM In-Reply-To: <3437BBA5-0941-40BE-A966-4FC1882E3686@gmail.com> References: <3437BBA5-0941-40BE-A966-4FC1882E3686@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: mile@ietf.org Subject: Re: [mile] considerations on RFC5070 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 04 May 2012 21:03:36 -0000 Hi Rossella, At 07:23 04-05-2012, Rossella Mattioli wrote: >- last but not least, I was wondering if the WG has statistics or >has done a survey regarding the actual usage of IODEF by CSIRTs >around the world. This could show which classes are considered >more/less fulfilling the everyday needs of response teams and also >eventual gaps/evolution they would underline. I recall that there was some research being done in a country in Latin America. I don't know whether IODEF was being used. Regards, -sm From rossella.mattioli@gmail.com Sat May 5 03:53:43 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC8D21F8548 for ; Sat, 5 May 2012 03:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sFNsf9j1jhk for ; Sat, 5 May 2012 03:53:39 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7400921F8547 for ; Sat, 5 May 2012 03:53:39 -0700 (PDT) Received: by werf13 with SMTP id f13so1443426wer.31 for ; Sat, 05 May 2012 03:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Ch89qzmhu81zPaMx67dPbLnfn10B2jyLHk9AHf0wvYo=; b=amToZkQHem3KKh4SyHCnEL8iSkPP5+ygVfcWDbBJIjSxb9ifctnW8q7Ja3kHVvnSWn ltux86SI24e+Yft1dsx7kmefufMQUUQmrbowwOtFUlrNtAESJ9jN+9x9bC5d1poIt3sh 4dDcdauiyjdtURMmlYurGaFeRNch6cKQRr3bVmYK1amrEokukIqvOZhM69wob9ShofhW UQOhdziC8BVdJgxaDqwvXh/euBtQZ9WP345STCYQofkZAxcJqvM7Xicf4qWZq3QPENNy LgpijUcAtCoscPlDXMotaWcA9x+R6sOjEBeCGvxYNUXYg98WWCtm3RTtwJ81+oeJIZui 0A/g== Received: by 10.180.105.198 with SMTP id go6mr20379047wib.19.1336215218499; Sat, 05 May 2012 03:53:38 -0700 (PDT) Received: from [10.1.13.147] ([193.40.56.10]) by mx.google.com with ESMTPS id ff2sm7500074wib.9.2012.05.05.03.53.36 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 May 2012 03:53:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Rossella Mattioli In-Reply-To: Date: Sat, 5 May 2012 13:53:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3437BBA5-0941-40BE-A966-4FC1882E3686@gmail.com> To: Thomas.Millar@us-cert.gov, kathleen.moriarty@emc.com, SM X-Mailer: Apple Mail (2.1257) Cc: mile@ietf.org Subject: Re: [mile] considerations on RFC5070 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 05 May 2012 10:53:43 -0000 Thank you so much Kathleen, Thomas and SM. I grouped the answers and put my comments inline. On May 4, 2012, at 6:37 PM, wrote: > Welcome aboard! >=20 > One of the things I hope to do in this WG - time permitting - is to = contribute to a guidance draft to advance the potential adoption of = IODEF and your questions are all good ones to start the conversation = around what RFC 5070 currently lacks. >=20 >>> Would you consider beneficial to have some classes with enumerated = category values regarding attack and malware type in IODEF ? This could = give at first sight a high level categorization of the attack/malware = type to the handler and prompt to future aggregation for comparison and = statistics.=20 > =09 > TM: I think that there is certainly room for some additional guidance = about utilizing the Method class of IODEF to indicate these types of = characteristics.=20 I agree with you, I believe that further implementing this class could = be helpful considering the importance of these indicators. >=20 > The trick is that there are not (and may never will be) globally = accepted taxonomies for attack types and malware characterization, so = this would have to be a pointer to a local registry of enumerations and = definitions - hopefully tailored from a common framework like CAPEC, but = every CSIRT and CSIRT-like organization has need for individualized = vocabularies. The Reference class under Method allows for a solution to = this, but it seems like adopters want to include their name for the kind = of attack or malware inline as an attribute, like the Impact class does = with type. I agree, there will be always internal vocabularies and if allowed, = users will always put their own names as attributes. This is why it = could be useful to have a high level enumerations and definitions which = CSIRTs can use to map their own dictionaries and insert their internal = characterizations and names as a subset. A general registry could be seen as a first effort in the direction of a = standardized high level characterization for attack and malware. This = could be then linked both to more organized frameworks and also = proprietary implementations. Considering the volume of these events, having not globally accepted = categories hampers the alignment of incident categorization. It also = doesn't easily allow to compare statistics between different CSIRTs and = have a global view on the real numbers. Implementing a general = characterization in IODEF could help as a first step in this direction.=20= > =09 > I would also humbly suggest that conflating things by including attack = vectors or types as enumerated values under the Impact class - as 5070 = does - creates confusion in this area. If you are referring at the current impact@type values:=20 1. admin. Administrative privileges were attempted. 2. dos. A denial of service was attempted. 3. file. An action that impacts the integrity of a file or database = was attempted. 4. info-leak. An attempt was made to exfiltrate information. 5. misconfiguration. An attempt was made to exploit a = mis-configuration in a system. 6. policy. Activity violating site's policy was attempted. 7. recon. Reconnaissance activity was attempted. 8. social-engineering. A social engineering attack was attempted 9. user. User privileges were attempted. 10. unknown. The classification of this activity is unknown. 11. ext-value. An escape value used to extend this attribute. I agree with you. >=20 >>> Domain data is usually an important part of an incident and I wonder = if a IODEF document could not benefit on how this information is handled = in RFC5901? Considering the DomainData, DomainContacts and Nameservers = elements, maybe it could be useful to insert this information also in = IODEF as a more generic class regarding domain data. >=20 > TM: I do not disagree. The issue may be where to put it. At first = glance I would think those classes would look nice under the System or = Node classes but that is not how 5901 does it. Yes, System or Node are probably the places where to put it. I only used = the RFC5901 example to show which elements could be useful to describe. >=20 >>> It is not straightforward how to use IODEF to describe some = important threats that are subjected to everyday data exchange like = sinkholes and C&C data feeds. How would you express this kind of data = with the current data schema ? I give you a short example taken from = http://www.shadowserver.org/wiki/pmwiki.php/Services/Sinkhole-HTTP-Referer= . > =46rom RFC5070 it is clear how to describe ReportTime - 2010-06-10 = 23:55:29 Address category=3Dipv4-addr - 200.234.220.51 Address = category=3DASN - 27715 but it is not straightforward how to describe the = following data: > Infection type - iframe exploit > The URL or http host visited - ww.robint.us The actual referral URL = - http://www.maispaulista.com.br/visualizar.asp?idMenu=3D22&idSubMenu=3D11= 5 > Country where the IP is located - BR >=20 > TM: Agreed. There are various places those things could be placed but = it is not clear from 5070 on which class or where they should be put. It = seems like this is something important enough that there should be some = additional guidance on it rather than leaving it for local definition. I totally agree, perhaps including the high level characterization I was = mentioning above and implementing the domain data could be considered in = defining this information. >=20 >>> last but not least, I was wondering if the WG has statistics or has = done a survey regarding the actual usage of IODEF by CSIRTs around the = world. This could show which classes are considered more/less fulfilling = the everyday needs of response teams and also eventual gaps/evolution = they would underline. >=20 > TM: I am not aware of any such statistics but I agree that they would = be useful. I am aware of only a very small number of operational = implementations of IODEF "in the wild" and I believe the APWG's version, = incorporating the 5901 extensions, is probably the most comprehensive in = terms of the number of classes it actually utilizes. On May 4, 2012, at 9:14 PM, wrote: ... > It would be great to have a survey of implementations, I am not aware = of one either. Other international CSIRTs use IODEF, such as JPCERT, = the Brazil CERT, Aus CERT (I think), and some in Europe (Terena started = IODEF). Additionally DFLabs has a product that is based on IODEF and it = looks like HP Arcsite supports IODEF. There was also a recent effort to = include IODEF for incident exchange via XMPP via IODEF. There are = probably others and it would be really nice to have their collective = input on any proposed improvements to the format or guidance. ... On May 4, 2012, at 11:56 PM, SM wrote: .... > I recall that there was some research being done in a country in Latin = America. I don't know whether IODEF was being used. ... Thank you so much. I noted APWG, JPCERT, the Brazil CERT, Aus CERT, = Terena and the vendors. I will look for the research in Latin America. Are these CERTs/orgs and vendors members of the MILE? Best regards, Rossella Mattioli From internet-drafts@ietf.org Wed May 9 03:07:42 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0610D21F855A; Wed, 9 May 2012 03:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3cHChGAE1oP; Wed, 9 May 2012 03:07:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8136721F851E; Wed, 9 May 2012 03:07:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120509100741.25473.80328.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2012 03:07:41 -0700 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-iodef-xmlreg-01.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 10:07:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange= Working Group of the IETF. Title : Expert Review for IODEF Extensions in IANA XML Registry Author(s) : Brian Trammell Filename : draft-ietf-mile-iodef-xmlreg-01.txt Pages : 3 Date : 2012-05-09 This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to IODEF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-iodef-xmlreg-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-iodef-xmlreg-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-xmlreg/ From trammell@tik.ee.ethz.ch Wed May 9 03:25:03 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B18921F8557 for ; Wed, 9 May 2012 03:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.14 X-Spam-Level: X-Spam-Status: No, score=-6.14 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOAO4z4WY9LK for ; Wed, 9 May 2012 03:25:02 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4B63021F8554 for ; Wed, 9 May 2012 03:24:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 04367D9304 for ; Wed, 9 May 2012 12:24:58 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2rMEgln5vTW2 for ; Wed, 9 May 2012 12:24:57 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B82DFD9300 for ; Wed, 9 May 2012 12:24:57 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 May 2012 12:24:56 +0200 References: <20120509100741.25473.79504.idtracker@ietfa.amsl.com> To: mile@ietf.org Message-Id: <27F1310F-5A0F-496C-A7CE-9B5D19A93760@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [mile] Fwd: New Version Notification for draft-ietf-mile-iodef-xmlreg-01.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 10:25:03 -0000 Greetings, all, This submission of iodef-xmlreg addresses AD comments received during = the WGLC, and is ready (in my opinion as author) for the IESG. Cheers, Brian (author hat) Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-mile-iodef-xmlreg-01.txt > Date: May 9, 2012 12:07:41 PM GMT+02:00 > To: trammell@tik.ee.ethz.ch >=20 > A new version of I-D, draft-ietf-mile-iodef-xmlreg-01.txt has been = successfully submitted by Brian Trammell and posted to the IETF = repository. >=20 > Filename: draft-ietf-mile-iodef-xmlreg > Revision: 01 > Title: Expert Review for IODEF Extensions in IANA XML = Registry > Creation date: 2012-05-09 > WG ID: mile > Number of pages: 3 >=20 > Abstract: > This document specifies restrictions on additions to the subset of > the IANA XML Namespace and Schema registries, to require Expert > Review for extensions to IODEF. >=20 >=20 >=20 >=20 > The IETF Secretariat From trammell@tik.ee.ethz.ch Wed May 9 06:59:45 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C5321F85FC for ; Wed, 9 May 2012 06:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBJyTmZGu3Av for ; Wed, 9 May 2012 06:59:44 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9021A21F85F0 for ; Wed, 9 May 2012 06:59:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EE959D930B; Wed, 9 May 2012 15:59:42 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id joYs4SCTdtmz; Wed, 9 May 2012 15:59:42 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 91CDFD9300; Wed, 9 May 2012 15:59:42 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4F999FB4.5070403@ieca.com> Date: Wed, 9 May 2012 15:59:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4DE7695F-C053-4676-A313-DA08652082C6@tik.ee.ethz.ch> References: <4F999FB4.5070403@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1257) Cc: mile@ietf.org Subject: Re: [mile] early AD-review of draft-ietf-mile-template X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 13:59:45 -0000 Hi, Sean, Many thanks for the review; I've incorporated these points into a = working -04 revision. A couple of questions or points, inline... On Apr 26, 2012, at 9:19 PM, Sean Turner wrote: > 12) A.8 and A.9 and I guess all appendices in this draft, should we = require that they explicitly be marked as normative parts of the = document? A.8 and A.9 are weird, in that they're appendices within an appendix. = Examples are definitely informative. The XML schema should be normative; = however, technically, I would presume it's the schema that goes into the = IANA registry (which, of course, in the normal case, gets taken from the = schema in Appendix A of an extension document) which is normative. > 13) Appendix B: Should we make up something to register as opposed to = using something real? Maybe something like lottery #? It would reduce potential confusion; we've already had appsarea feedback = on this example. I did spend a little time trying to come up with an = enumeration extension that was clearly ridiculous but still realistic = enough to be properly illustrative; this is as close as I got. Not sure = where we'd wedge a lottery number into one of the enumerations. I'm = inclined to leave this as it is for now... Best regards,=20 Brian (author hat)= From trammell@tik.ee.ethz.ch Wed May 9 07:00:39 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF2921F85FC for ; Wed, 9 May 2012 07:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LALTcu8tixdA for ; Wed, 9 May 2012 07:00:38 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7203A21F85F0 for ; Wed, 9 May 2012 07:00:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id CE3B3D930B; Wed, 9 May 2012 16:00:37 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8Q70gNw8lnde; Wed, 9 May 2012 16:00:37 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A1AF4D9300; Wed, 9 May 2012 16:00:36 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Wed, 9 May 2012 16:00:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <85F102E9-5AE7-4FAA-A913-5BFC343A8796@tik.ee.ethz.ch> References: To: X-Mailer: Apple Mail (2.1257) Cc: mile@ietf.org Subject: Re: [mile] WGLC: Review of draft-ietf-mile-template-03 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 14:00:39 -0000 hi, Kathleen, Thanks for your comments! I've incorporated these into the -04 working = revision, which I'll submit shortly. Comments/questions inline. On May 2, 2012, at 3:55 PM, = wrote: > This list does not include "restriction'. I know it is not currently = listed as one that can be extended, but I suspect that may change in and = RFC5070-bis from comments I have heard on difficulties with the limited = set... or it may get solved with an extension that enables additional = ways to mark data. I am not sure there is a way to do this, but if we = added something that said updated versions of IODEF may change this list = so that folks not as familiar with following references to the updates = and then understanding that the change is possible with new versions of = IODEF. I've added a note (as with one on types, as per Sean's comments) that = the list is current but may change in the future, check documents that = update 5070. > Appendix B: How do we get new enumerated Type extensions and new = attribute values into the schema? Do we also need a table where these = get added so that they can be included in the current schema version, = then where there are updates, if they have been useful, we pull them = into the new IODEF schema version? We may need to set that up here? = Any thoughts? Or is this handled some other way? I had a table created = for RID to serve this purpose. DO we want to do the same thing here? = Sorry I didn't catch it sooner. Couple of issues here that I can see, that follow from how the IODEF = extension mechanism works. 1. IODEF basically defines the contents of an extension attribute, = AdditionalData, and RecordItem to be free-form; so there's nowhere in = IODEF to note a specific extension is in use, other than in the = inclusion of schemas/namespaces in the XML document itself. 2. Since IODEF extensions need to use extension attributes and = AdditionalData/RecordItem, pulling them into a new IODEF schema version, = at which point I presume we'd want to take them out of AdditionalData = and incorporate them as "first class members" of the document (whether = by joining the enumeration or being directly contained without an = AdditionalData in the way) would cause them to be non-interoperable with = previous versions of IODEF.=20 Not sure what the solution to these is, but I think the right place to = address them is probably in any update to IODEF itself, not in the = template. Best regards, Brian (author hat) From turners@ieca.com Wed May 9 07:40:21 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C9411E809C for ; Wed, 9 May 2012 07:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qEIHojRlOey for ; Wed, 9 May 2012 07:40:20 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.41.242.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCF111E809A for ; Wed, 9 May 2012 07:40:20 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id C10AF5742AF90; Wed, 9 May 2012 09:40:19 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id B6CE55742AF57 for ; Wed, 9 May 2012 09:40:19 -0500 (CDT) Received: from [96.231.126.91] (port=48681 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SS83v-0003KJ-E0; Wed, 09 May 2012 09:40:19 -0500 Message-ID: <4FAA81D2.8050802@ieca.com> Date: Wed, 09 May 2012 10:40:18 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian Trammell References: <4F999FB4.5070403@ieca.com> <4DE7695F-C053-4676-A313-DA08652082C6@tik.ee.ethz.ch> In-Reply-To: <4DE7695F-C053-4676-A313-DA08652082C6@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-126-91.washdc.east.verizon.net (thunderfish.local) [96.231.126.91]:48681 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: mile@ietf.org Subject: Re: [mile] early AD-review of draft-ietf-mile-template X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 14:40:21 -0000 On 5/9/12 9:59 AM, Brian Trammell wrote: > Hi, Sean, > > Many thanks for the review; I've incorporated these points into a working -04 revision. A couple of questions or points, inline... > > On Apr 26, 2012, at 9:19 PM, Sean Turner wrote: > >> 12) A.8 and A.9 and I guess all appendices in this draft, should we require that they explicitly be marked as normative parts of the document? > > A.8 and A.9 are weird, in that they're appendices within an appendix. Examples are definitely informative. The XML schema should be normative; however, technically, I would presume it's the schema that goes into the IANA registry (which, of course, in the normal case, gets taken from the schema in Appendix A of an extension document) which is normative. So I guess adding a sentence in A.8/A.9 to say something like "When the draft is produced this Appendix should be marked as normative" and "When the draft is produced this Appendix should be marked as informative" would work for me. >> 13) Appendix B: Should we make up something to register as opposed to using something real? Maybe something like lottery #? > > It would reduce potential confusion; we've already had appsarea feedback on this example. I did spend a little time trying to come up with an enumeration extension that was clearly ridiculous but still realistic enough to be properly illustrative; this is as close as I got. Not sure where we'd wedge a lottery number into one of the enumerations. I'm inclined to leave this as it is for now... I'm fine with that. I'm sure there's somebody out there that'll have an opinion on this - and then we can ask them for an example ;) spt From internet-drafts@ietf.org Wed May 9 07:44:00 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE1911E809C; Wed, 9 May 2012 07:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kS3hTTrjYMWq; Wed, 9 May 2012 07:44:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EF811E8072; Wed, 9 May 2012 07:44:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120509144400.30539.34771.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2012 07:44:00 -0700 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-template-04.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 14:44:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange= Working Group of the IETF. Title : Guidelines for Defining Extensions to IODEF Author(s) : Brian Trammell Filename : draft-ietf-mile-template-04.txt Pages : 13 Date : 2012-05-09 This document provides guidelines for extensions to IODEF [RFC5070] for exchange of incident management data, and contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-template-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-template-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-template/ From trammell@tik.ee.ethz.ch Wed May 9 08:47:26 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E889421F846B for ; Wed, 9 May 2012 08:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p6IsHXwHDgb for ; Wed, 9 May 2012 08:47:26 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 52B5121F8418 for ; Wed, 9 May 2012 08:47:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6AB35D9310; Wed, 9 May 2012 17:47:24 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DYRhlmBCfy8i; Wed, 9 May 2012 17:47:24 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2B4BFD930C; Wed, 9 May 2012 17:47:24 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4FAA81D2.8050802@ieca.com> Date: Wed, 9 May 2012 17:47:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F999FB4.5070403@ieca.com> <4DE7695F-C053-4676-A313-DA08652082C6@tik.ee.ethz.ch> <4FAA81D2.8050802@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1257) Cc: mile@ietf.org Subject: Re: [mile] early AD-review of draft-ietf-mile-template X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 15:47:27 -0000 On May 9, 2012, at 4:40 PM, Sean Turner wrote: >>> 12) A.8 and A.9 and I guess all appendices in this draft, should we = require that they explicitly be marked as normative parts of the = document? >>=20 >> A.8 and A.9 are weird, in that they're appendices within an appendix. = Examples are definitely informative. The XML schema should be normative; = however, technically, I would presume it's the schema that goes into the = IANA registry (which, of course, in the normal case, gets taken from the = schema in Appendix A of an extension document) which is normative. >=20 > So I guess adding a sentence in A.8/A.9 to say something like "When = the draft is produced this Appendix should be marked as normative" and = "When the draft is produced this Appendix should be marked as = informative" would work for me. Okay, that makes sense. (As I've already submitted an -04, would it be = okay to hold this for -05 pending other IESG commentary, presuming = there's nothing else that needs to be done before then?) Cheers, Brian (author hat) From turners@ieca.com Wed May 9 08:55:21 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707E821F847F for ; Wed, 9 May 2012 08:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.734 X-Spam-Level: X-Spam-Status: No, score=-101.734 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIKx5Sujlu+O for ; Wed, 9 May 2012 08:55:14 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.93.82.10]) by ietfa.amsl.com (Postfix) with ESMTP id D260521F8463 for ; Wed, 9 May 2012 08:55:13 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 4EE6C5440A0CF; Wed, 9 May 2012 10:55:13 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 40C045440A08E for ; Wed, 9 May 2012 10:55:13 -0500 (CDT) Received: from [64.134.100.254] (port=49774 helo=[192.168.5.56]) by gator1743.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SS9EP-00063C-2H; Wed, 09 May 2012 10:55:13 -0500 References: <4F999FB4.5070403@ieca.com> <4DE7695F-C053-4676-A313-DA08652082C6@tik.ee.ethz.ch> <4FAA81D2.8050802@ieca.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-EB8165ED-30B2-4E87-9C71-19596BC54165; protocol="application/pkcs7-signature" Message-Id: X-Mailer: iPhone Mail (9B206) From: Sean Trner Date: Wed, 9 May 2012 11:55:10 -0400 To: Brian Trammell X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ip-64-134-100-254.public.wayport.net ([192.168.5.56]) [64.134.100.254]:49774 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "mile@ietf.org" Subject: Re: [mile] early AD-review of draft-ietf-mile-template X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 15:55:21 -0000 --Apple-Mail-EB8165ED-30B2-4E87-9C71-19596BC54165 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Absolutely. Spt Sent from my iPhone On May 9, 2012, at 11:47 AM, Brian Trammell wrote:= >=20 > On May 9, 2012, at 4:40 PM, Sean Turner wrote: >=20 >>>> 12) A.8 and A.9 and I guess all appendices in this draft, should we req= uire that they explicitly be marked as normative parts of the document? >>>=20 >>> A.8 and A.9 are weird, in that they're appendices within an appendix. Ex= amples are definitely informative. The XML schema should be normative; howev= er, technically, I would presume it's the schema that goes into the IANA reg= istry (which, of course, in the normal case, gets taken from the schema in A= ppendix A of an extension document) which is normative. >>=20 >> So I guess adding a sentence in A.8/A.9 to say something like "When the d= raft is produced this Appendix should be marked as normative" and "When the d= raft is produced this Appendix should be marked as informative" would work f= or me. >=20 > Okay, that makes sense. (As I've already submitted an -04, would it be oka= y to hold this for -05 pending other IESG commentary, presuming there's noth= ing else that needs to be done before then?) >=20 > Cheers, >=20 > Brian (author hat) >=20 --Apple-Mail-EB8165ED-30B2-4E87-9C71-19596BC54165 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUdDANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMjA0MTExNDQ3MjdaFw0xMzA0MTExNDQ3MjdaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANFniuhe1PHTHJz3PO+s3x0UXMwsH8t2er3qAYid2pRDzq6g RAnK49/RpeAoqdtl8Yb1k8yQ0srhvE6461ramVXu8uQEny8/C+tOUeZMPuL2StELpyq0yJ6us0cF AvaEFuEVQOGfVg0hfjh7PqUwyccTqPyY7n/tTFf7ZdekCIYJ4eoOfWAyjcnNbQKLskDrIhlXw2eR 0O2pKLFyFbeGbfeTh+EhvjLeyG2Ue+Am1NsF1XccSQdI6u+mflL93aYvhHct6gMB8mLyz4eAQlrv REYbyrd9rIzVEAeg3l/ct4d+EwYXZ+e7Zx/ksJPbSdg8UC3eezg6ELX7DaXMM8UNw28CAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQdHVybmVyc0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQA6SUSIybM+JcdlBcHzW2vEkDrMWbIVVNUU97NuXTOZNhmLoFe6gU2R4kL9sYTAuQfQ JEMtdtzUzQvuD77qZb4oHVlJiH3Y+8qOP5qAtkbD1351ksLWVhDf2qncxRWcTb5jKTYpJWQSlAWO LtbRrtrItgJJTNGKL2aRLu823EPI/gFOa9/8bVAiAwi8iAh5a2jZL7du1CmxGZFfN5x9Q0mzKKhG 7mVQRr0im8cZb/dh7WWu/YHExecQ110025GD2oibQUNgEVfexPptVyKVC3Lu12oB3zJ8GLcvKlVB RdIuYfL/mogoRLI2rUfNPzibx3lHq36OR7tqDckcXRsXYDyFqTA6YUFEKYdp1IJPghczwvKCfUSa 423plba+JSsg6djnAsFOy3GIR/nKq/W7JOUIOve9FTbLkqu9IWu5hpyRmW6asvwgIbh039VNWTfd xMRCcCdNpawbAeFTA6XrWs8Q2O4r/2GH6hkDGE1dh5sNCq2FsmQEwYCcOgzGzRtQgas/KJAiKvZg d9BRjL3VtApYewt91KJImHNGraETVd5jzOf5PssE3gG5k3QEOcCvo1er4tY9xUF0JUbJz97crnf5 OBrtxNaUfS2oFOmhZMQu3qDe/uyuIin3WwXo65hw3bmf8A0BPNSfNv82F8MB5yjD63pUbxNGksBi IhWRHMhhFDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUdDAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMDUwOTE1NTUxMlowIwYJKoZIhvcNAQkEMRYEFPRG5YoBL854T/G3Vlh9r8ku Qjf4MD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUdDBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUdDANBgkqhkiG9w0BAQEFAASCAQBhAqLYeMz1jmtstY92O6VFVSeq TpO/d27AnL39+vzqQKZ0aYtz5rz1weU/JOgvVc8bVIE5B3s58tOUD1NItUzVdNXX6SnyaZCvN+Fu pekDfSLebgUMSY/8CcfDOKCOsIPPv0k/UQzOotmZCWNdK0vuYYMITZxaRXyWSTuZvNdkKw0tDdiK 8aFwl2s6zYuYiQUOhG5nbAl2OISWE5ZrFo5bIsIzub/N8v2Zqh9bfOFf3GnxtPvbJMPg9WAbOULq AwgH9YNrXV4PSiCCg2QZxhpB/7olTk53dN9hZQ+y2uX1ZhPp7gJFxAgOi/AeQyzLzPqWfcfNH4N+ gqsrb/PnjgwEAAAAAAAA --Apple-Mail-EB8165ED-30B2-4E87-9C71-19596BC54165-- From kathleen.moriarty@emc.com Wed May 9 13:58:51 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CF121F8474 for ; Wed, 9 May 2012 13:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zutctMRNS0ww for ; Wed, 9 May 2012 13:58:51 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id D7F2C21F8472 for ; Wed, 9 May 2012 13:58:50 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q49KwnbV018986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2012 16:58:49 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 9 May 2012 16:58:40 -0400 Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q49Kwd7w004893; Wed, 9 May 2012 16:58:40 -0400 Received: from mx06a.corp.emc.com ([169.254.1.116]) by mxhub35.corp.emc.com ([::1]) with mapi; Wed, 9 May 2012 16:58:39 -0400 From: To: Date: Wed, 9 May 2012 16:58:38 -0400 Thread-Topic: WGLC: Review of draft-ietf-mile-template-03 Thread-Index: Ac0t7DBnmvLnR26jR5acWyD8x4vlXwAOf8QQ Message-ID: References: <85F102E9-5AE7-4FAA-A913-5BFC343A8796@tik.ee.ethz.ch> In-Reply-To: <85F102E9-5AE7-4FAA-A913-5BFC343A8796@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] WGLC: Review of draft-ietf-mile-template-03 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 20:58:51 -0000 Hi Brian, Thank you, the updated document looks good. I do agree that the questions = should be handled in an updated version of RCF5070. Being able to add enum= erations to existing attributes via a table could be very useful, but shoul= d be handled separately. We should add this to Rosella's list for discussi= on on the mailing list to see what people think. Thank you, Kathleen -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 Sent: Wednesday, May 09, 2012 10:01 AM To: Moriarty, Kathleen Cc: mile@ietf.org Subject: Re: WGLC: Review of draft-ietf-mile-template-03 hi, Kathleen, Thanks for your comments! I've incorporated these into the -04 working revi= sion, which I'll submit shortly. Comments/questions inline. On May 2, 2012, at 3:55 PM, wrote: > This list does not include "restriction'. I know it is not currently lis= ted as one that can be extended, but I suspect that may change in and RFC50= 70-bis from comments I have heard on difficulties with the limited set... o= r it may get solved with an extension that enables additional ways to mark = data. I am not sure there is a way to do this, but if we added something t= hat said updated versions of IODEF may change this list so that folks not a= s familiar with following references to the updates and then understanding = that the change is possible with new versions of IODEF. I've added a note (as with one on types, as per Sean's comments) that the l= ist is current but may change in the future, check documents that update 50= 70. > Appendix B: How do we get new enumerated Type extensions and new attribu= te values into the schema? Do we also need a table where these get added s= o that they can be included in the current schema version, then where there= are updates, if they have been useful, we pull them into the new IODEF sch= ema version? We may need to set that up here? Any thoughts? Or is this ha= ndled some other way? I had a table created for RID to serve this purpose.= DO we want to do the same thing here? Sorry I didn't catch it sooner. Couple of issues here that I can see, that follow from how the IODEF extens= ion mechanism works. 1. IODEF basically defines the contents of an extension attribute, Addition= alData, and RecordItem to be free-form; so there's nowhere in IODEF to note= a specific extension is in use, other than in the inclusion of schemas/nam= espaces in the XML document itself. 2. Since IODEF extensions need to use extension attributes and AdditionalDa= ta/RecordItem, pulling them into a new IODEF schema version, at which point= I presume we'd want to take them out of AdditionalData and incorporate the= m as "first class members" of the document (whether by joining the enumerat= ion or being directly contained without an AdditionalData in the way) would= cause them to be non-interoperable with previous versions of IODEF.=20 Not sure what the solution to these is, but I think the right place to addr= ess them is probably in any update to IODEF itself, not in the template. Best regards, Brian (author hat) From kathleen.moriarty@emc.com Wed May 9 14:00:29 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB8621F847F for ; Wed, 9 May 2012 14:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.554 X-Spam-Level: X-Spam-Status: No, score=-10.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnTo8clE1Dof for ; Wed, 9 May 2012 14:00:28 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 39BB021F847E for ; Wed, 9 May 2012 14:00:27 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q49L0Oju020651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2012 17:00:26 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 9 May 2012 17:00:15 -0400 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q49L0FeH020992; Wed, 9 May 2012 17:00:15 -0400 Received: from mx06a.corp.emc.com ([169.254.1.116]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Wed, 9 May 2012 17:00:15 -0400 From: To: , Date: Wed, 9 May 2012 17:00:14 -0400 Thread-Topic: [mile] early AD-review of draft-ietf-mile-template Thread-Index: Ac0t/eR0jj8FGC3USY+NI1En5oltAgAKKVRw Message-ID: References: <4F999FB4.5070403@ieca.com> <4DE7695F-C053-4676-A313-DA08652082C6@tik.ee.ethz.ch> <4FAA81D2.8050802@ieca.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-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] early AD-review of draft-ietf-mile-template X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 21:00:29 -0000 Hello Brian, Thank you for making all of the requested changes. It appears all recommen= ded changes were addressed in this WGLC. The document is ready for IESG la= st call. Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sea= n Trner Sent: Wednesday, May 09, 2012 11:55 AM To: Brian Trammell Cc: mile@ietf.org Subject: Re: [mile] early AD-review of draft-ietf-mile-template Absolutely. Spt Sent from my iPhone On May 9, 2012, at 11:47 AM, Brian Trammell wrote= : >=20 > On May 9, 2012, at 4:40 PM, Sean Turner wrote: >=20 >>>> 12) A.8 and A.9 and I guess all appendices in this draft, should we re= quire that they explicitly be marked as normative parts of the document? >>>=20 >>> A.8 and A.9 are weird, in that they're appendices within an appendix. E= xamples are definitely informative. The XML schema should be normative; how= ever, technically, I would presume it's the schema that goes into the IANA = registry (which, of course, in the normal case, gets taken from the schema = in Appendix A of an extension document) which is normative. >>=20 >> So I guess adding a sentence in A.8/A.9 to say something like "When the = draft is produced this Appendix should be marked as normative" and "When th= e draft is produced this Appendix should be marked as informative" would wo= rk for me. >=20 > Okay, that makes sense. (As I've already submitted an -04, would it be ok= ay to hold this for -05 pending other IESG commentary, presuming there's no= thing else that needs to be done before then?) >=20 > Cheers, >=20 > Brian (author hat) >=20 From kathleen.moriarty@emc.com Wed May 9 14:20:02 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE17011E80C8 for ; Wed, 9 May 2012 14:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHmHMED9CTmP for ; Wed, 9 May 2012 14:20:02 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 459EF11E8079 for ; Wed, 9 May 2012 14:20:01 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q49LK0cr006951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2012 17:20:01 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 9 May 2012 17:19:47 -0400 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q49LJlYM006940; Wed, 9 May 2012 17:19:47 -0400 Received: from mx06a.corp.emc.com ([169.254.1.116]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Wed, 9 May 2012 17:19:46 -0400 From: To: , Date: Wed, 9 May 2012 17:19:46 -0400 Thread-Topic: [mile] Fwd: New Version Notification for draft-ietf-mile-iodef-xmlreg-01.txt Thread-Index: Ac0tzgVrZOghQXqxRheOyO7793fPYAAW067Q Message-ID: References: <20120509100741.25473.79504.idtracker@ietfa.amsl.com> <27F1310F-5A0F-496C-A7CE-9B5D19A93760@tik.ee.ethz.ch> In-Reply-To: <27F1310F-5A0F-496C-A7CE-9B5D19A93760@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Fwd: New Version Notification for draft-ietf-mile-iodef-xmlreg-01.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 21:20:03 -0000 Hello, Thank you for making the updates to the document. The comments received ap= pear to all have been addressed. This document is ready for IESG last call= . Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: Wednesday, May 09, 2012 6:25 AM To: mile@ietf.org Subject: [mile] Fwd: New Version Notification for draft-ietf-mile-iodef-xml= reg-01.txt Greetings, all, This submission of iodef-xmlreg addresses AD comments received during the W= GLC, and is ready (in my opinion as author) for the IESG. Cheers, Brian (author hat) Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ietf-mile-iodef-xmlreg-01.txt > Date: May 9, 2012 12:07:41 PM GMT+02:00 > To: trammell@tik.ee.ethz.ch >=20 > A new version of I-D, draft-ietf-mile-iodef-xmlreg-01.txt has been succes= sfully submitted by Brian Trammell and posted to the IETF repository. >=20 > Filename: draft-ietf-mile-iodef-xmlreg > Revision: 01 > Title: Expert Review for IODEF Extensions in IANA XML Registry > Creation date: 2012-05-09 > WG ID: mile > Number of pages: 3 >=20 > Abstract: > This document specifies restrictions on additions to the subset of > the IANA XML Namespace and Schema registries, to require Expert > Review for extensions to IODEF. >=20 >=20 >=20 >=20 > The IETF Secretariat _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From internet-drafts@ietf.org Thu May 10 07:17:22 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B0C21F8566; Thu, 10 May 2012 07:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.322 X-Spam-Level: X-Spam-Status: No, score=-102.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+Ut6M-2RYno; Thu, 10 May 2012 07:17:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DCE21F8565; Thu, 10 May 2012 07:17:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120510141721.31040.73724.idtracker@ietfa.amsl.com> Date: Thu, 10 May 2012 07:17:21 -0700 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-sci-04.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2012 14:17:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange= Working Group of the IETF. Title : IODEF-extension to support structured cybersecurity info= rmation Author(s) : Takeshi Takahashi Kent Landfield Thomas Millar Youki Kadobayashi Filename : draft-ietf-mile-sci-04.txt Pages : 35 Date : 2012-05-10 This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched cybersecurity information exchange among cybersecurity entities. It provides the capability of embedding structured information, such as identifier- and XML-based information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-sci-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-sci/ From takeshi_takahashi@nict.go.jp Thu May 10 07:20:24 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE6A21F862A for ; Thu, 10 May 2012 07:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qQ5eWnCR+r6 for ; Thu, 10 May 2012 07:20:24 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id A961521F8617 for ; Thu, 10 May 2012 07:20:23 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q4AEKLPN025092 for ; Thu, 10 May 2012 23:20:21 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q4AEKLvV016125 for ; Thu, 10 May 2012 23:20:21 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id q4AEKL1J016122 for ; Thu, 10 May 2012 23:20:21 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 6333A2C6FF for ; Thu, 10 May 2012 23:20:21 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 5DAFD2C31F for ; Thu, 10 May 2012 23:20:21 +0900 (JST) From: "Takeshi Takahashi" To: References: <20120510141721.31040.73724.idtracker@ietfa.amsl.com> In-Reply-To: <20120510141721.31040.73724.idtracker@ietfa.amsl.com> Date: Thu, 10 May 2012 23:20:16 +0900 Message-ID: <015801cd2eb8$05895980$109c0c80$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDRtL0KXFSgxaH+JqT1jRtV5MGdJZW4bcw Content-Language: ja Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-04.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2012 14:20:25 -0000 Hello all, I've just uploaded a revised version of the SCI draft. We have several issues here, as discussed a short while ago. 1. How to support enumeration values (identifiers) such as CVE-ID? I also agree there are needs to support these enumerations, be it either revised IODEF or its extension. In my understanding, two ways of describing the values are proposed on the list : one is using the SCI classes while the other is extending iodef:Reference class. After the discussion last week, I thought that one solution could be as follwos: o We define the extended iodef:Reference class first o Then all the SCI classes are modifled so that they becomes the extended classes of the new iodef:Reference class. The required changes to the SCI classes are not that much, IMHO (though the SCI draft needs to wait until the IODEF revision work completes). As Kathleen suggested, this issue should be discussed on the Rosella's list. Let me come there soon. 2. How to reference cybersecurity specifications? I moved the list of specifications to the appendix III, and the main body defines only the structure of the IANA table. If that is allowed, all the references could be moved from normative to informative reference section. I have found old sentences in the 03 version, which I believe caused some confusion to the readers. I apologize for that. I know the draft still has more issues, but the above two are the biggest and bottleneck issues, so I am hoping to get feedback from this community so that we could move forward. Kind Regards, Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Thursday, May 10, 2012 11:17 PM > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-sci-04.txt > > > 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 : IODEF-extension to support structured > cybersecurity information > Author(s) : Takeshi Takahashi > Kent Landfield > Thomas Millar > Youki Kadobayashi > Filename : draft-ietf-mile-sci-04.txt > Pages : 35 > Date : 2012-05-10 > > This document extends the Incident Object Description Exchange Format > (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched > cybersecurity information exchange among cybersecurity entities. It > provides the capability of embedding structured information, such as > identifier- and XML-based information. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-sci-04.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-mile-sci/ > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Tue May 15 10:26:30 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515FE21F894E for ; Tue, 15 May 2012 10:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.536 X-Spam-Level: X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvD+j7rbUy8s for ; Tue, 15 May 2012 10:26:29 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6754B21F884A for ; Tue, 15 May 2012 10:26:29 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q4FHQRfM018783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 May 2012 13:26:28 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 15 May 2012 13:26:11 -0400 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q4FHQA5u032682; Tue, 15 May 2012 13:26:10 -0400 Received: from mx06a.corp.emc.com ([169.254.1.116]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Tue, 15 May 2012 13:25:12 -0400 From: To: , , Date: Tue, 15 May 2012 13:26:09 -0400 Thread-Topic: XMPP incident reporting extension Thread-Index: Ac0yt0hLky1piYLbSwC8SfWqEGnRVQABjUsQAABDvuA= Message-ID: References: <5EA5E378841F7043B9815EE1E6FAAB8F03B44271@hive.bronze.us-cert.gov> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org, stpeter@stpeter.im Subject: Re: [mile] XMPP incident reporting extension X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 17:26:30 -0000 I should have noted that their intent was to cover incidents relevant to XM= PP only, so it may be the operators/administrators of XMPP that would be th= e users (if they are actively using it). Similar to the MARF effort that i= s specific to mail abuse between mail operators. A formal binding that lets= us map between these efforts could be helpful. For MARF, there was a prop= osed MARF extension to IODEF to fill that gap, but was just proposed. Peter's IETF role: Peter Saint-Andre is currently co-director of the IETF A= pplications Area and also has served as Executive Director of the XMPP Stan= dards Foundation since 2002. Best regards, Kathleen -----Original Message----- From: idxwg-owner@nicwg.org [mailto:idxwg-owner@nicwg.org] On Behalf Of kat= hleen.moriarty@emc.com Sent: Tuesday, May 15, 2012 1:12 PM To: Thomas.Millar@us-cert.gov; idxwg@nicwg.org Subject: Re: XMPP incident reporting extension=20 This was recently implemented as you noted. Peter St. Andre was the cataly= st to make this happen, he is an AD in the IETF. He reached out after they= announced it for me to take a look from a MILE perspective (IODEF/RID, etc= .). Pretty cool! Best regards, Kathleen -----Original Message----- From: idxwg-owner@nicwg.org [mailto:idxwg-owner@nicwg.org] On Behalf Of Tho= mas.Millar@us-cert.gov Sent: Tuesday, May 15, 2012 12:25 PM To: idxwg@nicwg.org Subject: XMPP incident reporting extension=20 Just got updated to use IODEF last month! Contains its own tiny version of = RID, too, kinda. http://xmpp.org/extensions/xep-0268.html How widespread is XMPP server-to-server incident reporting/notification? Pe= ople actually do this? =A0- Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 From stpeter@stpeter.im Wed May 16 09:41:05 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386A321F8665 for ; Wed, 16 May 2012 09:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjnZoIDGXAvi for ; Wed, 16 May 2012 09:41:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 43F7621F8669 for ; Wed, 16 May 2012 09:41:00 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1CDBF4005A; Wed, 16 May 2012 10:56:44 -0600 (MDT) Message-ID: <4FB3D89B.3070806@stpeter.im> Date: Wed, 16 May 2012 10:40:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: kathleen.moriarty@emc.com References: <5EA5E378841F7043B9815EE1E6FAAB8F03B44271@hive.bronze.us-cert.gov> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: idxwg@nicwg.org, mile@ietf.org Subject: Re: [mile] XMPP incident reporting extension X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 16:41:05 -0000 On 5/15/12 11:26 AM, kathleen.moriarty@emc.com wrote: > I should have noted that their intent was to cover incidents relevant > to XMPP only, so it may be the operators/administrators of XMPP that > would be the users (if they are actively using it). It's not actively in use yet. I need to clean up the spec some more and then write some code or convince others to do so. However, there is definitely interest in implementing and deploying it among developers of XMPP server software and operators of XMPP services. > Similar to the > MARF effort that is specific to mail abuse between mail operators. A > formal binding that lets us map between these efforts could be > helpful. For MARF, there was a proposed MARF extension to IODEF to > fill that gap, but was just proposed. >From what I understand of the MARF extension, that sounds correct. In particular, we're not defining an XMPP transport binding for IODEF or RID, just a use of IODEF (with, as Tom noted, some RID-like semantics) for the XMPP network. > Peter's IETF role: Peter Saint-Andre is currently co-director of the > IETF Applications Area and also has served as Executive Director of > the XMPP Standards Foundation since 2002. Actually my IESG term ended at IETF 83, so now I'm just a regular IETF contributor again. :) Thanks for your interest! Peter > -----Original Message----- From: idxwg-owner@nicwg.org > [mailto:idxwg-owner@nicwg.org] On Behalf Of > kathleen.moriarty@emc.com Sent: Tuesday, May 15, 2012 1:12 PM To: > Thomas.Millar@us-cert.gov; idxwg@nicwg.org Subject: Re: XMPP incident > reporting extension > > This was recently implemented as you noted. Peter St. Andre was the > catalyst to make this happen, he is an AD in the IETF. He reached > out after they announced it for me to take a look from a MILE > perspective (IODEF/RID, etc.). Pretty cool! > > Best regards, Kathleen > > -----Original Message----- From: idxwg-owner@nicwg.org > [mailto:idxwg-owner@nicwg.org] On Behalf Of > Thomas.Millar@us-cert.gov Sent: Tuesday, May 15, 2012 12:25 PM To: > idxwg@nicwg.org Subject: XMPP incident reporting extension > > Just got updated to use IODEF last month! Contains its own tiny > version of RID, too, kinda. > > http://xmpp.org/extensions/xep-0268.html > > How widespread is XMPP server-to-server incident > reporting/notification? People actually do this? > > - Tom Millar, US-CERT > > thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 > 24x7: soc@us-cert.gov / 888-282-0870 From stpeter@stpeter.im Wed May 16 10:00:02 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD58821F86F7 for ; Wed, 16 May 2012 10:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16J+rOK7x-26 for ; Wed, 16 May 2012 10:00:01 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C9B1521F850B for ; Wed, 16 May 2012 10:00:01 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 302F34005A; Wed, 16 May 2012 11:15:45 -0600 (MDT) Message-ID: <4FB3DD10.6030706@stpeter.im> Date: Wed, 16 May 2012 11:00:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: kathleen.moriarty@emc.com References: <5EA5E378841F7043B9815EE1E6FAAB8F03B44271@hive.bronze.us-cert.gov> <4FB3D89B.3070806@stpeter.im> In-Reply-To: <4FB3D89B.3070806@stpeter.im> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: idxwg@nicwg.org, mile@ietf.org Subject: Re: [mile] XMPP incident reporting extension X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 17:00:02 -0000 A follow-up about RID... On 5/16/12 10:40 AM, Peter Saint-Andre wrote: > On 5/15/12 11:26 AM, kathleen.moriarty@emc.com wrote: > >> Similar to the >> MARF effort that is specific to mail abuse between mail operators. A >> formal binding that lets us map between these efforts could be >> helpful. For MARF, there was a proposed MARF extension to IODEF to >> fill that gap, but was just proposed. > > From what I understand of the MARF extension, that sounds correct. In > particular, we're not defining an XMPP transport binding for IODEF or > RID, just a use of IODEF (with, as Tom noted, some RID-like semantics) > for the XMPP network. If there's wider interest in an XMPP transport binding for IODEF/RID, then I could put some work into defining it. Currently we have a need on the XMPP network for communication among XMPP servers about incidents on the XMPP network, which is where XEP-0268 came from. I only recently changed the payload format to use IODEF. When doing that, I realized that some RID-like semantics would also be useful, but some of those mapped quite closely to the existing semantics of the XMPP "IQ" stanza type from RFC 6120, so it seemed sensible to just use XMPP primitives for our limited use case. Naturally, if an XMPP server is being used as a front end for reporting of more generalized incidents then we'll want to revisit some of the decisions I made when working on version 0.4 of XEP-0268. Peter -- Peter Saint-Andre https://stpeter.im/ From iesg-secretary@ietf.org Wed May 16 14:52:52 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B86321F8776; Wed, 16 May 2012 14:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq3ZNkRUwq+S; Wed, 16 May 2012 14:52:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0345421F875E; Wed, 16 May 2012 14:52:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120516215252.9444.43972.idtracker@ietfa.amsl.com> Date: Wed, 16 May 2012 14:52:52 -0700 Cc: mile@ietf.org Subject: [mile] Last Call: (Expert Review for IODEF Extensions in IANA XML Registry) to Proposed Standard X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.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: Wed, 16 May 2012 21:52:52 -0000 The IESG has received a request from the Managed Incident Lightweight Exchange WG (mile) to consider the following document: - 'Expert Review for IODEF Extensions in IANA XML Registry' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-05-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to IODEF. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-xmlreg/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-xmlreg/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Wed May 16 14:53:22 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706F221F87CD; Wed, 16 May 2012 14:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k79MZMuQL3w5; Wed, 16 May 2012 14:53:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AA321F879D; Wed, 16 May 2012 14:53:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120516215321.9671.39664.idtracker@ietfa.amsl.com> Date: Wed, 16 May 2012 14:53:21 -0700 Cc: mile@ietf.org Subject: [mile] Last Call: (Guidelines for Defining Extensions to IODEF) to Informational RFC X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.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: Wed, 16 May 2012 21:53:23 -0000 The IESG has received a request from the Managed Incident Lightweight Exchange WG (mile) to consider the following document: - 'Guidelines for Defining Extensions to IODEF' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-05-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides guidelines for extensions to IODEF [RFC5070] for exchange of incident management data, and contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mile-template/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mile-template/ballot/ No IPR declarations have been submitted directly on this I-D. From stpeter@stpeter.im Wed May 16 20:25:33 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787EC11E809F; Wed, 16 May 2012 20:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi41x+TK7DaX; Wed, 16 May 2012 20:25:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2837111E809C; Wed, 16 May 2012 20:25:31 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C63A24005A; Wed, 16 May 2012 21:41:15 -0600 (MDT) Message-ID: <4FB46FA6.6060005@stpeter.im> Date: Wed, 16 May 2012 21:25:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: ietf@ietf.org References: <20120516215321.9671.39664.idtracker@ietfa.amsl.com> In-Reply-To: <20120516215321.9671.39664.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: mile@ietf.org, The IESG Subject: Re: [mile] Last Call: (Guidelines for Defining Extensions to IODEF) to Informational RFC X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2012 03:25:33 -0000 On 5/16/12 3:53 PM, The IESG wrote: > > The IESG has received a request from the Managed Incident Lightweight > Exchange WG (mile) to consider the following document: > - 'Guidelines for Defining Extensions to IODEF' > as Informational RFC Although this document does no harm, I have my doubts that the topic warrants publication of an RFC (and I say that as someone who is defining some IODEF extensions for use on the XMPP network [1]). Why would a simple wiki page [2] not suffice? If we decide than an RFC is needed, I have some more actionable feedback... 1. The document could be construed as assuming that IODEF extensions will all be defined in Internet-Drafts, that extension namespaces will be registered with IANA, and even that namespaces will be of the form 'urn:ietf:params:xml:schema:iodef-*'. It might be helpful to clarify the intended applicability of this document, i.e., merely as helpful suggestions for authors of Internet-Drafts, not truly as universally applicable guidelines for defining IODEF extensions. 2. Why is RFC 6545 a normative reference? 3. Given the many comments provided by Martin Dürst, mentioning his AppsDir review in the Acknowledgements seems appropriate. 4. Some of the text in the appendix seems needlessly detailed (e.g., saying that each extension needs to be specified in a subsection, or the recommendation to include a UML diagram). 5. Why is the list of datatypes in appendix A.4.1 copied from RFC 5070? A simple reference would do. (I almost said the same about the list in Section 3, but that one is marginally useful.) 6. Some of the information in this document repeats information from the RFC style guide and other sources; why? Peter [1] http://xmpp.org/extensions/xep-0268.html [2] http://trac.tools.ietf.org/wg/mile/trac/wiki From turners@ieca.com Thu May 17 04:15:52 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF71621F86AD for ; Thu, 17 May 2012 04:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrIxR0D28eBt for ; Thu, 17 May 2012 04:15:52 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.170.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA1E21F864D for ; Thu, 17 May 2012 04:15:52 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id CA51C675893A0; Thu, 17 May 2012 06:15:51 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id BF99F67589367 for ; Thu, 17 May 2012 06:15:51 -0500 (CDT) Received: from [71.191.10.205] (port=37974 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SUygR-0004gf-Bo; Thu, 17 May 2012 06:15:51 -0500 Message-ID: <4FB4DDE6.7060906@ieca.com> Date: Thu, 17 May 2012 07:15:50 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: S Moonesamy References: <20120516215321.9671.39664.idtracker@ietfa.amsl.com> <4FB46FA6.6060005@stpeter.im> <6.2.5.6.2.20120516203822.0add38b8@resistor.net> In-Reply-To: <6.2.5.6.2.20120516203822.0add38b8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-71-191-10-205.washdc.east.verizon.net (thunderfish.local) [71.191.10.205]:37974 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: mile@ietf.org, appsdir@ietf.org Subject: Re: [mile] Last Call: (Guidelines for Defining Extensions to IODEF) to Informational RFC X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2012 11:15:52 -0000 On 5/17/12 12:17 AM, S Moonesamy wrote: > Hi Sean, > At 20:25 16-05-2012, Peter Saint-Andre wrote: >> 3. Given the many comments provided by Martin Dürst, mentioning his >> AppsDir review in the Acknowledgements seems appropriate. > > I read Martin's review of draft-ietf-mile-template-02. It was a thorough > review with recommendations on how to improve the draft. SM, Could you forward me the review. I don't seem to have it and I can't find it in the appsdir archive. Thanks, spt From sm@elandsys.com Wed May 16 21:18:38 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FD911E808E; Wed, 16 May 2012 21:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNU1IszSMahU; Wed, 16 May 2012 21:18:37 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3F311E8089; Wed, 16 May 2012 21:18:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.236.87]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4H4IK2U007296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 May 2012 21:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1337228314; i=@elandsys.com; bh=KFqm3RcAoeduRdIQOhDFvkgdWTxZEAgyjB5V/0X7ymA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kE+G+fPvTF4nwNoq2KiK049brNqTgHOMdyFWVDYMXID7lTCaCj5BDtvxNyotB0htP XOKxPuNnWoYaUyfIKUHagzSlqY70PdPmSLToaJgzZW9o/Kn+Gb9BEKIqCQVMkdT1xR RkUbQcfS0FSd4PRfODYer1iR5bLWsJWnbAGnMHaA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1337228314; i=@elandsys.com; bh=KFqm3RcAoeduRdIQOhDFvkgdWTxZEAgyjB5V/0X7ymA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=zHitrwl3lCz+6O3n1bwZ5sEEbTMl9XPcsnDPUVRQzyYGKN/4bmZjIX+bNG+3Eqj24 vPL5zasNk6xlvv6X3cb/im8qA9ejp7XHLJZwESN4T6dYfcvRYq9raAcQHxbmeR7b0c HiuDXOhQPcFEoLW5kmC3QpqLJFG7/Pj0S0wdlEPk= Message-Id: <6.2.5.6.2.20120516203822.0add38b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 16 May 2012 21:17:51 -0700 To: Sean Turner From: S Moonesamy In-Reply-To: <4FB46FA6.6060005@stpeter.im> References: <20120516215321.9671.39664.idtracker@ietfa.amsl.com> <4FB46FA6.6060005@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 17 May 2012 07:32:57 -0700 Cc: mile@ietf.org, appsdir@ietf.org Subject: Re: [mile] Last Call: (Guidelines for Defining Extensions to IODEF) to Informational RFC X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2012 04:18:38 -0000 Hi Sean, At 20:25 16-05-2012, Peter Saint-Andre wrote: >3. Given the many comments provided by Martin D=FCrst, mentioning his >AppsDir review in the Acknowledgements seems appropriate. I read Martin's review of=20 draft-ietf-mile-template-02. It was a thorough=20 review with recommendations on how to improve the draft. Regards, S. Moonesamy=20 From stpeter@stpeter.im Thu May 17 09:24:25 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BEA21F862B; Thu, 17 May 2012 09:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siohKS-3dYcc; Thu, 17 May 2012 09:24:24 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 96F0E21F85E3; Thu, 17 May 2012 09:24:20 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 21BC14005A; Thu, 17 May 2012 10:40:06 -0600 (MDT) Message-ID: <4FB52632.4060009@stpeter.im> Date: Thu, 17 May 2012 10:24:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sean Turner References: <20120516215321.9671.39664.idtracker@ietfa.amsl.com> <4FB46FA6.6060005@stpeter.im> <6.2.5.6.2.20120516203822.0add38b8@resistor.net> <4FB4DDE6.7060906@ieca.com> In-Reply-To: <4FB4DDE6.7060906@ieca.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: mile@ietf.org, appsdir@ietf.org, S Moonesamy Subject: Re: [mile] [appsdir] Last Call: (Guidelines for Defining Extensions to IODEF) to Informational RFC X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2012 16:24:26 -0000 On 5/17/12 5:15 AM, Sean Turner wrote: > On 5/17/12 12:17 AM, S Moonesamy wrote: >> Hi Sean, >> At 20:25 16-05-2012, Peter Saint-Andre wrote: >>> 3. Given the many comments provided by Martin Dürst, mentioning his >>> AppsDir review in the Acknowledgements seems appropriate. >> >> I read Martin's review of draft-ietf-mile-template-02. It was a thorough >> review with recommendations on how to improve the draft. > > SM, > > Could you forward me the review. I don't seem to have it and I can't > find it in the appsdir archive. That's because it was sent to the apps-discuss list before we established the appsdir list: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04377.html Brian Trammel's reply is here: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04399.html Sorry about the confusion! Peter -- Peter Saint-Andre https://stpeter.im/ From trammell@tik.ee.ethz.ch Fri May 18 05:13:27 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A74B21F858D; Fri, 18 May 2012 05:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2nkSDvtvlXN; Fri, 18 May 2012 05:13:26 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9009521F857F; Fri, 18 May 2012 05:13:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id F37D7D930A; Fri, 18 May 2012 14:13:25 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0p+YUr-N73VR; Fri, 18 May 2012 14:13:25 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id BE77ED9304; Fri, 18 May 2012 14:13:25 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4FB46FA6.6060005@stpeter.im> Date: Fri, 18 May 2012 14:13:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120516215321.9671.39664.idtracker@ietfa.amsl.com> <4FB46FA6.6060005@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1278) Cc: mile@ietf.org, The IESG , ietf@ietf.org Subject: Re: [mile] Last Call: (Guidelines for Defining Extensions to IODEF) to Informational RFC X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 18 May 2012 12:13:27 -0000 Hi, Peter, all, Many thanks for the comments; replies inline... On May 17, 2012, at 5:25 AM, Peter Saint-Andre wrote: > On 5/16/12 3:53 PM, The IESG wrote: >>=20 >> The IESG has received a request from the Managed Incident Lightweight >> Exchange WG (mile) to consider the following document: >> - 'Guidelines for Defining Extensions to IODEF' >> as Informational RFC >=20 > Although this document does no harm, I have my doubts that the topic > warrants publication of an RFC (and I say that as someone who is > defining some IODEF extensions for use on the XMPP network [1]). Why > would a simple wiki page [2] not suffice? Indeed, it may; the WG decided we wanted something semi-permanent to = give guidance to extension authors, especially given that we anticipated = (and have had) significant participation from people with little or no = previous involvement in the IETF. Whether that's an RFC or not is, but = an RFC seemed the natural thing to do, as it is how things are published = out of IETF WGs. The previous version of this document _did_ need to be an RFC as it = specified a change to the IANA XML registry requiring a Standards = Action; this has been split out into draft-ietf-mile-iodef-xmlreg per AD = guidance. > If we decide than an RFC is needed, I have some more actionable = feedback... >=20 > 1. The document could be construed as assuming that IODEF extensions > will all be defined in Internet-Drafts, that extension namespaces will > be registered with IANA, and even that namespaces will be of the form > 'urn:ietf:params:xml:schema:iodef-*'. It might be helpful to clarify = the > intended applicability of this document, i.e., merely as helpful > suggestions for authors of Internet-Drafts, not truly as universally > applicable guidelines for defining IODEF extensions. Hm. The document does indeed assume that extensions to IODEF are defined = in Internet-Drafts, that extension namespaces will be registered with = IANA, and that those namespaces be of the described form; it makes these = assumptions because that is the intent of the document. Whether that's = "universal" or not could be an open question, perhaps, but the intent is = to specify a more restrictive method of extension than that in 5070 in = the interests of consistency. So, yes, it's an informational document, = they're just helpful suggestions, but we would hope they'd be followed, = and the document is written assuming that they will... > 2. Why is RFC 6545 a normative reference? Oversight, should be informative (I checked this briefly; it is = referenced from a section entitled "Terminology", but this is = terminology in the Appendix; oops.) > 3. Given the many comments provided by Martin D=FCrst, mentioning his > AppsDir review in the Acknowledgements seems appropriate. Indeed, also oversight; thanks. > 4. Some of the text in the appendix seems needlessly detailed (e.g., > saying that each extension needs to be specified in a subsection, or = the > recommendation to include a UML diagram). These guidelines are intended to help the set of drafts defining IODEF = extensions to be consistent with RFC 5070 and with each other. > 5. Why is the list of datatypes in appendix A.4.1 copied from RFC = 5070? > A simple reference would do. (I almost said the same about the list in > Section 3, but that one is marginally useful.) The A.4.1. list was copied over because doing so was consistent with the = list in Section 3, more or less; it's intended to give an inline = definition of the allowable TYPE values as in the UML diagram in Figure = 1, section A.4. (Copying this was also consistent with the inclusion of = the list in Section 3.) > 6. Some of the information in this document repeats information from = the > RFC style guide and other sources; why? Here we have a duelling-commenters situation; this is per early-AD = commentary in = http://www.ietf.org/mail-archive/web/mile/current/msg00657.html and the = subsequent thread. Best regards, Brian (as author, draft-ietf-mile-template) From diego@tid.es Sat May 19 16:07:44 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80E111E8096 for ; Sat, 19 May 2012 16:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGS1-NOQdntb for ; Sat, 19 May 2012 16:07:43 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6059E11E8079 for ; Sat, 19 May 2012 16:07:43 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M4A00JSULKTUN@tid.hi.inet> for mile@ietf.org; Sun, 20 May 2012 01:07:41 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 3E.A6.19676.BB728BF4; Sun, 20 May 2012 01:07:39 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M4A00JSILKRUN@tid.hi.inet> for mile@ietf.org; Sun, 20 May 2012 01:07:39 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0298.004; Sun, 20 May 2012 01:07:39 +0200 Date: Sat, 19 May 2012 23:07:38 +0000 From: "Diego R. Lopez" In-reply-to: <4FB3DD10.6030706@stpeter.im> X-Originating-IP: [10.95.64.115] To: Peter Saint-Andre Message-id: <529518EF-0ECE-4D21-8820-FE7E96444792@tid.es> Content-id: <5EC1699FAC984F41B7D729CC5DE62A6E@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: [mile] XMPP incident reporting extension Thread-index: AQHNM4KyciXFlsqheUu+mrj7FWIkCZbMghsAgASWNwA= X-AuditID: 0a5f4e69-b7fe06d000004cdc-c9-4fb827bb9755 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsXCFe9nqLtHfYe/we+lehZ7/vcxOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+WZ26wF9yQq7ny6xtrA2CPRxcjJISFgIrF/91xGCFtM4sK9 9WxdjFwcQgLbGSX2dtxnhXB+MEp0LZoMlVnKKHHy72ymLkYODhYBVYnrPXog3WxA5qPm3+wg trCAqcTtv09YQWxOAS2Jpm9z2CA2KEj8OfeYBcQWAYpfutbHDjKTWaCTUaJvxWc2kJm8ApYS ux9xgdQwC5hJ/Fi/EqyXV0BQ4sfkeywgJcwC6hJTpuRClIhLNLfeZIGwFSWmLWoAe4ZRQFZi 5fnTjBCrzCR+bXrHCmFbSRy+8x3qYQGJJXvOM0PYohIvH/+D+ncCk8TF7jcsExglZiE5YxaS M2YhnDELyRmzkJyxgJF1FaNYcVJRZnpGSW5iZk66gZFeRqZeZl5qySZGSNRl7mBcvlPlEKMA B6MSD6/m1G3+QqyJZcWVuYcYJTmYlER51VV3+AvxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4WWQ A8rxpiRWVqUW5cOkZDg4lCR4eYAJQkiwKDU9tSItMweYWmDSTBycIO08QO3f1EDaiwsSc4sz 0yHypxglpcR5P4MkBEASGaV5cL2vGMWBjhTm/QeS5QEmQbiuV0ADmYAGVrJtAxlYkoiQkmpg LG7yEhL7+8ZI9dN9gZz7TxdWPhVSvaE2x8D/Sli6XeXMLOOPR01eFilK9lx1mWbdeq/Scm3V lHv73bMWvOzfspM1kNt7vUSqmfLsxjCOU6vLJabdlFnJc6XlRU5txrvC/JLGuOV94f7qnnKX P3k+OpktdPDk5B9vz5cuC37BLsfAyvNNqVROiaU4I9FQi7moOBEASaiO/T8DAAA= References: <5EA5E378841F7043B9815EE1E6FAAB8F03B44271@hive.bronze.us-cert.gov> <4FB3D89B.3070806@stpeter.im> <4FB3DD10.6030706@stpeter.im> Cc: "" , "" Subject: Re: [mile] XMPP incident reporting extension X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 19 May 2012 23:07:44 -0000 SGksDQoNCk9uIDE2IE1heSAyMDEyLCBhdCAxOTowMCAsIFBldGVyIFNhaW50LUFuZHJlIHdyb3Rl Og0KDQo+IEEgZm9sbG93LXVwIGFib3V0IFJJRC4uLg0KPg0KPiBPbiA1LzE2LzEyIDEwOjQwIEFN LCBQZXRlciBTYWludC1BbmRyZSB3cm90ZToNCj4+IE9uIDUvMTUvMTIgMTE6MjYgQU0sIGthdGhs ZWVuLm1vcmlhcnR5QGVtYy5jb20gd3JvdGU6DQo+Pg0KPj4+IFNpbWlsYXIgdG8gdGhlDQo+Pj4g TUFSRiBlZmZvcnQgdGhhdCBpcyBzcGVjaWZpYyB0byBtYWlsIGFidXNlIGJldHdlZW4gbWFpbCBv cGVyYXRvcnMuIEENCj4+PiBmb3JtYWwgYmluZGluZyB0aGF0IGxldHMgdXMgbWFwIGJldHdlZW4g dGhlc2UgZWZmb3J0cyBjb3VsZCBiZQ0KPj4+IGhlbHBmdWwuICBGb3IgTUFSRiwgdGhlcmUgd2Fz IGEgcHJvcG9zZWQgTUFSRiBleHRlbnNpb24gdG8gSU9ERUYgdG8NCj4+PiBmaWxsIHRoYXQgZ2Fw LCBidXQgd2FzIGp1c3QgcHJvcG9zZWQuDQo+Pg0KPj4gRnJvbSB3aGF0IEkgdW5kZXJzdGFuZCBv ZiB0aGUgTUFSRiBleHRlbnNpb24sIHRoYXQgc291bmRzIGNvcnJlY3QuIEluDQo+PiBwYXJ0aWN1 bGFyLCB3ZSdyZSBub3QgZGVmaW5pbmcgYW4gWE1QUCB0cmFuc3BvcnQgYmluZGluZyBmb3IgSU9E RUYgb3INCj4+IFJJRCwganVzdCBhIHVzZSBvZiBJT0RFRiAod2l0aCwgYXMgVG9tIG5vdGVkLCBz b21lIFJJRC1saWtlIHNlbWFudGljcykNCj4+IGZvciB0aGUgWE1QUCBuZXR3b3JrLg0KPg0KPiBJ ZiB0aGVyZSdzIHdpZGVyIGludGVyZXN0IGluIGFuIFhNUFAgdHJhbnNwb3J0IGJpbmRpbmcgZm9y IElPREVGL1JJRCwNCj4gdGhlbiBJIGNvdWxkIHB1dCBzb21lIHdvcmsgaW50byBkZWZpbmluZyBp dC4gQ3VycmVudGx5IHdlIGhhdmUgYSBuZWVkIG9uDQo+IHRoZSBYTVBQIG5ldHdvcmsgZm9yIGNv bW11bmljYXRpb24gYW1vbmcgWE1QUCBzZXJ2ZXJzIGFib3V0IGluY2lkZW50cyBvbg0KPiB0aGUg WE1QUCBuZXR3b3JrLCB3aGljaCBpcyB3aGVyZSBYRVAtMDI2OCBjYW1lIGZyb20uIEkgb25seSBy ZWNlbnRseQ0KPiBjaGFuZ2VkIHRoZSBwYXlsb2FkIGZvcm1hdCB0byB1c2UgSU9ERUYuIFdoZW4g ZG9pbmcgdGhhdCwgSSByZWFsaXplZA0KPiB0aGF0IHNvbWUgUklELWxpa2Ugc2VtYW50aWNzIHdv dWxkIGFsc28gYmUgdXNlZnVsLCBidXQgc29tZSBvZiB0aG9zZQ0KPiBtYXBwZWQgcXVpdGUgY2xv c2VseSB0byB0aGUgZXhpc3Rpbmcgc2VtYW50aWNzIG9mIHRoZSBYTVBQICJJUSIgc3RhbnphDQo+ IHR5cGUgZnJvbSBSRkMgNjEyMCwgc28gaXQgc2VlbWVkIHNlbnNpYmxlIHRvIGp1c3QgdXNlIFhN UFAgcHJpbWl0aXZlcw0KPiBmb3Igb3VyIGxpbWl0ZWQgdXNlIGNhc2UuIE5hdHVyYWxseSwgaWYg YW4gWE1QUCBzZXJ2ZXIgaXMgYmVpbmcgdXNlZCBhcw0KPiBhIGZyb250IGVuZCBmb3IgcmVwb3J0 aW5nIG9mIG1vcmUgZ2VuZXJhbGl6ZWQgaW5jaWRlbnRzIHRoZW4gd2UnbGwgd2FudA0KPiB0byBy ZXZpc2l0IHNvbWUgb2YgdGhlIGRlY2lzaW9ucyBJIG1hZGUgd2hlbiB3b3JraW5nIG9uIHZlcnNp b24gMC40IG9mDQo+IFhFUC0wMjY4Lg0KDQoNCldlIGhhdmUgYSBwcm9qZWN0IHByb3Bvc2FsIGlu IHdoaWNoIHN1Y2ggYSB0cmFuc3BvcnQgYmluZGluZyB3b3VsZA0KYmUgZXh0cmVtZWx5IGludGVy ZXN0aW5nLg0KDQpIb3BlIHRoaXMgd2lkZW5zIGludGVyZXN0Lg0KDQotLQ0KIkVzdGEgdmV6IG5v IGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVm b25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBk aWVnb0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUx IDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4 Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBw b2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVu IGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQg ZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBl bWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQuDQpodHRwOi8vd3d3LnRp ZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From stpeter@stpeter.im Mon May 21 08:06:25 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8379121F8674 for ; Mon, 21 May 2012 08:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lS8FoybeOxE4 for ; Mon, 21 May 2012 08:06:24 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DEF2321F8673 for ; Mon, 21 May 2012 08:06:24 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6891540067; Mon, 21 May 2012 09:22:23 -0600 (MDT) Message-ID: <4FBA59F0.6010501@stpeter.im> Date: Mon, 21 May 2012 09:06:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Diego R. Lopez" References: <5EA5E378841F7043B9815EE1E6FAAB8F03B44271@hive.bronze.us-cert.gov> <4FB3D89B.3070806@stpeter.im> <4FB3DD10.6030706@stpeter.im> <529518EF-0ECE-4D21-8820-FE7E96444792@tid.es> In-Reply-To: <529518EF-0ECE-4D21-8820-FE7E96444792@tid.es> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" , "" Subject: Re: [mile] XMPP incident reporting extension X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2012 15:06:25 -0000 On 5/19/12 5:07 PM, Diego R. Lopez wrote: > Hi, > > On 16 May 2012, at 19:00 , Peter Saint-Andre wrote: > >> A follow-up about RID... >> >> On 5/16/12 10:40 AM, Peter Saint-Andre wrote: >>> On 5/15/12 11:26 AM, kathleen.moriarty@emc.com wrote: >>> >>>> Similar to the >>>> MARF effort that is specific to mail abuse between mail operators. A >>>> formal binding that lets us map between these efforts could be >>>> helpful. For MARF, there was a proposed MARF extension to IODEF to >>>> fill that gap, but was just proposed. >>> >>> From what I understand of the MARF extension, that sounds correct. In >>> particular, we're not defining an XMPP transport binding for IODEF or >>> RID, just a use of IODEF (with, as Tom noted, some RID-like semantics) >>> for the XMPP network. >> >> If there's wider interest in an XMPP transport binding for IODEF/RID, >> then I could put some work into defining it. Currently we have a need on >> the XMPP network for communication among XMPP servers about incidents on >> the XMPP network, which is where XEP-0268 came from. I only recently >> changed the payload format to use IODEF. When doing that, I realized >> that some RID-like semantics would also be useful, but some of those >> mapped quite closely to the existing semantics of the XMPP "IQ" stanza >> type from RFC 6120, so it seemed sensible to just use XMPP primitives >> for our limited use case. Naturally, if an XMPP server is being used as >> a front end for reporting of more generalized incidents then we'll want >> to revisit some of the decisions I made when working on version 0.4 of >> XEP-0268. > > > We have a project proposal in which such a transport binding would > be extremely interesting. > > Hope this widens interest. Thanks for the expression of interest. I'll give some further thought to working on that binding. It should be pretty straightforward... Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon May 21 08:16:44 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C02121F867A; Mon, 21 May 2012 08:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h6B9Xn9RDok; Mon, 21 May 2012 08:16:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1A23F21F8679; Mon, 21 May 2012 08:16:43 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F1FD540067; Mon, 21 May 2012 09:32:41 -0600 (MDT) Message-ID: <4FBA5C59.4030102@stpeter.im> Date: Mon, 21 May 2012 09:16:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian Trammell References: <20120516215321.9671.39664.idtracker@ietfa.amsl.com> <4FB46FA6.6060005@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: mile@ietf.org, The IESG , ietf@ietf.org Subject: Re: [mile] Last Call: (Guidelines for Defining Extensions to IODEF) to Informational RFC X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2012 15:16:44 -0000 On 5/18/12 6:13 AM, Brian Trammell wrote: > Hi, Peter, all, > > Many thanks for the comments; And to you for following up. > replies inline... Likewise. > On May 17, 2012, at 5:25 AM, Peter Saint-Andre wrote: > >> On 5/16/12 3:53 PM, The IESG wrote: >>> >>> The IESG has received a request from the Managed Incident >>> Lightweight Exchange WG (mile) to consider the following >>> document: - 'Guidelines for Defining Extensions to IODEF' >>> as Informational RFC >> >> Although this document does no harm, I have my doubts that the >> topic warrants publication of an RFC (and I say that as someone who >> is defining some IODEF extensions for use on the XMPP network [1]). >> Why would a simple wiki page [2] not suffice? > > Indeed, it may; the WG decided we wanted something semi-permanent to > give guidance to extension authors, especially given that we > anticipated (and have had) significant participation from people with > little or no previous involvement in the IETF. Whether that's an RFC > or not is, but an RFC seemed the natural thing to do, as it is how > things are published out of IETF WGs. > > The previous version of this document _did_ need to be an RFC as it > specified a change to the IANA XML registry requiring a Standards > Action; this has been split out into draft-ietf-mile-iodef-xmlreg per > AD guidance. Thanks for the clarifications. I chatted about this I-D offlist with Sean Turner and he explained that a bunch of folks who are not familiar with the IETF might be coming here to define IODEF extensions, so I now think that an Informational RFC could be useful. >> If we decide than an RFC is needed, I have some more actionable >> feedback... >> >> 1. The document could be construed as assuming that IODEF >> extensions will all be defined in Internet-Drafts, that extension >> namespaces will be registered with IANA, and even that namespaces >> will be of the form 'urn:ietf:params:xml:schema:iodef-*'. It might >> be helpful to clarify the intended applicability of this document, >> i.e., merely as helpful suggestions for authors of Internet-Drafts, >> not truly as universally applicable guidelines for defining IODEF >> extensions. > > Hm. The document does indeed assume that extensions to IODEF are > defined in Internet-Drafts, that extension namespaces will be > registered with IANA, and that those namespaces be of the described > form; it makes these assumptions because that is the intent of the > document. Whether that's "universal" or not could be an open > question, perhaps, but the intent is to specify a more restrictive > method of extension than that in 5070 in the interests of > consistency. So, yes, it's an informational document, they're just > helpful suggestions, but we would hope they'd be followed, and the > document is written assuming that they will... As mentioned, I happen to be working on some IODEF extensions that are specific to the XMPP community. Is it expected that I work on the relevant spec in the MILE WG, in the XMPP WG, or (as I'm doing right now) at the XMPP Standards Foundation? IMHO, doing this work at the XSF makes the most sense because that's where most of the XMPP developers and operators are active. Seeking a sanity check on this work from the MILE WG does seem reasonable, though (once it's ready for review). >> 2. Why is RFC 6545 a normative reference? > > Oversight, should be informative (I checked this briefly; it is > referenced from a section entitled "Terminology", but this is > terminology in the Appendix; oops.) > >> 3. Given the many comments provided by Martin Dürst, mentioning >> his AppsDir review in the Acknowledgements seems appropriate. > > Indeed, also oversight; thanks. > >> 4. Some of the text in the appendix seems needlessly detailed >> (e.g., saying that each extension needs to be specified in a >> subsection, or the recommendation to include a UML diagram). > > These guidelines are intended to help the set of drafts defining > IODEF extensions to be consistent with RFC 5070 and with each other. > >> 5. Why is the list of datatypes in appendix A.4.1 copied from RFC >> 5070? A simple reference would do. (I almost said the same about >> the list in Section 3, but that one is marginally useful.) > > The A.4.1. list was copied over because doing so was consistent with > the list in Section 3, more or less; it's intended to give an inline > definition of the allowable TYPE values as in the UML diagram in > Figure 1, section A.4. (Copying this was also consistent with the > inclusion of the list in Section 3.) > >> 6. Some of the information in this document repeats information >> from the RFC style guide and other sources; why? > > Here we have a duelling-commenters situation; this is per early-AD > commentary in > http://www.ietf.org/mail-archive/web/mile/current/msg00657.html and > the subsequent thread. IMHO, it seems fine to repeat some of that information, as long as you say that the styleguide rules on general matters of RFC authorship. But your AD might know better. ;-) Peter -- Peter Saint-Andre https://stpeter.im/ From trammell@tik.ee.ethz.ch Wed May 23 05:08:33 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D4521F86AA; Wed, 23 May 2012 05:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIf1BONb80fm; Wed, 23 May 2012 05:08:32 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5B94121F86A4; Wed, 23 May 2012 05:08:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8C38ED930A; Wed, 23 May 2012 14:08:30 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0jO0Funr0bzk; Wed, 23 May 2012 14:08:30 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 5D494D9307; Wed, 23 May 2012 14:08:30 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4FBA5C59.4030102@stpeter.im> Date: Wed, 23 May 2012 14:08:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120516215321.9671.39664.idtracker@ietfa.amsl.com> <4FB46FA6.6060005@stpeter.im> <4FBA5C59.4030102@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1278) Cc: "" , ietf@ietf.org Subject: Re: [mile] Last Call: (Guidelines for Defining Extensions to IODEF) to Informational RFC X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2012 12:08:33 -0000 Hi, Peter, One minor point, inline... On May 21, 2012, at 5:16 PM, Peter Saint-Andre wrote: >> Hm. The document does indeed assume that extensions to IODEF are >> defined in Internet-Drafts, that extension namespaces will be >> registered with IANA, and that those namespaces be of the described >> form; it makes these assumptions because that is the intent of the >> document. Whether that's "universal" or not could be an open >> question, perhaps, but the intent is to specify a more restrictive >> method of extension than that in 5070 in the interests of >> consistency. So, yes, it's an informational document, they're just >> helpful suggestions, but we would hope they'd be followed, and the >> document is written assuming that they will... >=20 > As mentioned, I happen to be working on some IODEF extensions that are > specific to the XMPP community. Is it expected that I work on the > relevant spec in the MILE WG, in the XMPP WG, or (as I'm doing right > now) at the XMPP Standards Foundation? IMHO, doing this work at the = XSF > makes the most sense because that's where most of the XMPP developers > and operators are active. Seeking a sanity check on this work from the > MILE WG does seem reasonable, though (once it's ready for review). This is IMO the right way to go. During the creation of this document, = we envisioned in most cases that work to extend IODEF would not have any = other "natural" home, and as such would be done within the IETF in the = MILE WG; this assumption is probably apparent in the document. In cases where the work _does_ have a natural home (the application of = IODEF to XMPP-specific events is a perfect example), it definitely makes = sense to do work there in possible consultation with the MILE WG. Indeed, for such cases, the IODEF expert review on IODEF extension = schemas specified by draft-ietf-mile-iodef-xmlreg would be a final = backstop to ensure that specified extensions are consistent with IODEF. Best regards, Brian (as author, draft-ietf-mile-template)= From ietf-ipr@ietf.org Wed May 23 09:00:36 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF2D21F873C; Wed, 23 May 2012 09:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq1vRrXyfbzM; Wed, 23 May 2012 09:00:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6302221F86A4; Wed, 23 May 2012 09:00:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: takeshi_takahashi@nict.go.jp, kent_landfield@mcafee.com, thomas.millar@us-cert.gov, youki-k@is.aist-nara.ac.jp X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120523160035.1728.32859.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2012 09:00:35 -0700 X-Mailman-Approved-At: Wed, 23 May 2012 10:08:05 -0700 Cc: mile@ietf.org, stephen.farrell@cs.tcd.ie, ipr-announce@ietf.org Subject: [mile] IPR Disclosure: Sean Turner's Statement about IPR related to draft-ietf-mile-sci-04 belonging to The National Institute of Standards and Technology (NIST) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2012 16:00:36 -0000 Dear Takeshi Takahashi, Kent Landfield, Thomas Millar, Youki Kadobayashi: An IPR disclosure that pertains to your Internet-Draft entitled "IODEF- extension to support structured cybersecurity information" (draft-ietf-mile= -sci) was submitted to the IETF Secretariat on 2012-05-23 and has been posted on = the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1787/). The title of the IPR disclosure is "Sean Turner's Statement about IPR related to draft-ietf-mile-sci-04 belong= ing to The National Institute of Standards and Technology (NIST).""); The IETF Secretariat From ietf-ipr@ietf.org Wed May 23 09:01:43 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A05C21F8746; Wed, 23 May 2012 09:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAvxu5eGE+ej; Wed, 23 May 2012 09:01:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB4321F86DF; Wed, 23 May 2012 09:01:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: takeshi_takahashi@nict.go.jp, kent_landfield@mcafee.com, thomas.millar@us-cert.gov, youki-k@is.aist-nara.ac.jp X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120523160143.2838.46384.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2012 09:01:43 -0700 X-Mailman-Approved-At: Wed, 23 May 2012 10:08:05 -0700 Cc: mile@ietf.org, stephen.farrell@cs.tcd.ie, ipr-announce@ietf.org Subject: [mile] IPR Disclosure: Sean Turner's Statement about IPR related to draft-ietf-mile-sci-04 belonging to The MITRE Corporation X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2012 16:01:43 -0000 Dear Takeshi Takahashi, Kent Landfield, Thomas Millar, Youki Kadobayashi: An IPR disclosure that pertains to your Internet-Draft entitled "IODEF- extension to support structured cybersecurity information" (draft-ietf-mile= -sci) was submitted to the IETF Secretariat on 2012-05-23 and has been posted on = the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1786/). The title of the IPR disclosure is "Sean Turner's Statement about IPR related to draft-ietf-mile-sci-04 belong= ing to The MITRE Corporation.""); The IETF Secretariat From stpeter@stpeter.im Thu May 24 08:02:08 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D14521F8542 for ; Thu, 24 May 2012 08:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdRFU391Wwrm for ; Thu, 24 May 2012 08:02:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6243221F8528 for ; Thu, 24 May 2012 08:02:07 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A18A8400A4; Thu, 24 May 2012 09:18:15 -0600 (MDT) Message-ID: <4FBE4727.4050600@stpeter.im> Date: Thu, 24 May 2012 08:35:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian Trammell References: <20120516215321.9671.39664.idtracker@ietfa.amsl.com> <4FB46FA6.6060005@stpeter.im> <4FBA5C59.4030102@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mile] Last Call: (Guidelines for Defining Extensions to IODEF) to Informational RFC X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2012 15:02:08 -0000 On 5/23/12 6:08 AM, Brian Trammell wrote: > Hi, Peter, > > One minor point, inline... > > On May 21, 2012, at 5:16 PM, Peter Saint-Andre wrote: > >>> Hm. The document does indeed assume that extensions to IODEF are >>> defined in Internet-Drafts, that extension namespaces will be >>> registered with IANA, and that those namespaces be of the described >>> form; it makes these assumptions because that is the intent of the >>> document. Whether that's "universal" or not could be an open >>> question, perhaps, but the intent is to specify a more restrictive >>> method of extension than that in 5070 in the interests of >>> consistency. So, yes, it's an informational document, they're just >>> helpful suggestions, but we would hope they'd be followed, and the >>> document is written assuming that they will... >> >> As mentioned, I happen to be working on some IODEF extensions that are >> specific to the XMPP community. Is it expected that I work on the >> relevant spec in the MILE WG, in the XMPP WG, or (as I'm doing right >> now) at the XMPP Standards Foundation? IMHO, doing this work at the XSF >> makes the most sense because that's where most of the XMPP developers >> and operators are active. Seeking a sanity check on this work from the >> MILE WG does seem reasonable, though (once it's ready for review). > > This is IMO the right way to go. During the creation of this document, we envisioned in most cases that work to extend IODEF would not have any other "natural" home, and as such would be done within the IETF in the MILE WG; this assumption is probably apparent in the document. > > In cases where the work _does_ have a natural home (the application of IODEF to XMPP-specific events is a perfect example), it definitely makes sense to do work there in possible consultation with the MILE WG. > > Indeed, for such cases, the IODEF expert review on IODEF extension schemas specified by draft-ietf-mile-iodef-xmlreg would be a final backstop to ensure that specified extensions are consistent with IODEF. Hi Brian, thanks for the clarification! Peter -- Peter Saint-Andre https://stpeter.im/ From turners@ieca.com Mon May 28 12:06:17 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F0721F8668 for ; Mon, 28 May 2012 12:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.254 X-Spam-Level: X-Spam-Status: No, score=-102.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpteLNZxbRdO for ; Mon, 28 May 2012 12:06:12 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [64.5.52.14]) by ietfa.amsl.com (Postfix) with ESMTP id BBDD221F85C3 for ; Mon, 28 May 2012 12:06:08 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id 63AF26F2833E4; Mon, 28 May 2012 14:06:08 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id 569716F2833C3 for ; Mon, 28 May 2012 14:06:08 -0500 (CDT) Received: from [71.191.15.83] (port=38766 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZ5Ga-0005vy-2b for mile@ietf.org; Mon, 28 May 2012 14:06:08 -0500 Message-ID: <4FC3CC9F.1030700@ieca.com> Date: Mon, 28 May 2012 15:06:07 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mile@ietf.org References: <20120523160035.1728.32859.idtracker@ietfa.amsl.com> In-Reply-To: <20120523160035.1728.32859.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [71.191.15.83]:38766 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [mile] IPR Disclosure: Sean Turner's Statement about IPR related to draft-ietf-mile-sci-04 belonging to The National Institute of Standards and Technology (NIST) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2012 19:06:17 -0000 I've update this IPR statement by removing it. I incorrectly submitted the 3rd Party IPR disclosure based on SP 800-126r1 and was informed that SP 800-126r2 removed the note about NIST having trademarked XCCDF and SCAP. Apologies for any confusion this may have caused. spt On 5/23/12 12:00 PM, IETF Secretariat wrote: > > Dear Takeshi Takahashi, Kent Landfield, Thomas Millar, Youki Kadobayashi: > > An IPR disclosure that pertains to your Internet-Draft entitled "IODEF- > extension to support structured cybersecurity information" (draft-ietf-mile-sci) > was submitted to the IETF Secretariat on 2012-05-23 and has been posted on the > "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1787/). The title of the IPR disclosure is > "Sean Turner's Statement about IPR related to draft-ietf-mile-sci-04 belonging > to The National Institute of Standards and Technology (NIST).""); > > The IETF Secretariat > > From takeshi_takahashi@nict.go.jp Mon May 28 20:43:42 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A208821F8766 for ; Mon, 28 May 2012 20:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo578+gXHcUS for ; Mon, 28 May 2012 20:43:42 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id F045221F8738 for ; Mon, 28 May 2012 20:43:41 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q4T3hYKH014510; Tue, 29 May 2012 12:43:34 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q4T3hYAs023577; Tue, 29 May 2012 12:43:34 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id q4T3hY2X023574; Tue, 29 May 2012 12:43:34 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id F0C7416ABA; Tue, 29 May 2012 12:43:33 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail3.nict.go.jp (NICT Mail) with ESMTP id E9B6416AB5; Tue, 29 May 2012 12:43:33 +0900 (JST) From: "Takeshi Takahashi" To: "'Sean Turner'" , References: <20120523160035.1728.32859.idtracker@ietfa.amsl.com> <4FC3CC9F.1030700@ieca.com> In-Reply-To: <4FC3CC9F.1030700@ieca.com> Date: Tue, 29 May 2012 12:43:32 +0900 Message-ID: <000c01cd3d4d$37ed3100$a7c79300$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIRf4801q6DX71gJ6/gv0+flY7RcwL2L3+ulj/o7EA= Content-Language: ja Subject: Re: [mile] IPR Disclosure: Sean Turner's Statement about IPR related to draft-ietf-mile-sci-04 belonging to The National Institute of Standards and Technology (NIST) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2012 03:43:42 -0000 Hello Sean, thank you very much for your kind assistances you have provided for us. Let me come back to the discussion a short while later. Best Regards, Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Tuesday, May 29, 2012 4:06 AM > To: mile@ietf.org > Subject: Re: [mile] IPR Disclosure: Sean Turner's Statement about IPR > related to draft-ietf-mile-sci-04 belonging to The National Institute > of Standards and Technology (NIST) > > I've update this IPR statement by removing it. I incorrectly submitted > the 3rd Party IPR disclosure based on SP 800-126r1 and was informed that > SP 800-126r2 removed the note about NIST having trademarked XCCDF and > SCAP. Apologies for any confusion this may have caused. > > spt > > On 5/23/12 12:00 PM, IETF Secretariat wrote: > > > > Dear Takeshi Takahashi, Kent Landfield, Thomas Millar, Youki > Kadobayashi: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > > "IODEF- extension to support structured cybersecurity information" > > (draft-ietf-mile-sci) was submitted to the IETF Secretariat on > > 2012-05-23 and has been posted on the "IETF Page of Intellectual Property > Rights Disclosures" > > (https://datatracker.ietf.org/ipr/1787/). The title of the IPR > > disclosure is "Sean Turner's Statement about IPR related to > draft-ietf-mile-sci-04 belonging > > to The National Institute of Standards and Technology (NIST).""); > > > > The IETF Secretariat > > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From dromasca@avaya.com Wed May 30 05:17:06 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8582221F861C; Wed, 30 May 2012 05:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.468 X-Spam-Level: X-Spam-Status: No, score=-103.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3UNwY+R0dvr; Wed, 30 May 2012 05:17:06 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id D1DFE21F8625; Wed, 30 May 2012 05:17:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB4Pxk/GmAcF/2dsb2JhbABEtA2BB4IXAQEBAQMSHgo0CwwEAgEIDQQEAQELBgwHBAEGAUUJCAEBBBMIGodpC5wTnSGLBYIsgjZgA5YnhGKKAoJi X-IronPort-AV: E=Sophos;i="4.75,685,1330923600"; d="scan'208";a="350038127" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 30 May 2012 08:15:05 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 May 2012 08:14:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 May 2012 14:16:52 +0200 Message-ID: In-Reply-To: <20120516215321.9671.39664.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: (Guidelines for DefiningExtensions to IODEF) to Informational RFC Thread-Index: Ac0zrndzehc1YPfHShOUxclriX6j+AKrpZyg References: <20120516215321.9671.39664.idtracker@ietfa.amsl.com> From: "Romascanu, Dan (Dan)" To: X-Mailman-Approved-At: Wed, 30 May 2012 05:35:06 -0700 Cc: mile@ietf.org Subject: Re: [mile] Last Call: (Guidelines for DefiningExtensions to IODEF) to Informational RFC X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2012 12:17:06 -0000 Hi,=20 The inclusion of the template as an Appendix in the document is confusing - right now A.1 through A.7 define sections in the future I-Ds, while A.8 and A.9 describe appendices in the future I-D. This document has two sections each titled Appendix A and Appendix B. Moreover, this inclusion has the disadvantage that if changes or updates need to be brought up for reasons whatsoever, a new RFC needs to be written. Did the author and the WG considered adopting the approach taken by RFC 5249 which located the templates under the IETF tools web pages and only referred them from the RFC?=20 Regards, Dan > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: Thursday, May 17, 2012 12:53 AM > To: IETF-Announce > Cc: mile@ietf.org > Subject: Last Call: (Guidelines for > DefiningExtensions to IODEF) to Informational RFC >=20 >=20 > The IESG has received a request from the Managed Incident Lightweight > Exchange WG (mile) to consider the following document: > - 'Guidelines for Defining Extensions to IODEF' > as Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-05-30. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document provides guidelines for extensions to IODEF [RFC5070] > for exchange of incident management data, and contains a template > for > Internet-Drafts describing those extensions, in order to ease the > work and improve the quality of extension descriptions. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mile-template/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mile-template/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20