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 ). Why
would a simple wiki page  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;
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
Brian (as author, draft-ietf-mile-template)