<html>
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered)">
<style>
<!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
/* 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;}
span.EmailStyle17
        {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>
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Hello all,</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>This email provides a list of AMS issues for discussion
(most are related to Remote AMS). The first two issues are important; the
rest are minor.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>1)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font><font size=2 face=Arial><span style='font-size:
10.0pt;font-family:Arial'>Is our working group comfortable with constraining a
Remote-AMS network to be either a ‘mesh’ or a ‘tree’ –
keep in mind that if one agency creates a ‘mesh’ network, and
another agency creates a ‘tree’ network, the two Remote-AMS networks
will not interoperate (more specifically, Remote-AMS cannot be used to join the
two networks) . This may not be a big deal, but let’s make sure
that everyone is aware of this limitation and able to live with it.</span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>2)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font><font size=2 face=Arial><span style='font-size:
10.0pt;font-family:Arial'>The part of the Remote AMS specification that handles
the propagation of subscription assertions/cancellations is not intuitive for
me, but I think it can be expressed in a way that is intuitive. In
particular, rules that are currently spread across sections 4.4.3, 4.4.5.2,
4.4.6.2, 4.4.6.4, 4.4.7.2, and 4.4.7.5 can be put in a single section. The
Green Book material that I posted to our web site a few weeks ago summarizes an
approach that is intuitive (and could be contained in a single section) (see
the section titled “Calculating a Petition’s Source Continuum Set”
and compare it to the above-mentioned sections). Link:
<a
href="http://cwe.ccsds.org/sis/docs/sis-ams/draft%20documents/green%20book/rams%20green%20book%20text%20v38.doc">http://cwe.ccsds.org/sis/docs/sis-ams/draft
documents/green book/rams green book text v38.doc</a>
accompanying pictures are here: <a
href="http://cwe.ccsds.org/sis/docs/sis-ams/draft%20documents/green%20book/rams%20green%20book%20figures%20v1.ppt">http://cwe.ccsds.org/sis/docs/sis-ams/draft
documents/green book/rams green book figures v1.ppt</a>
If there is a consensus that the change is worth making, I will volunteer to
edit the Red Book. </span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>3)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font><font size=2 face=Arial><span style='font-size:
10.0pt;font-family:Arial'>Each time a gateway starts (4.4.2.1.2) it subscribes
locally to the pseudo-subject. But when it terminates (4.4.2.2.3) it
doesn’t unsubscribe locally. Seems like it should.</span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>4)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font><font size=2 face=Arial><span style='font-size:
10.0pt;font-family:Arial'>4.4.8 – is there a hole? Suppose the RPDU
header indicates ‘send on reception’ to ‘all
continua’? Presumably, that is not allowed, but the current specs
would propagate the message to all continua.</span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>5)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font><font size=2 face=Arial><span style='font-size:
10.0pt;font-family:Arial'>Clearly, a RAMS gateway needs to keep track of each
invitation from any of its local nodes, but I don’t see any explicit requirement
to do so (nor a specification of the mechanism that provides that information
to the local gateway) – suggest adding a section on responding to
Assert_Invitation.indication and Cancel_Invitation.indication.</span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>6)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font><font size=2 face=Arial><span style='font-size:
10.0pt;font-family:Arial'>Editorial change in section 3.2 –
“AMS” includes AAMS and Meta-AMS but not Remote AMS.</span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>7)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font><font size=2 face=Arial><span style='font-size:
10.0pt;font-family:Arial'>Add explanatory note in section 4.4.9.1
(“memory copy of the incoming APDU”).</span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>8)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font><font size=2 face=Arial><span style='font-size:
10.0pt;font-family:Arial'>Add explanatory note in section 4.3.3.1.1 (“enclosure
is essentially equivalent to an APDU”).</span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>9)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font><font size=2 face=Arial><span style='font-size:
10.0pt;font-family:Arial'>4.4.9 Editorial change: On receiving a
message.indication on a subject that is greater than zero…
(also applies to 4.4.8, except it’s a message.indication,
query.indication<b><span style='font-weight:bold'>,</span></b> or
reply.indication whose subject is a pseudo-subject)</span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>10)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'> </span></font></span></font><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>4.4.9.1
“construct an AAMS message having the same parameters” or something
similar instead of “exactly re-creating”. Recall that
version_number and checksum are not in the message.indication, but are needed
to exactly recreate the AAMS message.</span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>11)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'> </span></font></span></font><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>4.4.2.2.3
Careful: perhaps “neighbors” should be “declared
neighbors”.</span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>12)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'> </span></font></span></font><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>4.4.2.2.2
Why would the set of neighbors change on-the-fly? </span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>13)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'> </span></font></span></font><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>4.4.2.1.3
Editorial change. The current text ends with “and whose domain is
all nodes in all continua”. Given that a domain includes continuum,
unit, and role – there would be less chance of this clause being
misinterpreted if the text said “and with the following domain: all units
from all continua with any role” (or words to that effect). (or if
a note was added) </span></font></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'>14)<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'> </span></font></span></font><font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>Remote AMS
– forwarding an ‘Announcement’. The destination gateway
needs to know the source node’s role, but does not appear to have that
info – i.e. the source node’s role is not propagated through the
RAMS network. (Note: ‘source role number’ is carried in the
RPDU header, but section 4.3.3.1.2 says that “the destination continuum
number, unit number, and node number or role number of the envelope shall be
those identifying the *<b><span style='font-weight:bold'>destination</span></b>*
of the enclosure”). Anyway, I have not finished implementing this
capability, so this may turn out to be a misunderstanding on my part.</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Best regards,</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Tim</span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
</div>
</body>
</html>