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 |