Hi, Peter, all, Many thanks for the comments; replies inline... On May 17, 2012, at 5:25 AM, Peter Saint-Andre wrote: > On 5/16/12 3:53 PM, The IESG wrote: >> >> The IESG has received a request from the Managed Incident Lightweight >> Exchange WG (mile) to consider the following document: >> - 'Guidelines for Defining Extensions to IODEF' >> <draft-ietf-mile-template-04.txt> as Informational RFC > > Although this document does no harm, I have my doubts that the topic > warrants publication of an RFC (and I say that as someone who is > defining some IODEF extensions for use on the XMPP network [1]). Why > would a simple wiki page [2] not suffice? Indeed, it may; the WG decided we wanted something semi-permanent to give guidance to extension authors, especially given that we anticipated (and have had) significant participation from people with little or no previous involvement in the IETF. Whether that's an RFC or not is, but an RFC seemed the natural thing to do, as it is how things are published out of IETF WGs. The previous version of this document _did_ need to be an RFC as it specified a change to the IANA XML registry requiring a Standards Action; this has been split out into draft-ietf-mile-iodef-xmlreg per AD guidance. > If we decide than an RFC is needed, I have some more actionable feedback... > > 1. The document could be construed as assuming that IODEF extensions > will all be defined in Internet-Drafts, that extension namespaces will > be registered with IANA, and even that namespaces will be of the form > 'urn:ietf:params:xml:schema:iodef-*'. It might be helpful to clarify the > intended applicability of this document, i.e., merely as helpful > suggestions for authors of Internet-Drafts, not truly as universally > applicable guidelines for defining IODEF extensions. Hm. The document does indeed assume that extensions to IODEF are defined in Internet-Drafts, that extension namespaces will be registered with IANA, and that those namespaces be of the described form; it makes these assumptions because that is the intent of the document. Whether that's "universal" or not could be an open question, perhaps, but the intent is to specify a more restrictive method of extension than that in 5070 in the interests of consistency. So, yes, it's an informational document, they're just helpful suggestions, but we would hope they'd be followed, and the document is written assuming that they will... > 2. Why is RFC 6545 a normative reference? Oversight, should be informative (I checked this briefly; it is referenced from a section entitled "Terminology", but this is terminology in the Appendix; oops.) > 3. Given the many comments provided by Martin Dürst, mentioning his > AppsDir review in the Acknowledgements seems appropriate. Indeed, also oversight; thanks. > 4. Some of the text in the appendix seems needlessly detailed (e.g., > saying that each extension needs to be specified in a subsection, or the > recommendation to include a UML diagram). These guidelines are intended to help the set of drafts defining IODEF extensions to be consistent with RFC 5070 and with each other. > 5. Why is the list of datatypes in appendix A.4.1 copied from RFC 5070? > A simple reference would do. (I almost said the same about the list in > Section 3, but that one is marginally useful.) The A.4.1. list was copied over because doing so was consistent with the list in Section 3, more or less; it's intended to give an inline definition of the allowable TYPE values as in the UML diagram in Figure 1, section A.4. (Copying this was also consistent with the inclusion of the list in Section 3.) > 6. Some of the information in this document repeats information from the > RFC style guide and other sources; why? Here we have a duelling-commenters situation; this is per early-AD commentary in http://www.ietf.org/mail-archive/web/mile/current/msg00657.html and the subsequent thread. Best regards, Brian (as author, draft-ietf-mile-template)