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

Brian Trammell <trammell@tik.ee.ethz.ch> Wed, 23 May 2012 12:08 UTC

Return-Path: <trammell@tik.ee.ethz.ch>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D4521F86AA; Wed, 23 May 2012 05:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIf1BONb80fm; Wed, 23 May 2012 05:08:32 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5B94121F86A4; Wed, 23 May 2012 05:08:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8C38ED930A; Wed, 23 May 2012 14:08:30 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0jO0Funr0bzk; Wed, 23 May 2012 14:08:30 +0200 (MEST)
Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 5D494D9307; Wed, 23 May 2012 14:08:30 +0200 (MEST)
Subject: Re: [mile] Last Call: <draft-ietf-mile-template-04.txt> (Guidelines for Defining Extensions to IODEF) to Informational RFC
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Brian Trammell <trammell@tik.ee.ethz.ch>
In-Reply-To: <4FBA5C59.4030102@stpeter.im>
Date: Wed, 23 May 2012 14:08:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DAAC19A0-9FF8-4DF4-B7CD-9A843743D2E5@tik.ee.ethz.ch>
References: <20120516215321.9671.39664.idtracker@ietfa.amsl.com> <4FB46FA6.6060005@stpeter.im> <B06DB832-2813-4431-94B9-1F7B3492A595@tik.ee.ethz.ch> <4FBA5C59.4030102@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1278)
Cc: "<mile@ietf.org>" <mile@ietf.org>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 May 2012 12:08:33 -0000

Hi, Peter,

One minor point, inline...

On May 21, 2012, at 5:16 PM, Peter Saint-Andre wrote:

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

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,

Brian (as author, draft-ietf-mile-template)