Additional Data Related to an Emergency Call
draft-ietf-ecrit-additional-data-38
Yes
(Alissa Cooper)
No Objection
(Deborah Brungard)
(Joel Jaeggli)
Note: This ballot was opened for revision 33 and is now closed.
Alissa Cooper Former IESG member
Yes
Yes
(for -33)
Unknown
Ben Campbell Former IESG member
Yes
Yes
(2015-09-01 for -34)
Unknown
[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 explicitly. -- 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 provider? -- 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 path? -- 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 abbreviation. -- 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 context. - 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. --10: 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.
Alvaro Retana Former IESG member
No Objection
No Objection
(2015-09-01 for -34)
Unknown
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2015-09-18 for -35)
Unknown
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.
Brian Haberman Former IESG member
No Objection
No Objection
(2015-09-02 for -34)
Unknown
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.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -34)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2015-09-03 for -34)
Unknown
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.
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -34)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-09-02 for -34)
Unknown
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.
Spencer Dawkins Former IESG member
No Objection
No Objection
(2015-09-02 for -34)
Unknown
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 Former IESG member
(was Discuss)
No Objection
No Objection
(2015-10-04 for -36)
Unknown
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.) [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.