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

[Adam Montville <[e-mail]>]

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]> [mailto:[e-mail]] On Behalf Of Panos Kampanakis (pkampana)
Sent: Thursday, June 06, 2013 8:33 AM
To: Moriarty, Kathleen; [e-mail]<mailto:[e-mail]>; Adam Montville ([e-mail]<mailto:[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]> [mailto:[e-mail]] On Behalf Of Moriarty, Kathleen
Sent: Friday, May 17, 2013 2:13 PM
To: [e-mail]<mailto:[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.