[CESG] CESG-P-2020-03-004 Approval to publish CCSDS 902.13-M-1, Abstract Event Definition (Magenta Book, Issue 1)

Thu Jun 25 18:47:54 UTC 2020

Dear CESG Members,

Conditions for approval of CCSDS 902.13-M-1, Abstract Event 
Definition (Magenta Book, Issue 1) have been disposed to the 
satisfaction of the AD(s) who voted to approve with conditions. The 
Secretariat will now proceed with CMC polling to authorize publication.
-------------- next part --------------
From:	Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Sent:	Thursday, June 25, 2020 2:38 PM
To:	Barkley, Erik J (US 3970); Berry, David S (US 3920); Colin.Haddow at esa.int
Cc:	CCSDS Secretariat; Lamy Alain; Oltrogge, Daniel; Gramling, Cheryl J. (GSFC-
5950); Mehran.Sarkarati at esa.int; Mario Merri; Roger Thompson
Subject:	Re: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to publish CCSDS 902.13-
M-1,  Abstract Event Definition (Magenta Book, Issue 1)

Categories:	Poll Condition Closure

Works for me.

Proceed.

Thanks, Peter

From: Erik Barkley <erik.j.barkley at jpl.nasa.gov> 
Date: Thursday, June 25, 2020 at 10:13 AM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, David Berry 
<david.s.berry at jpl.nasa.gov>, Colin Haddow <Colin.Haddow at esa.int> 
Cc: Tom Gannett <thomas.gannett at tgannett.net>, Lamy Alain <Alain.Lamy at cnes.fr>, 
"Oltrogge, Daniel" <doltrogge at agi.com>, "Gramling, Cheryl J. (GSFC-5950)" 
<cheryl.j.gramling at nasa.gov>, "Mehran.Sarkarati at esa.int" 
<Mehran.Sarkarati at esa.int>, Mario Merri <Mario.Merri at esa.int>, Roger Thompson 
<roger.rocketbrain at btinternet.com> 
Subject: RE: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to publish CCSDS 902.13-M-
1, Abstract Event Definition (Magenta Book, Issue 1)

Peter,

Okay, so then the language will be, to the effect that, the type 
parameter shall be mandatory in any using recommendations unless 
a waiver is granted by the CESG.  I am okay with that. If you are okay 
with that then I think we can move on to updating the AED.

-Erik

From: Shames, Peter M (US 312B)  
Sent: Thursday, June 25, 2020 09:53 
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>; Berry, David S (US 3920) 
<david.s.berry at jpl.nasa.gov>; Colin.Haddow at esa.int 
Cc: CCSDS Secretariat <thomas.gannett at tgannett.net>; Lamy Alain <Alain.Lamy at cnes.fr>; 
Oltrogge, Daniel <doltrogge at agi.com>; Gramling, Cheryl J. (GSFC-5950) 
<cheryl.j.gramling at nasa.gov>; Mehran.Sarkarati at esa.int; Mario Merri <Mario.Merri at esa.int>; 
Roger Thompson <roger.rocketbrain at btinternet.com> 
Subject: Re: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to publish CCSDS 902.13-M-1, 
Abstract Event Definition (Magenta Book, Issue 1)

I think it will be a lot less hassle in the future if the language is "shall" and any deviation from 
that is treated as a waiver, rather than the other way around.

Let's make really clear how we intend this to operate.  Otherwise it will all be "management by 
exception".

Thanks, Peter

From: Erik Barkley <erik.j.barkley at jpl.nasa.gov> 
Date: Wednesday, June 24, 2020 at 5:04 PM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, David Berry 
<david.s.berry at jpl.nasa.gov>, Colin Haddow <Colin.Haddow at esa.int> 
Cc: Tom Gannett <thomas.gannett at tgannett.net>, Lamy Alain 
<Alain.Lamy at cnes.fr>, "Oltrogge, Daniel" <doltrogge at agi.com>, "Gramling, 
Cheryl J. (GSFC-5950)" <cheryl.j.gramling at nasa.gov>, 
"Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>, Mario Merri 
<Mario.Merri at esa.int>, Roger Thompson <roger.rocketbrain at btinternet.com> 
Subject: RE: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to publish CCSDS 
902.13-M-1, Abstract Event Definition (Magenta Book, Issue 1)

Peter,

Please see replies below.

-Erik

From: Shames, Peter M (US 312B)  
Sent: Wednesday, June 24, 2020 16:28 
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>; Berry, David S (US 3920) 
<david.s.berry at jpl.nasa.gov>; Colin.Haddow at esa.int 
Cc: CCSDS Secretariat <thomas.gannett at tgannett.net>; Lamy Alain 
<Alain.Lamy at cnes.fr>; Oltrogge, Daniel <doltrogge at agi.com>; Gramling, Cheryl J. 
(GSFC-5950) <cheryl.j.gramling at nasa.gov>; Mehran.Sarkarati at esa.int; Mario Merri 
<Mario.Merri at esa.int>; Roger Thompson <roger.rocketbrain at btinternet.com> 
Subject: Re: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to publish CCSDS 902.13-M-
1, Abstract Event Definition (Magenta Book, Issue 1)

Hi Erik,

Thanks.  I am ok with everything that you stated.  I assume, from item 6, that this means 
that you will modify the AED to include the definition and policy for this registry.  Right?

eb> Yes, correct.  The book will be updated to include definition 
and policy. 

I do have just one remaining Peter Falk / Columbo type question

-          If the event type is not mandatory, and some user of the AED decides to create 
a new event type that does not have a "type" specified, what gets 
registered?  And where?

This proposed approach seems to open the door to creation of "compliant" event type 
records that are not recorded anywhere and that have no intrinsic means of 
determining what format they are.  Is that really what you intend and how do you think 
that will work?

eb> I believe that any creation of any new event type 
recommendation based on the AED, would in fact have to go 
through a CESG review prior to publication and the any such 
using recommendation would then have to justify why it is 
deviating from the should statement in the AED. 

Thanks, Peter

From: Erik Barkley <erik.j.barkley at jpl.nasa.gov> 
Date: Wednesday, June 24, 2020 at 2:48 PM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, David Berry 
<david.s.berry at jpl.nasa.gov>, Colin Haddow <Colin.Haddow at esa.int> 
Cc: Tom Gannett <thomas.gannett at tgannett.net>, Lamy Alain 
<Alain.Lamy at cnes.fr>, "Oltrogge, Daniel" <doltrogge at agi.com>, 
"Gramling, Cheryl J. (GSFC-5950)" <cheryl.j.gramling at nasa.gov>, 
"Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>, Mario Merri 
<Mario.Merri at esa.int>, Roger Thompson 
<roger.rocketbrain at btinternet.com> 
Subject: RE: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to publish 
CCSDS 902.13-M-1, Abstract Event Definition (Magenta Book, Issue 1)

Peter,

Here is what Colin and I propose to resolve the Abstract 
Event Definition (AED) poll condition, given the email 
exchanges and opinions expressed.   

1)      Leave the type parameter as optional
2)      Add a statement that using recommendations 
(ie., specializations/realizations of the AED) 
should make the type parameter mandatory
3)      Work with SANA to create an event type registry 
that will be designated as a global registry, citing 
appropriate policy section(s) in the RMP
4)      The event type registry content will include: 
a.       The name of the type
b.       A description of the type
c.       The using document that creates the 
realized/concrete event definition (i.e, 
CCSDS document number)
5)      Populate the initial registry with the event types 
defined by the CSSM Common Data Entities 
(CDE - which specializes the AED for service 
management) as the CDE includes making the 
inherited event type mandatory
6)      Document the event type registry, as outlined 
above, in the AED

I think this does due diligence to resolving the poll 
condition while also taking into account those voices, 
including mine, that do not think the type parameter 
needs to be mandatory.  Are you okay with what is 
proposed?

Best regards,
-Erik 

From: Shames, Peter M (US 312B)  
Sent: Monday, June 22, 2020 13:38 
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>; Berry, David S (US 
3920) <david.s.berry at jpl.nasa.gov>; Colin.Haddow at esa.int 
Cc: CCSDS Secretariat <thomas.gannett at tgannett.net>; Lamy Alain 
<Alain.Lamy at cnes.fr>; Oltrogge, Daniel <doltrogge at agi.com>; Gramling, Cheryl 
J. (GSFC-5950) <cheryl.j.gramling at nasa.gov>; Mehran.Sarkarati at esa.int; Mario 
Merri <Mario.Merri at esa.int>; Roger Thompson 
<roger.rocketbrain at btinternet.com> 
Subject: Re: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to publish CCSDS 
902.13-M-1, Abstract Event Definition (Magenta Book, Issue 1)

Guys,

What Erik just stated is EXACTLY what I am trying to promote.  The using spec 
gets to define how they create the domain (or global) spec from the AED 
abstraction.

But then they must register that so that others can find the spec and use the 
type to determine which kind of event record they are dealing with.

Peter

From: Erik Barkley <erik.j.barkley at jpl.nasa.gov> 
Date: Monday, June 22, 2020 at 12:38 PM 
To: David Berry <david.s.berry at jpl.nasa.gov>, Peter Shames 
<peter.m.shames at jpl.nasa.gov>, Colin Haddow 
<Colin.Haddow at esa.int> 
Cc: Tom Gannett <thomas.gannett at tgannett.net>, Lamy Alain 
<Alain.Lamy at cnes.fr>, "Oltrogge, Daniel" <doltrogge at agi.com>, 
"Gramling, Cheryl J. (GSFC-5950)" <cheryl.j.gramling at nasa.gov>, 
"Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>, Mario 
Merri <Mario.Merri at esa.int>, Roger Thompson 
<roger.rocketbrain at btinternet.com> 
Subject: RE: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to 
publish CCSDS 902.13-M-1, Abstract Event Definition (Magenta 
Book, Issue 1)

David,

I concur with you re ..rather than shoehorn an 
event into an inappropriate type; better to 
leave it unspecified...

I think it is the using recommendations that will 
have the best definition of what kind of domain 
specific event types it defines.  I am open to 
indicating in the AED that using recommendations 
should define and make event types mandatory for 
their specific domain (which in fact is something 
that service management has done in its local 
specialization of the AED).

-Erik 

From: Berry, David S (US 3920)  
Sent: Monday, June 22, 2020 11:32 
To: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>; 
Colin.Haddow at esa.int 
Cc: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>; CCSDS 
Secretariat <thomas.gannett at tgannett.net>; Lamy Alain 
<Alain.Lamy at cnes.fr>; Oltrogge, Daniel <doltrogge at agi.com>; 
Gramling, Cheryl J. (GSFC-5950) <cheryl.j.gramling at nasa.gov>; 
Mehran.Sarkarati at esa.int; Mario Merri <Mario.Merri at esa.int>; Roger 
Thompson <roger.rocketbrain at btinternet.com> 
Subject: Re: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to publish 
CCSDS 902.13-M-1, Abstract Event Definition (Magenta Book, Issue 1)

Peter, Erik, Colin, et al.:

I would say that at this point the Nav WG is 
not even nearly close to defining any 
registries for events. While we've been 
discussing events for quite a while, our 
Lead Editor for Events is also tied up with 
the Attitude Data Message revisions that 
have priority in the WG. So our Navigation 
Events Message is somewhat behind.

In terms of Peter's principal early concern 
that caused the "disapprove" vote, in 
looking back at at an early Nav WG prototype 
of the "Navigation Events Message" XML 
instances that were prepared, the XML 
instances do contain a 'type="xxx"' 
attribute (along with a name attribute and 
an event ID element). So there's plenty of 
identification/classification intent at 
least in these few examples. I think there 
will be an effort in Nav to classify events 
by type, but it also seems that it might be 
desirable to allow a null type rather than 
shoehorn an event into an inappropriate 
type; better to leave it unspecified, which 
the AED currently allows.

I also think that requiring an event to come 
from a registry may be overly restrictive, 
inefficient, and "practically" impossible to 
enumerate in an XML schema.

Regards,
David

From: "Shames, Peter M (US 312B)" 
<peter.m.shames at jpl.nasa.gov> 
Date: Monday, June 22, 2020 at 9:49 AM 
To: David Berry <david.s.berry at jpl.nasa.gov>, 
"Colin.Haddow at esa.int" <Colin.Haddow at esa.int> 
Cc: "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>, 
CCSDS Secretariat <thomas.gannett at tgannett.net>, Lamy Alain 
<Alain.Lamy at cnes.fr>, "Oltrogge, Daniel" <doltrogge at agi.com>, 
"Gramling, Cheryl J. (GSFC-5950)" <cheryl.j.gramling at nasa.gov>, 
"Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>, Mario 
Merri <Mario.Merri at esa.int>, Roger Thompson 
<roger.rocketbrain at btinternet.com> 
Subject: Re: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to 
publish CCSDS 902.13-M-1, Abstract Event Definition (Magenta 
Book, Issue 1)

Hi David, et al,

Thanks for doing these forensics.  My take-away is that Nav does 
recognize that "event types" have meaning and should be mandatory, 
not optional.  That said, it appears that you need more than the limited 
list that SM has proposed and that you may also wish the ability to 
extend any such list with "mission specific" options.  I suspect that the 
MOIMS MPS WG may have similar concerns, so I have copied them on 
this response as well.

To meet this and do it in a standardized, yet extensible, way I propose 
the following:
1)      Create a simple SANA registry of standard event types.
2)      Populate it with the following sets of event types: 
a.       Commonly adopted event types
b.       SM specific events
c.       Nav specific event
d.       MPS specific events
3)      Allow registration of new Domain Specific, but commonly 
agreed within the domain, event types.  Such as a Nav subset, 
or an MPS subset.
4)      Register the code, the source, and the (separate) location 
where the event type and data structure is documented.  This is 
much like what we did for the new CFDP checksum registry.  See 
https://sanaregistry.org/r/checksum_identifiers.
5)      Make sure that any common event type definitions that are 
adopted, where they are shared among WGs, are agreed by all 
WGs.
6)      Allow either some means for registration of new "mission 
specific" event types or for a "non-standard" flag that at least 
tags any locally assigned types as being special and in need of 
out of band resolution.

You might even consider making subsets of the registry for these 
different type sets.  It occurs to me that a workable "type" code could 
easily be handled by a 32-bit field where the high order 2 or 3 (or 4) bits 
are a "domain designator" and the rest of the bits are just assigned 
consecutively.  Making those high order bits = "000b" for the common 
set provides a convenient discriminator.  Adding such a 32-bit identifier 
field is pretty low overhead in my opinion, but still allows a unique, and 
extensible, set of code types to be defined.  Or you could just use the 
OID that will be assigned by the SANA as the unique "code".

Does that work for all concerned?

Thanks, Peter

From: David Berry <david.s.berry at jpl.nasa.gov> 
Date: Saturday, June 20, 2020 at 6:10 PM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, Colin Haddow 
<Colin.Haddow at esa.int> 
Cc: Erik Barkley <erik.j.barkley at jpl.nasa.gov>, Tom Gannett 
<thomas.gannett at tgannett.net>, Lamy Alain 
<Alain.Lamy at cnes.fr>, "Oltrogge, Daniel" <doltrogge at agi.com>, 
"Gramling, Cheryl J. (GSFC-5950)" <cheryl.j.gramling at nasa.gov> 
Subject: Re: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to 
publish CCSDS 902.13-M-1, Abstract Event Definition (Magenta 
Book, Issue 1)

Peter, Erik, Colin:

I have to admit that the Nav WG discussions 
with Service Management were more or less 
completed a while back, and I delegated the 
task to 4 folks in the WG who had a lot of 
interest in the details of the topic (3 
still remain in the WG, and I've copied them 
here). So I do not explicitly recall the 
logic of wanting the event "type" to be 
optional. I recall that there was much more 
discussion about time in the abstract event 
definition (e.g., allowing both absolute 
time and relative time, and different time 
scales), and Service Management was very 
accommodating. But I recall nothing specific 
about making the event type optional. I will 
note that the event type has been optional 
in the drafts for 4-ish years, so Service 
Management appears to have not thought it 
entirely unreasonable.

In looking back through materials prepared 
by Nav WG, I found one requirement in the 
set of requirements we prepared for Service 
Management shortly after the Rome 2016 
meetings, which may apply here:

1.1.10
Each type of event shall be uniquely identified by an event 
identifier.

Note: event identifiers are in general application domain specific 
and therefore the event structure shall mandate the appearance of 
the event type but not the detailed enumeration of event types in 
the application domain.

However, this does seem to imply that the 
event type should be required, not 
optional... 

The Nav WG members involved may have been 
reacting to the following list of event 
types in the Service Management schema in 
desiring an optional event type, but I can't 
say for sure. I think the nature of orbital 
events would be quite broad and potentially 
mission specific, and that Navigation didn't 
necessarily want to be pinned down to a 
specific short list like this.

            <xsd:simpleType 
name="TypesOfSrvMgtEventsType">
                        <xsd:restriction base="xsd:string">
                                    <xsd:enumeration value="COMMS"/>
                                    <xsd:enumeration 
value="DATARATE"/>
                                    <xsd:enumeration value="RFI"/>
                                    <xsd:enumeration 
value="CONFLICTS"/>
                                    <xsd:enumeration value="COSTS"/>
                                    <xsd:enumeration value="OTHER"/>
                        </xsd:restriction>

Regards,
David

From: "Shames, Peter M (US 312B)" 
<peter.m.shames at jpl.nasa.gov> 
Date: Friday, June 19, 2020 at 3:35 PM 
To: "Colin.Haddow at esa.int" <Colin.Haddow at esa.int>, David 
Berry <david.s.berry at jpl.nasa.gov> 
Cc: "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>, 
CCSDS Secretariat <thomas.gannett at tgannett.net> 
Subject: Re: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to 
publish CCSDS 902.13-M-1, Abstract Event Definition (Magenta 
Book, Issue 1)

Hi Colin and David,

Thanks for that explanation.  I knew that you had spent some time 
talking to Nav about this, was not aware it had been more widespread.

That said, I am still puzzled as to why it would be a good idea to have 
event objects defined where the event type was not required.  In fact, if 
this is to be a spec that is widely adopted / adapted, why wouldnt we 
want to have an "Event Type Registry" where the types are registered 
and the location of type definitions are pointed to?  This would parallel 
what is now being done in CFDP, for instance, where they have just 
added the ability to use different checksum algorithms and a registry of 
checksum algorithms has been defined.  

I am really leery of having a lot of new "event" type definitions floating 
around where we have to know "by management" as it were, what 
these event records are and what they mean.  It seems, from what you 
say, that the SM plans to make these event type specs include a type as 
a mandatory element.  So I'd like to ask David why the Nav WG thinks 
that having untyped event structures is such a good idea?  And, as a 
corollary, what harm the addition of an Event Type field would cause?

Thanks, Peter

From: Colin Haddow <Colin.Haddow at esa.int> 
Date: Thursday, June 18, 2020 at 5:18 AM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov> 
Cc: Erik Barkley <erik.j.barkley at jpl.nasa.gov>, Tom Gannett 
<thomas.gannett at tgannett.net>, David Berry 
<david.s.berry at jpl.nasa.gov> 
Subject: Re: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to 
publish CCSDS 902.13-M-1, Abstract Event Definition (Magenta 
Book, Issue 1)

Hi Peter,  
                   in defining the Abstract Event, which is a concept that has a 
wide use case, certainly wider that just the Service Management W/G, 
we had interactions with several other working groups, MOIMS SM&C, 
MOIMS Mission Planning and in particular the Nav W/G, with which we 
had several joint sessions on the topic and whose members reviewed 
some of the working drafts of the abstract event.  

In the course of the discussions with the other W/Gs (and again in 
particular the Nav W/G) the abstract event evolved to become 
considerably more flexible and generic. One of the inputs that drove this 
was that, for at least some of the use cases that the Nav W/G envisaged 
, there was no need to have an event type specified. Thus this was made 
optional.  

In the specialisation of the abstract event used by service management 
the type is actually mandatory, so in principle the type in the abstract 
event could be made mandatory and this would have no effect on service 
management. It would however create potential issues for the use of the 
abstract event by other working groups.  

I would therefore strongly argue, to enable a common definition of event 
to be adopted, that the type in the abstract event should remain optional.  

Cheers for now,  

Colin  

-------------------------------------------------------------------------------------------------
-------- 
Dr. Colin R. Haddow, 
HSO-GI, European Space Agency, 
European Space Operations Centre, 
Robert-Bosch-Str 5, 
64293 Darmstadt, 
Germany. 

Phone; +49 6151 90 2896 
Fax;      +49 6151 90 3010 
E-Mail;  colin.haddow at esa.int 
-------------------------------------------------------------------------------------------------
-------- 

From:        "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>  
To:        "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>  
Cc:        "CCSDS Secretariat" <thomas.gannett at tgannett.net>, 
"Colin.Haddow at esa.int" <Colin.Haddow at esa.int>  
Date:        11/06/2020 00:49  
Subject:        Re: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to publish 
CCSDS 902.13-M-1,  Abstract Event Definition (Magenta Book, Issue 1) 

I'm certainly open to a further discussion.  

I can indeed imagine that you could create a streaming service 
where the source & destination, or the service provider, of "pipe" 
provided all of the needed data typing.  That said, in this day and 
age I really wonder if saving a few bytes of Type ID is a huge 
benefit.  Aren't we typically slinging XML, or JSON, or some 
other "wordy" data streams around?

Thanks, Peter

From: Erik Barkley <erik.j.barkley at jpl.nasa.gov> 
Date: Wednesday, June 10, 2020 at 2:41 PM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov> 
Cc: Tom Gannett <thomas.gannett at tgannett.net>, Colin Haddow 
<Colin.Haddow at esa.int> 
Subject: RE: [EXTERNAL] Re: CESG-P-2020-03-004 Approval 
to publish CCSDS 902.13-M-1, Abstract Event Definition 
(Magenta Book, Issue 1)

Peter,

It is not inconceivable that somewhere in CCSDS 
some sort of streaming service is developed based 
on the abstract event definition. I will admit I'm 
hard-pressed to say what service that could be given 
what we have already defined but let's take this is as 
hypothetical case. Let's say that the service operates 
similar to SLE/CSTS  in other words in a bound 
context, and that it only deals in one type of event 
message. If the type parameter is mandatory now 
every message has to carry the same type 
information. Okay, doesn't hurt anything rather 
than being a bit redundant. 

In any case, I think I will defer to Colin on this, 
being that he is the book boss and coordinated a fair 
amount with the NAVWG on this definition.    As I 
recall, there were a fair number of RIDs during 
agency review some of which, although I don't recall 
any touched on the type parameter, had subtle 
points with regard to mandatory versus optional 
parameters. I'd like to see what Colin has to say.

-Erik

From: Shames, Peter M (US 312B)  
Sent: Wednesday, June 10, 2020 13:34 
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov> 
Cc: CCSDS Secretariat <thomas.gannett at tgannett.net>; 
Colin.Haddow at esa.int 
Subject: Re: [EXTERNAL] Re: CESG-P-2020-03-004 Approval 
to publish CCSDS 902.13-M-1, Abstract Event Definition 
(Magenta Book, Issue 1)

Hi Erik,

I guess I am still failing to understand why having everything, 
including Type, be optional is so desirable.  I do know that the SLS 
guys tend to like to use what they call "managed parameters" 
instead of taking up what they see as valuable PDU space with flag 
bits.  Somehow, given the voluminous nature of most CSS specs I 
cannot believe that is the case here.

What is the strong argument that you have for not making at least 
Type be mandatory?  Also, it does occur to me that you might even 
want a registry of Event Types, but I am not asserting that as a 
requirement.

Do recall that as a MB this is still a Normative CCSDS document.  

Thanks, Peter

From: Erik Barkley <erik.j.barkley at jpl.nasa.gov> 
Date: Wednesday, June 10, 2020 at 1:20 PM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov> 
Cc: Tom Gannett <thomas.gannett at tgannett.net>, Colin Haddow 
<Colin.Haddow at esa.int> 
Subject: RE: [EXTERNAL] Re: CESG-P-2020-03-004 Approval 
to publish CCSDS 902.13-M-1, Abstract Event Definition 
(Magenta Book, Issue 1)

Peter,

I appreciate the desire to have a concrete definition, 
but I still think the onus lies with using 
recommendation. As an example, below is a 
screenshot from one such using recommendation, 
the SM Common Data Entities, which states the 
form that the abstract event takes for the purposes 
of service management:

Here type and user are now mandatory as well as 
statement of epochTimeSystem and expression of 
times in TimeCodeB.  I think this is as it should be. 
Can we guarantee that having the type definition be 
mandatory causes no harm/issues to any potential 
future using recommendation?  I will concede that 
a definition, in the extreme, could be 
NULL.   Given that this is a magenta book and 
therefore a best practices, we could do something 
like add a statement that says that a using 
recommendation should at least make the type 
parameter mandatory in order to have a meaningful 
derived concrete event from the abstract event 
definition. I'm not sure the exact phrasing yet but 
something along those lines. Does that work for 
you?

-Erik

From: Shames, Peter M (US 312B)  
Sent: Wednesday, June 10, 2020 10:15 
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov> 
Cc: CCSDS Secretariat <thomas.gannett at tgannett.net>; 
Colin.Haddow at esa.int 
Subject: Re: [EXTERNAL] Re: CESG-P-2020-03-004 Approval 
to publish CCSDS 902.13-M-1, Abstract Event Definition 
(Magenta Book, Issue 1)

Erik,

I get what you are trying to do, but this still strikes me as being 
really vague to the point where a definition, in the extreme, could 
be NULL.  I.e. everything is both Abstract and Optional.   You 
seem adamant that this is just fine.  I'd consider accepting it, but I 
truly have no idea what do to with it.  

I think that at least the Type parameter ought to be Mandatory, 
otherwise you really have just a NULL definition as a possible 
outcome.

Peter

From: Erik Barkley <erik.j.barkley at jpl.nasa.gov> 
Date: Tuesday, June 9, 2020 at 5:01 PM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov> 
Cc: Tom Gannett <thomas.gannett at tgannett.net>, Colin Haddow 
<Colin.Haddow at esa.int> 
Subject: RE: [EXTERNAL] Re: CESG-P-2020-03-004 Approval 
to publish CCSDS 902.13-M-1, Abstract Event Definition 
(Magenta Book, Issue 1)

Peter,

Attached please find the CSS Area responses to your 
conditions.  Essentially the responses boil down to 902x13m being 
an abstract definition with further specification being the 
provenance of the using recommendation.   

Best regards,
-Erik  

-----Original Message-----
From: CCSDS Secretariat <thomas.gannett at tgannett.net> 
Sent: Tuesday, April 21, 2020 08:11
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>; 
Colin.Haddow at esa.int
Cc: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Subject: [EXTERNAL] Re: CESG-P-2020-03-004 Approval to 
publish CCSDS 902.13-M-1, Abstract Event Definition (Magenta 
Book, Issue 1)

Colin, Erik:

The CESG poll to approve publication of CCSDS 902.13-M-1, 
Abstract Event Definition (Magenta Book, Issue 1) concluded with 
conditions. 
Please negotiate disposition of the conditions directly with the
AD(s) who voted to approve with conditions and CC the 
Secretariat on all related correspondence.

CESG E-Poll Identifier:  CESG-P-2020-03-004 Approval to 
publish CCSDS 902.13-M-1, Abstract Event Definition (Magenta 
Book, Issue 1)

Results of CESG poll beginning 31 March 2020 and ending 17 
April 2020:

                 Abstain:  1 (20%) (Calzolari) Approve 
Unconditionally:  3 (60%) (Barkley, Burleigh, Wilmot) Approve 
with Conditions:  1 (20%) (Shames) Disapprove with Comment:  0 
(0%)

CONDITIONS/COMMENTS:

     Peter Shames (Approve with Conditions):  The table 3-1 that 
defines the data structure appears to consist entirely of "optional" 
items, in which case a NULL structure would be acceptable.  Is 
this really the case?  Also, the terms "type" and "user" in that table 
appear to be so vaguely defined as to be meaningless.

Total Respondents:  5

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

     MOIMS

SECRETARIAT INTERPRETATION OF RESULTS:  Approved 
with Conditions
PROPOSED SECRETARIAT ACTION:            Generate CMC 
poll after 
conditions have been addressed

* * * * * * * * * * * * * * * * * * * * * * * *

This message is intended only for the recipient(s) 
named above. It may contain proprietary information 
and/or
protected content. Any unauthorised disclosure, use, 
retention or dissemination is prohibited. If you have 
received
this e-mail in error, please notify the sender 
immediately. ESA applies appropriate organisational 
measures to protect
personal data, in case of data privacy 
queries, please contact the ESA Data 
Protection Officer (dpo at esa.int).