[Cesg-all] Results of CESG poll closing 8 November 2013

[CCSDS Secretariat]

CESG E-Poll Identifier:  CESG-P-2013-10-001 
Approval to publish CCSDS 871.3-M-1,  Spacecraft 
Onboard Interface Services—Device Enumeration Service (Magenta Book, Issue 1)
Results of CESG poll beginning 25 October 2013 and ending 8 November 2013:

                  Abstain:  1 (20%) (Calzolari)
  Approve Unconditionally:  2 (40%) (Peccia, Taylor)
  Approve with Conditions:  2 (40%) (Shames, Barkley)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

      Peter Shames (Approve with Conditions):  As 
indicated in the attched mark-up of the document 
there are a significant number of what appear to 
be "loose ends" in this document.  The most significant are these:

1) The concept of "notifications" is widely used, 
but there is essentially no guidance as to what 
these are nor how they are to be provided.
2) There are abstract service interfaces for 
"DeviceFound" and "DeviceLost" that have 
indicaitons but no corresponding request.  There 
is no suggestion about how these "naked 
indicators" are to be returned to a user 
application that has not provided any sort of binding address.
3) There is not even an abstract MIB for the DES. 
Further, there is a statement to the effect that 
the DES might use the DVS and/or DAS MIB.  This 
sort of cross coupling violates all sorts of 
normal modularity and side effect constraints.
4) The three different figures all use the same 
components (mostly), but the connections among 
them seem to be different in each figure and 
nowhere are these "notifications" even identified.

Even for a MB much of this just seems entirely 
too vague.  I recommend inclusion of at least 
abstract elements that describe how all of this is intended to hang together.

      Erik Barkley (Approve with Conditions):  1) 
this may be just a request for clarification and 
not strictly a condition: why are the device 
virtualization and device access services not 
shown in the application support layer of figure 
2 – 1? It seems that figures 2-1 and 2-2 would be 
more consistent if this were the case. Request 
clarification and/or suggest revision as indicated.

2) in figure 2 – 3, the device enumeration 
service does not appear in the identifiers 
mapping. Is this intentional? On page 2-2 there 
is indication that the device enumeration service 
assigns a system unique identifier to each device 
but yet this is not present in the figure?  Please clarify or revise as needed.

3) page 2-4, minor editorial, but suggest 
changing from “
b) the Virtual Device Identifier 
(system-wide unique) to be used in the DVS 
primitives is assigned
”  to “
b) assigns the 
Virtual Device Identifier (system-wide unique) to 
be used in the DVS primitives
” .  Rationale: 
this is a list of what the management consists of 
and so should therefore be stated in active voice.

4) Page 3-1 suggests stating what exactly is 
meant by “mapping it across the SOIS 
communication stack”. Rationale is that this is a 
normative statement but the action here appears to be notional.

5) page 3-1, 3.1.4 should  this include 
“unmapping” the device across the SOIS com stack, 
as this is now a removed device? If not, 
clarification via a note may be useful to the 
implementer. (note the "unmapping" would 
presumably also be detailed to pair properly with "mapping").

6) page 3-4: there are several primitives listed 
that tend to be notifications -- for example, 
DEVICE_FOUND, DEVICE_LOST, etc. There is, 
however, no primitive for subscribing to these 
notifications. The recommendation appears to be 
unclear as to how the user entity is supposed to 
receive these notifications otherwise. Please 
clarify. If a DES registration/subscription 
primitive is added it seems that an 
deregistration/un-subscription primitive is also needed.

7) page 3-5: suggesting changing from “
and be 
enabled in the SOIS architecture.” to “
and be 
enabled.”  Rationale:  it’s unclear as to what 
the denotation of enabling in the SOIS 
architecture versus enabling in 
non-SOIS  architecture really means here. It 
seems that salient action is enabling/disabling.


Total Respondents:  5

No response was received from the following Area(s):

      SIS

SECRETARIAT INTERPRETATION OF RESULTS:
PROPOSED SECRETARIAT ACTION:

* * * * * * * * * * * * * * * * * * * * * * * *
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 871x3m0_CESG_Approval-SEA.pdf
Type: application/pdf
Size: 609472 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/cesg-all/attachments/20131113/8e1a84fe/871x3m0_CESG_Approval-SEA-0001.pdf