Subject: Re: [mile] Working Group Last Call for draft-ietf-mile-enum-reference-format

From: Alexey Melnikov <[email-masked]>
Date: Sun, 11 May 2014 20:54:53 +0100

> On 8 May 2014, at 12:30, "Takeshi Takahashi" <[email-masked]> 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.

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?

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

---

From: "Black, David" <[email-masked]>
Date: Sun, 11 May 2014 18:45:59 -0400

Alexey,

Thanks for the review - I'll take the IANA topics ...

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

Hmm ... my recollection is that this text was intended to encourage the
Designated Expert for the registry to use his/her best judgment to exclude
"unprintable" acronyms and the like.  I think we can assume that any such
expert reviewer will do that anyway and simply delete this sentence.

> Nit: I think it would be better to say "Specification Required (which implies

Sure, that makes sense to me.

Thanks,
--David

> -----Original Message-----
> From: mile [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: Sunday, May 11, 2014 3:55 PM
> To: <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [mile] Working Group Last Call for draft-ietf-mile-enum-
> reference-format
> 
> 
> > send your comments to the mailing list; we'd a so appreciate a comment if
> 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?
> 
> 
> 4  IANA Considerations
> 
> 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".
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: Adam Montville <[email-masked]>
Date: Sun, 18 May 2014 18:57:49 -0500

> General comment: Is this intended as Proposed Standard? The draft header doesn't say the document type.

I'll update this, thank you.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 May 2014 13:29:01 +0100

Hi Adam,

> <[email-masked]> wrote: 
  [...]
>> 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)?
I think some discussion of this would be helpful. It can be entirely 
informative.
> 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 was expecting that the XML Schema in your document would make it 
clear. But instead you introduced a new XML element which doesn't seem 
to be connected to ReferenceName. So either updating the XML Schema or 
saying that explicitly would help.
> 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?

Best Regards,
Alexey

---

From: Adam Montville <[email-masked]>
Date: Mon, 19 May 2014 06:33:34 -0700

On May 19, 2014, at 5:29 AM, Alexey Melnikov <[email-masked]> wrote:

>>> 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)?
> I think some discussion of this would be helpful. It can be entirely informative.

I'll add some discussion about this to the draft, unless you intend for further discussion to be held here, on the list, before any updates to the draft are made.

>> 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 was expecting that the XML Schema in your document would make it clear. But instead you introduced a new XML element which doesn't seem to be connected to ReferenceName. So either updating the XML Schema or saying that explicitly would help.

I can change the schema in the draft.  It's my mistake that the schema is new, when it really should amend the schema expressed in 5070.