Re: [mile] ROLIE Data Model Enumeration
"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Fri, 03 March 2017 06:46 UTC
Return-Path: <takeshi_takahashi@nict.go.jp>
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 227B312979D for <mile@ietfa.amsl.com>; Thu, 2 Mar 2017 22:46:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMQ7WurYNQZK for <mile@ietfa.amsl.com>; Thu, 2 Mar 2017 22:46:23 -0800 (PST)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9C4129793 for <mile@ietf.org>; Thu, 2 Mar 2017 22:46:23 -0800 (PST)
Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id v236kJ6M045109; Fri, 3 Mar 2017 15:46:19 +0900 (JST)
Received: from VAIO (ssh1.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id v236kJvK045086; Fri, 3 Mar 2017 15:46:19 +0900 (JST)
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: "'Panos Kampanakis (pkampana)'" <pkampana@cisco.com>, "'Banghart, Stephen A. (Fed)'" <stephen.banghart@nist.gov>, mile@ietf.org
References: <SN1PR09MB09602C26522BDBDEFD9C9235F0980@SN1PR09MB0960.namprd09.prod.outlook.com> <c23b982531134738af5b6fc7efc040ce@XCH-ALN-010.cisco.com>
In-Reply-To: <c23b982531134738af5b6fc7efc040ce@XCH-ALN-010.cisco.com>
Date: Fri, 03 Mar 2017 15:46:18 +0900
Message-ID: <023501d293e9$dcc9ee50$965dcaf0$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFVls7gm16Ptqc2cBMzE2InwYTCIgIkpUKYomuAvuA=
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.7 at zenith2
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/2gwGRxVnUl21r3gmF3182zQVKsg>
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" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2017 06:46:25 -0000
+1 to the proposal and to Panos's comment. Thank you, Take From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana) Sent: Wednesday, January 4, 2017 1:18 AM To: Banghart, Stephen A. (Fed); mile@ietf.org Subject: Re: [mile] ROLIE Data Model Enumeration Happy New Year to everyone! +1. I think registering formats will be challenging and could slow down adopters. I think it would be beneficial if the ROLIE draft included text for an example 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 and Registration of Data Models. Data model enumeration/registration would involve requiring extension documents to register their supported data models for a given information type with IANA. Pros: │ Provides one location that lists all officially registered data formats. Cons: │ Requires document authors to choose (often arbitrarily!) and register data format namespaces │ Registered identifiers don't help implementations understand data formats, and if chosen arbitrarily may not even help identify the format in a way that is meaningful to clients. │ Provides no additional automation support. │ Increases work load on extension authors │ Extensions must provide IANA considerations section that specifies data model registration and perhaps an additional table for the data models. │ 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 supported data models if needed. Extension specifications may additionally discuss the data models intended to be used for a given information type. We believe this provides for adequate coverage of the model namespaces to be used in the extension specification, without requiring the extra burden of dealing with IANA considerations for models. Any feedback on this proposal? I personally feel like requiring registration is not worth the price. Thanks, Stephen Banghart
- [mile] ROLIE Data Model Enumeration Banghart, Stephen A. (Fed)
- Re: [mile] ROLIE Data Model Enumeration Panos Kampanakis (pkampana)
- Re: [mile] ROLIE Data Model Enumeration Takeshi Takahashi