Alexey, I'll comment on this one, as that was text that I contributed to the draft:
> Allocation Policy: Expert Review [RFC5226] and Specification > Required [RFC5226] . > > (And similar text in 4.1: > > The table is to be managed by IANA using the Expert Review [RFC5226] > and Specification Required [RFC5226] allocation policies as further > specified in Section 7 . > ) > > I think this is not very clear. If you just meant Specification required > (which implies Expert review), I would describe it as: > > Allocation Policy: Specification Required [RFC5226] (which includes > Expert Review [RFC5226]). That was the intent; your suggestion is clearer. Thanks, --David > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alexey Melnikov > Sent: Thursday, October 17, 2013 9:40 AM > To: [email protected] > Cc: <[email protected]> Team; The IESG > Subject: [Gen-art] Gen-ART LC Review of draft-ietf-mile-sci-09 > > 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-sci-09.txt > Reviewer: Alexey Melnikov > Review Date: 2013-10-16 > IETF LC End Date: 2013-10-22 > > Summary: This draft is nearly ready for publication as a Standard Track > document. > > Major issues: > > I have a couple of IANA related questions/comments about this document. > I hope they would be easy to address. > > In 4.1: > > The SpecID attributes of extended classes (Section 4.3) must allow > the values of the specifications' namespace fields, but otherwise, > implementations are not required to support all specifications of the > IANA table and may choose which specifications to support, though the > specification listed in the initial table needs to be minimally > supported, as described in Section 5. In case an implementation > received a data it does not support, it may expand its functionality > by looking up the IANA table or notify the sender of its inability to > > I've been told in the past that IANA's website is not designed for mass > retrieval of data by multiple devices. So very few (if any) > specifications actually recommend automatic download of data from IANA's > website. I think this needs to be discussed with IANA. > > parse the data by using any means defined outside the scope of this > specification. > > In Section 7: > > Allocation Policy: Expert Review [RFC5226] and Specification > Required [RFC5226] . > > (And similar text in 4.1: > > The table is to be managed by IANA using the Expert Review [RFC5226] > and Specification Required [RFC5226] allocation policies as further > specified in Section 7 . > ) > > I think this is not very clear. If you just meant Specification required > (which implies Expert review), I would describe it as: > > Allocation Policy: Specification Required [RFC5226] (which includes > Expert Review [RFC5226]). > > If you meant for Expert Review to be used as an alternative when there > is no specification, then you need to rephrase this to be clear. > > Minor issues: > > 4.2. Extended Data Type: XMLDATA > > This extension inherits all of the data types defined in the IODEF > model. One data type is added: XMLDATA. An embedded XML data is > represented by the XMLDATA data type. This type is defined as the > extension to the iodef:ExtensionType [RFC5070] , whose dtype > attribute is set to "xml." > > I think you meant "xml". I.e. the value doesn't include any dots. > > > In 4.3.1: > > Platform: Zero or more. An identifier of software platform involved > in the specific attack pattern, which is elaborated in > Section 4.3.2 . > > It would be good to have an idea of what kind of values can be used. In > particular I am thinking if you are planning to reuse any existing > registries. > > In Section 9.1: > > [MMDEF] IEEE ICSG Malware Metadata Exchange Format Working Group, > "Malware Metadata Exchange Format". > > [EICAR] European Expert Group for IT-Security, "Anti-Malware > Testfile", 2003. > > These 2 references don't look Normative, as they are only used in an > example. > > Nits: > > 1. Introduction > > To efficiently run cybersecurity operations, these exchanged > information needs to be machine-readable. IODEF provides a > structured means to describe the information, but it needs to embed > various non-structured such information in order to convey detailed > > Delete "such" before "information"? If that is not the right fix, > then I don't know what you were trying to say here. > > information. Further structure within IODEF increases IODEF > documents' machine-readability and thus facilitates streamlining > cybersecurity operations. > > In Section 3, last paragraph: > > Another example is that, when an administrator wishes to check the > configuration of host computers in his organization, he may send a > query to host computers, which may automatically generate XML-based > software configuration information upon receiving thequery by running > > thequery --> the query > > a software and may embed that to an IODEF document, which is then > sent back to the administrator. > > In 4.3.5: > > WeaknessID: OPTIONAL. STRING. An identifier of a weakness to be > reported. This attribute SHOULD be used whenever such identifier > is available/ Both RawData and Reference elements MUST NOT be used > > I think you meant "." instead of "/". > > when this attribute is used, while either of them MUST be used if > this attribute is omitted. > > 4.3.7. Verifcation > > typo: Verification > > A Verification consists of an extension to the > Incident.AdditionalData element with a dtype of "xml". The extension > elements describes incident on vefifying incidents. > > typo: verifying > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
