Re: [mile] Reference and related nits in draft-ietf-mile-enum-reference-format

[Adam Montville <[e-mail]>]

David, thank you.  I've noted all of these and will make appropriate updates.

Are there other comments other than those posed by Alexey and David?

On May 18, 2014, at 7:39 PM, Black, David <[e-mail]> wrote:

> Hi Adam,
> 
>> With respect to your first sentence above, I assert that the document does not
>> "seem" to update ReferenceName, but actually does. :-)  Is it necessary to
>> explicitly state the obvious in this case?  I'm happy to update the document,
>> but I'm not sure I believe such a statement is necessary.  If it is necessary,
>> then a single sentence can be added to the abstract making the statement.
>> Thoughts here?
> 
> In this case, it is necessary to state the obvious for the sake of clarity -
> I've been there and had to do that ;-).  In addition to a sentence in the
> abstract, the header on the title page needs an "Updates: 5070 (if approved)"
> line, and a section should be added entitled "Summary of Changes to RFC 5070"
> that identifies the changes.
> 
> For a somewhat longer recent example, see RFC 7146:
> 	http://datatracker.ietf.org/doc/rfc7146/
> 
> ----------------
> 
> Here are some additional editorial nits that need attention ...
> 
> a) I recently had another draft dinged by the IESG for using a citation as
> a word in a sentence e.g., "[IODEF]" in the first sentence in Section 2:
> 
>   The need is to place enumeration identifiers and their references in
>   [IODEF]'s Reference class.
> 
> Believe it or not, the appropriate change is "[IODEF]" -> "IODEF [IODEF]" -
> I suggest just doing this and not asking why :-). The whole draft should be
> checked for other uses of citations in this fashion.
> 
> b) In addition, references should not be cited in the abstract, so I believe
> the appropriate changes to the two citations in the abstract are:
> 
>   The Incident Object Description Exchange Format [IODEF] provides a
> 
> 		"[IODEF]" -> "(IODEF)"
> 
>   Reference class used to reference external entities (such as
>   enumeration identifiers).  However, the method of external entity
>   identification has been left unstructured.  This document describes a
>   method to provide structure for referencing external entities for the
>   [IODEF] Reference class.
> 
> 		"[IODEF]" -> "IODEF"
> 
> Otherwise, the draft still looks good.
> 
> Thanks,
> --David
> 
>> -----Original Message-----
>> From: mile [mailto:[e-mail]] On Behalf Of Adam Montville
>> Sent: Sunday, May 18, 2014 7:58 PM
>> To: Alexey Melnikov
>> Cc: <[e-mail]>; [e-mail]
>> Subject: Re: [mile] Working Group Last Call for draft-ietf-mile-enum-
>> reference-format
>> 
>> 
>> On May 11, 2014, at 2:54 PM, Alexey Melnikov <[e-mail]>
>> wrote:
>> 
>>> 
>>>> On 8 May 2014, at 12:30, "Takeshi Takahashi" <[e-mail]>
>> wrote:
>>>> 
>>>> Greetings, all,
>>>> 
>>>> This is the Working Group Last Call for
>>>> draft-ietf-mile-enum-reference-format, IODEF Enumeration Reference Format.
>>>> 
>>>> The last call starts now, and ends Monday 26 May 2014.
>>>> 
>>>> Please read the latest revision of the draft,
>>>> http://tools.ietf.org/html/draft-ietf-mile-enum-reference-format-04, and
>>>> send your comments to the mailing list; we'd also appreciate a comment if
>>>> you're fine with the draft as is.
>>> 
>>> Hi,
>>> Below is my review of the draft:
>>> 
>>> General comment: Is this intended as Proposed Standard? The draft header
>> doesn't say the document type.
>> 
>> I'll update this, thank you.
>> 
>>> 
>>> The document seems to update ReferenceName syntax to allow for nested XML
>> elements. However the document doesn't say that.
>>> In relationship to this: would this document cause any interoperability
>> issues with programs that can only parse the old schema?
>> 
>> I am unsure about interoperability issues, but they should be minimal and are
>> likely implementation specific.
>> 
>> I tried an experiment where I generated some code (JAXB) for IODEF 1.0 and
>> then fed it a modified recon example (Section 7.2 from RFC 5070).  The
>> <ReferenceName> element contained an <EnumRef> element as opposed to the
>> string "nmap".  Unmarshalling seemed to work without issue, but when examining
>> the ReferenceName element , the only thing present was a newline character.
>> In an example that doesn't use generated code but instead uses a SAX or DOM
>> parser, we can grab the inner XML.  Using a validating DOM/SAX/other parser
>> will, of course, break if the enumeration reference XML is embedded, so
>> parsers will need to be updated.
>> 
>> I'm not a professional implementor, so it would be good to hear considerations
>> from others.  Then, should these considerations be placed in the document (I
>> assume that was the good point of raising the issue)?
>> 
>> With respect to your first sentence above, I assert that the document does not
>> "seem" to update ReferenceName, but actually does. :-)  Is it necessary to
>> explicitly state the obvious in this case?  I'm happy to update the document,
>> but I'm not sure I believe such a statement is necessary.  If it is necessary,
>> then a single sentence can be added to the abstract making the statement.
>> Thoughts here?
>> 
>> 
>>> 
>>> 
>>> 4  IANA Considerations
>>> 
>>>     Note that certain name requests should not be permitted as either
>>>     Full Name or Abbreviation entries for the requested IANA table.
>>> 
>>> Do you mean restrictions imposed by the syntax described below or something
>> else? If you intended to exclude some specific keywords, where is the list of
>> them defined? Either way, I think you need to clarify. If you just meant the
>> ABNF restrictions, I suggest adding something like "The restrictions are
>> specified in the ABNF below".
>>> 
>>>     Allocation Policy: Expert Review [RFC5226] and Specification
>>>     Required [RFC5226]
>>> 
>>> Nit: I think it would be better to say "Specification Required (which
>> implies Expert Review)".
>>> 
>>> _______________________________________________
>>> mile mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mile
>