Re: [mile] Request for draft reviews - review of IODEF Enumeration Reference
"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Tue, 30 July 2013 13:59 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 632E421F9C40 for <mile@ietfa.amsl.com>; Tue, 30 Jul 2013 06:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.055
X-Spam-Level:
X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, J_CHICKENPOX_55=0.6]
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 HdYgmipJcLGb for <mile@ietfa.amsl.com>; Tue, 30 Jul 2013 06:59:31 -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 81A7321F9955 for <mile@ietf.org>; Tue, 30 Jul 2013 06:59:31 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id r6UDxMmZ019408; Tue, 30 Jul 2013 22:59:22 +0900 (JST)
Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id r6UDxMud023706; Tue, 30 Jul 2013 22:59:22 +0900 (JST)
Received: from VAIO (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id r6UDxJrc023703; Tue, 30 Jul 2013 22:59:20 +0900 (JST)
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: 'Adam Montville' <Adam.Montville@cisecurity.org>, "'Black, David'" <david.black@emc.com>, mile@ietf.org
References: <1C9F17D1873AFA47A969C4DD98F98A753C880A@xmb-rcd-x10.cisco.com> <05BCCEB107AF88469B9F99783D47C1D66F2D3B@CISEXCHANGE1.msisac.org.local> <1C9F17D1873AFA47A969C4DD98F98A753C8B6E@xmb-rcd-x10.cisco.com> <8D3D17ACE214DC429325B2B98F3AE712982651F2@MX15A.corp.emc.com> <05BCCEB107AF88469B9F99783D47C1D6700607@CISEXCHANGE1.msisac.org.local>
In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6700607@CISEXCHANGE1.msisac.org.local>
Date: Tue, 30 Jul 2013 22:59:21 +0900
Message-ID: <001801ce8d2c$ff300e60$fd902b20$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHNmUvlaKWv49Wtyi/VZVgggGBregIJtYNQAvkcTTIC0FXHbgGYZho4mTPJYXA=
Content-Language: ja
Subject: Re: [mile] Request for draft reviews - review of IODEF Enumeration Reference
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 30 Jul 2013 13:59:36 -0000
Hello Adam, David, and all. Regarding the character set of Full Name and Abbreviation, let me comment on a bit here. I also think we do not need Unicode, and ASCII code is fine. I have discussed with a couple of Japanese colleagues, but none of us were able to come up with any acronyms (or its full name) made by Japanese characters. When we create acronyms, they consist of in English alphabets. Of course, some acronyms could be based on Japanese letters, but those acronyms have corresponding full name in Romaji. (Romaji is a type of Japanese letters that uses English alphabets to express Japanese letters.) Since Romaji is expressed in English alphabets, I do not see the need for Unicode here. I mean, I also support using ASCII code for the "Full Name" and "Abbreviation." Thank you. Take From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Adam Montville Sent: Tuesday, June 25, 2013 12:55 AM To: Black, David; mile@ietf.org Subject: Re: [mile] Request for draft reviews - review of IODEF Enumeration Reference David, before I forget, thanks for the assistance here I havent had an opportunity to read through this in detail, and might not be able to this week due to impending deadlines. I will certainly get to it next week, however. Adam From: Black, David [mailto:david.black@emc.com] Sent: Tuesday, June 18, 2013 6:48 AM To: Adam Montville; mile@ietf.org Subject: RE: [mile] Request for draft reviews - review of IODEF Enumeration Reference Hi Adam, The -02 version of this draft was definitely useful, and its expired, so a new version would be a good idea ;-). This message is a bit long and detailed, but IANA considerations are full of details ... > Also, are there good IANA-related RFCs I can look at to tighten this > draft up a bit? What I was intending for the IANA section is to convey > both what the registry contains and the format of each element therein. That intent is fine, as good IANA considerations text for registry creation does exactly that. At the risk of blowing my own horn, heres a recent RFC that is entirely IANA Considerations: http://www.rfc-editor.org/rfc/rfc6580.txt The IANA considerations text in Takes SCI draft is another reasonable example to work from. Also, RFC 2434 has been replaced by RFC 5226. Here are a few specific suggestions on the IANA considerations text: [1] Change this introductory sentence: OLD Registration request for the IODEF Enumeration Reference Format: NEW This memo creates the following registry for IANA to manage: END That should resolve the confusion that Panos noted. [2] This sentence seems out of place: The registry is intended to enable enumeration value additions to attributes of a given reference class of an IETF standard, for example, the Reference class of the IODEF schema. I think it would be better placed in Section 2.3, which already covers this, so just deleting that sentence may suffice. [3] This text seems vague: Note that certain name requests should not be permitted as either Full Name or Abbreviation entries for the requested IANA table. For example, the following list should not be permitted: foo, bar, example.com. It is anticipated that the Expert Review process will flag any additional undesired Full Name or Abbreviation issues. There should be some additional explanation of what should not be permitted and why, but that approach seems problematic - it could easily get long and will inevitably miss some things that wed like to exclude. Moreover, Im not even sure about the excluded examples - what if someone (cleverly) comes up with a widely used Fraud Observable Objects format, would we really want to disallow FOO :-) ? It may be better to leave this to the judgment of the Designated Expert, so Id suggest turning this approach around - remove the above text and instead write some additional guidance to the designated expert on what the abbreviation should represent. On the proposed new formats: Abbreviation: The abbreviation of the enumeration as a string from the ASCII character set. An abbreviation may be an initialism or acronym, is free-form, but is limited to between two and five upper-case characters meeting the regular expression: ^[A-Z]{2,5}$ Version: The version of the enumeration as a string using major and minor dotted notation meeting the regular expression as follows: ^[1-9]+\.[0-9]+$ Id suggest using ABNF rather than regular expressions - see RFC 5234 (http://www.rfc-editor.org/rfc/rfc5234.txt) including the core rules in Appendix B.1 (e.g., DIGIT). OTOH, the regexp formats are more compact - if they are retained, a reference needs to be cited that defines the regexp notation used. Several questions: - Is the limitation to ASCII ok? Its certainly the most straightforward approach, as use of 7-bit ASCII avoids a pile of Unicode issues, but are there any important existing or likely specs whose acronyms cant be expressed in ASCII? [Take - do you know of any spec that is likely to need non-ASCII characters in an IODEF reference?] - Will 5 characters always be enough? All the current examples fit, but what about clever future acronyms that use more? - Is the restriction to upper case ok? Same concern about current examples vs. future, but like the ASCII limitation, always upper case eliminates case conversion concerns (Warning: Unicode case conversion is a complex area that should be avoided if possible). - Is the limitation of version to major.minor (x.y) is overly restrictive? Sooner or later there will be 3 or 4 element version numbers when someone needs to make a really small tweak/fix. Also, what happens when someone decides to number something as 4.3A instead of adding another dotted element? Overall, Id suggest as little as we can get away with for version format restrictions, as the spec authors who choose versions probably wont have IODEF in mind when they do so. I also wonder how Version is going to be used - would it be: - For display only? - For exact match against the version that the IODEF recipient is using? - For more detailed comparison (e.g., this or later, same major version)? The first two use cases suggest no formatting restrictions, but the third use case requires that version be parseable - is that necessary? As a strawman for Abbreviation, Id suggest: Stay with upper case ASCII (avoids Unicode, avoids string miscompares courtesy of case-sensitive comparison instead of case-insensitive). Allow longer strings, e.g., up to 20 characters. Add guidance to designated expert to favor short strings (i.e., acronyms). Id add a sentence to Section 2 to say that the avoidance of string miscompares caused by case-sensitive comparison is the reason for upper case ASCII. Thanks, --David From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana) Sent: Thursday, June 06, 2013 3:42 PM To: Adam Montville; mile@ietf.org; Adam Montville Subject: Re: [mile] Request for draft reviews - review of IODEF Enumeration Reference You probably have seen this http://www.ietf.org/rfc/rfc2434.txt but I am pointing it out anyway From: Adam Montville [mailto:Adam.Montville@cisecurity.org] Sent: Thursday, June 06, 2013 1:39 PM To: Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org; Adam Montville Subject: RE: [mile] Request for draft reviews - review of IODEF Enumeration Reference Thank you! Ill make the changes you recommend. Also, are there good IANA-related RFCs I can look at to tighten this draft up a bit? What I was intending for the IANA section is to convey both what the registry contains and the format of each element therein. If theres a better way to do this, lets do it. Adam From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana) Sent: Thursday, June 06, 2013 8:33 AM To: Moriarty, Kathleen; mile@ietf.org; Adam Montville (amontville@tripwire.com) Subject: Re: [mile] Request for draft reviews - review of IODEF Enumeration Reference Hi Adam, I think this is close to being done. I had reviewed in the past and the registry format is as we had all agreed. I did a fresh review and had some minor nits and suggestions, and some confusion for the IANA considerations section. - maybe rephrase but one that seems the most appropriate at this point is to... to but the most appropriate at this point is to... - especially enumerations such as CEE, CVE, CCE maybe put informative references for CEE, CVE and CCE? - Where id_type is an IANA-registered type having the form... I am proposing to rephrase the paragraph a little to avoid the And where The format of the ReferenceName MUST follow the form of id_type:version:id where id_type is an IANA-registered type having the form <Abbreviation> The version is an IANA-registered type having the form <Version> The id is the actual enumeration identifier string. - In section 4 IANA Considerations, it is not very clear to me what each paragraph is trying to convey. It this section trying to describe the IANA registry or the format of a registry update request? To me it seems it is mostly the former with some info on the latter. Should the Name of the Registry: "Enumeration Reference Type Identifiers" be in the Fields to record in the registry: ? Does the paragraph The registry is intended to enable enumeration value additions... describe what the IANA registry represents or should it be in the registry request for a new value? Rgs, Panos From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Friday, May 17, 2013 2:13 PM To: mile@ietf.org Subject: [mile] Request for draft reviews Greetings! We have had a number of documents updated since the last meeting. Thank you to all of the editors for making the requested changes! The current list of drafts up for review (including those that will be a part of the WG after the charter update) include: RFC5070-bis (IODEF Revision): http://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ Draft on IODEF Guidance: (input from experience, real use cases, and draft review will be helpful) http://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/ Structured Cybersecurity Information draft (close to final): http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ IODEF Enumeration Reference Format: http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-format/ Resource-Oriented Lightweight Indicator Exchange (ROLIE): http://datatracker.ietf.org/doc/draft-field-mile-rolie/ Please take some time to review the drafts and provide feedback to the list. It would be helpful if we can iterate on most of them prior to the next meeting. A couple of the drafts are very close to being done. The list of current drafts and published RFCs can be found at the following link: http://datatracker.ietf.org/wg/mile/ We will follow up soon on the charter update as well. Thank you all in advance! Kathleen ... This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. ... This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
- Re: [mile] Request for draft reviews - review of … Panos Kampanakis (pkampana)
- Re: [mile] Request for draft reviews - review of … Adam Montville
- Re: [mile] Request for draft reviews - review of … Panos Kampanakis (pkampana)
- Re: [mile] Request for draft reviews - review of … Black, David
- Re: [mile] Request for draft reviews - review of … Adam Montville
- Re: [mile] Request for draft reviews - review of … Takeshi Takahashi
- Re: [mile] Request for draft reviews - review of … Adam Montville