|
I reviewed the document draft-ietf-ecrit-phonebcp in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. The views represented here are those of the reviewer and do not represent the opinion of any other entity, including the Operations Directorate. ------------------------------------------------ Review Summary: Intended status: Best Current Practice This memo describes best current practice for how devices, networks, service providers and Public Safety Answering Points (PSAPs) should use IETF standards for emergency calling over IP networks. Is the document readable? In general the document is reasonably well organized. However, there are some requirements that do not seem easily translated into specific implementation or deployment guidance. See detailed comments for examples. Does it contain nits? Maybe. idnits 2.12.09 tmp/draft-ietf-ecrit-phonebcp-17.txt: tmp/draft-ietf-ecrit-phonebcp-17.txt(1142): Found possible FQDN 'test.sos.ambulance' in position 3; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". tmp/draft-ietf-ecrit-phonebcp-17.txt(1143): Found possible FQDN 'test.sos.animal' in position 3; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". tmp/draft-ietf-ecrit-phonebcp-17.txt(1144): Found possible FQDN 'test.sos.fire' in position 3; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". tmp/draft-ietf-ecrit-phonebcp-17.txt(1145): Found possible FQDN 'test.sos.gas' in position 3; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". tmp/draft-ietf-ecrit-phonebcp-17.txt(1146): Found possible FQDN 'test.sos.marine' in position 3; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". tmp/draft-ietf-ecrit-phonebcp-17.txt(1147): Found possible FQDN 'test.sos.mountain' in position 3; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". tmp/draft-ietf-ecrit-phonebcp-17.txt(1148): Found possible FQDN 'test.sos.physician' in position 3; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". tmp/draft-ietf-ecrit-phonebcp-17.txt(1149): Found possible FQDN 'test.sos.poison' in position 3; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". tmp/draft-ietf-ecrit-phonebcp-17.txt(1150): Found possible FQDN 'test.sos.police' in position 3; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) -- however, there's a paragraph with a matching beginning. Boilerplate error? IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii): "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English." ... text found in draft: "Code Components extracted from this document must include Simplified BSD ......^ License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License." -- The document date (March 28, 2011) is 26 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3841' is defined on line 999, but no explicit reference was found in the text '[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller P...' ** Downref: Normative reference to an Experimental draft: draft-ietf-mmusic-media-loopback (ref. 'I-D.ietf-mmusic-media-loopback') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sipcore-location-conveyance' -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP-MED' Summary: 1 error (**), 4 warnings (==), 3 comments (--). Is the document class appropriate? Probably. However, 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. It is my assumption that these issues should be fixed by clarifying individual requirements, rather than changing the document status. Is the problem well stated? Yes. Is the problem really a problem? Yes. There is a need to provide guidance on how to use IETF standards for emergency calling. Does the document consider existing solutions? There are instances in the document where it is unclear whether the recommendations refer to Best Future Practice or Best Current Practice. In general, the transition to "all-IP" emergency services will take time so that the capabilities of devices, applications, networks, service providers and PSAPs will not all be upgraded at once. As a result, behavior during the transition needs to considered. See detailed comments for examples. Does the solution break existing technology? There are instances in the document where the recommended behavior will be sub-optimal during the transition. This makes me uncomfortable because emergency services are literally a matter of life and death. Since SIP has mechanisms to determine the capabilities of other parties, I'd suggest that the document describe the adaptation or negotiation process rather than just assuming that all elements support "all-IP" emergency services. Does the solution preclude future activity? No. Is the solution sufficiently configurable? 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. Can performance be measured? How? Performance can be measured via metrics such as call failure rates (which should be REALLY low for emergency calls!), media metrics (latency, jitter), etc. Does the solution scale well? There are instances where unnecessary load could be generated (e.g. use of a Service URN when the service provider doesn't support it). Is Security Management discussed? This document relies on RFC 5069 and draft-ietf-geopriv-arch for security considerations in emergency calling, so the Security Considerations (Section 16) is skimpy, though security (TLS) is discussed in Secton 9.1. This is probably ok. ----------------------------------------------- Detailed comments: http://www.drizzle.com/~aboba/ops-dir/draft-ietf-ecrit-phonebcp |
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf