Subject: Re: [mile] APPSDIR review of draft-ietf-mile-template-02

From: Brian Trammell <[email-masked]>
Date: Wed, 7 Mar 2012 09:12:52 +0100

Greetings, all,

On discussion with Sean, it's become clear that the intended status of BCP to allow the template draft to require expert review for IODEF extensions is not the right approach; so, we're going to have to split the draft back in two (which is, after all, what's in the charter): an informational -mile-template and a standards-track iodef-xmlreg.

So, I've submitted draft-trammell-mile-iodef-xmlreg-01, which contains the relevant language for specifying this (and is essentially the same as the -00 revision of this draft from last July with a new date). I'd like to ask for adoption as a WG item in Paris.

There is still an open issue as to whether iodef extensions should have their own subregistry or not (see quoted portion of review, below); I'll take this up with IANA. If anyone on the list has any opinions on this, please share them. :) Once that's resolved, this draft will also IMO be ready for WGLC (assuming it's adopted of course), since the text has already been through WGLC in the mile-template document.

I'll submit new revision of -mile-template which removes the IODEF XML registry language, and addresses other APPSDIR review comments later today.

Cheers,

Brian (as -template and -iodef-xmlreg author)

On Feb 29, 2012, at 5:36 PM, Brian Trammell wrote:

> Hello, Martin,
> 
> Many thanks for your (thorough!) review! Replies to these points, inline.
> 
> On Feb 29, 2012, at 11:28 AM, Martin J. Dürst wrote:
> 
>> I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
>> 
>> Please resolve these comments along with any other comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
>> 
>> Document: draft-ietf-mile-template-02
>> Title: Guidelines for Defining Extensions to IODEF
>> Reviewer: Martin Dürst
>> Review Date: 2012/02/29
>> 
>> 
>> Summary: This document may be ready for publication as a BCP after fixing some issues.
>> 
>> 
>> Mayor Issues:
>> 
>> This draft is extremely short (the main text is less than three pages). I'm not at all sure if it is worth spending a BCP number on it. Given the fact that it's a deliverable of the mile WG, for the rest of this review, I'm assuming that this has been discussed before, and the answer was positive. However, I'm nevertheless seriously wondering whether it would not be better to have a bit more experience with actual extension documents before putting best current practice in RFC form. (I can only see two extension documents at http://datatracker.ietf.org/wg/mile/; experience from both the IETF and the W3C shows that it may take considerable time to get extensions right.)
> 
> The status of the draft was indeed discussed in the WG, and we were indeed expecting a discussion on its intended status after sending it up. The content of the template itself is essentially informational: we have a lot of contributions from people just coming into the IETF community, so we wanted a template to help jumpstart these authors's efforts. 
> 
> On the other hand, the IANA note requires a standards action. BCP was the result, but we agree it's a little weird.
> 
>> Section 6, IANA Considerations, says:
>>  [IANA NOTE: The authors request that IANA include a note at the top
>>  of http://www.iana.org/assignments/xml-registry/schema.html, stating
>>  "Changes to the XML Schema registry for schema names beginning with
>>  'urn:ietf:params:xml:schema:iodef' are subject to an additional IODEF
>>  Expert Review [RFC5226]," and naming the designated expert.]
>> The example in the appendix (urn:ietf:params:xml:schema:iodef-myextension-1.0) shows that "names beginning with
>> 'urn:ietf:params:xml:schema:iodef" refers to a simple textual prefix match. I'd expect that this is rather difficult to implement for IANA, and it definitely doesn't scale well at all (e.g. if other frameworks also add such restrictions). It would probably be better to have a separate registry e.g. under urn:ietf:params:xml:schema:iodef: or urn:ietf:params:xml:iodef-extension-schema: or some such.
> 
> I suppose we could use a separate registry if it simplifies things (we honestly hadn't considered the scalability issues that would result from this being a precedent, good point), but there are already extensions in the present registry following the "textual match" semantics:
> 
> iodef-phish-1.0	 urn:ietf:params:xml:schema:iodef-phish-1.0 [RFC5901]
> iodef-rid-1.0	 urn:ietf:params:xml:schema:iodef-rid-1.0   [RFC6045]
> iodef-rid-2.0	 urn:ietf:params:xml:schema:iodef-rid-2.0   [RFC-ietf-mile-rfc6045-bis-11.txt]
> 
> So, we'd have to split the registry. 
> 
> It also appears that "subregistries" (e.g. urn:ietf:params:xml:schema:pidf:*) are kept in the same registry, so I'm not sure whether 'urn:ietf:params:xml:schema:iodef-' is harder to manage than 'urn:ietf:params:xml:schema:iodef:'.
> 
> Perhaps the right thing here is to refer this to IANA?