[Cesg-all] Results of CESG polls closing 20 November 2012

Thomas Gannett tomg at aiaa.org
Wed Nov 28 10:24:28 EST 2012


Skipped content of type multipart/alternative-------------- next part --------------
        CESG POLL ITEM DISPOSITION (PID) INITIATION FORM
AREA PID NUMBER:	01
SUBMITTING AREA: 	Space Internetworking Services (SIS)
------------------------------------------------------------------
REVIEWER'S NAME:	Keith Scott   
E-MAIL ADDRESS:	kscott at mitre.org
------------------------------------------------------------------
DOCUMENT NUMBER:   CCSDS 871.3-R-0      Proposed Red Book, Issue 0
DOCUMENT NAME:     Spacecraft Onboard Interface Services—Device Enumeration Service
DATE ISSUED:       November 2012
PAGE NUMBER:       1-1         PARAGRAPH NUMBER:  1.1
PID SHORT TITLE:   ABSTRACT service interfaces
------------------------------------------------------------------
DESCRIPTION OF REQUESTED CHANGE:  (Use From: "..." To "..." format)

From:
The purpose of this document is to define services and service interfaces provided by the SOIS Device Enumeration Service (DES).

To:
The purpose of this document is to define services and abstract service interfaces provided by the SOIS Device Enumeration Service (DES).

------------------------------------------------------------------
CATEGORY OF REQUESTED CHANGE:    Editorial 
------------------------------------------------------------------
SUPPORTING ANALYSIS:
As stated in the next sentence, the document specifies the service only and not the methods of providing the service.

------------------------------------------------------------------
DISPOSITION:

=====
        CESG POLL ITEM DISPOSITION (PID) INITIATION FORM
AREA PID NUMBER:	02
SUBMITTING AREA: 	Space Internetworking Services (SIS)
------------------------------------------------------------------
REVIEWER'S NAME:	Keith Scott   
E-MAIL ADDRESS:	kscott at mitre.org
------------------------------------------------------------------
DOCUMENT NUMBER:   CCSDS 871.3-R-0      Proposed Red Book, Issue 0
DOCUMENT NAME:     Spacecraft Onboard Interface Services—Device Enumeration Service
DATE ISSUED:       November 2012
PAGE NUMBER:       1-1         PARAGRAPH NUMBER:  1.1
PID SHORT TITLE:   No specification of access implementation
------------------------------------------------------------------
DESCRIPTION OF REQUESTED CHANGE:  (Use From: "..." To "..." format)

From:
Its scope is to specify the service only and not to specify methods of providing the service, although use of the SOIS subnetwork services is assumed.

To:
Its scope is to specify the service only and not to specify methods of providing or accessing the service, although use of the SOIS subnetwork services is assumed.

------------------------------------------------------------------
CATEGORY OF REQUESTED CHANGE:    Editorial 
------------------------------------------------------------------
SUPPORTING ANALYSIS:
As stated in the next sentence, the document specifies the service only and not the methods of providing the service.

------------------------------------------------------------------
DISPOSITION:

=====
        CESG POLL ITEM DISPOSITION (PID) INITIATION FORM
AREA PID NUMBER:	03
SUBMITTING AREA: 	Space Internetworking Services (SIS)
------------------------------------------------------------------
REVIEWER'S NAME:	Keith Scott   
E-MAIL ADDRESS:	kscott at mitre.org
------------------------------------------------------------------
DOCUMENT NUMBER:   CCSDS 871.3-R-0      Proposed Red Book, Issue 0
DOCUMENT NAME:     Spacecraft Onboard Interface Services—Device Enumeration Service
DATE ISSUED:       November 2012
PAGE NUMBER:       1-1, 1-2         PARAGRAPH NUMBER:  1.1, 1.6
PID SHORT TITLE:   References to Green Books
------------------------------------------------------------------
DESCRIPTION OF REQUESTED CHANGE:  (Use From: "..." To "..." format)

The document references the SOIS Green Book (Reference D2) and SOIS Services Green Book (Reference D3) and states that the specification in this document (the DES) "is intended to be applied together with it" (D2, 1.1) and "should not be applied without first consulting this reference (D3, 1.6)".  Surely reference D3 doesn't contain anything normative (being a Green Book).

Including the other Green books as non-normative references seems ok, and pointing readers to them (even pointing them STRONGLY towards them) seems OK, but this language ("... and SHOULD NOT be applied without first consulting the reference," makes me think that there's something in the Green books that really wants to be normative to the DES.  If there is, it should be included here; if there's not, it should be clear that the references are not normative.

------------------------------------------------------------------
CATEGORY OF REQUESTED CHANGE:    Editorial 
------------------------------------------------------------------
SUPPORTING ANALYSIS:
Green Books are non-normative and should not be implied to be normative through reference from Red/Blue books (IMHO).

------------------------------------------------------------------
DISPOSITION:



=====
        CESG POLL ITEM DISPOSITION (PID) INITIATION FORM
AREA PID NUMBER:	04
SUBMITTING AREA: 	Space Internetworking Services (SIS)
------------------------------------------------------------------
REVIEWER'S NAME:	Keith Scott   
E-MAIL ADDRESS:	kscott at mitre.org
------------------------------------------------------------------
DOCUMENT NUMBER:   CCSDS 871.3-R-0      Proposed Red Book, Issue 0
DOCUMENT NAME:     Spacecraft Onboard Interface Services—Device Enumeration Service
DATE ISSUED:       November 2012
PAGE NUMBER:       3-1         PARAGRAPH NUMBER:  3.2.2, 3.2.3
PID SHORT TITLE:   Minimum service from underlying layers
------------------------------------------------------------------
DESCRIPTION OF REQUESTED CHANGE:  (Use From: "..." To "..." format)

What does it mean that the minimum expected service from the underling layers is:

"Control of the MIB of the DVS" is expected?  Does this mean the DES can manipulate (read/write) the DVS (and DAS, 3.2.3) MIBS?  Read only?  This smacks of more inter-process communication than MIB, though mechanisms to implement either are probably outside the scope of this document.

------------------------------------------------------------------
CATEGORY OF REQUESTED CHANGE:    Technical Fact 
------------------------------------------------------------------
SUPPORTING ANALYSIS:
I don't understand what the required service is, and suspect others might be similarly confused.

------------------------------------------------------------------
DISPOSITION:


=====
        CESG POLL ITEM DISPOSITION (PID) INITIATION FORM
AREA PID NUMBER:	05
SUBMITTING AREA: 	Space Internetworking Services (SIS)
------------------------------------------------------------------
REVIEWER'S NAME:	Keith Scott   
E-MAIL ADDRESS:	kscott at mitre.org
------------------------------------------------------------------
DOCUMENT NUMBER:   CCSDS 871.3-R-0      Proposed Red Book, Issue 0
DOCUMENT NAME:     Spacecraft Onboard Interface Services—Device Enumeration Service
DATE ISSUED:       November 2012
PAGE NUMBER:       3-2         PARAGRAPH NUMBER:  3.3.2
PID SHORT TITLE:   Transaction identifier
------------------------------------------------------------------
DESCRIPTION OF REQUESTED CHANGE:  (Use From: "..." To "..." format)

I thought we'd agreed that the mechanism for matching an indication to a particular request was part of the implementation and not part of the service specification?  I'm not adament about its inclusion or exclusion but I think we should agree on ONE approach for all documents and stick to it.

In e.g. the ADD_DEVICE / REMOVE_DEVCE services, the TID is not part of the requests, but IS part of the indications; that seems incorrect.  The TID IS part of the QUERY_DEVICES.request.

------------------------------------------------------------------
CATEGORY OF REQUESTED CHANGE:    Editorial 
------------------------------------------------------------------
SUPPORTING ANALYSIS:


------------------------------------------------------------------
DISPOSITION:


=====
        CESG POLL ITEM DISPOSITION (PID) INITIATION FORM
AREA PID NUMBER:	06
SUBMITTING AREA: 	Space Internetworking Services (SIS)
------------------------------------------------------------------
REVIEWER'S NAME:	Keith Scott   
E-MAIL ADDRESS:	kscott at mitre.org
------------------------------------------------------------------
DOCUMENT NUMBER:   CCSDS 871.3-R-0      Proposed Red Book, Issue 0
DOCUMENT NAME:     Spacecraft Onboard Interface Services—Device Enumeration Service
DATE ISSUED:       November 2012
PAGE NUMBER:       3-10         PARAGRAPH NUMBER:  3.4.10.3.7
PID SHORT TITLE:   Non-abstract access mechanisms / parameters
------------------------------------------------------------------
DESCRIPTION OF REQUESTED CHANGE:  (Use From: "..." To "..." format)

There's a hidden requirement here that attributeNames do not contain whitespace, and probably that they don't contain any of the =<>! characters.  Probably want to state that somewhere.  Even specifying things like 'string' and 'whitespace' starts to get dangerously close to implementation, I think (ASCII? EBCDIC? Unicode?), NULL-terminated strings?  From an abstract service definition I think you really pass three things to QUERY_DEVICES and even '=' '>' or '<' are 'abstract' (i.e., you could use EQUAL, LESSTHAN, GREATERTHAN in the spec, and resolve to some sort of token (like -1, 0, 1) in the implementation).

Another argument for this would be symmetry: you don't specify anything of the semantics of the spacecraftNetworkAddress (though it too probably wants to be devoid of whitespace under the current rules).

Require a list to begin with, and 3.4.10.3.8 can go away so long as a list can have only one member.  It's an abstract service spec, so the overhead of list management is NIL.



------------------------------------------------------------------
CATEGORY OF REQUESTED CHANGE:    Technical Fact 
------------------------------------------------------------------
SUPPORTING ANALYSIS:
I think that in order to fully specify the (non-abstract) service interface would require defining things like the character set and string encoding mechanism.  Since I don't think you want to do that here, making the interface fully abstract seems like the better approach, with the benefit that it's consistent with section 1. 

------------------------------------------------------------------
DISPOSITION:





-------------- next part --------------
A non-text attachment was scrubbed...
Name: 871x0m0_CESG_Approval-SEA.pdf
Type: application/pdf
Size: 531643 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/cesg-all/attachments/20121128/65982169/871x0m0_CESG_Approval-SEA-0001.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 871x3r0_CESG_Approval-SEA.pdf
Type: application/pdf
Size: 598113 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/cesg-all/attachments/20121128/65982169/871x3r0_CESG_Approval-SEA-0001.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 871x2r0_CESG_Approval-SEA.pdf
Type: application/pdf
Size: 503944 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/cesg-all/attachments/20121128/65982169/871x2r0_CESG_Approval-SEA-0001.pdf


More information about the CESG-all mailing list