Subject: Re: [mile] Last Call: <draft-ietf-mile-template-04.txt> (Guidelines for Defining Extensions to IODEF) to Informational RFC

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 May 2012 21:25:26 -0600

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?

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.

2. Why is RFC 6545 a normative reference?

3. Given the many comments provided by Martin Dürst, mentioning his
AppsDir review in the Acknowledgements seems appropriate.

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).

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.)

6. Some of the information in this document repeats information from the
RFC style guide and other sources; why?

Peter

[1] http://xmpp.org/extensions/xep-0268.html

[2] http://trac.tools.ietf.org/wg/mile/trac/wiki

---

From: SM <[email-masked]>
Date: Wed, 16 May 2012 23:50:23 -0700

At 14:53 16-05-2012, The IESG wrote:
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2012-05-30. Exceptionally, comments may be

The Abstract mentions that this draft contains a template for 
[writing] Internet-Drafts describing [extensions to IODEF].  Why is a 
RFC needed for a template to write I-Ds?  It seems like the WG is 
encouraging future authors to copy and paste the text and generate new RFCs.

Regards,
-sm

---

From: Brian Trammell <[email-masked]>
Date: Fri, 18 May 2012 14:13:25 +0200

Hi, Peter, all,

Many thanks for the comments; replies inline...

> 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.

> 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.)

> AppsDir review in the Acknowledgements seems appropriate.

Indeed, also oversight; thanks.

> 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.

> 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.)

> 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)

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 May 2012 09:16:41 -0600

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.

>>> 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' 
>> 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.

>> 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).

> 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.
> 
>> 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/

---

From: Brian Trammell <[email-masked]>
Date: Wed, 23 May 2012 14:08:28 +0200

Hi, Peter,

One minor point, inline...

> MILE WG does seem reasonable, though (once it's ready for review).

This is IMO the right way to go. During the creation of this document, we envisioned in most cases that work to extend IODEF would not have any other "natural" home, and as such would be done within the IETF in the MILE WG; this assumption is probably apparent in the document.

In cases where the work _does_ have a natural home (the application of IODEF to XMPP-specific events is a perfect example), it definitely makes sense to do work there in possible consultation with the MILE WG.

Indeed, for such cases, the IODEF expert review on IODEF extension schemas specified by draft-ietf-mile-iodef-xmlreg would be a final backstop to ensure that specified extensions are consistent with IODEF.

Best regards,

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 30 May 2012 14:16:52 +0200

Hi, 

The inclusion of the template as an Appendix in the document is
confusing - right now A.1 through A.7 define sections in the future
I-Ds, while A.8 and A.9 describe appendices in the future I-D. This
document has two sections each titled Appendix A and Appendix B.
Moreover, this inclusion has the disadvantage that if changes or updates
need to be brought up for reasons whatsoever, a new RFC needs to be
written. Did the author and the WG considered adopting the approach
taken by RFC 5249 which located the templates under the IETF tools web
pages and only referred them from the RFC? 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:ietf-announce-
> [email-masked]] On Behalf Of The IESG
> Sent: Thursday, May 17, 2012 12:53 AM
> To: IETF-Announce
> Cc: [email-masked]
> Subject: Last Call: <draft-ietf-mile-template-04.txt> (Guidelines for
> DefiningExtensions to IODEF) to Informational RFC
> 
> 
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This document provides guidelines for extensions to IODEF [RFC5070]
>    for exchange of incident management data, and contains a template
> for
>    Internet-Drafts describing those extensions, in order to ease the
>    work and improve the quality of extension descriptions.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-mile-template/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-mile-template/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
>