Framework for Emergency Calling Using Internet Multimedia
draft-ietf-ecrit-framework-13

[Ballot comment]
All discuss comments were addressed. The remaining comments below are things that the WG (editor?) decided didn't need addressing. Left in here for posterity.

General comment: Some of the language seems more SIP-centric than it needs to be, and most of the document is not SIP-centric. It provides important information to people implementing emergency calling services irrelevant of protocol.

Section 3, Alice example: Why is SIP REGISTER even part of this discussion? Seems to be that SIP register could occur before or after contacting a LIS, and is not really part of emergency calling at all.

The dial string appears only to be retrieved at boot time. Doesn't it have to be periodically refreshed to make sure that the current local dial string is correct based on current location?

Section 3, top of p. 11: "initial LoST query [M3] to learn a URI for use if the LoST query fails during an emergency call". If the LoST query fails during an emergency call, there is no guarantee that the URI that you got at boot time will be valid anyway. Given that, why isn't there a generic hard-coded "pray and hope someone will help" URI that I can use if the LoST query fails? That is, why do I have to do that initial LoST query at all?

6.2.1 makes more sense to me at the end of section 6.2 instead of the beginning.

6.6 paragraph 1 seems much more about *how* one gets location than *when*. What you are saying here is that if you are getting netwok measured location information, you had better be asking the local network and not some VPN. In the case of NATs, again it's not timing, but mechanism that is important: You had better pass your globally visible address corresponding to your local network and not your NAT address when talking to an LCP.

[Ballot comment]
-13 fixed my discuss points, thanks.

Not sure if Sean's discuss was sorted or not, so the comment below
may now be moot...or not;-)

I support Sean's discuss wrt IPR and LC processes. I'm also unclear
how IPR that affects this informational document would not affect the
phonebcp document but who knows with these things.

[Ballot comment]
-13 fixed my discuss points.

I support Sean's discuss wrt IPR and LC processes. I'm also unclear
how IPR that affects this informational document would not affect the
phonebcp document but who knows with these things.

[Ballot comment]
The Gen-ART Review by Francis Dupont on 2010-03-05 included some
  editorial comments.  Please consider them if an update to this
  document is needed for any reason.

[Ballot discuss]
The Gen-ART Review by Francis Dupont on 2010-03-05 raised two minor
  issues.  What, if anything, was done to address this IETF Last Call
  comment: "the Terminology is incomplete, no PSAP for instance"

[Ballot comment]
I agree with Pete's first discuss.  Is this addressed somewhere else in the SIP stack of documents (i.e., if you don't use security an attacker can ...).

[Ballot discuss]
The IETF LC was issued in 2010-02.  The IPR disclosure was filed in 2010-08 and obviously wasn't in the IETF LC.  Has the IPR disclosure been discussed by the WG?

[Ballot discuss]
(1) Section 3 says: "a caller must obtain his location...prior to making
emergency calls." That seems overstated - if I can't find my location
are you saying that the call can't happen? (A "should" would be right
here I think.)

(3) How would any of this work with p2psip? (Just checking again.)

[Ballot comment]
(1) I support Sean's discuss wrt IPR and LC processes. I'm also unclear
how IPR that affects this informational document would not affect the
phonebcp document but who knows with these things.

(2) Intro: "there are currently no international standards" - doesn't 112
qualify as an international standard for an existing emergency call system?
Then: "However, the Internet crosses national boundaries, and thus
international standards for equipment and software are required." Don't you
mean that Internet standards are required?

[Ballot discuss]
(1) Section 3 says: "a caller must obtain his location...prior to making
emergency calls." That seems overstated - if I can't find my location
are you saying that the call can't happen? (A "should" would be right
here I think.)

(2) Is MESSAGE/MSRP the right IM choice to make for emergencies? Would
xmpp be more likely to be useful? (Just checking.)

(3) How would any of this work with p2psip? (Just checking again.)

[Ballot discuss]
I'm not done yet.

The IETF LC was issued in 2010-02.  The IPR disclosure was filed in 2010-08 and obviously wasn't in the IETF LC.  Has the IPR disclosure been discussed by the WG?

[Ballot comment]
General comment: Some of the language seems more SIP-centric than it needs to be, and most of the document is not SIP-centric. It provides important information to people implementing emergency calling services irrelevant of protocol. I've given a couple of specifics below.

"The IETF has historically refused to create national variants..." seems rather judgemental. How about "The IETF has historically not created national variants..."

No mention in made in the intro paragraph of section 3 regarding manual config (where neither measurment nor LCP is used).

Example in section 3: Why does the phone get its location both at boot time and at emergency call time? The latter would seem to suffice. Belt and suspenders? Isn't location something that gets periodically updated by most devices anyway?

Section 3, Alice example: Why is SIP REGISTER even part of this discussion? Seems to be that SIP register could occur before or after contacting a LIS, and is not really part of emergency calling at all.

The dial string appears only to be retrieved at boot time. Doesn't it have to be periodically refreshed to make sure that the current local dial string is correct based on current location?

Section 3, top of p. 11: "initial LoST query [M3] to learn a URI for use if the LoST query fails during an emergency call". If the LoST query fails during an emergency call, there is no guarantee that the URI that you got at boot time will be valid anyway. Given that, why isn't there a generic hard-coded "pray and hope someone will help" URI that I can use if the LoST query fails? That is, why do I have to do that initial LoST query at all?

Section 6.2.1:

  The use of the mechanism introduces the possibility of users falsely
  declaring themselves to be somewhere they are not.  As an aside,
  normally, if an emergency caller insists that he is at a location
  different from what any automatic location determination system
  reports he is, responders will always be sent to the user's self-
  declared location.  However, this is a matter of local policy and is
  outside the scope of this document.

I don't understand the hedge. It seems perfectly reasonable to say:

  The use of the mechanism introduces the possibility of users falsely
  declaring themselves to be somewhere they are not.  However, this is
  generally not a problem in practice. Commonly, if an emergency caller
  insists that he is at a location different from what any automatic
  location determination system reports he is, responders will always
  be sent to the user's self-declared location.

It doesn't sound "outside the scope of this document" at all.

6.2.1 makes more sense to me at the end of section 6.2 instead of the beginning.

6.2.4: Location beacons are end-system measured location mechanisms, not network measured.

6.6 paragraph 1 seems much more about *how* one gets location than *when*. What you are saying here is that if you are getting netwok measured location information, you had better be asking the local network and not some VPN. In the case of NATs, again it's not timing, but mechanism that is important: You had better pass your globally visible address corresponding to your local network and not your NAT address when talking to an LCP.

6.6 paragraph 2: Once per day for a mobile device seems like an extremely low rate. Maybe add a sentence like, "For networks with mobile devices, much higher refresh rates could be expected."

6.7: Why not change section title to simply "Conveying location"? SIP is the example in this section, not the point of it (AFAICT).

6.10: "When validation fails, the location given must not be used for an emergency call." What if I have no other location information? Should I not send something? Or is this supposed to be covered in 6.11 (in which case a forward reference would be useful)?

[Ballot discuss]
9.1: There is no discussion here of the security and privacy implications of continuing a call without TLS, and there is no such information in the Security Considerations section. For example, if TLS cannot be established, should I give a more coarse-grained location? Should I use some mechanism to encrypt the location? Somewhere this needs to be discussed.

(The remainder of this discussion, like that for draft-ietf-ecrit-phonebcp, is for the IESG and need not be addressed by the WG at this time.)

There are several places from 6.5 on which contain *very* normative text. I've noted a few below. I don't think they belong in this document, as the document itself states in section 2.

6.5 paragraph 2, from "For this reason" to the end, is normative language. Not appropriate for this document.

6.9 paragraph 2 and 4: More normative language. The references are sufficient.

6.10: "When validation fails, the location given must not be used for an emergency call." This is normative language that probably doesn't belong here.

Sections 9-15 are in large part redundant with draft-ietf-ecrit-phonebcp, and have lots of normative statements.

It is again not clear to me whether this document (or parts of this document) or draft-ietf-ecrit-phonebcp intends to be framework, or "best current practice", or applicability statement, etc. One way or the other, this document should get rid of its normative text, but what the resultant document set should look like needs to be discussed.

[Ballot discuss]
Last paragraph of section 5: These restrictions on UA design
are out of place for an IETF document.  If the intent is to
just ask UI implementors and regulators to consider these
concerns, the language should be adjusted.

2nd paragraph page 18: "[RFC4119] with a recent extension [RFC5139]"
ages badly. Suggest "[RFC4119] with an extension [RFC5139]" instead.

Section 9.3 needs a little more clarity to reflect 6.3 correctly.
It is not clear enough that this should only happen if the UA has
not provided location information itself, and needs to discuss how the proxy determines whether UA has sufficient support on its own. Some
pointers to other discussion in this document may help, but as written,
this can be read to require a proxy to perform these actions no matter what the UA does.

The sentence "This is a change from [RFC3261] where the Contact: header
is optional." is incorrect. Inclusion of a Contact header field in an
INVITE request is MUST strengh for a UAC in 3261. UASs are allowed to
accept INVITE requests without a Contact header field only for backwards
compatibility with RFC2543 implementations.

Section 15, paragraph 2 is missing a reference to PhoneBCP at the
beginning of the sentence.

---- (Apr 13 2010) Adopting these two points from Cullen's discuss ----

Section 10. Use of PAI. Need to discuss how this works with anonymous call. Places like women's shelters, or many phones in some legal jurisdictions, typically configure all calls to be anonymous in the 3325 sense yet it seems like they still need call back from emergency call to work. I also wonder about how the spec-T would work. If the solutions requires every service provider to have a spec-T with every psap, this does not seem feasible. How does the PAI not get removed when passing it to out of the domain of the service prover and too the psap?

Section 14. 2nd para. At the time this was first written, this was true,
however, at this point of time the IETF does have consensus about keying for SRTP. It seems that given that security is desirable, we should use the agreed on keying solution.

[Ballot comment]
The Gen-ART Review by Francis Dupont on 2010-03-05 included some
  editorial comments.  Please consider them if an update to this
  document is needed for any reason.

[Ballot discuss]
The Gen-ART Review by Francis Dupont on 2010-03-05 raised two minor
  issues.  What, if anything, was done to address this IETF Last Call
  comment: "the Terminology is incomplete, no PSAP for instance"

[Ballot comment]
Section 1:
PSAP is not explained in this section, please write out on first usage

Section 1:
NENA (National Emergency Number Association):

I guess that this is an USA National association, if that is true please make it clear.

Section 6.2.2
  The threshold for when interior location is needed is approximately
  650 square meters.  This value is derived from fire brigade
  recommendations of spacing of alarm pull stations.  However, interior
  space layout, construction materials and other factors should be
  considered.

In this type of reference it would be good to specify which fire brigade
that has this recommendations. I would be highly surprised if the California recommendations are exactly the same as the one in Stockholm.

[Ballot discuss]
Last paragraph of section 5: These restrictions on UA design
are out of place for an IETF document.  If the intent is to
just ask UI implementors and regulators to consider these
concerns, the language should be adjusted.

2nd paragraph page 18: "[RFC4119] with a recent extension [RFC5139]"
ages badly. Suggest "[RFC4119] with an extension [RFC5139]" instead.

Section 9.3 needs a little more clarity to reflect 6.3 correctly.
It is not clear enough that this should only happen if the UA has
not provided location information itself, and needs to discuss how the proxy determines whether UA has sufficient support on its own. Some
pointers to other discussion in this document may help, but as written,
this can be read to require a proxy to perform these actions no matter what the UA does.

The sentence "This is a change from [RFC3261] where the Contact: header
is optional." is incorrect. Inclusion of a Contact header field in an
INVITE request is MUST strengh for a UAC in 3261. UASs are allowed to
accept INVITE requests without a Contact header field only for backwards
compatibility with RFC2543 implementations.

Section 15, paragraph 2 is missing a reference to PhoneBCP at the
beginning of the sentence.

[Ballot comment]
The Gen-ART Review by Francis Dupont on 2010-03-05 included some
  editorial comments.  Please consider them if an update to this
  document is needed for any reason.

[Ballot discuss]
The Gen-ART Review by Francis Dupont on 2010-03-05 raised two minor
  issues.  What, if anything, was done to address these IETF Last Call
  comments:

  (1) the Terminology is incomplete, no PSAP for instance

  (2) the GPS stuff seems a bit USA centric; you should show the
      document to a GPS (or Galileo) expert

[Ballot discuss]
AD needs to check if any new  LC comments came.

Few small comments as part of my AD review. Typically I would have sent these before IETF Last Call but given the timing of the IESG calls and next IETF meeting, I decided we could sort them out as part of IETF Last Call. They are all small and could likely be fixed with RFC Editor notes after we decide what they need to say.

6.2.1 Para 2. The statement that user provided location information is less accurate seems to be contradicted by the later statement that emergency responders will be dispatch to user self-declared location. I know what you are getting at here but seems like some words could be tightened up.

Section 9.1 - para 1. Typo with the xref.

Section 10. The text around the contact header and GRU does not seem right. Are contacts optional in an INVITE? a device with a global reachable IP can still use a GRU. When you say that the B2B contact manipulations should result in a contact header that is usable for call back it sounds like you are saying that current B2BUAs will all do this. Is that true or did it mean to say this can be a problem and they need to do this? The text here just seems to a a bit out of sync with the phone-bcp. Just have a look at this section and see if you think any changes are needed.

Section 10. Use of PAI. Need to discuss how this works with anonymous call. Places like women's shelters, or many phones in some legal jurisdictions,  typically configure all calls to be anonymous in the 3325 sense yet it seems like they still need call back from emergency call to work. I also wonder about how the spec-T would work. If the solutions requires every service provider to have a spec-T with every psap, this does not seem feasible. How does the PAI not get removed when passing it to out of the domain of the service prover and too the psap?

Section 14. 2nd para. At the time this was first written, this was true, however, at this point of time the IETF does have consensus about keying for SRTP. It seems that given that security is desirable, we should use the agreed on keying solution.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Marc Linsner (mlinsner@cisco.com) - Yes, this version is ready for
publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has had multiple WG reviews from key WG members. This
document was vetted via the Emergency Services Workshop at several of it¹s
meetings. Organizations participating include: 3GPP, 3GPP2, ETSI EMTEL,
NENA, IEEE, EENA, etc.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

No further review required.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No specific concerns about this document. No known IPR has been filed nor
discussed.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

While there has been some past controversy around some of the exact wording
in this document, there is overall WG consensus that this document - in its
present form - should be published. The WG as a whole has been working on
the document.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No known threats for an appeal.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

There are no ID-NITs in this document. There is one informative reference
that points to an old SIP document (draft-ietf-sip-location-conveyance-13).
This will be changed to point to the current sipcore document with the next
version.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

This is a framework document, therefore all references are informative.


(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

No IANA considerations for this document are required.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

This document is a BCP, no protocol validation required.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.


³The IETF has standardized various aspects of placing emergency calls. This
document describes how all of those component parts are used to support
emergency calls from citizens and visitors to authorities.²