Re: [mile] WGLC: Review of draft-ietf-mile-template-03

[Brian Trammell <[e-mail]>]

hi, Kathleen,

Thanks for your comments! I've incorporated these into the -04 working revision, which I'll submit shortly. Comments/questions inline.

On May 2, 2012, at 3:55 PM, <[e-mail]> <[e-mail]> wrote:

> This list does not include "restriction'.  I know it is not currently listed as one that can be extended, but I suspect that may change in and RFC5070-bis from comments I have heard on difficulties with the limited set... or it may get solved with an extension that enables additional ways to mark data.  I am not sure there is a way to do this, but if we added something that said updated versions of IODEF may change this list so that folks not as familiar with following references to the updates and then understanding that the change is possible with new versions of IODEF.

I've added a note (as with one on types, as per Sean's comments) that the list is current but may change in the future, check documents that update 5070.

> Appendix B:  How do we get new enumerated Type extensions and new attribute values into the schema?  Do we also need a table where these get added so that they can be included in the current schema version, then where there are updates, if they have been useful, we pull them into the new IODEF schema version?  We may need to set that up here?  Any thoughts? Or is this handled some other way?  I had a table created for RID to serve this purpose.  DO we want to do the same thing here?  Sorry I didn't catch it sooner.

Couple of issues here that I can see, that follow from how the IODEF extension mechanism works.

1. IODEF basically defines the contents of an extension attribute, AdditionalData, and RecordItem to be free-form; so there's nowhere in IODEF to note a specific extension is in use, other than in the inclusion of schemas/namespaces in the XML document itself.

2. Since IODEF extensions need to use extension attributes and AdditionalData/RecordItem, pulling them into a new IODEF schema version, at which point I presume we'd want to take them out of AdditionalData and incorporate them as "first class members" of the document (whether by joining the enumeration or being directly contained without an AdditionalData in the way) would cause them to be non-interoperable with previous versions of IODEF. 

Not sure what the solution to these is, but I think the right place to address them is probably in any update to IODEF itself, not in the template.

Best regards,

Brian (author hat)