[Teas-ns-dt] A commonly used approach to tracking issues...

[Eric Gray <[e-mail]>]

Authors/Editors,

To be more precise about the measurability aspect, what I believe was suggested is as follows:
1) list measurability as a generic characteristic that may apply to many objectives;
2) for example - directly measurable, indirectly measurable or calculated, implicit.
3) some examples might be provided, but it must be clear that any explicitly listed objectives (or SLA parameters) are examples and - in specific cases (underlying technologies, applicable measurement approaches, etc.) - may apply to different categories;
4) note that - if this gets to be too hard - that might be seen as evidence that providing examples in this draft might actually be a bad idea;
5) separately list (and define) an initial robust set of objectives;
6) add text that further objectives may be defined as needed in subsequent specification.

It's important for people to remember that this is a definitions draft.  It should not be seen as necessary by anyone to include every possible service objective that might be needed to serve some specific use case (or use cases), or we will never complete this work.

On the topic of encryption, it is clear that - unless a client is providing their own - it is typically not possible for the client to determine directly that their traffic is actually being protected by encryption.

However, it is commonly trivial for a provider to determine if their own encryption has failed.  Typically, if a client's traffic is supposed to be protected (by encryption, for example) it is implied that the service must be terminated if any failure occurs where the client's data is no longer protected (i.e. - the "last level of protection" should be to reject further traffic from any client when the protection they contracted for cannot be provided).

There are other examples of difficult (or impossible) to measure service characteristics where it is the provider's implied responsibility to discontinue the service when a requested service objective cannot be (or is not being) met.  We could refer to these as implicit objectives.

If the understanding is that the service will be discontinued under these conditions (particularly if there is an error code for, or other indication of, the specific reason for discontinuing the service), then the existence of one or more implicit objectives is - in fact - measurable (assuming a certain amount of trust exists).

Regarding Jeff's observation about data storage, and Kiran's objection to this (saying that storage is not part of a transport slice): Kiran's wanting to include network function resources as a specific objective of a transport slice opens the door for this, because "caching" is very definitely a reasonable network function application.  If that is not the case, then we may want to consider putting network function resources in the same bucket with other "stuff to be defined in subsequent specification" (specifically because it is necessary to understand the specific set of supported network functions).

--
Eric