Subject: [Ecrit] Suggestion for "Provider-Info" block usage (draft-ietf-ecrit-additional-data-29.txt)

From: Matt Serra <[email-masked]>
Date: Fri, 1 May 2015 22:05:53 +0000

Our NENA Additional Data WG made an observation that we'd like to submit for the groups consideration:

We noted section 4.1 describes the usage for the "Data Provider Information Block" as "SHOULD" and "MAY" provide.

We'd like to propose that the group consider making the usage of this block "Conditional": MUST be provided if the data-provider inserts any other block, otherwise MAY be provided.

This would ensure that the provider of all data inserted into the Call Info header identifies themselves.

Regards,

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: Tue, 5 May 2015 15:49:01 -0700

At 10:05 PM +0000 5/1/15, Matt Serra wrote:

>  We noted section 4.1 describes the usage for the "Data Provider 
> Information Block" as "SHOULD" and "MAY" provide.
>
>  We'd like to propose that the group consider making the usage of 
> this block "Conditional": MUST be provided if the data-provider 
> inserts any other block, otherwise MAY be provided.
>

This seems reasonable to me: if an entity adds any blocks, it MUST 
add a Provider Info block.  If it touches the call in some way but 
does not add any blocks, it MAY add a Provider Info block (to 
indicate that it did touch the call, which might be useful for after 
the fact problem tracking).

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Americans have an abiding belief in their ability to control reality
by purely material means.... airline insurance replaces the fear of
death with the comforting prospect of cash.
            ==Cecil Beaton, It Gives Me Great Pleasure, 1955.