Last Call comments on draft-strombergson-shf-04.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



My first overall thought is "why??"
Not everything needs to be wrapped in XML, and in this case, it appears
that there are few real benefits and a number of significant drawbacks.

It is difficult to tell from the document whether the authors actually
intend this format as a substitute for programming-data formats like
S-records, or as a format for transferring data dumps over the Internet.
It has a number of drawbacks which would seem to make it unsuitable for
the former case, and doesn't seem to offer much over a raw hex dump
for the latter.  It would be helpful if the authors could clarify the
intended application for this format.

I would also advise the authors and other interested parties to examine
draft-housley-cms-fw-wrap-09.txt, on which an IETF Last Call recently
concluded.  It describes a method for securely transporting firmware
images over the internet and directly to hardware devices.  While it is
too complex to be suitable for direct programming of low-level devices,
it is quite appropriate for delivery as far as the workstation, device
programmer, or bootloader.  [Note that I have nothing to do with that
document, other than having recently reviewed it]


In any case, I see a number of problems, some of which are significant;

- This specification repeatedly uses the word "byte" to refer to an octet.
 Further, it prohibits representation of data with word sizes which are
 not multiples of 8 bits, claiming that such things are not used in
 "practical present-day applications".  While byte sizes other than 8 bits
 and word sizes which are not multiples of 8 bits have become extremely
 uncommon in general-purpose computing devices, they are still used in
 more special-purpose devices, and many of the low-level devices which
 are within the stated scope of this document are programmed with data
 which uses "odd" word sizes.

- The introduction indicates an intent to provide an alternative to
 formats used for "hexadecimal data" and particularly device programming
 data, the de facto standard "S-record" format is mentioned by name.
 However, it fails to capture a fundamental property of such formats,
 which is that they are generally simple enough to send to a device or
 programmer without further parsing.  The authors admit that an XML
 parser is "not easily deployed in hardware devices", but suggest that
 instead a workstation should be used to convert data from the specified
 format into one the device can actually handle.

 If this is the expected use case, then I fail to see the advantage over
 simply transporting the data over established file-transfer protocols
 (FTP, HTTP) in a format which can be directly understood by the device.
 Many devices can be programmed by sending the distributed image over an
 RS-232 connection with no preprocessing; requiring a translation step
 severely reduces the set of devices that can be used for this purpose.
 For example, it makes it unlikely that I would be able to walk around
 my machine room with a PDA, upgrading firmware in network devices or
 RAID controllers.

- This specification REQUIREs the use of SHA-1, providing no means to
 upgrade to an alternate hash in the future.  This lack of algorithm
 agility is not very forward-looking.

- In section 4.1, you say "if the value is untrue...".  I suspect you
 mean something like "if the value does not match...".  Further,
 rather than leaving the behaviour in the case of an incorrect length
 up to the implementation, it should be RECOMMENDED (RFC2119) that
 implementations reject such files.

- In section 4.2, you require the start_address attribute to be
 provided, even though it may not be meaningful in all cases.  This
 attribute should be OPTIONAL.

- I don't believe 64 bits are required to represent word size.
 In fact, I question whether it is necessary for this format to
 represent word size at all.

- The number of blocks is OPTIONAL, but the block length is REQUIRED.
 Further, there is a per-block checksum but no overall checksum.
 These properties would seem to suggest that the intent is to allow
 stream-encoding by encoding an arbitrary number of relatively small
 blocks.  This is fine, but lacking both a block count and an overall
 checksum, there is no way to tell whether the entire dump was
 transferred correctly.  I would suggest adding an overall-checksum
 element, to be encoded after the last block (_not_ as an attribute).

- Why is the number of _bits_ in a block limited to 2^64-1?
 This limitation seems unnecessary, given that everything else is
 done in terms of octets.

- The requirement that words inside a dump be represented in network
 order is silly.  The contents of a dump are by their nature specific
 to a particular device, and should be in whatever format is most
 appropriate for that device.  Again, I question whether this format
 should have any notion of "words" at all.

- I understand the desire to ignore stray characters in dump data,
 since various software may introduce additional formatting.  However,
 it seems reasonable to expect that attributes will be well-formed
 and consist only of legal characters.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@xxxxxxx>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]