Re: [mile] early AD-review of draft-ietf-mile-template

Thanks, Sean!

In an attempt to help at #2, we could also consider the following definition of an incident (section 2.2.7) from early work setting the initial IODE requirements.  The definition covers a security incident and an IT incident.

http://tools.ietf.org/html/rfc3067

Thanks,
Kathleen

-----Original Message-----
From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner
Sent: Thursday, April 26, 2012 3:19 PM
To: mile@ietf.org
Subject: [mile] early AD-review of draft-ietf-mile-template

Here's my early AD-review.

spt

--------------

1) s1: r/a section Appendix A/a section (Appendix A)

2) s1: r/of an Internet-Draft/for an Internet-Draft

3) s2, bullet 1: Definition of "incident": Not sure if you want to do 
this, but there's a definition in RFC 4949 (the internet security 
glossary) for incident and that points to security incident:

  $ security incident
     1. (I) A security event that involves a security violation. (See:
     CERT, security event, security intrusion, security violation.)

I think this is also pretty vague, but it might give those who need a 
clue maybe some more clue.  Basically just add an informative reference 
to RFC 4949.  Up to you.

4) s2, bullet 2: Contains the following statement:

    If, after detailed examination of the problem area and
    the IODEF specification, ...

How about we add the concept of examination *and consultation* to not so 
subtly suggest that people openly talk about their idea with this 
community (or at least somebody in the know) before embarking on doing 
an internet-draft.  So maybe:

    If, after detailed examination and consultation (possibly with the
    IODEF Expert reviewer) of the problem area and the IODEF
    specification, ...

* Trying to figure out where the IODEF expert will be listed so we can 
point to it, but we can add the pointer later.

5) s7.1:

The reference for 5226 is probably now informative?

Update the reference to 6545.

Drop reference to 3688.

6) Appendix A: I'm mildly concerned that somebody will read this and say 
"well hold on there you might be conflicting with the RFC editor's 
requirements."  I think you probably need to add some text in the intro 
that says that any rules, as specified by the RFC editor, obviously take 
precedent to anything in this draft and that the latest version of the 
RFC editor's style guide should be consulted 
(http://www.rfc-editor.org/styleguide.html) for additional instructions. 
  Might also be worth mentioning that you're not going to talk about the 
abstract, status of this memo, copy right, and author addresses sections.

7) A.4.1: Can the types be extended/updated?  If so, then should that be 
mentioned here?

8) In A.5 it's worth noting that this section is required by the RFC 
editor.  You might also be worth an informative reference to RFC 3552 - 
though some people dislike this RFC (adding this reference is up to you).

9) A.6: Isn't the point of an extension document is that something is 
*always* registered?  If it is, then isn't this section always required?

10) A.7: Worth pointing out that this is required by the RFC editor.

11) A.8: r/should/will in the following:

  Each of the examples in section
  Appendix A.9 should be verified to validate against this schema by
  automated tools.

Under what circumstance would they not be?

12) A.8 and A.9 and I guess all appendices in this draft, should we 
require that they explicitly be marked as normative parts of the document?

13) Appendix B: Should we make up something to register as opposed to 
using something real? Maybe something like lottery #?
_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile