Last Call Review of draft-ietf-mile-enum-reference-format-10
review-ietf-mile-enum-reference-format-10-opsdir-lc-winter-2014-12-17-00

Hello,

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.
 These comments were written primarily for the benefit of the
operational area directors.

Document editors and WG chairs should treat these comments just like any
other last call comments.

I believe the draft is ready with one issue worth mentioning.

The content of the draft is indeed straightforward and a logical
addition to the existing IODEF XML Schema. It is important to be able to
specify not only a value, but also the format.

My only question is: why was an integer chosen for the identification of
the format?

Using an integer makes the IODEF report
a) less human-readable, because the reader needs to consult an external
"dictionary" to find out which format the value is in
b) requires systems which process the IODEF reports to have an always
up-to-date local dictionary to be able to map the integer value to the
Full Name / Abbreviation / Version.

Integer dictionaries are a common vehicle in protocols which are densely
packed and care about message lengths; e.g. RADIUS. Requiring up-to-date
dictionaries is difficult; RADIUS has many war stories to tell of
implementations which think a value is invalid (and, e.g. discard) while
they are simply a bit behind and don't know that the value is actually
meanwhile defined and in use.

IODEF is not in that category - an XML report in IODEF would typically
be very lengthy already, and it would not make much difference if there
is an attribute specIndex="1" or something more verbose like
specReference="urn:ietf:iodef:specList:CVE" (hypothetical example
assuming 1 = CVE, and a random URN branch).

Having more talkative names would at least make the reports more
human-readable. And for automated processing, so long as the processing
doesn't require knowing the corresponding "Full Name" "Abbreviation" or
"Specification URI" fields, it would be self-sufficient and would not
require an always-up-to-date dictionary.

In summary, the question would be: why define an IANA registry and XML
attribute for integers, where a registry of (say) URNs and XML attribute
for the corresponding string would be more readable - and thus easier to
manage for humans?

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me



http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66




Attachment:


0x8A39DC66.asc




Description:

 application/pgp-keys




Attachment:


signature.asc




Description:

 OpenPGP digital signature