Additional Data Related to an Emergency Call
RFC 7852

Note: This ballot was opened for revision 33 and is now closed.

(Ben Campbell) Yes

Comment (2015-09-01 for -34)
No email
send info
[Edit: I asked a question below about what happens if you dereference a block, and find the URL points to something other than what you expected. On reflection, I should expand that  to ask how dereferencing errors should be handled in general.] 

This draft was clearly lots of work; thanks for making it happen. However, I have a number of comments:

The shepherd’s writeup indicates that no XML or media type reviews were
required—but this document contains a lot of XML (examples and schema),
 and a number of media type registrations. Is that an error in the writeup, 
or have those reviews been skipped?

This draft implicitly assumes that the emergency calls are signaled with
SIP. I don't dispute that assumption, but I think it should it's worth a
paragraph stating it explicitly.

-- section 2, 2nd paragraph:
Are there any considerations for services provided with no "company" or
"service provider" behind them? For example, lets say an individual hosts
some VoIP related services for her own use (e.g. a SIP registrar, maybe a
stun/turn server,etc) Are those in scope? I'm guessing not, since they would
be unlikely to be registered with NENA, but it would be worth saying that

-- 3: 
Is there a critical need for the bit about "certain private-use
situations"? That seems like license for abuse, without more elaboration
about "prexisting relationship" and "privacy issues addressed".

-- 4, third paragraph from end: 
Can you elaborate on what you mean by "at
the same time"? Does that mean for the same call? Occurring in some interval
of time ?

-- 4.1.4 
Is a provider limited to one type? If the same provider provides
services in multiple categories,  would they create multiple instances?

-- 4.1.5: 
Do you intend 24x7 support to be a prerequisite to be a data

-- 4.1.7, Description: "Although multiple <vcard> elements may be contained
in a structure only one <vcard> element SHOULD be provided.  If more than
one appears, the first SHOULD be used."
When might it be reasonable to violate either of these SHOULDs? If the
receiver should only look at the first entry why are multiple entries
allowed at all?

Also, it seems like there are vcard fields that are not useful to this
purpose and might still have privacy implications. Do we really need people
to send everything?

-- 4.2.1, How Used..., last sentence: 
The term "wireless "needs more
precision if you're going to use it in a 2119 expression. With a Wi-Fi
handset connected to a wired Internet service count as wireless? How about a
cordless phone?

-- Figure 5: 
-Can the list of wireless types change over time? 
-I don't understand the full definition of "temp". Are these terms defined somewhere?
-Do you really want "POTS" vs "PSTN"? 
-Is VoIP intentionally limited to OTT services?

-- 4.3.3: 
What if the device model designation is not a number?

-- 5, list item 1: "The "purpose" parameter also indicates the kind of data
(by its MIME subtype) that is available at the URI" 
What happens if the URL points to something other than the indicated thing?

- list item 2, last sentence: 
I gathered this section was an overview, since
you have detailed procedures later. Please consider moving 2119 language to
that section.

-- Section 5, last paragraph: "only blocks in the registry are permitted to
be sent using the mechanisms specified in this document"
Are implementations supposed to check the registry at run time? (Also, that
language sounds like it should be normative.)

-- 5.1, last paragraph: "More than one Call-Info header field with a purpose
value starting with ’EmergencyCallData’ can be expected, but at least one
MUST be provided.  The device MUST provide one if it knows no service
provider is in the path of the call."
What's the scope of the first MUST? Emergency calls? Is it possible the
device doesn't know whether there is a service provider in the path? Should
this say it MUST insert unless it knows there is a service provider in tHe

-- 8:
It might be worth discussing the potential harm done by a malicious proxy
modifying a data element, or a compromised data source return incorrect
information when dereferencing a URL.

The first paragraph REQUIRES verification of requester credentials, but does
specify the form of those credentials. Subsequent text talks about
client-certs and PKI verification. Are other forms of credentials allows?
(HTTP-digest, application level logins, etc). If client-certs are required,
please say that explicitly.

- "PSAPs and responder agencies SHOULD deploy a PKI " 
When might they not? What if they don't?

- "emergency services authorities could obtain a credential from the DNS
entry of the domain" 
Can you elaborate on that or cite something?

- paragraph starting with "Much of the information supplied by service
providers and devices is private and confidential":
Seems like that should go in the privacy considerations. (And probably also
the intro.)

-- section 10: 
Many of the registry policies require experts to access
whether an organization might be "legitimate" or "relevant". Are these
reasonable expectations on the DEs? (I don't know the answer.)

Nits and Editorial Comments:

-- 4.2.1, Description: Currently, the only valid entries are...
Current as of when?  I suggest "The initially valid entries are..."

-- 4.2.1, How Used... : "... service provider does not know ..." 
Does not know...what?  (That's part of a long, convoluted sentence. Please consider
breaking it into simpler sentences.)

"... it is known to be valuable." 
Known by whom?

-- 4.3.1, Description: "It is possible to receive two Additional Data
Associated with a Call data structures,..." (Occurs in several places.) 
The naming is confusing. It's easy to read "additional data associated with..."
as it's plain English meaning, rather than as a name. I suggest doing
something more distinctive than capital letters. Perhaps quotes, or even an

-- 4.3.7: That seems odd for this to be a subsection of the device
information function.

-- section 5: 
It seems awkard to use a numbered list for elements that are
close to a page long each. This forces each to be a single, overlong
paragraph. Please consider subsections.

-- section 5, list item 2: "circumstances about the provision of the location"
 I'm not sure I understand the meaning of "provision" in this
- Sentence starting with: "When the access network provider" 
This sentence provides context information that would have been useful to have at
the start of the section.

-- 5.4, 2nd paragraph: 
I think people are going to be confused and look for
"by-reference" in 3204 or 3459. It might be worth re-citing 5621.


Some sections reference tables from other sections, and some include the
tables directly. It would be nice to be consistent, one way or the other.

Alissa Cooper Yes

(Jari Arkko) No Objection

Comment (2015-09-03 for -34)
No email
send info
A Gen-ART review arrived from Francis Dupont a while ago. Hopefully the authors can go over the comments and see what needs addressing, before the draft is approved.

Deborah Brungard No Objection

(Spencer Dawkins) No Objection

Comment (2015-09-02 for -34)
No email
send info
I note that Stephen hasn't cleared his Discuss yet, so I'll let that play out (and thanks to all who are busily Discussing it), but just for the record, I'm also confused between 

   The intent
   is that every emergency call carry the information described here
   using the mechanisms described here.

and (paraphrasing)

"we aren't the experts on extending this mechanism, and we can't say who is, but there's more than one set of experts"

This tussle sounds like a fork waiting to happen.

Is that going to be a problem? One answer could be "if it is, we aren't the ones who are going to have to solve it", but I thought I'd ask.

(Stephen Farrell) (was Discuss) No Objection

Comment (2015-10-04 for -36)
No email
send info
Thanks for handling my discuss points.

-35 handled most of the stuff below just fine but I left
the comments there. I didn't check -36 for that.

- 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.)


- 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.

(Brian Haberman) No Objection

Comment (2015-09-02 for -34)
No email
send info
I have no objections to the publication of this document.

- I find text like "Optional for blocks supplied by the originating device, mandatory otherwise" in multiple places in this specification.  Is there a reason for not saying "originating devices MAY supply this information, all other entities MUST supply this information" or some such?

- I look forward to the resolution of Stephen's DISCUSS points.

(Joel Jaeggli) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2015-09-18 for -35)
No email
send info
Thanks so much for addressing all my comments -- version -35 looks really good.

A minor thing that the RFC Editor will correct anyway, but if you happen to do another round of changes: You have "mime" in lower case in three places (in Sections 4.2, 4.3, and 4.5), and they should be upper-cased.

(Kathleen Moriarty) No Objection

Comment (2015-09-02 for -34)
No email
send info
Thanks for your work on this document and the detailed security and privacy considerations balanced against safety risks.  I don't have any questions besides those already asked, but do appreciate the detailed security and privacy recommendations with the understanding of the need to balance risk (to the caller) for this work.

Alvaro Retana No Objection

Comment (2015-09-01 for -34)
No email
send info
Given that the intent of the document “is that every emergency call carry the information described here using the mechanisms described here”, and that additional information is being introduced as ‘Required’, shouldn’t it update RFC6443 and/or at least RFC6881?