Subject: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 01 Sep 2015 16:47:54 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-ecrit-additional-data-34: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I've two things I'd like to chat about. (Note: I'm not trying
here to insist on my preferred outcome, but I would like to
have the discussion or else be pointed at where the WG 
already did that.)

(1) section 3: You say these MAY be used.  I'm not
sure that's a good option.  I think the data
minimisation recommendations argued for in RFC6973 and
RFC7258 would argue to add a MUST NOT. For example,
saying that these additional data MUST NOT be sent in
any non-emergency call without explicit user
permission on a per-call basis or something similar?
I have to admit I'm nervous that defining all of these
may mean that some UA somewhere starts sending some of
them in other calls without asking. A restriction
along those lines would also be more in line with
webrtc too perhaps. But maybe this was discussed in
the WG, having considered those privacy issues - was
it? Either way, would adding such a "MUST NOT except
if..." be a good plan?  4.3.4 is a good example of the
kind of thing I'd not want easily emitted in a call.

(2) I'd like to (perhaps briefly) argue that the
registries here should require more than expert
review. Extensibility in dealing with what will
inevitably be highly privacy sensitive data structures
that are vulnerable to misuse once registered seems to
perhaps call for a more stringent registration regime.
The document itself also argues (in 4.3.7) that adding
new kinds of data here can be counter productive for
emergency call handling, so being more conservative in
what we add seems unusually correct here. I'd like to
suggest we require standards track for extensions.
The following very recent -00 draft [1] makes some
related arguments (but of course has no standing in
the IETF so is just offered as a way to avoid
repeating some arguments, not as an appeal to
authority.)

   [1]
https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- abstract: the "or by reference" point is made twice
in the abstract

- intro: floor plans? HVAC status? really? Why not
contact lists? proximity of friends? That (or
inferring as much) seems to me to be going too far, if
applied to all calls. I'd say just saying that this
could be extended in future by other standards-track
specifications is enough. (See also discuss points above)

- intro: Wedding anniversary? That's surely not
relevant to a PSAP. 

- figure 5: "prison" is out of context here, I'd suggest 
deleting it. If not, why not add hospital, power station 
and many other kinds of building? There may be some 
country specific issue or technical here, but labelling 
that with "prison" seems inappropriate to me. 

- 4.3.8: sorry I don't get the privacy argument, can
you try explain it to me?  (I didn't know it was
possible to tempt an implementation, so the language
there could be improved for sure:-)

- section 5: good that this is HTTPS only. I think
provisioning the PKI for such a thing is easily done
these days and is rightly not optional. It might be
useful to say that TLS here needs to follow BCP195.  I
agree with the earlier comment that you should be
clear as to when mutually authenticated TLS is
required. The secdir review [2] also raised similar
issues and it'd be good to see responses to that too.
(Yes, that review only arrived today so it's entirely
reasonable to not have responded so far.)

   [2]
https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html

- section 8: the sizes of the various additional data
items here could be characteristic and leak value
information regardless of TLS or not-TLS - perhaps add
a warning that these may enable relatively simple
traffic analysis. And wouldn't it be nice if someone
had done the analysis of this potential vulnerability?
This is btw a real issue - recall that avatar icon
image size was usable to identify 30+% of contacts in
one social network even over TLS, but before the
provider canonicalised the avatar image sizes. 

- Thanks for section 9. Good job.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 01 Sep 2015 20:09:04 -0500

One comment-comment:

> that with "prison" seems inappropriate to me.

Hopefully the authors have more specifics, but my understanding is, at 
least in the US, prison inmate phone systems get very special handling. 
I can't speak for other countries.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Sep 2015 02:36:05 +0100

Hiya,

> I can't speak for other countries.

Sure. And many other countries have many other oddities no doubt.
I'd not be surprised if emergency call from mobiles in pubs late
in the evening were treated a bit differently for example in many
places.

So I guess I'm suggesting to isolate the technical aspects of that
handling and put one or more descriptors for those into the table.

Assigning very country specific meanings to generic terms is
probably not a great plan.

S.

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 2 Sep 2015 14:52:37 +0000

I’m okay with the MUST NOT except, and I can imagine other uses for these that will work fine if we write a document that explains them.

I’m strongly against standards track for extensions.  There are a number of organizations who have expertise that need to be able to define the data.  We can’t be experts in all things.  An example is that we’re going to extend for medical data useful to a first responder.  Clearly has major privacy issues, but we’re not the experts in that, and those that are don’t write RFCs.  NENA, the 9-1-1 organization in North America is working on extensions for location related data, and also knows 10X more about location data for emergency response than IETF does.  We need to let the experts do their jobs.

Brian

> On Sep 1, 2015, at 4:47 PM, Stephen Farrell <[email-masked]> wrote:
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Sep 2015 15:57:40 +0100

On 02/09/15 15:52, Rosen, Brian wrote:
> I’m okay with the MUST NOT except, and I can imagine other uses for
> these that will work fine if we write a document that explains them.

Cool, should be relatively easy to work out words if everyone
agrees on that.

> 
> I’m strongly against standards track for extensions.  There are a
> number of organizations who have expertise that need to be able to
> define the data.  We can’t be experts in all things.  An example is
> that we’re going to extend for medical data useful to a first
> responder.  Clearly has major privacy issues, but we’re not the
> experts in that, and those that are don’t write RFCs.  NENA, the
> 9-1-1 organization in North America is working on extensions for
> location related data, and also knows 10X more about location data
> for emergency response than IETF does.  We need to let the experts do
> their jobs.

Fair point. If we had a way to say "IETF standards-track or a standard
from an emergency services SDO" I'd be fine with that. I don't think we
do have a way to say that though, other than by writing guidance in
the IANA considerations section to that effect. Maybe someone who is
better at IANA minutiae can figure out a way to get that effect?

Cheers,
S.

>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>> 
>> 
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>> information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> here to insist on my preferred outcome, but I would like to have
>> the discussion or else be pointed at where the WG already did
>> that.)
>> 
>> (1) section 3: You say these MAY be used.  I'm not sure that's a
>> good option.  I think the data minimisation recommendations argued
>> for in RFC6973 and RFC7258 would argue to add a MUST NOT. For
>> example, saying that these additional data MUST NOT be sent in any
>> non-emergency call without explicit user permission on a per-call
>> basis or something similar? I have to admit I'm nervous that
>> defining all of these may mean that some UA somewhere starts
>> sending some of them in other calls without asking. A restriction 
>> along those lines would also be more in line with webrtc too
>> perhaps. But maybe this was discussed in the WG, having considered
>> those privacy issues - was it? Either way, would adding such a
>> "MUST NOT except if..." be a good plan?  4.3.4 is a good example of
>> the kind of thing I'd not want easily emitted in a call.
>> 
>> (2) I'd like to (perhaps briefly) argue that the registries here
>> should require more than expert review. Extensibility in dealing
>> with what will inevitably be highly privacy sensitive data
>> structures that are vulnerable to misuse once registered seems to 
>> perhaps call for a more stringent registration regime. The document
>> itself also argues (in 4.3.7) that adding new kinds of data here
>> can be counter productive for emergency call handling, so being
>> more conservative in what we add seems unusually correct here. I'd
>> like to suggest we require standards track for extensions. The
>> following very recent -00 draft [1] makes some related arguments
>> (but of course has no standing in the IETF so is just offered as a
>> way to avoid repeating some arguments, not as an appeal to 
>> authority.)
>> 
>> [1] 
>> in the abstract
>> 
>> - intro: floor plans? HVAC status? really? Why not contact lists?
>> proximity of friends? That (or inferring as much) seems to me to be
>> going too far, if applied to all calls. I'd say just saying that
>> this could be extended in future by other standards-track 
>> - intro: Wedding anniversary? That's surely not relevant to a PSAP.
>> 
>> 
>> - figure 5: "prison" is out of context here, I'd suggest deleting
>> it. If not, why not add hospital, power station and many other
>> kinds of building? There may be some country specific issue or
>> technical here, but labelling that with "prison" seems
>> inappropriate to me.
>> 
>> - 4.3.8: sorry I don't get the privacy argument, can you try
>> explain it to me?  (I didn't know it was possible to tempt an
>> implementation, so the language there could be improved for
>> sure:-)
>> 
>> - section 5: good that this is HTTPS only. I think provisioning the
>> PKI for such a thing is easily done these days and is rightly not
>> optional. It might be useful to say that TLS here needs to follow
>> BCP195.  I agree with the earlier comment that you should be clear
>> as to when mutually authenticated TLS is required. The secdir
>> review [2] also raised similar issues and it'd be good to see
>> responses to that too. (Yes, that review only arrived today so it's
>> entirely reasonable to not have responded so far.)
>> 
>> [2] 
>> - section 8: the sizes of the various additional data items here
>> could be characteristic and leak value information regardless of
>> TLS or not-TLS - perhaps add a warning that these may enable
>> relatively simple traffic analysis. And wouldn't it be nice if
>> someone had done the analysis of this potential vulnerability? This
>> is btw a real issue - recall that avatar icon image size was usable
>> to identify 30+% of contacts in one social network even over TLS,
>> but before the provider canonicalised the avatar image sizes.
>> 
>> _______________________________________________ Ecrit mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 2 Sep 2015 15:09:04 +0000

“Document Required” and “Expert Review” with guidance to the expert?

Brian

> On Sep 2, 2015, at 7:57 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Sep 2015 16:14:26 +0100

> “Document Required” and “Expert Review” with guidance to the expert?

Yeah that might be best I guess, if the guidance says something
the equivalent of "standards-track or a specification from a
<recognized?> emergency services SDO"

Do I recall right that this draft already sets up one registry that
essentially lists that kind of emergency services SDO? If so, then
an option might be to require that the specification be from one
of those and to require IESG approval for getting added to that
registry. We have a similar sort of setup for SDOs that do some
media type stuff, so this isn't that innovative, if the list of
relevant SDOs is likely smallish and stable.

Cheers,
S.

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 2 Sep 2015 15:38:25 +0000

No, there is no such list.  There is a registry of identifiers assigned by other authorities, which is what I think you are thinking about.  But that list is not a list of entities who produce standards.  It happens that NENA has an ID series, and does standards, but there are plenty of examples of standards organizations who don’t have identifier series and others that have identifiers series but don’t produce standards.  I’m confident an expert can distinguish when a document comes from an appropriate organization.

Brian
> On Sep 2, 2015, at 8:14 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Sep 2015 16:42:29 +0100

On 02/09/15 16:38, Rosen, Brian wrote:
> No, there is no such list.  There is a registry of identifiers
> assigned by other authorities, which is what I think you are thinking
> about.  But that list is not a list of entities who produce
> standards.  It happens that NENA has an ID series, and does
> standards, but there are plenty of examples of standards
> organizations who don’t have identifier series and others that have
> identifiers series but don’t produce standards.  I’m confident an
> expert can distinguish when a document comes from an appropriate
> organization.

Fair enough. I'd clear the discuss on that basis anyway.

Cheers,
S.

>> Yeah that might be best I guess, if the guidance says something the
>> equivalent of "standards-track or a specification from a 
>> Do I recall right that this draft already sets up one registry
>> that essentially lists that kind of emergency services SDO? If so,
>> then an option might be to require that the specification be from
>> one of those and to require IESG approval for getting added to
>> that registry. We have a similar sort of setup for SDOs that do
>> some media type stuff, so this isn't that innovative, if the list
>> of relevant SDOs is likely smallish and stable.
>> 
>> Cheers, S.
>> 
>> 
>>> 
>>> Brian
>>> 
>>>>> I’m okay with the MUST NOT except, and I can imagine other
>>>>> uses for these that will work fine if we write a document
>>>>> that explains them.
>>>> 
>>>>> I’m strongly against standards track for extensions.  There
>>>>> are a number of organizations who have expertise that need to
>>>>> be able to define the data.  We can’t be experts in all
>>>>> things.  An example is that we’re going to extend for medical
>>>>> data useful to a first responder.  Clearly has major privacy
>>>>> issues, but we’re not the experts in that, and those that are
>>>>> don’t write RFCs.  NENA, the 9-1-1 organization in North
>>>>> America is working on extensions for location related data,
>>>>> and also knows 10X more about location data for emergency
>>>>> response than IETF does.  We need to let the experts do their
>>>>> jobs.
>>>> 
>>>> Fair point. If we had a way to say "IETF standards-track or a
>>>> standard from an emergency services SDO" I'd be fine with that.
>>>> I don't think we do have a way to say that though, other than
>>>> by writing guidance in the IANA considerations section to that
>>>> effect. Maybe someone who is better at IANA minutiae can figure
>>>> out a way to get that effect?
>>>> 
>>>> Cheers, S.
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> Brian
>>>>> 
>>>>>> Stephen Farrell has entered the following ballot position
>>>>>> for draft-ietf-ecrit-additional-data-34: Discuss
>>>>>> 
>>>>>> When responding, please keep the subject line intact and
>>>>>> reply to all email addresses included in the To and CC
>>>>>> lines. (Feel free to cut this introductory paragraph,
>>>>>> however.)
>>>>>> 
>>>>>> 
>>>>>> Please refer to 
>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>>> (1) section 3: You say these MAY be used.  I'm not sure
>>>>>> that's a good option.  I think the data minimisation
>>>>>> recommendations argued for in RFC6973 and RFC7258 would
>>>>>> argue to add a MUST NOT. For example, saying that these
>>>>>> additional data MUST NOT be sent in any non-emergency call
>>>>>> without explicit user permission on a per-call basis or
>>>>>> something similar? I have to admit I'm nervous that 
>>>>>> defining all of these may mean that some UA somewhere
>>>>>> starts sending some of them in other calls without asking.
>>>>>> A restriction along those lines would also be more in line
>>>>>> with webrtc too perhaps. But maybe this was discussed in
>>>>>> the WG, having considered those privacy issues - was it?
>>>>>> Either way, would adding such a "MUST NOT except if..." be
>>>>>> a good plan?  4.3.4 is a good example of the kind of thing
>>>>>> I'd not want easily emitted in a call.
>>>>>> 
>>>>>> (2) I'd like to (perhaps briefly) argue that the registries
>>>>>> here should require more than expert review. Extensibility
>>>>>> in dealing with what will inevitably be highly privacy
>>>>>> sensitive data structures that are vulnerable to misuse
>>>>>> once registered seems to perhaps call for a more stringent
>>>>>> registration regime. The document itself also argues (in
>>>>>> 4.3.7) that adding new kinds of data here can be counter
>>>>>> productive for emergency call handling, so being more
>>>>>> conservative in what we add seems unusually correct here.
>>>>>> I'd like to suggest we require standards track for
>>>>>> extensions. The following very recent -00 draft [1] makes
>>>>>> some related arguments (but of course has no standing in
>>>>>> the IETF so is just offered as a way to avoid repeating
>>>>>> some arguments, not as an appeal to authority.)
>>>>>> 
>>>>>> [1] 
>>>>>> in the abstract
>>>>>> 
>>>>>> - intro: floor plans? HVAC status? really? Why not contact
>>>>>> lists? proximity of friends? That (or inferring as much)
>>>>>> seems to me to be going too far, if applied to all calls.
>>>>>> I'd say just saying that this could be extended in future
>>>>>> by other standards-track specifications is enough. (See
>>>>>> also discuss points above)
>>>>>> 
>>>>>> and many other kinds of building? There may be some country
>>>>>> specific issue or technical here, but labelling that with
>>>>>> "prison" seems inappropriate to me.
>>>>>> 
>>>>>> - 4.3.8: sorry I don't get the privacy argument, can you
>>>>>> try explain it to me?  (I didn't know it was possible to
>>>>>> tempt an implementation, so the language there could be
>>>>>> improved for sure:-)
>>>>>> 
>>>>>> provisioning the PKI for such a thing is easily done these
>>>>>> days and is rightly not optional. It might be useful to say
>>>>>> that TLS here needs to follow BCP195.  I agree with the
>>>>>> earlier comment that you should be clear as to when
>>>>>> mutually authenticated TLS is required. The secdir review
>>>>>> [2] also raised similar issues and it'd be good to see 
>>>>>> responses to that too. (Yes, that review only arrived today
>>>>>> so it's entirely reasonable to not have responded so far.)
>>>>>> 
>>>>>> [2] 
>>>>>> could be characteristic and leak value information
>>>>>> regardless of TLS or not-TLS - perhaps add a warning that
>>>>>> these may enable relatively simple traffic analysis. And
>>>>>> wouldn't it be nice if someone had done the analysis of
>>>>>> this potential vulnerability? This is btw a real issue -
>>>>>> recall that avatar icon image size was usable to identify
>>>>>> 30+% of contacts in one social network even over TLS, but
>>>>>> before the provider canonicalised the avatar image sizes.
>>>>>> 
>>>>>> _______________________________________________ Ecrit
>>>>>> mailing list [email-masked]

---

From: Randall Gellens <[email-masked]>
Date: Mon, 14 Sep 2015 18:56:16 -0700

Hi Stephen and everyone,

Thanks for your comments.  Please see in-line.

>  https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

There are two subissues here: the non-use of normative language, and 
the recognition that there are limited non-emergency cases where this 
can be used.  The document originally had normative language here, 
but there was some small discussion in ECRIT meetings and email based 
on (if I recall correctly), an objection from Keith Drage that the 
document couldn't impose these blanket mandates; Keith wanted the 
document to say only that use outside of an emergency call was 
undefined, but I wanted something stronger, so added text that it was 
not appropriate.  I don't mind if we want to go back to being 
normative, but I wanted to point out that it was changed based on 
Keith's objection.  The permission for certain private-use cases is 
to permit telematics service providers to use the same mechanisms on 
both legs of a call: between the vehicle and the telematics service 
center, and between the telematics service center and the PSAP; 
further, it makes sense to use the same mechanisms between the 
vehicle and telematics service center in all calls, since the service 
center call handler determines if a call is an emergency or not (as 
opposed to the vehicle in the direct case).  This is a very limited 
case, and it matches how things work in circuit-switched calls.

>  https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00

We've had some discussion on this point alone.  I changed all 
instances where the text said:

    The expert should determine that the entity requesting a new value 
is relevant for this service element

To add an example that the entity is a recognized emergency-related SDO:

    The expert should determine that the entity requesting a new value 
is relevant for this service element (e.g., a recognized emergency 
services related SDO)

I don't think it's duplicative, since the first time says that this 
document does it both ways, and the second time says that previous 
mechanisms also did it both ways.

>  specifications is enough. (See also discuss points above)

This text is informative and explanatory, it helps the reader 
understand what is meant by information about a location, and 
mentions specific types of data that NENA is in fact working on. 
Both proximity of friends and contact lists seem like data associated 
with a caller, which NENA has also worked on and defined a separate, 
out-of-band mechanism for (the data is held by a third party, a 
registry of third parties is available to the PSAP, who queries them).

>  - intro: Wedding anniversary? That's surely not

The text in question mentions it only as an example of personal data 
that might seem to indicate that vcard should be categorized as data 
about the caller rather than data about the call.  The draft does not 
require that anniversary date be sent (and in fact doesn't mandate 
which vcard fields are to be sent), although it's conceivable that a 
wedding anniversary might be useful to a PSAP call taker in some 
circumstances (such as when a caller might be suicidal).

>  that with "prison" seems inappropriate to me.

We've discussed this in other email, but the short answer is that 
this matches capabilities provided in legacy emergency services 
systems, and we don't want to lose functionality.  It's quite common 
for calls from prisons to be treated very differently than other 
calls, and this isn't the case for power stations, hospitals, etc.

>  there could be improved for sure:-)

I've reworded the text in question so it should be much clearer now:

    Privacy:  Information sent as a device/service-specific additional
       data URL in the DeviceInfo block is by reference (not by value),
       which inherently provides some additional privacy protection
       (since the requester needs to supply a certificate which is
       verified by the supplier).

>  https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html

I'm working through my email and the comments on this document, so 
I'll respond to that message on its own.  In response to other 
comments, I've clarified that when dereferencing blocks passed by 
reference, the requester supplies a client-side certificate which the 
supplier checks to uphold its policy (e.g., that the requester is an 
emergency services entity possessing a certificate issued by an 
emergency services CA).

>  provider canonicalised the avatar image sizes.

Given the restricted scope (emergency calls only), I'm not sure what 
would be useful to say here.  It's not expected that the same device 
issues a large number of emergency calls.

>  - Thanks for section 9. Good job.

Thank you.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Bankruptcy as a solution is kind of un-American.
    --Tom Horton, Chief Financial Officer American Airlines,
      reported in USA Today, 6 April 2006.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 18 Sep 2015 17:13:31 +0100

Hiya,

On 15/09/15 02:56, Randall Gellens wrote:
> There are two subissues here: the non-use of normative language, and the
> recognition that there are limited non-emergency cases where this can be
> used.  The document originally had normative language here, but there
> was some small discussion in ECRIT meetings and email based on (if I
> recall correctly), an objection from Keith Drage that the document
> couldn't impose these blanket mandates; Keith wanted the document to say
> only that use outside of an emergency call was undefined, but I wanted
> something stronger, so added text that it was not appropriate.  I don't
> mind if we want to go back to being normative, but I wanted to point out
> that it was changed based on Keith's objection.  The permission for
> certain private-use cases is to permit telematics service providers to
> use the same mechanisms on both legs of a call: between the vehicle and
> the telematics service center, and between the telematics service center
> and the PSAP; further, it makes sense to use the same mechanisms between
> the vehicle and telematics service center in all calls, since the
> service center call handler determines if a call is an emergency or not
> (as opposed to the vehicle in the direct case).  This is a very limited

Hmm... in earlier emails with Brian Rosen, I thought we were heading
towards a "MUST NOT except" direction? The changes in -35 don't seem
to me to going there at all. Was there discussion between authors or
the WG on this or do we just have diverging author opinions?

On the current text change in section 3, I don't know what a
"telematics" service provider is (really, it was maybe a meaningful
term here in the early 1990's but is no longer) and the "or other"
clause waters any restriction down to nothing at all since any
relevant entity here is some kind of service provider.

How about saying: "This data MUST NOT be sent for calls that are
not clearly emergency calls. Generic implementations (e.g. of a
SIP UA) MUST only send this data for an emergency call.
Specialised user agents that need to send this data in a possibly
non-emergency call ought be described in specialised RFCs that
justify the need for that data."

I would suggest deleting the text added here between -34 and -35.

I would prefer a 2119 normative statement in this case, as I think
(some of) the customers for UAs here are the sort who do pay
attention to that kind of thing.

> We've had some discussion on this point alone.  I changed all instances
> where the text said:
> 
>    The expert should determine that the entity requesting a new value is
> relevant for this service element
> 
>    The expert should determine that the entity requesting a new value is
> relevant for this service element (e.g., a recognized emergency services
> related SDO)

That's a good change and I've cleared that part of the discuss.
As a non-blocking comment, I'd suggest explaining the issue
at the start of section 11 as well as in the subsections and
I wondered if that phrasing might also apply to other 11.1.x
subsections, but I'm ok that the expert once alerted to this
will probably do the right thing.

The other stuff below is fine.

Cheers,
S.

> This text is informative and explanatory, it helps the reader understand
> what is meant by information about a location, and mentions specific
> types of data that NENA is in fact working on. Both proximity of friends
> and contact lists seem like data associated with a caller, which NENA
> has also worked on and defined a separate, out-of-band mechanism for
> (the data is held by a third party, a registry of third parties is
> available to the PSAP, who queries them).
> 
> require that anniversary date be sent (and in fact doesn't mandate which
> vcard fields are to be sent), although it's conceivable that a wedding
> anniversary might be useful to a PSAP call taker in some circumstances
> (such as when a caller might be suicidal).
> 
> We've discussed this in other email, but the short answer is that this
> matches capabilities provided in legacy emergency services systems, and
> we don't want to lose functionality.  It's quite common for calls from
> prisons to be treated very differently than other calls, and this isn't
> the case for power stations, hospitals, etc.
> 
> I'm working through my email and the comments on this document, so I'll
> respond to that message on its own.  In response to other comments, I've
> clarified that when dereferencing blocks passed by reference, the
> requester supplies a client-side certificate which the supplier checks
> to uphold its policy (e.g., that the requester is an emergency services
> entity possessing a certificate issued by an emergency services CA).
> 
>

---

From: Randall Gellens <[email-masked]>
Date: Fri, 18 Sep 2015 11:04:18 -0700

Hi Stephen,

>  the WG on this or do we just have diverging author opinions?

I think Brian had forgotten that the switch in the text from 
normative to descriptive language was based on Keith's objection, 
which was discussed in an ECRIT session and then referred to in 
others during document status updates.

>  relevant entity here is some kind of service provider.

I think the term "telematics service provider" is pretty clear, much 
more so now than in the '90s, since all major vehicle manufacturers 
now have telematics systems with emergency capabilities, and those 
that don't currently have them will be deploying them within a couple 
of years.  Back in the '90s there were only a few, such as OnStar. 
Brian and I have talked to various vehicle and solution vendors who 
have expressed a desire to use the same mechanism on both legs of a 
call.  Further, in a system such as OnStar, vehicle-initiated 
emergency calls go to the service center and likely will be placed as 
normal, not emergency calls (which in cellular systems generally 
follow a specific set of steps, including an emergency registration 
followed by an emergency session establishment, which has 
difficulties when the call is placed to a third-party and not a PSAP).

The current wording seems more restrictive to me than you seem to 
think.  The current wording says "communications between a ... 
service provider and dedicated equipment ... where the endpoints have 
a preexisting relationship and privacy issues are addressed within 
the relationship" which seems to me to rule out casual use.  There 
needs to be a service provider who has dedicated equipment and there 
needs to be a preexisting relationship that addresses privacy issues. 
General softphone implementations are not going to transmit the data 
except in an emergency call.  Only software on dedicated devices will 
send the data on other classes of calls.

>  justify the need for that data."

I think we already make the point that general-purpose 
implementations won't send the data except in an emergency call 
(although maybe we could call this out to make it even more clear), 
but expecting telematics service providers to publish RFCs seems way 
too high a burden, and for no benefit, since such specialized 
implementations are the only ones that would send the data on other 
call types.

>  attention to that kind of thing.

This was originally 2119 normative language but was changed after 
Keith's objection.

>  will probably do the right thing.

I've added the following new paragraph to Section 11:

    For several of the sub-registries, "Expert Review" is the criteria
    for adding new entries.  As discussed in Section 5, it can be
    counterproductive to register new types of data, and as discussed in
    Section 10, data sent as part of an emergency call can be very
    privacy-sensitive.  In some cases, it is anticipated that various
    standards bodies dealing with emergency services might need to
    register new values, and in those cases text below advises the
    designed expert to verify that the entity requesting the registration
    is relevant (e.g., a recognized emergency services related SDO).  In
    other cases, especially those where the trade-off between the
    potential benefit versus danger of new registrations is more
    conservative (such as Section 11.1.9), "Specification Required" is
    the criteria, which is a higher hurdle and also implicitly includes
    an expert review.

-------------- Randomly selected tag: ---------------
    Life is ... a shopping mall ... where items such as worldly success,
love of music, a strong backhand, close relationships with your family,
a few good friends and countless other things are on sale.
    The commodity with which they are purchased is not money, but time.
                                                   --William Rehnquist

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 18 Sep 2015 22:38:12 +0100

On 18/09/15 19:04, Randall Gellens wrote:
>>> the
> I think Brian had forgotten that the switch in the text from normative
> to descriptive language was based on Keith's objection, which was
> discussed in an ECRIT session and then referred to in others during
> document status updates.

Hmm again;-) I'm not so pushed about the use or lack of normative
language (though I do prefer it in this case) as with what is
said. And there seems to me to be quite a divergence between what
Brian was saying and what you're saying. (Which is entirely fine
and could be meaningful to you folks too, or just something I'm
mixed up about.)

> more so now than in the '90s,

I may be an outlier here, but I do think the opposite. The set of
things at [1] better match my understanding of the term. Or maybe
it's more of a US-centric usage? Or it could just have changed over
time I guess.

    [1]
https://scholar.google.com/scholar?q=telematics&hl=en&as_sdt=0%2C5&as_ylo=&as_yhi=1993

If you do keep that term, maybe add a reference. Or say "vehicle
tracking services" or something that'll still work even if the
terminology wanders again.

> since all major vehicle manufacturers now
> have telematics systems with emergency capabilities, and those that
> don't currently have them will be deploying them within a couple of
> years.  Back in the '90s there were only a few, such as OnStar. Brian
> and I have talked to various vehicle and solution vendors who have
> expressed a desire to use the same mechanism on both legs of a call. 
> Further, in a system such as OnStar, vehicle-initiated emergency calls
> go to the service center and likely will be placed as normal, not
> emergency calls (which in cellular systems generally follow a specific
> set of steps, including an emergency registration followed by an
> emergency session establishment, which has difficulties when the call is
> placed to a third-party and not a PSAP).
> 
> think.  

Right, I think we're seeing different meanings in the text. And
that's probably a signal that a bit more work's needed. But I'm
out of time right now, I'll look at it again over the weekend and
maybe get inspired. Or maybe someone else will be.

Cheers,
S.

> The current wording says "communications between a ... service
> provider and dedicated equipment ... where the endpoints have a
> preexisting relationship and privacy issues are addressed within the
> relationship" which seems to me to rule out casual use.  There needs to
> be a service provider who has dedicated equipment and there needs to be
> a preexisting relationship that addresses privacy issues. General
> softphone implementations are not going to transmit the data except in
> an emergency call.  Only software on dedicated devices will send the
> data on other classes of calls.
> 
> I think we already make the point that general-purpose implementations
> won't send the data except in an emergency call (although maybe we could
> call this out to make it even more clear), but expecting telematics
> service providers to publish RFCs seems way too high a burden, and for
> no benefit, since such specialized implementations are the only ones
> that would send the data on other call types.
> 
>>> understand
>>> which

---

From: Randall Gellens <[email-masked]>
Date: Fri, 18 Sep 2015 15:16:54 -0700

>  and could be meaningful to you folks too, or just something I'm

Sorry, I am not seeing the difference.  The current text says "not 
appropriate...with non-emergency calls" and then adds the "however" 
which is the equivalent of the "except".  And that "however" is quite 
restrictive since it only applies to service providers with dedicated 
devices.

>  terminology wanders again.

The link you gave is searching for the term "telematics," which I 
agree is very broad and covers many things.  The term we use is 
"telematics service provider", which is more specific and has a 
generally-accepted meaning.  See, e.g.,"

https://www.google.com/search?q=%22telematics+service+provider%22&ie=utf-8&oe=utf-8

>  maybe get inspired. Or maybe someone else will be.

Can you elaborate as to what your concern is?  I think the current 
text is clear that general-purpose implements won't send this data 
except in an emergency call.  Some dedicated devices that have a 
pre-existing relationship with a service provider in which privacy 
issues are addressed are permitted to do so.  What's the problem?

Also, you didn't reply to the text I added to satisfy your concern 
with the IANA considerations section.

-------------- Randomly selected tag: ---------------
Manual Writer's Creed:  Garbage in, gospel out.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 22 Sep 2015 14:11:33 -0700

Hi Stephen,

I haven't seen a reply to my message from Friday 3:16 PM PDT 
regarding the scope language, nor my message from Friday 11:04 AM PDT 
which had proposed text for the IANA Considerations section.

All other DISCUSSes and comments have been resolved.  Perhaps we can 
chat on the phone for 20 minutes or so?  Let me know your 
availability today and the next couple of days.

-------------- Randomly selected tag: ---------------
I can't stand Country music, but I don't mean to denigrate people
who do.  And for people who do like to listen to Country music, to
denigrate someone means to belittle them.               --anon

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Sep 2015 22:24:32 +0100

Hiya,

On 22/09/15 22:11, Randall Gellens wrote:
> Hi Stephen,
> 
> I haven't seen a reply to my message from Friday 3:16 PM PDT regarding
> the scope language, nor my message from Friday 11:04 AM PDT which had
> proposed text for the IANA Considerations section.
> 
> chat on the phone for 20 minutes or so?  Let me know your availability
> today and the next couple of days.

Not great, as I'll be at the Marnew workshop. [1] We could do a call
early next week though. How's Monday at 1600 UTC?

Cheers,
S.

[1] https://www.iab.org/activities/workshops/marnew/

---

From: Randall Gellens <[email-masked]>
Date: Tue, 22 Sep 2015 14:43:02 -0700

Hi Stephen,

Would 17:30 UTC on Monday work?

-------------- Randomly selected tag: ---------------
A politician will always be there when he needs you.
      --Richard Smolik