Subject: [Ecrit] Thoughts on draft-ietf-ecrit-additional-data v29

From: Matt Serra <[email-masked]>
Date: Thu, 9 Apr 2015 17:33:28 +0000

All -

It's been a while since I've read the doc front to back and I have a few observations / questions I'd like to submit to the group.

4. Data Provider Information and deriving "intent"/"context":

-          In theory, a given data provider can provide any combination of the defined structures

-          As I understand, this mechanism will be expanded to carry more than call-describing information (as is the focus of the current document).  For example, information about the caller (medical info), and perhaps their emergency contacts.

-          Arguably, the only mechanism provided to distinguish the "intent" or "context" of the provided data to infer it which blocks transmitted by the data provider.  As some of the blocks will likely be reused across scenarios (e.g. data provider and comments), some ambiguity could be introduced.

-          Recipients of this data may want an easier way to audit the data accompanying a call, so they can filter out the data relevant to the business function the receiving system  performs.

-          Options:

o   Add a field to the Provider-Info block where the Data Provider could identify the intent of the set of data being passed over

o   Extend the valid values in the "TypeOfProvider".  I'm open to this, but it could mean a given provider would appear with different TypeOfProvider values if they source multiple kinds of data.  It is also possible that this field could become overloaded.

o   Do nothing.  Assume a given data-set will contain a small number of blocks, and that the blocks are self-describing.

-          Thoughts?

4.1 Data Provider information.  I believe a Data Provider could also supply this block.  There are and will be entities that are neither a service provider or an access network provider.  This may also suggest we extend the valid values in 4.1.4

Thanks,

Matt

[rave_email_signature]

  Matthew A. Serra, ENP
  Sr. Director, Product Management
  Mobile:  201.245.1557
  [email-masked]<mailto:[email-masked]>

---

From: "Randall Gellens" <[email-masked]>
Date: Thu, 9 Apr 2015 20:10:30 -0700

Hi Matt,

Thanks for the review and thoughts.  Please see in-line.

> It's been a while since I've read the doc front to back and I have a few
> observations / questions I'd like to submit to the group.
>
> -          As I understand, this mechanism will be expanded to carry more
> than call-describing information (as is the focus of the current
> document).  For example, information about the caller (medical info), and
> perhaps their emergency contacts.
>
> -          Arguably, the only mechanism provided to distinguish the
> "intent" or "context" of the provided data to infer it which blocks
> transmitted by the data provider.  As some of the blocks will likely be
> reused across scenarios (e.g. data provider and comments), some ambiguity
> could be introduced.

The idea is that the definition of each block includes the type of data
and its intended use.  Some blocks, especially those describing the data
provider, will be added by multiple data providers, but I don't see this
as introducing any ambiguity.  Furthermore, when a data provider adds a
set of blocks, these are linked together by an identifying string.

The intent is that each entity processing the call and its data will have
a policy as to which blocks it will access.  For example, a PSAP may
decide to access blocks with the caller's contact information, but choose
to not access blocks containing medical data.  Blocks not accessed by one
entity are still available to other entities.  A responder might have a
policy to access blocks containing medical data.

> -          Recipients of this data may want an easier way to audit the
> data accompanying a call, so they can filter out the data relevant to the
> business function the receiving system  performs.

I am not sure what you mean by "audit" but there is clearly an intent to
enable each entity to decide which blocks it chooses to access.  There are
important reasons why an entity may choose to not access certain blocks
(e.g., medical data).

> -          Options:
>
> o   Add a field to the Provider-Info block where the Data Provider could
> identify the intent of the set of data being passed over

This is supposed to be clear from the block definition.

> o   Extend the valid values in the "TypeOfProvider".  I'm open to this,
> but it could mean a given provider would appear with different
> TypeOfProvider values if they source multiple kinds of data.  It is also
> possible that this field could become overloaded.

This field is an IANA registry and so can be expanded as needed.

> o   Do nothing.  Assume a given data-set will contain a small number of
> blocks, and that the blocks are self-describing.

The definition of each block should indicate the type of data and the
expected use.

> -          Thoughts?
>
>
> 4.1 Data Provider information.  I believe a Data Provider could also
> supply this block.

I'm not sure what you mean.  This block is supposed to be added by each
data provider.

>  There are and will be entities that are neither a
> service provider or an access network provider.  This may also suggest we
> extend the valid values in 4.1.4

This is an IANA registry and so can be expanded as needed.  If you feel
additional values are needed at the onset, please suggest them and why.

---

From: Matt Serra <[email-masked]>
Date: Fri, 10 Apr 2015 15:45:35 +0000

Randy - I think that makes sense.  

The only other question I have is related to what happens when a single data provider provides multiple forms of data?  For example, providing Service Information and associated Comment, as well as a TBD "caller" and/or "location" block that are also accompanied by other general-purpose blocks, such as Comments or Emergency Contacts?

Would there be a way to distinguish which "reusable" block goes with a particular form of data provided by the same Data Provider?

The only way I see this working with the current layout, would be for the DataProvider to provide multiple separate sets of blocks, grouped by the form of data being described (call, caller or location), where each of these groups have a nearly identical Data Provider block, varying only by a unique DataProviderReference which would be used by the receiving system to collate the blocks properly.

I hope I'm being clear - - I could sketch something up if not.

And yes, by "audit" I was referring to a process where the system consuming the data inspects the various blocks for the purpose of deciding what, if anything, to do with each set of data based on the rules built into the data-consuming system.

Thanks,

Matt.

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Thursday, April 9, 2015 11:11 PM
To: Matt Serra
Cc: [email-masked]
Subject: Re: [Ecrit] Thoughts on draft-ietf-ecrit-additional-data v29

Hi Matt,

> It's been a while since I've read the doc front to back and I have a 
> few observations / questions I'd like to submit to the group.
>
> document).  For example, information about the caller (medical info), 
> and perhaps their emergency contacts.
>
> transmitted by the data provider.  As some of the blocks will likely 
> be reused across scenarios (e.g. data provider and comments), some 
> ambiguity could be introduced.

The idea is that the definition of each block includes the type of data and its intended use.  Some blocks, especially those describing the data provider, will be added by multiple data providers, but I don't see this as introducing any ambiguity.  Furthermore, when a data provider adds a set of blocks, these are linked together by an identifying string.

The intent is that each entity processing the call and its data will have a policy as to which blocks it will access.  For example, a PSAP may decide to access blocks with the caller's contact information, but choose to not access blocks containing medical data.  Blocks not accessed by one entity are still available to other entities.  A responder might have a policy to access blocks containing medical data.

> data accompanying a call, so they can filter out the data relevant to 
> the business function the receiving system  performs.

I am not sure what you mean by "audit" but there is clearly an intent to enable each entity to decide which blocks it chooses to access.  There are important reasons why an entity may choose to not access certain blocks (e.g., medical data).

> TypeOfProvider values if they source multiple kinds of data.  It is 
> also possible that this field could become overloaded.

> blocks, and that the blocks are self-describing.

The definition of each block should indicate the type of data and the expected use.

> 4.1 Data Provider information.  I believe a Data Provider could also 

I'm not sure what you mean.  This block is supposed to be added by each data provider.

>  There are and will be entities that are neither a service provider or 
> an access network provider.  This may also suggest we extend the valid 
> values in 4.1.4

This is an IANA registry and so can be expanded as needed.  If you feel additional values are needed at the onset, please suggest them and why.

---

From: "Randall Gellens" <[email-masked]>
Date: Sat, 11 Apr 2015 18:40:12 -0700

Hi Matt,

> The only other question I have is related to what happens when a single
> data provider provides multiple forms of data?  For example, providing
> Service Information and associated Comment, as well as a TBD "caller"
> and/or "location" block that are also accompanied by other general-purpose
> blocks, such as Comments or Emergency Contacts?
>
> Would there be a way to distinguish which "reusable" block goes with a
> particular form of data provided by the same Data Provider?
>
> The only way I see this working with the current layout, would be for the
> DataProvider to provide multiple separate sets of blocks, grouped by the
> form of data being described (call, caller or location), where each of
> these groups have a nearly identical Data Provider block, varying only by
> a unique DataProviderReference which would be used by the receiving system
> to collate the blocks properly.

I'm not sure why the service provider would need to include separate Data
Provider blocks.  What would be the problem with a service provider
including as many blocks as it can?  E.g., provider info, service info,
device info, future location info, future caller info, etc.

If there was a need for a single service provider to include multiple
blocks of the same type (duplicates if you will), hypothetically, maybe a
call transited a service provider multiple times, then yes, each set of
blocks would have a unique DataProviderReference.  There is text in the
draft saying so.  But I'm not sure how realistic this scenario is.

> And yes, by "audit" I was referring to a process where the system
> consuming the data inspects the various blocks for the purpose of deciding
> what, if anything, to do with each set of data based on the rules built
> into the data-consuming system.

To be very clear, the system would inspect the block metadata (i.e., the
block type) to decide if it wants to access the block data. This allows a
system to avoid ever accessing data it wants to avoid (such as medical
data).  Having the block metadata in the header makes this easier.