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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf