<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ray, Timothy J. (GSFC-583.0) wrote:
<blockquote
cite="mid:C3B9C435D7725E4EABE2B62200A42C12815467@NDMSEVS36A.ndc.nasa.gov"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 11 (filtered)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:"\@MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
p.StyleParagraph4Kernat14pt, li.StyleParagraph4Kernat14pt, div.StyleParagraph4Kernat14pt
{margin-top:12.0pt;
margin-right:0in;
margin-bottom:0in;
margin-left:0in;
margin-bottom:.0001pt;
text-align:justify;
line-height:14.0pt;
font-size:12.0pt;
font-family:"Times New Roman";}
span.EmailStyle18
{font-family:Arial;
color:windowtext;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
/* List Definitions */
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<div class="Section1">
<p class="MsoNormal"><font face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;">Dear WG members,</span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;"> </span></font></p>
<p class="MsoNormal"><font face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;">Here are some minor
questions/comments on our specification:</span></font></p>
</div>
</blockquote>
Tim, sorry it has taken me so long to respond to these, but luckily all
this dithering enables me to attach some last-minute issues of my own.
<font face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;"><br>
</span></font>
<blockquote
cite="mid:C3B9C435D7725E4EABE2B62200A42C12815467@NDMSEVS36A.ndc.nasa.gov"
type="cite">
<div class="Section1">
<p class="MsoNormal"><font face="Times New Roman" size="3"><span
style="font-size: 12pt;">3.1.10.2 -- Application_data is shown as
optional. Is it really
optional? (Is the idea to enable ‘no-op’ messages?)</span></font></p>
</div>
</blockquote>
Yes, that's the idea: a message with a subject but no content could
serve as a sort of signal with minimal overhead. You could always
accomplish the same thing with a message that has a single byte of
dummy application data, but that seems a bit klugey.
<font face="Times New Roman" size="3"><span style="font-size: 12pt;"><br>
</span></font>
<blockquote
cite="mid:C3B9C435D7725E4EABE2B62200A42C12815467@NDMSEVS36A.ndc.nasa.gov"
type="cite">
<div class="Section1">
<p class="MsoNormal"><font face="Times New Roman" size="3"><span
style="font-size: 12pt;">3.1.11.2 -- ditto</span></font></p>
<p class="MsoNormal"><font face="Times New Roman" size="3"><span
style="font-size: 12pt;"> </span></font></p>
<p class="MsoNormal"><font face="Times New Roman" size="3"><span
style="font-size: 12pt;">3.1.13.2 -- ditto</span></font></p>
</div>
</blockquote>
Yes, and 3.1.12.2 as well.
<font face="Times New Roman" size="3"><span style="font-size: 12pt;"><br>
</span></font>
<blockquote
cite="mid:C3B9C435D7725E4EABE2B62200A42C12815467@NDMSEVS36A.ndc.nasa.gov"
type="cite">
<div class="Section1">
<p class="MsoNormal"><font face="Times New Roman" size="3"><span
style="font-size: 12pt;">5.1.5.14 -- Inconsistency between text and
picture. Is it
role-number followed by node-number or vice-versa?</span></font></p>
</div>
</blockquote>
It's node number followed by role number. I think this is fixed in the
latest version of the spec I posted to the CWE, but it definitely will
be fixed in the one I'll post later today.
<font face="Times New Roman" size="3"><span style="font-size: 12pt;"><br>
</span></font>
<blockquote
cite="mid:C3B9C435D7725E4EABE2B62200A42C12815467@NDMSEVS36A.ndc.nasa.gov"
type="cite">
<div class="Section1">
<p class="MsoNormal"><font face="Times New Roman" size="3"><span
style="font-size: 12pt;">5.1.5.18 – The second field in the diagram is
labelled ‘MAMS
endpoint name’ but the structure below the label appears to be a
delivery-point-name. I think the label is correct and the diagram
needs
to be changed. If my understanding is correct, a MAMS-endpoint-name
does
not explicitly specifiy the transport service (e.g. udp) because all
AMS
entities have agreed in advance on a particular transport service,
while a
delivery-point-name explicitly specifies the transport service (e.g.
tcp or udp
or …).</span></font></p>
</div>
</blockquote>
You are right about this distinction, Tim. Unfortunately the edition
of the spec that I'm working with is different enough from the one
you're writing about to make it hard for me to find what needs to be
corrected. I'll be posting yet another update this afternoon; could
you please look at section 5.1.5 and see if the items you're concerned
about have been addressed?
<font face="Times New Roman" size="3"><span style="font-size: 12pt;"><br>
</span></font>
<blockquote
cite="mid:C3B9C435D7725E4EABE2B62200A42C12815467@NDMSEVS36A.ndc.nasa.gov"
type="cite">
<div class="Section1">
<p class="MsoNormal"><font face="Times New Roman" size="3"><span
style="font-size: 12pt;">5.1.1.2 – (I’m not familiar with time code
formats, but I
think this comment is correct) Table 5-1 shows the MPDU
header format. It includes CUC Time. If we haven’t done so
already, I suggest that we explicitly state whether or not the
‘preamble’ portion of CUC is included. Otherwise, the reader
of an MPDU will not be able to determine (with certainty) whether or
not a preamble
is present.</span></font></p>
</div>
</blockquote>
Excellent point. The intent of the RID resolution that is embodied in
this text was specifically to enable time tags to be self-describing,
so the Preamble (P-field) is indeed required. I'll make this change.
<font face="Times New Roman" size="3"><span style="font-size: 12pt;"><br>
</span></font>
<blockquote
cite="mid:C3B9C435D7725E4EABE2B62200A42C12815467@NDMSEVS36A.ndc.nasa.gov"
type="cite">
<div class="Section1">
<p class="MsoNormal"><font face="Times New Roman" size="3"><span
style="font-size: 12pt;">5.1.3.3 -- Heartbeat Source. The meaning of
the phrase
“node’s number” is unclear to me. I think the intention
is for this to mean “node-id” (a 4-byte number that factors in a
node’s unit, number, and role) rather than the “node number”
(a 1-byte number) by which the node is identified within its cell.</span></font></p>
</div>
</blockquote>
No, the intent was that the node number alone was going to be
sufficient here. Heartbeats from the configuration server are
identified by sender's unit number (in the MAMS PDU header) being set
to zero; heartbeats from a registrar have got sender's unit number set
to the registrar's unit number but have Reference value set to zero;
heartbeats from a node have got sender's unit number set to the number
of the unit in which the node is registered and have Reference value
set to node number. I think all of these are unambiguous, so we don't
need the whole node ID in the Reference for heartbeats. Am I missing
anything?<br>
<br>
And while I'm talking about spec tweaks, here are a couple more that
came to me as I was updating source code to conform to the revised Red
Book.<br>
<br>
1. Since we've agreed that implementation-specific "echo" capability
is something we no longer want to require (meaning we need to delete
4.2.7.4.4 and 4.2.7.4.5), we now need to provide MAMS endpoint name in
the Supplementary Data of the registrar_query MPDU. (All the other
MPDUs that we might need to echo to unregistered entities already
contain MAMS endpoint name somewhere in their supplementary data.)<br>
<br>
2. Table 5-1: should add a comment on "Sender's unit number" noting
that it is zero if the sender is configuration service.<br>
<br>
3. We need an additional Refusal Reason code 4 (in the last paragraph
of 5.1.5) for "No such unit", to support section 4.2.3.2.1 -- rejection
of registrar announcement because the indicated cell isn't in the MIB.<br>
<br>
4. In section 3.1.13.2, context for Announce should be optional (not
required), as it is for Publish and Send.<br>
<br>
5. In 3.1.11.4, the word "shall" in "operation of the querying node
shall be suspended" should be "may". We have already agreed (see
4.3.5.1.2.4.1) that this is optional.<br>
<br>
6. In table 5-3, the Reference value for the node_status message must
still be Node ID so that registrars receiving these messages can know
how to forward them (4.2.8.4). In the event that an aggregated
node_status message is issued by the Registrar, the node number and
role number in the Node ID are simply set to zero.<br>
<br>
7. A point on checksums. We have agreed that they are optional on
both MAMS and AAMS messages, but how about the enclosure structures
inside RAMS messages? On the one hand, an enclosure is supposed to be
"identical in format and semantics to an AAMS message". On the other
hand, checksums on enclosures may be overkill since they are already
likely to be pretty well protected: while in RAMS messages they will be
included in the forward error correction applied to the encapsulating
link frames, and while inside AAMS messages sent by RAMS gateways they
will be included in the checksums calculated for those AAMS messages.
In my implementation, though, I am assuming that enclosures *may* have
their own checksums and therefore an AAMS message from a RAMS gateway
may in the worst case have two layers of checksum to verify. If
anybody disagrees, please speak up.<br>
<br>
Scott<br>
</body>
</html>