[evla-sw-discuss] MIB stream protocol comments

[Ken Sowinski]

I begin with a lament that had this specification been
distributed as an simple text file I could have easily
inserted silly comments as appropriate.  As it is, I
must tediously describe the context of my comments.

It would have been easier to understand the intent of
the document from the beginning if the initial paragraphs
had explained that the content of a datagram will be a
Data Device Record and that a DDR is composed of the
various data items to be defined.  


What follows is a list specific comments on some of
the text.  Some typos were probably missed; I hope
I did not forget any comments of substance.  

I suggest omitting the table near the bottom of the 
first page and supplying the mapping to data type
value in the detailed definitions which follow.

Under BYTE:, write "two's" for "twos".

Do we really need a LONG?  I suppose it doesn't hurt
to have it defined even if it is never used.

If this is a formal spec, then the relevant ISO number
ought to be used rather than "IEEE floats".  If this
is an informal guide, it hardly matters.

Under TIMESTAMP:, the caveat about "big-endian" order ought
to be included.  Or, merely mention it at the beginning
as a general principle and leave it out of the detailed
definitions.  Should "date/time" be "date and time"?

Under STRING:, read "are" for "is" in the second line.
In the last line but one, "vector" is mentioned, but
is never defined.  Should this be an "array"?  In the 
last sentence, perhaps "common" is meant rather than 
"unique"?  Do we really expect to have strings longer
than 255 characters?  Though I said this before, I
note that these strings are not 'C strings'.  If these
were counted, null-terminated strings, we still easily
know how long the item is and the conversion to a C
char[] is trivial.

I find the use of "ARRAY" and "STRUCT" confusing.  In
common usage, an "array' is a set of identical objects; 
and a "struct" is a collection of not necessarily identical
objects.  Here, "array" is used to mean "struct", and a 
"struct" is more "table-like" than "struct-like".  By 
"table-like", I mean something which has many rows and a 
label describing each of the rows.  All this is by way of 
asking whether we want an "array" type of the kind I 
described above: a set of identical objects.

Under ARRAY:, the picture probably ought to refer to
elements "1 to n" rather than "1 to 6" and employ ellipsis.
If we are going to have strings with more than 255 characters,
might we not also have arrays with more than 255 elements?

I don't know what is intended by "Records", but my feeling
is that the "MonitorPoint" is more like a data element than
a Device Data Record.  Reading further, my impression is
that a DDR is in a class by itself.

Under MonitorPoint:, should it be "MONITORPOINT" to be
consistent with all the other headings?  Is "device"
at the end of the second sentence intended to be "Device"?
If the ID is intended to be unique within the d(D)evice,
allowing for 65536 of them seems like overkill.

Under DEVICE DATA RECORD:, is it intended that a datagram
contain exactly one DDR and nothing else?  Would a datagram
containing, say, an array of INTEGERS of length 100 and
nothing else be illegal?  If so, then the data type code for
the DDR is unnecessary and if present serves only as a 
'sanity' check on the datagram: any datagram not containing
'13' in the first byte is not streamed monitor data.  In
the second sentence, are we guaranteeing that all the MPs
in the DDR are sampled at the same rate, or that they have
been sampled synchronously (or within epsilon of it) as well?
Phrased differently, are MPs sampled at once a second all
guaranteed to be sampled at the same second if they are in
the same DDR?  In the last sentence of the first paragraph,
read "These" for "these" and "in" for "w.r.t.".  Should there
be a numerical justification for 1280 based on known MTUs
and the overhead of known encapsulation schemes?  I would
argue for a stronger statement than that given in the 
explanation of the revision ID.  Since we have so many of
these, and so many MP IDs, I suggest that once a MP ID is
assigned it never be reused for another purpose, thus the
number of MP IDs will continue to grow but old data will
always be uniquely interpretable.  Revision ID should be 
bumped any time MP IDs are added or removed.  Is the timestamp
the time the DDR was generated or the time that the data
was acquired?  Is the "system" referred to in the explanation
of Device ID, the Device, the MIB, the antenna, or the whole
of the VLA?  I rather liked the idea of having the Device ID 
be a short string.  That would allow people at antennas or at a 
bench to refer Devices by name rather than an obscure number; 
something that may be hard to translate without reference to 
another, perhaps distant, computer.  The explanation for 
Device ID refers to "SHORT (as defined above)".  It makes
sense for the Device ID to be an 'unsigned short' (as in the
string byte count) than a 'short'.  As long as you have defined 
a STRUCT, I offer the silly idea that you can con-struct- a DDR 
as a STRUCT.  Let there be  collection of unordered pairs like:
"attention",0
"length", 123
"revision", 212
etc,...
with the right half of each pair suitably encoded as required
by the spec.

Finally, fonts and/or font sizes could be better used to mark the
different sections of the document.  


The scheme outlined in this document seems to allow for everything 
that I can think of, but it is not clear to me where total power 
data fits in.  We will likely want to buffer total power data and 
transmit chunks of it at a time, but that breaks the 'one measurement 
per DDR' rule.  Some thought should be given to how to fit total power
data into this scheme, or to whether it ought to be accomodated in 
some different way.