Re: [Gen-art] Last Call Review: draft-ietf-mile-enum-reference-format-10

[Tom Taylor <[e-mail]>]

OK, thanks.

Tom

On 12/12/2014 7:36 PM, Black, David wrote:
> Tom,
>
>> Seems like you need a reference to 5070-bis rather than 5070, then.
>
> Actually, I think it's a mix, as RFC 5070 is appropriate to reference for
> design rationale, but the 5070-bis draft will be the first use of this,
> and much of the discussion in the draft is independent of IODEF version.
>
> I believe that RFC 5070 [IODEF] needs to move to an informative reference,
> and an informative reference to the 5070-bis draft [IODEFv2] needs to be
> added.  Both references would be informative as use of this format does not
> require implementation of any version of IODEF.
>
> To incorporate this reference update, I suggest the following text changes,
> many of which involve removing citations of RFC 5070 [IODEF] where the
> discussion is independent of IODEF version.  Please let us know whether
> this set of changes looks sufficient.
>
> -- Abstract
>
> OLD
>     but the IODEF Reference class
>     (as specified in RFC 5070) does not indicate how to include both of
>     these important pieces of information.
> NEW
>     but the IODEF Reference class
>     (as specified for IODEF v1 in RFC 5070) does not indicate how to include
>     both of these important pieces of information.
>
> OLD
>     While this memo does not update IODEF, it provides
>     the ability for future revisions of IODEF to leverage the
>     ReferenceName class herein described.
> NEW
>     While this memo does not update IODEF v1, this enumeration reference
>     format is used in IODEF v2 and is applicable to other formats that
>     support this class of enumeration references.
>
> -- Section 1 Introduction
>
>     There is an identified need to specify a format to include relevant
>     enumeration values from other data representation formats in an IODEF
>     [IODEF] document. It is anticipated that this requirement will exist
>     in other standardization efforts within several IETF Working Groups,
>     but the scope of this document pertains solely to IODEF [IODEF].
>
> Remove both of the above "[IODEF]" citations as the above text is independent
> of IODEF version.  To cover and cite IODEF versions, append the following
> sentence to the above paragraph:
>
>     This format is used in IODEF v2 [IODEFv2] which replaces the original
>     IODEF v1 [IODEF] specification.
>
> -- Section 2
>
>     The need is to place enumeration identifiers and their enumeration
>     format references in IODEF's [IODEF] Reference class.  There are
>     several ways to accomplish this goal, but the most appropriate at
>     this point is to require a specific structure for the ReferenceName
>     string of the IODEF [IODEF] Reference class, and use an IANA registry
>     to manage references to specific enumeration reference formats.
>
> Remove both "[IODEF]" citations as this discussion is independent of
> IODEF version.
>
>     Per IODEF [IODEF] the ReferenceName is of type ML_STRING.
>
> No change, leave "[IODEF]" citation; that sentence is specific to IODEF v1.
>
> -- Section 2.3 (will be 2.2) Reference Method Applicability
>
>        While the scope of this document pertains to IODEF [IODEF], it
>        should be readily apparent that any standard needing to reference
>        an enumeration identified by a specially formatted string can use
>        this method of providing structure after the standard has been
>        published.  In effect, this method provides a standardized
>        interface for enumeration formats, thus allowing a loose coupling
>        between a given standard and the enumeration identifiers it needs
>        to reference now and in the future.
>
> Remove "[IODEF]" citation, as this discussion is independent of IODEF
> version.
>
> -- Section 3  Security Considerations
>
> Remove all "[IODEF]" citations from this section, as the security
> considerations are independent of IODEF version.
>
> -- Section 4 IANA Considerations
>
> OLD
>        This document specifies an identifier format for the IODEF [IODEF]
>        ReferenceName string of the Reference class.  All fields,
>        including abbreviation, are mandatory.
> NEW
>        This document specifies an enumeration reference identifier format.
>        All fields, including abbreviation, are mandatory.
>
> The above rewrite aligns this text with text elsewhere (e.g., Section 2.3)
> indicating that this format has more general applicability beyond IODEF.
>
> Thanks,
> --David
>
>
>> -----Original Message-----
>> From: Tom Taylor [mailto:[e-mail]]
>> Sent: Tuesday, December 09, 2014 6:09 PM
>> To: Black, David; Gen Art; draft-ietf-mile-enum-reference-
>> [e-mail]
>> Subject: Re: Last Call Review: draft-ietf-mile-enum-reference-format-10
>>
>> Seems like you need a reference to 5070-bis rather than 5070, then.
>>
>> Tom
>>
>> On 09/12/2014 4:40 PM, Black, David wrote:
>>> Tom,
>>>
>>> Thanks for reviewing this draft.
>>>
>>>> Major issues: I am having a hard time reconciling the extension
>>>> procedures specified in Section 5 of RFC 5070 [IODEF] with the content
>>>> of the draft.
>>>
>>> No surprise there, as those extension procedures are not being used,
>>> although one would have to be a mile WG participant to understand why ...
>>>
>>>> As I see it, you have added an attribute to ReferenceName,
>>>> and this is actually not covered by RFC 5070. As I understand it, 5.1
>>>> covers ENUMs and 5.2 covers new classes. My conclusion is that this
>>>> document should update RFC 5070, describing how to add new attributes --
>>>> or is that the equivalent of adding a new class? Even if it were a
>>>> simple matter of adding ENUMs, where are the ext- declarations called
>>>> for by Section 5.1 of RFC 5070?
>>>
>>> The mile WG is in the process of replacing RFC 5070 with a new IODEF v2
>>> including a new XML schema that will use the enum ref format schema in
>>> the draft that you reviewed.  Here's the 5070bis draft:
>>>
>>> http://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/
>>>
>>> This topic was discussed in the mile WG meeting in Honolulu, and the
>>> course of action that resulted is to not update RFC 5070 or provide
>>> extension definitions for it because RFC 5070 will be replaced soon.
>>>
>>> Thanks,
>>> --David
>>>
>>>> -----Original Message-----
>>>> From: Tom Taylor [mailto:[e-mail]]
>>>> Sent: Tuesday, December 09, 2014 1:25 PM
>>>> To: Gen Art; [e-mail]
>>>> Subject: Last Call Review: draft-ietf-mile-enum-reference-format-10
>>>>
>>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>>> Gen-ART, please see the FAQ at
>>>>
>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>>
>>>> Please resolve these comments along with any other Last Call comments
>>>> you may receive.
>>>>
>>>> Document: draft-ietf-mile-enum-reference-format-10
>>>> Reviewer: Tom Taylor
>>>> Review Date: 9/12/2014
>>>> IETF LC End Date: 16/12/2014
>>>> IESG Telechat date: (if known)
>>>>
>>>> Summary: Basically a well-written document with tiny nits. The "major
>>>> issue" may simply be a matter of my inexperience with XML schemas.
>>>>
>>>> Major issues: I am having a hard time reconciling the extension
>>>> procedures specified in Section 5 of RFC 5070 [IODEF] with the content
>>>> of the draft. As I see it, you have added an attribute to ReferenceName,
>>>> and this is actually not covered by RFC 5070. As I understand it, 5.1
>>>> covers ENUMs and 5.2 covers new classes. My conclusion is that this
>>>> document should update RFC 5070, describing how to add new attributes --
>>>> or is that the equivalent of adding a new class? Even if it were a
>>>> simple matter of adding ENUMs, where are the ext- declarations called
>>>> for by Section 5.1 of RFC 5070?
>>>>
>>>> Minor issues:
>>>>
>>>> Nits/editorial comments:
>>>>
>>>> Tiny nit, third paragraph of Security Considerations:
>>>>        s/third-party/third party/ (three times)
>>>> Former is an adjective, but contecxt requires a noun.
>>>>
>>>> The last sentence of the IANA Considerations section has a forward
>>>> reference to Section 6 which should instead be Section 5.
>>>
>>>
>