From nobody Tue Jan 3 08:18:31 2017 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 D28BA12966F for ; Tue, 3 Jan 2017 08:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lncC_C7VH3sJ for ; Tue, 3 Jan 2017 08:18:28 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348D212966D for ; Tue, 3 Jan 2017 08:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15238; q=dns/txt; s=iport; t=1483460307; x=1484669907; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ya4gc7aSHJo85OHH8QAgJ3qp+fymru4nlLoe1PKqnZM=; b=ffD7vTZ0FWIjsjNt98WpElazYc+hN1EZSqO5owHd/16R7pYjlILTB+C0 CpxCSTj8OjKKQdzlndxg1vVBpgmH9hg/c5J0HidOa6FV9mF2SamojGo1c HsJbzDLD0AX8m5xgobfk2f21MV7mtwMXAT9Iup6xeiLsbJp9v7NmB1RUU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AwCNzmtY/4cNJK1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJxRgEBAQEBH1+BDAeiFo9zgxmCD4IIhiICgUtAEwECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQEEIA1cAgEIEQQBASgHMhQJCAEBBAESCIhorn8IgiiKHQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2GRYRhhB5egkyCXwWVCYV0AZE0kF6OLoQOASABNoE?= =?us-ascii?q?qhgtyhzEBgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,455,1477958400"; d="scan'208,217";a="193389920" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jan 2017 16:18:16 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v03GIGOS031237 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Jan 2017 16:18:16 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 3 Jan 2017 10:18:15 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1210.000; Tue, 3 Jan 2017 10:18:15 -0600 From: "Panos Kampanakis (pkampana)" To: "Banghart, Stephen A. (Fed)" , "mile@ietf.org" Thread-Topic: ROLIE Data Model Enumeration Thread-Index: AdJUkLkVdwqU2UKsSJC6MkKU9WhzPgRS1f8Q Date: Tue, 3 Jan 2017 16:18:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.102.61.102] Content-Type: multipart/alternative; boundary="_000_c23b982531134738af5b6fc7efc040ceXCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mile] ROLIE Data Model Enumeration X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 16:18:30 -0000 --_000_c23b982531134738af5b6fc7efc040ceXCHALN010ciscocom_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Happy New Year to everyone! +1. I think registering formats will be challenging and could slow down ado= pters. I think it would be beneficial if the ROLIE draft included text for an exam= ple representation in section 6.2.3 though. The IODEFv2 XML schema could be= one example. Panos From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Banghart, Stephen A.= (Fed) Sent: Monday, December 12, 2016 11:01 AM To: mile@ietf.org Subject: [mile] ROLIE Data Model Enumeration All, The other issue discussed at the IETF 97 MILE meeting was the Enumeration a= nd Registration of Data Models. Data model enumeration/registration would involve requiring extension docum= ents to register their supported data models for a given information type w= ith IANA. Pros: =94 Provides one location that lists all officially registered data f= ormats. Cons: =94 Requires document authors to choose (often arbitrarily!) and regi= ster data format namespaces =94 Registered identifiers don't help implementations understand data= formats, and if chosen arbitrarily may not even help identify the format i= n a way that is meaningful to clients. =94 Provides no additional automation support. =94 Increases work load on extension authors =94 Extensions must provide IANA considerations section that specifie= s data model registration and perhaps an additional table for the data mode= ls. =94 Extensions must have a separate section describing the data model= in addition to the IANA consideration Proposal: Do not require data format registration in extension drafts= . This does not preclude an extension from establishing a registry for supp= orted data models if needed. Extension specifications may additionally disc= uss the data models intended to be used for a given information type. We be= lieve this provides for adequate coverage of the model namespaces to be use= d in the extension specification, without requiring the extra burden of dea= ling with IANA considerations for models. Any feedback on this proposal? I personally feel like requiring registratio= n is not worth the price. Thanks, Stephen Banghart --_000_c23b982531134738af5b6fc7efc040ceXCHALN010ciscocom_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Happy= New Year to everyone!

=  

+= 1. I think registering formats will be challenging and could slow down adop= ters.

I thi= nk it would be beneficial if the ROLIE draft included text for an example r= epresentation in section 6.2.3 though. The IODEFv2 XML schema could be one = example.

=  

Panos=

=  

=  

From: mile [mailto:mile-bounces@ietf.org] = On Behalf Of Banghart, Stephen A. (Fed)
Sent: Monday, December 12, 2016 11:01 AM
To: mile@ietf.org
Subject: [mile] ROLIE Data Model Enumeration

 

All,

 

The other issue discussed at the IETF 97 MILE meetin= g was the Enumeration and Registration of Data Models.

 

Data model enumeration/registration would involve re= quiring extension documents to register their supported data models for a g= iven information type with IANA.

 

Pros:

=94       Provides one location that lists all officia= lly registered data formats.

Cons:

=94       Requires document authors to choose (often a= rbitrarily!) and register data format namespaces

=94       Registered identifiers don’t help impl= ementations understand data formats, and if chosen arbitrarily may not even= help identify the format in a way that is meaningful to clients.

=94       Provides no additional automation support.

=94       Increases work load on extension authors

=94       Extensions must provide IANA considerations = section that specifies data model registration and perhaps an additional ta= ble for the data models.

=94       Extensions must have a separate section desc= ribing the data model in addition to the IANA consideration

 

Proposal:

        &nbs= p;       Do not require data format registrat= ion in extension drafts. This does not preclude an extension from establish= ing a registry for supported data models if needed. Extension specification= s may additionally discuss the data models intended to be used for a given information type. We believe this p= rovides for adequate coverage of the model namespaces to be used in the ext= ension specification, without requiring the extra burden of dealing with IA= NA considerations for models.

 

Any feedback on this proposal? I personally feel lik= e requiring registration is not worth the price.

 

Thanks,

Stephen Banghart

--_000_c23b982531134738af5b6fc7efc040ceXCHALN010ciscocom_-- From nobody Tue Jan 3 08:24:02 2017 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 2E6E9129685 for ; Tue, 3 Jan 2017 08:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.361 X-Spam-Level: X-Spam-Status: No, score=-17.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veed6Myg6szA for ; Tue, 3 Jan 2017 08:23:57 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D36A129579 for ; Tue, 3 Jan 2017 08:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15904; q=dns/txt; s=iport; t=1483460636; x=1484670236; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=IS3IaZaISGRDwp7bSqtrCo4RZUrl/xCm2iTxKcTd8DQ=; b=Tv5foZeX6vrAUCzX+OtNVaEFkm4/71NEzNoTFAGZuPBj42TPgLURQJVh d84NHz/oHsVhCeVpazDeh+agz9R6//hzBCT7S8pzlZxijbH6arWjPMxSY TcA6kTNy5uH1iGE5fdPy2K1s5Iyzcz9b6I35FAQwjDj6rOcTsS4kIOPlr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAwBXz2tY/4MNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFGAQEBAQEfX4EMB4VOnEiCXo0VgxmCD4IIKoQegVoCgUtBEgE?= =?us-ascii?q?CAQEBAQEBAWIohGgBAQEELVwCAQgRBAEBKAcyFAkIAQEEARIIiGgOsSeKHQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2GRViECYI/gXFMhQ0eBY8Gi3cBhlODEodPkF6?= =?us-ascii?q?JfoQwhA4BJgkogSougyuCMnKHMQGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,455,1477958400"; d="scan'208,217";a="367945607" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jan 2017 16:23:54 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v03GNs6U007559 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Jan 2017 16:23:54 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 3 Jan 2017 10:23:53 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1210.000; Tue, 3 Jan 2017 10:23:53 -0600 From: "Panos Kampanakis (pkampana)" To: "Banghart, Stephen A. (Fed)" , "mile@ietf.org" , "alexey.melnikov@isode.com" Thread-Topic: ROLIE Service and Category Document Location Issue Thread-Index: AdJRkaLeZWqJvsa9S0ea5cMxkoznUQUS/BMQ Date: Tue, 3 Jan 2017 16:23:53 +0000 Message-ID: <2b5ba8381eea42549686cfe6c5e63bf3@XCH-ALN-010.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.102.61.102] Content-Type: multipart/alternative; boundary="_000_2b5ba8381eea42549686cfe6c5e63bf3XCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mile] ROLIE Service and Category Document Location Issue X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 16:24:00 -0000 --_000_2b5ba8381eea42549686cfe6c5e63bf3XCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 on A. As someone mentioned in IETF97, the /.well-known directory is com= monly used in many other occasions. For ROLIE, a /.well-known/rolie/service= doc or repositorydoc URI would suffice I think. Panos From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Banghart, Stephen A.= (Fed) Sent: Thursday, December 08, 2016 4:07 PM To: mile@ietf.org; alexey.melnikov@isode.com Subject: [mile] ROLIE Service and Category Document Location Issue As requested at the IETF 97 MILE meeting, I've put together some Use Case e= xamples of using service and category documents that highlight the primary = differences between the choices for this issue. Those options are: A: Require that ROLIE repositories place the Service and Category documents= in a pre-determined location based on a standardized URL template. This lo= cation may be a link or redirect to the actual location. B: ROLIE repositories are not required to place their Service and Category = documents at a pre-determined location. The use cases below highlight the need for a well-defined location for the = service and category documents to support automated discovery. The use case= s illustrate that option B is not really an option if our goal is to suppor= t automated discovery and use of ROLIE repositories. Feedback on the approa= ches described below would be appreciated. If you are not a fan of using we= ll-defined URL templates, then alternate proposals that support these autom= ation use cases would also be appreciated. Thanks, Stephen Banghart Defined Service Document and Category Document Location Examples Service Document Use Case: A ROLIE user agent becomes aware of a host (examplesecurityorg.co= m) that hosts a ROLIE repository. The host i= s identified by some means, such as by DNS Service Record lookup. However, = as the agent only knows the server host name, the agent knows neither the l= ocation of the ROLIE feeds nor information about a given feed's contents. Goal: In order to locate the feeds, the operator must find the Atom service= document located somewhere on the server. With Defined Location: If the user agent sends a GET request to "https://ex= amplesecurityorg.com/rolie/servicedocument", as this is the pre-specified location. This is h= andled on the server as a redirect to its preferred service document locati= on: "https://examplesecurityorg.com/1234/sec/srvdoc". Without Defined Location: The agent must manually search the front-facing s= ection of the site, looking for a stated Atom service document location. Fa= iling that search, the operator must search website documentation or contac= t admins of the site and request the URL. Neither of these methods support = automation and require human interaction. If the URL can be identified usin= g these manual methods, , the agent can now send a GET request to "https://= examplesecurityorg.com/1234/sec/srvdoc" to retrieve the service document. This use case is best supported if the ROLIE repository contents can be dis= covered in an automatable way. A well-defined location for the service docu= ment provides a predictable means for collection discovery as long as the h= ost name of the ROLIE repository is known. Category Document Use Case: A ROLIE user agent wants to programmatically populate a list that= contains all of the categories provided by a ROLIE repository. The categor= y list will be used to generate search queries tailored to this repository,= as the repository may be using any number of global or local categories, s= uch as information-type. This ROLIE repository is also configured to only a= llow POST requests if they belong to one of the categories specified in the= category document. If the user agent intends to write to this repository i= t must locate the category document. Goal: The tool needs to know the full list of categories supported by the = repository. With Defined Location: The user agent sends a get request to "https://examp= lesecurityorg.com/rolie/categorydocument", and parses it to generate a full list of supporte= d categories. This is handled on the server as a redirect to its preferred = category document location: "https://examplesecurityorg.com/1234/sec/catdoc= ". Without Defined Location: If the user agent is only interested in the curre= ntly provided categories, it must parse all feeds provided by the repositor= y to generate a list. This activity must be repeated on every connection, i= ncurring a heavy performance and bandwidth cost. If the user agent intends to write to the repository, it must manually sear= ch the front-facing section of the site, looking for a stated Atom category= document location. Failing that search, the operator must contact admins o= f the site and request the URL. Neither of these methods support automation= and require human interaction. Having completed this task, the agent can n= ow send a GET request to "https://examplesecurityorg.com/1234/sec/catdoc". Having a well-defined location for the category document can simplify and o= ptimize category information discovery. --_000_2b5ba8381eea42549686cfe6c5e63bf3XCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 on A.  As someone mentioned in IETF97, the /.well-k= nown directory is commonly used in many other occasions. For ROLIE, a /.wel= l-known/rolie/servicedoc or repositorydoc URI would suffice I think.

Panos

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Bangha= rt, Stephen A. (Fed)
Sent: Thursday, December 08, 2016 4:07 PM
To: mile@ietf.org; alexey.melnikov@isode.com
Subject: [mile] ROLIE Service and Category Document Location Issue

 

As= requested at the IETF 97 MILE meeting, I’ve put together some Use Ca= se examples of using service and category documents that highlight the prim= ary differences between the choices for this issue. Those options are:

 

A: Require th= at ROLIE repositories place the Service and Category documents in a pre-det= ermined location based on a standardized URL template. This location may be a link or redirect to the actual locati= on.

B: ROLIE repo= sitories are not required to place their Service and Category documents at = a pre-determined location.

 

Th= e use cases below highlight the need for a well-defined location for the se= rvice and category documents to support automated discovery. The use cases = illustrate that option B is not really an option if our goal is to support automated discovery and use of ROLIE r= epositories. Feedback on the approaches described below would be appreciate= d. If you are not a fan of using well-defined URL templates, then alternate= proposals that support these automation use cases would also be appreciated.

Th= anks,

St= ephen Banghart

 

De= fined Service Document and Category Document Location Examples

Service Document

Use Case: A ROLIE user agent becomes aware of= a host (examplesecurityorg.com) that hosts a ROLIE repository. The host is identified by some means, su= ch as by DNS Service Record lookup. However, as the agent only knows the server host name, the agent knows nei= ther the location of the ROLIE feeds nor information about a given feedR= 17;s contents.

Goal: In order to = locate the feeds, the operator must find the Atom service document located somewhere on the server.=

With Defined Location<= /b>: If the user agent sends a GET request to “https://examplesecurityorg.co= m/rolie/servicedocument”, as this is the pre-specified location. This is handled on the server as a redirect to its= preferred service document location: “https://examplesecurityorg.com/1234/sec/= srvdoc”.

Without Defined Locati= on: The agent must manually search the front-facing section of the site= , looking for a stated Atom service document location. Failing that search,= the operator must search website documentation or contact admins of the site and request the URL. Neither of these method= s support automation and require human interaction. If the URL can be ident= ified using these manual methods, , the agent can now send a GET request to= “https://= examplesecurityorg.com/1234/sec/srvdoc” to retrieve the service document.

This use case is best supported if the ROLIE reposit= ory contents can be discovered in an automatable way. A well-defined locati= on for the service document provides a predictable means for collection dis= covery as long as the host name of the ROLIE repository is known.

Category Document

Use Case: A ROLIE user agent wants to program= matically populate a list that contains all of the categories provided by a= ROLIE repository. The category list will be used to generate search querie= s tailored to this repository, as the repository may be using any number of global or local categories, such= as information-type. This ROLIE repository is also configured to only allo= w POST requests if they belong to one of the categories specified in the ca= tegory document. If the user agent intends to write to this repository it must locate the category document.<= o:p>

 Goal: The to= ol needs to know the full list of categories supported by the repository.

With Defined Location:= The user agent sends a get request to “https://examplesecurityorg.com/= rolie/categorydocument”, and parses it to generate a full list of supported categories. This is handled on the serve= r as a redirect to its preferred category document location: “https://examplesecurity= org.com/1234/sec/catdoc”.

Without Defined Locati= on: If the user agent is only interested in the currently provided cate= gories, it must parse all feeds provided by the repository to generate a li= st. This activity must be repeated on every connection, incurring a heavy performance and bandwidth cost. <= /o:p>

If the user agent intends= to write to the repository, it must manually search the front-facing secti= on of the site, looking for a stated Atom category document location. Faili= ng that search, the operator must contact admins of the site and request the URL. Neither of these methods support a= utomation and require human interaction. Having completed this task, the ag= ent can now send a GET request to “https://examplesecurityorg.com/1234/sec/catdoc= ”.

Having a well-defined location for the category docu= ment can simplify and optimize category information discovery.

 

--_000_2b5ba8381eea42549686cfe6c5e63bf3XCHALN010ciscocom_--