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

Sure or you could point to both or neither ;)

spt

On 4/26/12 3:31 PM, kathleen.moriarty@emc.com wrote:
> 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
>
>