Skip to main content

Best Current Practice for Communications Services in Support of Emergency Calling
RFC 6881

Revision differences

Document history

Date Rev. By Action
2015-10-14
20 (System) Notify list changed from ecrit-chairs@ietf.org, draft-ietf-ecrit-phonebcp@ietf.org to (None)
2013-04-05
(System) Posted related IPR disclosure: Qualcomm Incorporated's Statement about IPR related to RFC 6881
2013-03-08
20 (System) IANA registries were updated to include RFC6881
2013-03-07
20 (System) RFC published
2013-03-06
20 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2013-02-20
20 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc6881">AUTH48</a> from RFC-EDITOR
2012-08-22
20 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
20 (System) post-migration administrative database adjustment to the No Objection position for Pete Resnick
2012-08-22
20 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
20 (System) post-migration administrative database adjustment to the Yes position for Dan Romascanu
2012-08-22
20 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2012-08-22
20 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2011-09-23
20 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-09-23
20 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2011-09-16
20 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-09-13
20 (System) IANA Action state changed to In Progress
2011-09-13
20 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2011-09-12
20 Amy Vezza IESG state changed to Approved-announcement sent
2011-09-12
20 Amy Vezza IESG has approved the document
2011-09-12
20 Amy Vezza Closed "Approve" ballot
2011-09-12
20 Amy Vezza Approval announcement text regenerated
2011-09-12
20 Robert Sparks Ballot writeup text changed
2011-09-09
20 Pete Resnick
[Ballot comment]
ED-26/INT-20: There's a typo in here:

  ED-26/INT-20 If the device is configured to use DHCP for
  bootstrapping, and does not use …
[Ballot comment]
ED-26/INT-20: There's a typo in here:

  ED-26/INT-20 If the device is configured to use DHCP for
  bootstrapping, and does not use it MUST include both options for
  location acquisition (civic and geodetic), the option for LIS
  discovery, and the option for LoST discovery as defined in [RFC4776],
  [RFC6225], [RFC5986] and [RFC5223].

That doesn't parse. I assume you mean something like "and does not use manual configuration or its own measurement to determine location,". I think it would be peachy if that's what you intended.

ED-47: I'm not clear why S/MIME is NOT RECOMMENDED here.

--

I am still concerned that this document is being put forward as a BCP *and* is using 2119 language when it is really serving as a conformance statement for other SDOs. On the one hand, it could be seen as an applicability statement for implementers of the protocols, expressing what they need to account for in the use of those protocols. But if it's an AS, then it should be standards track, as reviewing the interoperation of actual implementations is a reasonable thing, and BCP is not inappropriate. However, there is no expectation that there is going to be review of the AS from an interoperability point of view because it really become a set of conformance requirements imposed by external bodies. So if interoperability is not going to be checked, the 2119 language is inappropriate in the first place.

But even if the WG wanted to make this a standards track AS, the 2119 language in here is *way* outside of the scope of 2119. To pick an example right off the top:

4.  Which devices and services should support emergency calls

  ED-1 A device or application SHOULD support emergency calling if a
  user could reasonably expect to be able to place a call for help with
  the device.  Some jurisdictions have regulations governing this.

I don't see how the interoperability of that SHOULD could possibly be tested from an interoperability perspective, which is what 2119 requires for the use of the keyword. In other places, 2119 language is used reasonably (e.g., "It is RECOMMENDED that location determination not take longer than 250 ms to obtain routing location..."), but it's a big mixture.

I think this document should either be informational (without 2119 language at all) or a standards track AS (with sane 2119 language). But this is important work and the working group made a conscious decision (with AD approval) to go forward this way. I'm therefore not willing to hold up this document based on this process issue. But the IESG really needs to discuss and fix this problem for the future.
2011-09-09
20 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss
2011-09-08
20 Russ Housley
[Ballot discuss]
The Gen-ART Review by Miguel Garcia on 20-Feb-2011 lead to a
  discussion, but that discussion has not reached closure yet.
  That …
[Ballot discuss]
The Gen-ART Review by Miguel Garcia on 20-Feb-2011 lead to a
  discussion, but that discussion has not reached closure yet.
  That discussion needs to reach a conclusion to determine what
  changes, if any, are needed to the document.
2011-09-08
20 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss
2011-09-07
20 Stephen Farrell [Ballot comment]
-20 cleared all my discuss points, thanks all
2011-09-07
20 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2011-09-06
20 (System) New version available: draft-ietf-ecrit-phonebcp-20.txt
2011-09-06
20 Jari Arkko
[Ballot comment]
I think -19 is better, and I have no blocking concern on it any more. I still wish the document would make it …
[Ballot comment]
I think -19 is better, and I have no blocking concern on it any more. I still wish the document would make it clearer that support for these functions is a significant issue for some access networks, and that access networks should be in charge of deciding (along with legal requirements) whether to employ them.
2011-09-06
20 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss
2011-09-06
20 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-09-03
20 Stephen Farrell
[Ballot comment]
Updated comment (2011-08-20): Please fix this so that ID-NITs is happy.

--- original comments below

(1) Abstract could make it clear if this …
[Ballot comment]
Updated comment (2011-08-20): Please fix this so that ID-NITs is happy.

--- original comments below

(1) Abstract could make it clear if this doc just addresses
BCP for IETF docs or also for others as well, and if others
are included which SDOs?

(2) Is ietf-ecrit-framework required reading or not? Make it
clear.

(3) 6.1 mentions not changing the determination mechanism but
that's only introduced in 6.2. Add a forward reference.

(4) LCP is used without expansion

(5) s/IPSEC/IPsec/
2011-09-03
20 Stephen Farrell
[Ballot discuss]
-18 and/or email discussion cleared up all my discuss points
bar the one below. -19 made no change here so the discuss
remains …
[Ballot discuss]
-18 and/or email discussion cleared up all my discuss points
bar the one below. -19 made no change here so the discuss
remains

(2) ED-1 has a SHOULD requirement for when its ok to not
support emergency calls. Saying its driven by user
expectation seems vague and not that easy for a developer
to handle. I can see how this could be hard, but I do wonder
if there's not a more objective criterion that could be stated.

On June 20th I suggested alternative text for ED-1 but I
don't think I saw a response to that.

"  ED-1 A device or application that implements SIP calling SHOULD
  support emergency calling. Some jurisdictions have regulations
  governing which devices need to support emergency calling and
  developers are encouraged to ensure that devices they develop
  meet relevant regulatory requirements. Unfortunately, the
  natural variation in those regulations also makes it impossible
  to accurately describe the cases when developers do not have
  to support emergency calling."
2011-09-03
20 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-09-03
19 (System) New version available: draft-ietf-ecrit-phonebcp-19.txt
2011-08-23
20 Robert Sparks State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup.
2011-08-20
20 Stephen Farrell
[Ballot comment]
Updated comment (2011-08-20): Please fix this so that ID-NITs is happy.

--- original comments below

(1) Abstract could make it clear if this …
[Ballot comment]
Updated comment (2011-08-20): Please fix this so that ID-NITs is happy.

--- original comments below

(1) Abstract could make it clear if this doc just addresses
BCP for IETF docs or also for others as well, and if others
are included which SDOs?

(2) Is ietf-ecrit-framework required reading or not? Make it
clear.

(3) 6.1 mentions not changing the determination mechanism but
that's only introduced in 6.2. Add a forward reference.

(4) LCP is used without expansion

(5) s/IPSEC/IPsec/
2011-08-20
20 Stephen Farrell
[Ballot discuss]
-18 and/or email discussion cleared up all my discuss points
bar the one below.

(2) ED-1 has a SHOULD requirement for when its …
[Ballot discuss]
-18 and/or email discussion cleared up all my discuss points
bar the one below.

(2) ED-1 has a SHOULD requirement for when its ok to not
support emergency calls. Saying its driven by user
expectation seems vague and not that easy for a developer
to handle. I can see how this could be hard, but I do wonder
if there's not a more objective criterion that could be stated.

On June 20th I suggested alternative text for ED-1 but I
don't think I saw a response to that.

"  ED-1 A device or application that implements SIP calling SHOULD
  support emergency calling. Some jurisdictions have regulations
  governing which devices need to support emergency calling and
  developers are encouraged to ensure that devices they develop
  meet relevant regulatory requirements. Unfortunately, the
  natural variation in those regulations also makes it impossible
  to accurately describe the cases when developers do not have
  to support emergency calling."
2011-08-19
20 Stephen Farrell
[Ballot discuss]
-18 and/or email discussion cleared up all my discuss points
bar the one below.

(2) ED-1 has a SHOULD requirement for when its …
[Ballot discuss]
-18 and/or email discussion cleared up all my discuss points
bar the one below.

(2) ED-1 has a SHOULD requirement for when its ok to not
support emergency calls. Saying its driven by user
expectation seems vague and not that easy for a developer
to handle. I can see how this could be hard, but I do wonder
if there's not a more objective criterion that could be stated.

On June 20th I suggested alternative text for ED-1 but I
don't think I saw a response to that.

"  ED-1 A device or application that implements SIP calling SHOULD
  support emergency calling. Some jurisdictions have regulations
  governing which devices need to support emergency calling and
  developers are encouraged to ensure that devices they develop
  meet relevant regulatory requirements. Unfortunately, the
  natural variation in those regulations also makes it impossible
  to accurately describe the cases when developers do not have
  to support emergency calling."
2011-07-28
20 Dan Romascanu
[Ballot comment]
In version 18, in the process of changing the IANA review policy one of the resulting sentences resulted broken: ' The expert review …
[Ballot comment]
In version 18, in the process of changing the IANA review policy one of the resulting sentences resulted broken: ' The expert review should consider The Reference is this document. '
2011-07-28
20 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to Yes from Discuss
2011-07-28
18 (System) New version available: draft-ietf-ecrit-phonebcp-18.txt
2011-04-30
20 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Shawn Emery.
2011-04-28
20 Pete Resnick
[Ballot comment]
Editorial: Weird use of the term "element". It's non-obvious to me. I might have used "entity". Maybe it's understood in this environment.

ED-3 …
[Ballot comment]
Editorial: Weird use of the term "element". It's non-obvious to me. I might have used "entity". Maybe it's understood in this environment.

ED-3 looks like it should be ED/SP statement. I assume that anyone who reads the second sentence understands why location of the device has anything to do with recognizing dial strings; I sorta can figure it out, but not my area. I don't understand what "could" implies in the second sentence.

Editorial: The term "UA" magically appears in 6.9 and is used elsewhere as well. Is that an "endpoint"?

ED-47: S/MIME is mentioned here without reference. And I'm not clear why S/MIME is NOT RECOMMENDED here.

Editorial (I think): ED-78 gives an example of "urn:servicetest.sos.fire". Is there a missing ":" in there?

AN-5 and AN-10 seem to conflict. Can you not do network measured location *instead of* hard-wired location configuration and still not require end system measured location?

I'm not clear on AN-13/INT-14. If a proxy is providing the location, and the network is providing, e.g., hard-wired location configuration, why would DHCP or HELD ever be involved? And does this have anything to do with ED-24?
2011-04-28
20 Pete Resnick
[Ballot discuss]
ED-25-27/INT-19-21. If the endpoint measures or has manual configuration for its location, it still "SHOULD obtain...after local network config" and "MUST include [DHCP] …
[Ballot discuss]
ED-25-27/INT-19-21. If the endpoint measures or has manual configuration for its location, it still "SHOULD obtain...after local network config" and "MUST include [DHCP] options for location acquisition"? That doesn't seem correct.

ED-59/SP-31 and ED-62/AN-29: There's clearly a security consideration here, but the Security Considerations section is empty except for pointers to two documents which do not address the security consideration of the downgrade.

Section 12 reads like a big security hole without any attempt at solution. Once a call is established, shouldn't some sort of security token be exchanged so that callback can occur securely if necessary?

---
The rest of this is for the IESG and need not be addressed by the WG. I will move it to a non-blocking comment if all of the rest of the above comments are cleared.
---

I am very concerned that this document is being put forward as a BCP *and* is using 2119 language when it is really serving as a conformance statement for other SDOs. On the one hand, it could be seen as an applicability statement for implementers of the protocols, expressing what they need to account for in the use of those protocols. But if it's an AS, then it should be standards track, as reviewing the interoperation of actual implementations is a reasonable thing, and BCP is not inappropriate. However, there is no expectation that there is going to be review of the AS from an interoperability point of view because it really become a set of conformance requirements imposed by external bodies. So if interoperability is not going to be checked, the 2119 language is inappropriate in the first place.

But even if the WG wanted to make this a standards track AS, the 2119 language in here is *way* outside of the scope of 2119. To pick an example right off the top:

4.  Which devices and services should support emergency calls

  ED-1 A device or application SHOULD support emergency calling if a
  user could reasonably expect to be able to place a call for help with
  the device.  Some jurisdictions have regulations governing this.

I don't see how the interoperability of that SHOULD could possibly be tested from an interoperability perspective, which is what 2119 requires for the use of the keyword. In other places, 2119 language is used reasonably (e.g., "It is RECOMMENDED that location determination not take longer than 250 ms to obtain routing location..."), but it's a big mixture.

I think this document should either be informational (without 2119 language at all) or a standards track AS (with sane 2119 language). But this is important work and the working group made a conscious decision (with AD approval) to go forward this way. I'm therefore not willing to hold up this document based on this process issue. But the IESG really needs to discuss and fix this problem for the future.
2011-04-28
20 Cindy Morgan Removed from agenda for telechat
2011-04-28
20 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation.
2011-04-28
20 Sean Turner
[Ballot discuss]
This is an updated discuss. 

Section 6.1: For the 1st paragraph which entity is the requirement on?  All the other requirements statements are …
[Ballot discuss]
This is an updated discuss. 

Section 6.1: For the 1st paragraph which entity is the requirement on?  All the other requirements statements are targeted at an entity or entities.
2011-04-28
20 Jari Arkko
[Ballot discuss]
I hate to pile on the comments that were already made by others, but I think the document places unreasonable mandatory requirements on …
[Ballot discuss]
I hate to pile on the comments that were already made by others, but I think the document places unreasonable mandatory requirements on access networks, often without much actual current practice in the world for doing so. Some examples:

  AN-12 Access networks with range of <10 meters (e.g. personal area
  networks such as Bluetooth MUST provide a location to mobile devices
  connected to them.  The location provided SHOULD be that reported by
  the upstream access network unless a more accurate mechanism is
  available.

A *MUST* requirement for every access network? Most networks today do not do this, and there are networks where it would be difficult to do so. For instance, a sensor-only network that runs off stateless address autoconfiguration and has no DHCP. A SHOULD would be a very reasonable requirement, however.

  AN-14/INT-15 Where a router is employed between a LAN and WAN in a
  small (less than approximately 650 square meters) area, the router
  MUST be transparent to the location provided by the WAN to the LAN.
  This may mean the router must obtain location as a client from the
  WAN, and supply an LCP server to the LAN with the location it
  obtains.  Where the area is larger, the LAN MUST have a location
  configuration mechanism satisfying the requirements of this document.

I think this is another reasonable requirement, but not at a MUST level. A SHOULD be OK here, I think.

  AN-16 Network administrators MUST take care in assigning IP addresses
  such that VPN address assignments can be distinguished from local
  devices (by subnet choice, for example), and LISs SHOULD NOT attempt
  to provide location to addresses that arrive via VPN connections
  unless it can accurately determine the location for such addresses.

This is a tough requirement. Especially at a MUST level. There are very good reasons why one might wish to place devices in the same subnet (link local discovery, for instance).

  ED-46/AN-26 To prevent against spoofing of the DHCP server, elements
  implementing DHCP for location configuration SHOULD use [RFC3118]
  although the difficulty in providing appropriate credentials is
  significant.

This one is a SHOULD, and notes the difficulties. Nevertheless, having this requirement in a BCP is laughable, because as far as we can tell *no one* on the entire planet has turned RFC 3118 on. I would suggest deleting this requirement entirely, or perhaps constructing some other requirement about recommending L2 security be turned on.
2011-04-28
20 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded
2011-04-27
20 Ron Bonica [Ballot comment]
Support most of the discuss positions posted
2011-04-27
20 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-04-27
20 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-04-27
20 Sean Turner
[Ballot discuss]
This is an updated discuss. 

Section 6.1: For the 1st paragraph which entity is the requirement on?  All the other requirements statements are …
[Ballot discuss]
This is an updated discuss. 

Section 6.1: For the 1st paragraph which entity is the requirement on?  All the other requirements statements are targeted at an entity or entities.

ED-74 made me wonder whether there should be a statement that if the endpoints support video it should remain on?

(no action required): draft-ietf-mmusic-media-loopback is listed as a normative reference, but that draft does not indicate what track it is intended for.  According to the mmusic charter page: 2009 - Submit SDP extensions for Media Loopback for Proposed Standard.  It seems that the mmusic draft should be updated but that shouldn't hold up this draft.
2011-04-27
20 Dan Romascanu [Ballot comment]
I support Pete's part of the DISCUSS that states that section 12 points to a security hole that needs to be addressed
2011-04-27
20 Dan Romascanu
[Ballot discuss]
Part of the issues in the DISCUSS were raised in Bernard Aboba's OPS-DIR review. I recommend all his review to be addressed. I …
[Ballot discuss]
Part of the issues in the DISCUSS were raised in Bernard Aboba's OPS-DIR review. I recommend all his review to be addressed. I included in my DISCUSS those issues that seemed to me critical.

1. A number of the recommendations made would appear to assume an all-IP NG911
"NENA i3" architecture, as opposed to the "NENA i2" transitional architecture.  In those
cases, the recommendations would represent "Best Future Practice" rather than
"Best Current Practice".

In a number of cases normative language appears to be used in ways different from
those described in RFC 2119.  In some cases, the term "SHOULD" is used in
situations where statutes or regulations may mandate behavior. 

I agree here with Bernard that the BCP status is probably adequate, but in some places the requirements need clarification.

Bernard also writes:

Overall, I was left with the question as to whether the
recommendations in this document applied beyond "all-IP"
deployments based on the framework document, to transitional
"NENA i2" environments as well.  I suspect that the "INT"
requirements would also apply to gateways between IP and
legacy PSAPs, but this isn't stated explicitly. 

I also find odd the fact that the document does not refer at least informationaly to the NENA i2 and i3 architectures. The behavior of the system and requirements may be different in i2 and i3 environments. There are places where behavior should be configurable or negotiated to allow for better behavior in a transitional environment. There are also places where behavior will be prescribed by local statues or regulations, so that configuration and/or negotiation is a practical requirement.

2. I had a hard time translating some of the AN (Access Networks related) requirements. For example:

  AN-5 Access networks supporting copper, fiber or other hard wired IP
  packet service SHOULD support location configuration.  If the network
  does not support location configuration, it MUST require every device
  that connects to the network to support end system measured location.

If I am an operator of an AN that does not support location configuration how should I read the requirement? Is this an administrative requirement, or should the network be designed so that devices that do not support end system measured location (and have it activated?) cannot connect to the network?

3. ED-3 is confusing. I think that it tries to state that string recognition MUST be supported and that the endpoints SHOULD provide this function, but if this is not the case the SP MAY do it. If I am correct than this needs to be an ED/SP requirement, and I would like the cases of exception to be clarified. If I mis-understood please help me understand, maybe with some text changes.

4. Section 17.2:

> The
  registration process is Expert review by ECRIT working group, its
  successor, or, in their absence, the IESG. 

I suggest to define this policy as Expert Review as per RFC 5226 and have a Designated Expert nominated. The designated expert can than use help from ECRIT, IESG, or other in the future.
2011-04-27
20 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded
2011-04-27
20 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-04-26
20 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-04-26
20 Sean Turner [Ballot comment]
I support Stephen's discusses 3-5.
2011-04-26
20 Sean Turner
[Ballot discuss]
Section 6.1: For the 1st paragraph which entity is the requirement on?  All the other requirements statements are targeted at an entity or …
[Ballot discuss]
Section 6.1: For the 1st paragraph which entity is the requirement on?  All the other requirements statements are targeted at an entity or entities.

ED-74 made me wonder whether there should be a statement that if the endpoints support video it should remain on?

Process related: draft-ietf-mmusic-media-loopback is listed as a normative reference, but that draft does not indicate what track it is intended for.  I assume it's standards track because a downref to the draft was not called out during IETF LC, but I wanted to verify.
2011-04-26
20 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2011-04-26
20 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-04-26
20 Stephen Farrell
[Ballot comment]
(1) Abstract could make it clear if this doc just addresses
BCP for IETF docs or also for others as well, and if …
[Ballot comment]
(1) Abstract could make it clear if this doc just addresses
BCP for IETF docs or also for others as well, and if others
are included which SDOs?

(2) Is ietf-ecrit-framework required reading or not? Make it
clear.

(3) 6.1 mentions not changing the determination mechanism but
that's only introduced in 6.2. Add a forward reference.

(4) LCP is used without expansion

(5) s/IPSEC/IPsec/
2011-04-26
20 Stephen Farrell
[Ballot discuss]
(1) Is this stating requirements (if so for whom) or documenting
BCP based on *current* implementations and deployments?
That's not clear to me …
[Ballot discuss]
(1) Is this stating requirements (if so for whom) or documenting
BCP based on *current* implementations and deployments?
That's not clear to me and I think it ought be clear for a BCP.

(2) ED-1 has a SHOULD requirement for when its ok to not
support emergency calls. Saying its driven by user
expectation seems vague and not that easy for a developer
to handle. I can see how this could be hard, but I do wonder
if there's not a more objective criterion that could be stated.

(3) ED-48 has  MUST for IPsec or TLS. ED-62 says that if the
TLS handshake fails then location retrieval MUST be retried.
What if IPsec SA establishment fails? (Would the UA know?)

(4) I think the overall use of TLS and IPsec maybe needs to
be restated perhaps along the lines of "Do try to use TLS,
but if the handshake fails, then for emergency calls only, its
ok to do everything in clear."

(5) I'm not sure that you even want to mention IPsec here,
other than to say that an emergency call might require a
UA to break some IPsec policy rule. (E.g. if the IPsec policy is
that all traffic be routed to a VPN g/w.) I may have missed
where that is stated - is that there somewhere or what's the
BCP for that case?
2011-04-26
20 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-04-24
20 Pete Resnick
[Ballot discuss]
Some of these might turn out to be comments rather than discussions:

AN-5 and AN-10 seem to conflict. Can you not do network …
[Ballot discuss]
Some of these might turn out to be comments rather than discussions:

AN-5 and AN-10 seem to conflict. Can you not do network measured location *instead of* hard-wired location configuration and still not require end system measured location?

I'm not clear on AN-13/INT-14. If a proxy is providing the location, and the network is providing, e.g., hard-wired location configuration, why would DHCP or HELD ever be involved? And does this have anything to do with ED-24?

ED-25-27/INT-19-21. If the endpoint measures or has manual configuration for its location, it still "SHOULD obtain...after local network config" and "MUST include [DHCP] options for location acquisition"? That doesn't seem correct.

ED-59/SP-31 and ED-62/AN-29: There's clearly a security consideration here, but the Security Considerations section is empty except for pointers to two documents which do not address the security consideration of the downgrade.

Section 12 reads like a big security hole without any attempt at solution. Once a call is established, shouldn't some sort of security token be exchanged so that callback can occur securely if necessary?

---
The rest of this is for the IESG and need not be addressed by the WG. I will move it to a non-blocking comment if all of the rest of the above comments are cleared.
---

I am very concerned that this document is being put forward as a BCP *and* is using 2119 language when it is really serving as a conformance statement for other SDOs. On the one hand, it could be seen as an applicability statement for implementers of the protocols, expressing what they need to account for in the use of those protocols. But if it's an AS, then it should be standards track, as reviewing the interoperation of actual implementations is a reasonable thing, and BCP is not inappropriate. However, there is no expectation that there is going to be review of the AS from an interoperability point of view because it really become a set of conformance requirements imposed by external bodies. So if interoperability is not going to be checked, the 2119 language is inappropriate in the first place.

But even if the WG wanted to make this a standards track AS, the 2119 language in here is *way* outside of the scope of 2119. To pick an example right off the top:

4.  Which devices and services should support emergency calls

  ED-1 A device or application SHOULD support emergency calling if a
  user could reasonably expect to be able to place a call for help with
  the device.  Some jurisdictions have regulations governing this.

I don't see how the interoperability of that SHOULD could possibly be tested from an interoperability perspective, which is what 2119 requires for the use of the keyword. In other places, 2119 language is used reasonably (e.g., "It is RECOMMENDED that location determination not take longer than 250 ms to obtain routing location..."), but it's a big mixture.

I think this document should either be informational (without 2119 language at all) or a standards track AS (with sane 2119 language). But this is important work and the working group made a conscious decision (with AD approval) to go forward this way. I'm therefore not willing to hold up this document based on this process issue. But the IESG really needs to discuss and fix this problem for the future.
2011-04-21
20 Russ Housley
[Ballot discuss]
The Gen-ART Review by Miguel Garcia on 20-Feb-2011 lead to a
  discussion, but that discussion has not reached closure yet.
  That …
[Ballot discuss]
The Gen-ART Review by Miguel Garcia on 20-Feb-2011 lead to a
  discussion, but that discussion has not reached closure yet.
  That discussion needs to reach a conclusion to determine what
  changes, if any, are needed to the document.
2011-04-21
20 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded
2011-04-21
20 Amanda Baber
We understand that draft-ietf-ecrit-phonebcp-17.txt is now requesting
the following IANA actions:

ACTION 1:

Upon approval, IANA will add register the following in the URN Service …
We understand that draft-ietf-ecrit-phonebcp-17.txt is now requesting
the following IANA actions:

ACTION 1:

Upon approval, IANA will add register the following in the URN Service
Labels registry at
http://www.iana.org/assignments/urn-serviceid-labels

Service Description Reference
------- ----------- ---------
test self-test [RFC-to-be]


ACTION 2:

Upon approval, IANA will create the following registry at
http://www.iana.org/assignments/urn-serviceid-labels

Registry: 'test' Sub-Service
Registration Procedures: Expert Review

Service Description
---------------------- -----------------
test.sos test for sos
test.sos.ambulance test for sos.ambulance
test.sos.animal-control test for sos.animal-control
test.sos.fire test for sos.fire
test.sos.gas test for sos.gas
test.sos.marine test for sos.marine
test.sos.mountain test for sos.mountain
test.sos.physician test for sos.physician
test.sos.poison test for sos.poison
test.sos.police test for sos.police
2011-04-21
20 Pete Resnick
[Ballot comment]
Editorial: Weird use of the term "element". It's non-obvious to me. I might have used "entity". Maybe it's understood in this environment.

ED-3 …
[Ballot comment]
Editorial: Weird use of the term "element". It's non-obvious to me. I might have used "entity". Maybe it's understood in this environment.

ED-3 looks like it should be ED/SP statement. I assume that anyone who reads the second sentence understands why location of the device has anything to do with recognizing dial strings; I sorta can figure it out, but not my area. I don't understand what "could" implies in the second sentence.

Editorial: The term "UA" magically appears in 6.9 and is used elsewhere as well. Is that an "endpoint"?

ED-47: S/MIME is mentioned here without reference. And I'm not clear why S/MIME is NOT RECOMMENDED here.

Editorial (I think): ED-78 gives an example of "urn:servicetest.sos.fire". Is there a missing ":" in there?
2011-04-21
20 Pete Resnick
[Ballot discuss]
Some of these might turn out to be comments rather than discussions:

AN-5 and AN-10 seem to conflict. Can you not do network …
[Ballot discuss]
Some of these might turn out to be comments rather than discussions:

AN-5 and AN-10 seem to conflict. Can you not do network measured location *instead of* hard-wired location configuration and still not require end system measured location?

I'm not clear on AN-13/INT-14. If a proxy is providing the location, and the network is providing, e.g., hard-wired location configuration, why would DHCP or HELD ever be involved? And does this having anything to do with ED-24?

ED-25-27/INT-19-21. If the endpoint measures or has manual configuration for its location, it still "SHOULD obtain...after local network config" and "MUST include [DHCP] options for location acquisition"? That doesn't seem correct.

ED-59/SP-31 and ED-62/AN-29: There's clearly a security consideration here, but the Security Considerations section is empty except for pointers to two documents which do not address the security consideration of the downgrade.

Section 12 reads like a big security hole without any attempt at solution. Once a call is established, shouldn't some sort of security token be exchanged so that callback can occur securely if necessary?

---
The rest of this is for the IESG and need not be addressed by the WG. I will move it to a non-blocking comment if all of the rest of the above comments are cleared.
---

I am very concerned that this document is being put forward as a BCP *and* is using 2119 language when it is really serving as a conformance statement for other SDOs. On the one hand, it could be seen as an applicability statement for implementers of the protocols, expressing what they need to account for in the use of those protocols. But if it's an AS, then it should be standards track, as reviewing the interoperation of actual implementations is a reasonable thing, and BCP is not inappropriate. However, there is no expectation that there is going to be review of the AS from an interoperability point of view because it really become a set of conformance requirements imposed by external bodies. So if interoperability is not going to be checked, the 2119 language is inappropriate in the first place.

But even if the WG wanted to make this a standards track AS, the 2119 language in here is *way* outside of the scope of 2119. To pick an example right off the top:

4.  Which devices and services should support emergency calls

  ED-1 A device or application SHOULD support emergency calling if a
  user could reasonably expect to be able to place a call for help with
  the device.  Some jurisdictions have regulations governing this.

I don't see how the interoperability of that SHOULD could possibly be tested from an interoperability perspective, which is what 2119 requires for the use of the keyword. In other places, 2119 language is used reasonably (e.g., "It is RECOMMENDED that location determination not take longer than 250 ms to obtain routing location..."), but it's a big mixture.

I think this document should either be informational (without 2119 language at all) or a standards track AS (with sane 2119 language). But this is important work and the working group made a conscious decision (with AD approval) to go forward this way. I'm therefore not willing to hold up this document based on this process issue. But the IESG really needs to discuss and fix this problem for the future.
2011-04-21
20 Pete Resnick [Ballot Position Update] New position, Discuss, has been recorded
2011-04-21
20 Robert Sparks State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-04-21
20 Robert Sparks Placed on agenda for telechat - 2011-04-28
2011-04-21
20 Robert Sparks [Ballot Position Update] New position, Yes, has been recorded for Robert Sparks
2011-04-21
20 Robert Sparks Ballot has been issued
2011-04-21
20 Robert Sparks Created "Approve" ballot
2011-04-07
20 Robert Sparks Ballot writeup text changed
2011-03-28
17 (System) New version available: draft-ietf-ecrit-phonebcp-17.txt
2011-02-21
20 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-02-18
20 Amanda Baber We understand that this document doesn't require any IANA actions.
2011-02-16
20 Samuel Weiler Request for Last Call review by SECDIR is assigned to Shawn Emery
2011-02-16
20 Samuel Weiler Request for Last Call review by SECDIR is assigned to Shawn Emery
2011-02-07
20 Cindy Morgan Last call sent
2011-02-07
20 Cindy Morgan
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <ecrit@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-ecrit-phonebcp-16.txt> (Best Current Practice for Communications Services in support of Emergency Calling) to BCP


The IESG has received a request from the Emergency Context Resolution
with Internet Technologies WG (ecrit) to consider the following document:
- 'Best Current Practice for Communications Services in support of
  Emergency Calling'
  <draft-ietf-ecrit-phonebcp-16.txt> as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ecrit-phonebcp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ecrit-phonebcp/

2011-02-07
20 Robert Sparks Last Call was requested
2011-02-07
20 Robert Sparks State changed to Last Call Requested from AD Evaluation::AD Followup.
2011-02-07
20 Robert Sparks Last Call text changed
2011-02-07
20 (System) Ballot writeup text was added
2011-02-07
20 (System) Last call text was added
2011-02-07
20 (System) Ballot approval text was added
2011-02-07
20 Robert Sparks Ballot writeup text changed
2010-10-25
20 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-10-25
16 (System) New version available: draft-ietf-ecrit-phonebcp-16.txt
2010-09-17
20 Robert Sparks State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Robert Sparks
2010-07-12
20 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-07-12
15 (System) New version available: draft-ietf-ecrit-phonebcp-15.txt
2010-07-01
20 Robert Sparks State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Robert Sparks
2010-07-01
20 Robert Sparks [Note]: 'Marc Linsner (mlinsner@cisco.com) is the document shepherd.' added by Robert Sparks
2010-03-24
20 Cullen Jennings Responsible AD has been changed to Robert Sparks from Cullen Jennings
2010-01-19
14 (System) New version available: draft-ietf-ecrit-phonebcp-14.txt
2009-11-10
20 Cullen Jennings State Changes to AD Evaluation from Publication Requested by Cullen Jennings
2009-08-07
20 Cindy Morgan
UPDATED PROTO WRITE-UP (specifically, 1.e):

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document …
UPDATED PROTO WRITE-UP (specifically, 1.e):

(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 of it¹s several
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.
The last remaining issue was a discussion titled ŒApplicability Statement¹.
Text was submitted and rejected by the WG. See:
http://www.ietf.org/mail-archive/web/ecrit/current/msg06434.html

There was a liaison statement received from 3GPP on July 21, 2009 stating
they may in the future have comments about this draft. The liaison can be
reviewed at: https://datatracker.ietf.org/liaison/551/

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


One reference is wrongly identified with id-nits as informational, it¹s
actually Standards Track, hence we ignored this idnits warning. All other
idnits have been resolved. There is one 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].

References are split into Informative and Normative.


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


³This document describes how access networks, SIP user agents, proxy
servers and PSAPs support emergency calling, as outlined in
[I-D.ietf-ecrit-framework], which is designed to complement the present
document in section headings, numbering and content. This BCP succinctly
describes the requirements of end devices and applications, access networks
(including enterprise access networks), service providers and PSAPs to
achieve globally interoperable emergency calling on the Internet.

This document also defines requirements for "Intermediate" devices which
exist between end devices or applications and the access network. For
example, a home router is an "Intermediate" device.²
2009-07-29
20 Cindy Morgan
(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 …
(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 of it¹s several
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.
The last remaining issue was a discussion titled ŒApplicability Statement¹.
Text was submitted and rejected by the WG. See:
http://www.ietf.org/mail-archive/web/ecrit/current/msg06434.html

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


One reference is wrongly identified with id-nits as informational, it¹s
actually Standards Track, hence we ignored this idnits warning. All other
idnits have been resolved. There is one 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].

References are split into Informative and Normative.


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


³This document describes how access networks, SIP user agents, proxy
servers and PSAPs support emergency calling, as outlined in
[I-D.ietf-ecrit-framework], which is designed to complement the present
document in section headings, numbering and content. This BCP succinctly
describes the requirements of end devices and applications, access networks
(including enterprise access networks), service providers and PSAPs to
achieve globally interoperable emergency calling on the Internet.

This document also defines requirements for "Intermediate" devices which
exist between end devices or applications and the access network. For
example, a home router is an "Intermediate" device.²
2009-07-29
20 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2009-07-29
20 Cindy Morgan [Note]: 'Marc Linsner (mlinsner@cisco.com) is the document shepherd.' added by Cindy Morgan
2009-07-27
13 (System) New version available: draft-ietf-ecrit-phonebcp-13.txt
2009-07-09
12 (System) New version available: draft-ietf-ecrit-phonebcp-12.txt
2009-06-04
11 (System) New version available: draft-ietf-ecrit-phonebcp-11.txt
2009-06-04
10 (System) New version available: draft-ietf-ecrit-phonebcp-10.txt
2009-03-27
09 (System) New version available: draft-ietf-ecrit-phonebcp-09.txt
2009-02-27
08 (System) New version available: draft-ietf-ecrit-phonebcp-08.txt
2009-01-27
07 (System) New version available: draft-ietf-ecrit-phonebcp-07.txt
2008-11-04
06 (System) New version available: draft-ietf-ecrit-phonebcp-06.txt
2008-07-10
05 (System) New version available: draft-ietf-ecrit-phonebcp-05.txt
2008-02-25
04 (System) New version available: draft-ietf-ecrit-phonebcp-04.txt
2007-11-19
03 (System) New version available: draft-ietf-ecrit-phonebcp-03.txt
2007-09-19
02 (System) New version available: draft-ietf-ecrit-phonebcp-02.txt
2007-09-09
20 (System) Document has expired
2007-03-08
01 (System) New version available: draft-ietf-ecrit-phonebcp-01.txt
2006-10-18
00 (System) New version available: draft-ietf-ecrit-phonebcp-00.txt