<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.emailstyle17
{mso-style-name:emailstyle17;
font-family:"Arial","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:1953127765;
mso-list-type:hybrid;
mso-list-template-ids:-1323650580 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Tim, thanks once again for all the work you’ve been
putting into this. Remote AMS is getting much more – and more constructive
– scrutiny than I had ever hoped for.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Some comments on your issues:<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Do you have something in mind as an alternative to constraining
a RAMS network to be either a mesh or a tree? The definitions are mutually
exclusive (for any network of more than 2 gateways), so there’s no way
that any RAMS network could be both. Are you suggesting that we discard
one or the other? Or are you proposing to replace one or the other (or
both) with a new structure altogether?<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I agree that the description of the propagation of subscription
assertions and cancellations in RAMS is not intuitive. However, I believe
it is precise, comprehensive, and unambiguous. I think those are the
qualities that are most important in a formal specification. I agree that
the approach you posted a few weeks ago will seem more intuitive to many
readers, but I don’t think it is a better spec. I think adding it
to the Green Book as an alternate perspective on the problem and as a guide to
developers is very important. But I think that losing the current
language in the Red Book and replacing it with your alternative text would be a
major mistake. This may just be one of those rare topics on which we
simply will not agree.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Whenever any AMS node (including a RAMS gateway) terminates, all
of its subscriptions automatically terminate (4.2.6.4[4]), so I think we’re
already getting the correct behavior. How much value would an additional,
explicit unsubscribe add?<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>4.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Good catch. 4.4.8.3.1 should be modified to say
something like “If the continuum number in the envelope header is zero
then (a) if the control code in the envelope indicates “send on reception”
then the message shall be discarded, otherwise (b) the RAMS gateway shall
forward the envelope data structure – an RPDU – to all declared
neighbors.”<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>5.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I think this is an implementation matter, Tim. We probably
should mention it in the guidance to developers in the Green Book, but it isn’t
part of the protocol and it isn’t part of the service interface. If
we start down the path of telling the developer everything she needs to do in
order to make AMS work, I think we’ll end up with an unnecessarily thick
specification.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>6.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Actually “AMS” has evolved into a blanket term that
refers to the system as a whole, that is, everything covered in this spec.
I think a better approach here would be to insert an additional Note before
Note 1 saying something like “Note that this Transport service definition
applies to the Transport Services utilized by the MAMS and AMS protocols as described
in 2.3.1. The services used to implement Remote AMS communication
channels as described in 4.4.1 are not subject to this definition.”<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>7.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Here and in 4.4.8 I think the right thing to do is to change the
language: the gateway is a RAMS application node, so (as you pointed out to me)
it never actually sees these messages – it only receives service
indication primitives. If we say that then we can’t talk about
copying the incoming APDU, but we can instead say “An enclosure data
structure shall be constructed from the parameters of the primitive in the same
way that an AAMS message would be constructed from those parameters if the message’s
destination were a node in the local continuum.” That’s
consistent with the language in 4.3.3.1.1 and it removes the false requirement
to make an exact copy of the received message.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>8.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Do we really need that note? It actually seems pretty
clear to me already. But if everybody agrees it would be helpful, okay.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>9.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Right, as in (7) above.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>10.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Yes, again as in (7).<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>11.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>No, I think this should be all neighbors. The absence of a
declaration from a neighbor doesn’t mean the neighbor isn’t running
or doesn’t care about your own declaration – it could be that the
neighbor is 40 light minutes away and its declaration just hasn’t reached
you yet. If the retraction goes into the bit bucket, no harm done.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>12.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>You might have a RAMS network that operates continuously for 20
years. During that time, you might want to add some new continua/gateways
and/or remove some continua/gateways.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>13.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>But isn’t the current language already clear? I don’t
see how “All nodes in all continua” could be interpreted to mean that
nodes in some roles wouldn’t be included.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>14.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Excellent catch! 4.3.3.1.2 is wrong – it didn’t
get updated when we added the source ID and destination ID fields to the
envelope structure. It should say “The continuum number, unit
number, and destination ID number of the envelope shall be those identifying
the destination of the enclosure; the source ID number of the envelope shall
identify source node's own role, and the subject number of the envelope
shall identify the subject specified in the original service primitive.”<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Scott<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
sis-ams-bounces@mailman.ccsds.org [mailto:sis-ams-bounces@mailman.ccsds.org] <b>On
Behalf Of </b>Ray, Timothy J. (GSFC-5830)<br>
<b>Sent:</b> Friday, March 06, 2009 8:46 AM<br>
<b>To:</b> sis-ams@mailman.ccsds.org<br>
<b>Subject:</b> [Sis-ams] Issues for discussion<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Hello
all,</span><o:p></o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'> </span><o:p></o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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><o:p></o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'> </span><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>1)</span><span
style='font-size:7.0pt'> </span><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>2)</span><span
style='font-size:7.0pt'> </span><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>3)</span><span
style='font-size:7.0pt'> </span><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>4)</span><span
style='font-size:7.0pt'> </span><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>5)</span><span
style='font-size:7.0pt'> </span><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>6)</span><span
style='font-size:7.0pt'> </span><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Editorial change in
section 3.2 – “AMS” includes AAMS and Meta-AMS but not Remote
AMS.</span><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>7)</span><span
style='font-size:7.0pt'> </span><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Add explanatory note
in section 4.4.9.1 (“memory copy of the incoming APDU”).</span><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>8)</span><span
style='font-size:7.0pt'> </span><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Add explanatory note
in section 4.3.3.1.1 (“enclosure is essentially equivalent to an
APDU”).</span><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>9)</span><span
style='font-size:7.0pt'> </span><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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>,</b> or reply.indication
whose subject is a pseudo-subject)</span><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>10)</span><span
style='font-size:7.0pt'> </span><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'>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><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>11)</span><span
style='font-size:7.0pt'> </span><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'>4.4.2.2.3 Careful: perhaps
“neighbors” should be “declared neighbors”.</span><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>12)</span><span
style='font-size:7.0pt'> </span><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'>4.4.2.2.2 Why would the set of
neighbors change on-the-fly? </span><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>13)</span><span
style='font-size:7.0pt'> </span><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'>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><o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>14)</span><span
style='font-size:7.0pt'> </span><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'>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>destination</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><o:p></o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'> </span><o:p></o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Best
regards,</span><o:p></o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Tim</span><o:p></o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'> </span><o:p></o:p></p>
</div>
</div>
</body>
</html>