Subject: Re: [dtn] AMP comment on type hierarchy and operators

From: Brian Sipos <[email-masked]>
Date: Wed, 6 Apr 2016 19:26:29 +0000

I was not too clear on this, but there are three things being discussed:
1. I advocate making a type hierarchy with root type. This does not (necessarily) mean any change to current type ID assignments.

2. The type ID table, which may benefit from being able to define literals/operators to take/return new All or Numeric type IDs.

3. My conception of ADM derived types is that they would take two forms, both similar to SNMP textual convention, and both being transparent to AMP (ie no new type IDs).
Subtypes of concrete numeric (INT, FLOAT32, etc) would be used to either refine valid range, specify a value unit, or define semantics via YANG description.
Subtypes of BLOB would be used for application specific binary encoding. A blind AMP decoder sees BLOB, but ADM aware decoder could interpret data.
I suppose you could also subtype STR to document valid patterns, etc.
On Apr 6, 2016 12:27 PM, "Birrane, Edward J." <[email-masked]> wrote:

I agree that we need a way to classify types, and what types are used where. Since types appear in many places in AMP, I am worried about expanding the definition of the basic types beyond a BYTE.

Currently the concept for OPS is that they up-cast their operands based on the types of the operands, which is what the current reference implementation does.  For example, for the + op, float32 + int generates a float32. operands for which there is no defined type conversion results in an expression error (e.g., 4 + "three").

The next version of the AMP spec needs to list these allowed conversions.

It would be good to brainstorm on what derived types in ADMs would look like. Do you have an example of a derived type you would like to see in one of the ADMs you are working on?

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
________________________________
From: dtn <[email-masked]> on behalf of Brian Sipos <[email-masked]>
Sent: Monday, April 4, 2016 4:59 PM
To: [email-masked]
Subject: [dtn] AMP comment on type hierarchy and operators

This is a comment against "draft-birrane-dtn-amp-02".

It may be helpful to put the AMP basic/compound data types into a true hierarchy. One reason for this is to distinguish the "Numeric" types from non-numeric. A secondary reason would be to allow defining an "Any" root type for the basic/compound types.

This would then allow for specifying an ADM literal/operator which takes the "Any" base type as argument/return to perform the same behavior as the multitude of "User VAST", "User Float", ... literals of draft-birrane-dtn-adm-agent-01. It would also allow the numerical operators of the same draft to take "Number" abstract type as argument/return. As currently defined, the "adm-agent-01" operators are not actually able to be defined in AMP because they do not have operand types specified (unless I am somehow misreading the AMP spec on MID encoding).

I don't see this as a huge issue, but it would simplify ADMs by allowing literals and operators defined with an abstract type to be given a derived type at runtime and satisfy all of the (other) protocol constraints on types.

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sun, 17 Apr 2016 19:51:34 +0000

Brian,

  Agreed that having some way for ADMs to define their own types so as to provide bounds checking or to make use of the BLOB type is a useful feature, and that implementing this kind of support in AMP does not necessarily mean expanding the size of the AMP types.

  I could see AMP supporting a hierarchy of types, with the first layer being something like {numeric, logical, structure}  and then the AMP IDs at the second layer. I further agree that with a little cleverness we could keep all of the basic AMP types to 1 byte (much like the first 2 octets in ASN.1 are combined).

  There are some real challenges to this approach:

  - There needs to be a way to ensure different ADMs do not define the same type, thus making a type collision on an agent trying to implement both ADMs. This either means a registry for such types, or placing ADM-defined type definitions in the ADM OID subtree.  The latter means type definitions for non-basic types are going to be large on the wire.

  - I am worried about the implications for type dependencies. What happens when ADM1 defines a subtype which ADM2 wishes to further subtype? You could get different behavior from an agent based on whether it supports neither, one, the other, or both ADMs.

  It would be interesting to map out the impact of that on the general-purpose evaluation engines. I am certainly willing to try and represent this in the next AMP spec. Perhaps we should come up with a few concrete examples as well.

-Ed

---

From: Brian Sipos [mailto:[email-masked]]
Sent: Wednesday, April 06, 2016 3:26 PM
To: Birrane, Edward J.
Cc: [email-masked]
Subject: Re: AMP comment on type hierarchy and operators

On Apr 6, 2016 12:27 PM, "Birrane, Edward J." <[email-masked]<mailto:[email-masked]>> wrote:

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
________________________________
From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of Brian Sipos <[email-masked]<mailto:[email-masked]>>
Sent: Monday, April 4, 2016 4:59 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn] AMP comment on type hierarchy and operators

---

From: Brian Sipos <[email-masked]>
Date: Mon, 18 Apr 2016 13:25:20 +0000

Conveniently, specifying an ADM in YANG takes care of both of these issues:

 - All YANG types are namespaced to the module, so "adm1:mytype" and "adm2:mytype" are absolutely unique and unambiguous.

 - The exiting YANG module "import" semantics are applied, so that if ADM2 chooses to "import" from ADM1 the import is for a specific, dated revision of the ADM1 module. For stable, long-term operations I'm really using "adm1@2016-08-12" rather than just plain "adm1".

My advocated behavior is that *all* of this typing occurs outside of the AMP proper and lives entirely in agent/manager domain. None of these extended types are encoded "on the wire" and none involve any change to current AMP to accommodate. These all behave nearly identically to current SNMP "textual convention" behavior, which means that if I don't have the ADM module then I see the base encoded type (INT, BLOB, etc.) which is fine if I don't necessarily care about the value semantics. If I do have the ADM module, then the ADM is how the OID and derived type are associated and how I (as the Manager application) can determine that this INT is really an "adm2:Counter" which has units of "bytes", etc.

________________________________
From: Birrane, Edward J. <[email-masked]>
Sent: Sunday, April 17, 2016 15:51
To: Brian Sipos
Cc: [email-masked]
Subject: RE: AMP comment on type hierarchy and operators

Brian,

-Ed

---

Space Exploration Sector

-Ed

---

---

From: Brian Sipos <[email-masked]>
Date: Mon, 18 Apr 2016 14:13:41 +0000

Also, speaking specifically about subtypes:

Because the YANG definition of subtype is that it is used to "formally restrict the set of possible values" it's really an optional behavior from perspective of an ADM. If I subtype a "port-number" type it's really only to exclude/include a certain port range. If I subtype a "counter32" type it is really only to apply a human-readable unit name. These are not really things that would directly affect an Agent's behavior, but more in the other direction; as in the ADM should be updated to reflect any functional changes in the Agent. An agent should (would) already be restricting the use of port numbers, time durations, data sizes, etc.

________________________________
From: dtn <[email-masked]> on behalf of Brian Sipos <[email-masked]>
Sent: Monday, April 18, 2016 09:25
To: Birrane, Edward J.
Cc: [email-masked]
Subject: Re: [dtn] AMP comment on type hierarchy and operators

Brian,

-Ed

---

Space Exploration Sector

-Ed

---