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

["Black, David" <[e-mail]>]

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