[Sis-ams] comments on our spec

[Scott Burleigh]

Ray, Timothy J. (GSFC-583.0) wrote:
>
> Dear WG members,
>
>  
>
> Here are some minor questions/comments on our specification:
>
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. 
>
> 3.1.10.2 -- Application_data is shown as optional.  Is it really 
> optional?  (Is the idea to enable 'no-op' messages?)
>
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. 
>
> 3.1.11.2 -- ditto
>
>  
>
> 3.1.13.2 -- ditto
>
Yes, and 3.1.12.2 as well. 
>
> 5.1.5.14  -- Inconsistency between text and picture.  Is it 
> role-number followed by node-number or vice-versa?
>
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. 
>
> 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 ...).
>
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? 
>
> 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.
>
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. 
>
> 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.
>
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?

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.

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.)

2.   Table 5-1: should add a comment on "Sender's unit number" noting 
that it is zero if the sender is configuration service.

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.

4.   In section 3.1.13.2, context for Announce should be optional (not 
required), as it is for Publish and Send.

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.

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.

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.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-ams/attachments/20080723/f39999dd/attachment.htm