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

[Jari Arkko <[e-mail]>]

Tom, 

Thanks for the review. And thank you David and others for the updates.

Jari

On 13 Dec 2014, at 03:55, Tom Taylor <[e-mail]> wrote:

> 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.
>>>> 
>>>> 
>> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art