On 5/18/12 6:13 AM, Brian Trammell wrote: > Hi, Peter, all, > > Many thanks for the comments; And to you for following up. > replies inline... Likewise. > 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. Thanks for the clarifications. I chatted about this I-D offlist with Sean Turner and he explained that a bunch of folks who are not familiar with the IETF might be coming here to define IODEF extensions, so I now think that an Informational RFC could be useful. >> 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... As mentioned, I happen to be working on some IODEF extensions that are specific to the XMPP community. Is it expected that I work on the relevant spec in the MILE WG, in the XMPP WG, or (as I'm doing right now) at the XMPP Standards Foundation? IMHO, doing this work at the XSF makes the most sense because that's where most of the XMPP developers and operators are active. Seeking a sanity check on this work from the MILE WG does seem reasonable, though (once it's ready for review). >> 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. IMHO, it seems fine to repeat some of that information, as long as you say that the styleguide rules on general matters of RFC authorship. But your AD might know better. ;-) Peter -- Peter Saint-Andre https://stpeter.im/