Re: [mile] Request for draft reviews - review of IODEF Enumeration Reference

[Adam Montville <[e-mail]>]

Take,

Thank you for your comments and approval.  They are appreciated.  

Regards,

Adam


> -----Original Message-----
> From: Takeshi Takahashi [mailto:[e-mail]]
> Sent: Tuesday, July 30, 2013 6:59 AM
> To: Adam Montville; 'Black, David'; [e-mail]
> Subject: RE: [mile] Request for draft reviews - review of IODEF Enumeration
> Reference
> 
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Adam Montville
> Sent: Tuesday, June 25, 2013 12:55 AM
> To: Black, David; [e-mail]
> Subject: Re: [mile] Request for draft reviews - review of IODEF Enumeration
> Reference
> 
> David, before I forget, thanks for the assistance here.  I haven't 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:[e-mail]]
> Sent: Tuesday, June 18, 2013 6:48 AM
> To: Adam Montville; [e-mail]
> Subject: RE: [mile] Request for draft reviews - review of IODEF Enumeration
> Reference
> 
> Hi Adam,
> 
> The -02 version of this draft was definitely useful, and it's 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, here's a recent RFC
> that is entirely IANA Considerations:
> 
>       http://www.rfc-editor.org/rfc/rfc6580.txt
> 
> The IANA considerations text in Take's 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 we'd like to
> exclude.  Moreover, I'm 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 I'd 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]+$
> 
> I'd 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?  It's 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 can't 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, I'd suggest as little as we can get away with for version format
> restrictions, as the spec authors who choose versions probably won't 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, I'd 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).
> 
> I'd 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Panos Kampanakis (pkampana)
> Sent: Thursday, June 06, 2013 3:42 PM
> To: Adam Montville; [e-mail]; 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:[e-mail]]
> Sent: Thursday, June 06, 2013 1:39 PM
> To: Panos Kampanakis (pkampana); Moriarty, Kathleen; [e-mail]; Adam
> Montville
> Subject: RE: [mile] Request for draft reviews - review of IODEF Enumeration
> Reference
> 
> Thank you!  I'll 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 there's a better way to do this, let's do it.
> 
> Adam
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Panos Kampanakis (pkampana)
> Sent: Thursday, June 06, 2013 8:33 AM
> To: Moriarty, Kathleen; [e-mail]; Adam Montville
> ([e-mail])
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Moriarty, Kathleen
> Sent: Friday, May 17, 2013 2:13 PM
> To: [e-mail]
> 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.
> 
> ...

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.