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/