Skip to main content

Framework for Emergency Calling Using Internet Multimedia
RFC 6443

Revision differences

Document history

Date Rev. By Action
2015-10-14
13 (System) Notify list changed from ecrit-chairs@ietf.org, draft-ietf-ecrit-framework@ietf.org to (None)
2013-11-15
(System) Posted related IPR disclosure: Qualcomm Incorporated's Statement about IPR related to RFC 6443
2013-01-15
(System) Posted related IPR disclosure: Qualcomm Incorporated's Statement about IPR related to RFC 6443
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
13 (System) post-migration administrative database adjustment to the Yes position for Robert Sparks
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Pete Resnick
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2011-12-21
13 Cindy Morgan State changed to RFC Published from RFC Ed Queue.
2011-12-21
13 (System) RFC published
2011-09-14
13 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-09-14
13 (System) IANA Action state changed to No IC from In Progress
2011-09-14
13 (System) IANA Action state changed to In Progress
2011-09-14
13 Amy Vezza IESG state changed to Approved-announcement sent
2011-09-14
13 Amy Vezza IESG has approved the document
2011-09-14
13 Amy Vezza Closed "Approve" ballot
2011-09-14
13 Amy Vezza State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2011-09-14
13 Robert Sparks Ballot writeup text changed
2011-09-14
13 Robert Sparks Approval announcement text changed
2011-09-14
13 Robert Sparks Approval announcement text regenerated
2011-09-14
13 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-09-13
13 Pete Resnick
[Ballot comment]
All discuss comments were addressed. The remaining comments below are things that the WG (editor?) decided didn't need addressing. Left in here for …
[Ballot comment]
All discuss comments were addressed. The remaining comments below are things that the WG (editor?) decided didn't need addressing. Left in here for posterity.

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

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

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

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

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

6.6 paragraph 1 seems much more about *how* one gets location than *when*. What you are saying here is that if you are getting netwok measured location information, you had better be asking the local network and not some VPN. In the case of NATs, again it's not timing, but mechanism that is important: You had better pass your globally visible address corresponding to your local network and not your NAT address when talking to an LCP.
2011-09-13
13 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss
2011-09-08
13 Stephen Farrell
[Ballot comment]
-13 fixed my discuss points, thanks.

Not sure if Sean's discuss was sorted or not, so the comment below
may now be moot...or …
[Ballot comment]
-13 fixed my discuss points, thanks.

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

I support Sean's discuss wrt IPR and LC processes. I'm also unclear
how IPR that affects this informational document would not affect the
phonebcp document but who knows with these things.
2011-09-08
13 Stephen Farrell
[Ballot comment]
-13 fixed my discuss points.

I support Sean's discuss wrt IPR and LC processes. I'm also unclear
how IPR that affects this informational …
[Ballot comment]
-13 fixed my discuss points.

I support Sean's discuss wrt IPR and LC processes. I'm also unclear
how IPR that affects this informational document would not affect the
phonebcp document but who knows with these things.
2011-09-08
13 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2011-09-07
13 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-09-07
13 (System) New version available: draft-ietf-ecrit-framework-13.txt
2011-09-07
13 Russ Housley
[Ballot comment]
The Gen-ART Review by Francis Dupont on 2010-03-05 included some
  editorial comments.  Please consider them if an update to this
  document …
[Ballot comment]
The Gen-ART Review by Francis Dupont on 2010-03-05 included some
  editorial comments.  Please consider them if an update to this
  document is needed for any reason.
2011-09-07
13 Russ Housley
[Ballot discuss]
The Gen-ART Review by Francis Dupont on 2010-03-05 raised two minor
  issues.  What, if anything, was done to address this IETF Last …
[Ballot discuss]
The Gen-ART Review by Francis Dupont on 2010-03-05 raised two minor
  issues.  What, if anything, was done to address this IETF Last Call
  comment: "the Terminology is incomplete, no PSAP for instance"
2011-09-07
13 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss
2011-08-23
13 Robert Sparks State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup.
2011-04-28
13 Cindy Morgan Removed from agenda for telechat
2011-04-28
13 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation.
2011-04-28
13 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-04-28
13 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-04-28
13 Sean Turner
[Ballot comment]
I agree with Pete's first discuss.  Is this addressed somewhere else in the SIP stack of documents (i.e., if you don't use security …
[Ballot comment]
I agree with Pete's first discuss.  Is this addressed somewhere else in the SIP stack of documents (i.e., if you don't use security an attacker can ...).
2011-04-28
13 Sean Turner
[Ballot discuss]
The IETF LC was issued in 2010-02.  The IPR disclosure was filed in 2010-08 and obviously wasn't in the IETF LC.  Has the …
[Ballot discuss]
The IETF LC was issued in 2010-02.  The IPR disclosure was filed in 2010-08 and obviously wasn't in the IETF LC.  Has the IPR disclosure been discussed by the WG?
2011-04-28
13 Stephen Farrell
[Ballot discuss]
(1) Section 3 says: "a caller must obtain his location...prior to making
emergency calls." That seems overstated - if I can't find my …
[Ballot discuss]
(1) Section 3 says: "a caller must obtain his location...prior to making
emergency calls." That seems overstated - if I can't find my location
are you saying that the call can't happen? (A "should" would be right
here I think.)

(3) How would any of this work with p2psip? (Just checking again.)
2011-04-26
13 Stephen Farrell
[Ballot comment]
(1) I support Sean's discuss wrt IPR and LC processes. I'm also unclear
how IPR that affects this informational document would not affect …
[Ballot comment]
(1) I support Sean's discuss wrt IPR and LC processes. I'm also unclear
how IPR that affects this informational document would not affect the
phonebcp document but who knows with these things.

(2) Intro: "there are currently no international standards" - doesn't 112
qualify as an international standard for an existing emergency call system?
Then: "However, the Internet crosses national boundaries, and thus
international standards for equipment and software are required." Don't you
mean that Internet standards are required?
2011-04-26
13 Stephen Farrell
[Ballot discuss]
(1) Section 3 says: "a caller must obtain his location...prior to making
emergency calls." That seems overstated - if I can't find my …
[Ballot discuss]
(1) Section 3 says: "a caller must obtain his location...prior to making
emergency calls." That seems overstated - if I can't find my location
are you saying that the call can't happen? (A "should" would be right
here I think.)

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

(3) How would any of this work with p2psip? (Just checking again.)
2011-04-26
13 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-04-26
13 Sean Turner
[Ballot discuss]
I'm not done yet.

The IETF LC was issued in 2010-02.  The IPR disclosure was filed in 2010-08 and obviously wasn't in the …
[Ballot discuss]
I'm not done yet.

The IETF LC was issued in 2010-02.  The IPR disclosure was filed in 2010-08 and obviously wasn't in the IETF LC.  Has the IPR disclosure been discussed by the WG?
2011-04-26
13 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2011-04-26
13 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-04-25
13 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-04-24
13 Pete Resnick
[Ballot comment]
General comment: Some of the language seems more SIP-centric than it needs to be, and most of the document is not SIP-centric. It …
[Ballot comment]
General comment: Some of the language seems more SIP-centric than it needs to be, and most of the document is not SIP-centric. It provides important information to people implementing emergency calling services irrelevant of protocol. I've given a couple of specifics below.

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

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

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

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

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

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

Section 6.2.1:

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

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

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

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

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

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

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

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

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

6.10: "When validation fails, the location given must not be used for an emergency call." What if I have no other location information? Should I not send something? Or is this supposed to be covered in 6.11 (in which case a forward reference would be useful)?
2011-04-24
13 Pete Resnick
[Ballot discuss]
9.1: There is no discussion here of the security and privacy implications of continuing a call without TLS, and there is no such …
[Ballot discuss]
9.1: There is no discussion here of the security and privacy implications of continuing a call without TLS, and there is no such information in the Security Considerations section. For example, if TLS cannot be established, should I give a more coarse-grained location? Should I use some mechanism to encrypt the location? Somewhere this needs to be discussed.

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

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

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

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

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

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

It is again not clear to me whether this document (or parts of this document) or draft-ietf-ecrit-phonebcp intends to be framework, or "best current practice", or applicability statement, etc. One way or the other, this document should get rid of its normative text, but what the resultant document set should look like needs to be discussed.
2011-04-24
13 Pete Resnick [Ballot Position Update] New position, Discuss, has been recorded
2011-04-21
13 Robert Sparks State changed to IESG Evaluation from IESG Evaluation::AD Followup.
2011-04-21
13 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to Yes from Discuss
2011-04-21
13 Robert Sparks Placed on agenda for telechat - 2011-04-28
2010-10-25
12 (System) New version available: draft-ietf-ecrit-framework-12.txt
2010-08-30
(System) Posted related IPR disclosure: Qualcomm Incorporated's Statement about IPR related to draft-ietf-ecrit-framework-11
2010-07-12
13 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-07-12
11 (System) New version available: draft-ietf-ecrit-framework-11.txt
2010-04-14
13 Robert Sparks
[Ballot discuss]
Last paragraph of section 5: These restrictions on UA design
are out of place for an IETF document.  If the intent is to …
[Ballot discuss]
Last paragraph of section 5: These restrictions on UA design
are out of place for an IETF document.  If the intent is to
just ask UI implementors and regulators to consider these
concerns, the language should be adjusted.

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

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

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

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

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

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

Section 14. 2nd para. At the time this was first written, this was true,
however, at this point of time the IETF does have consensus about keying for SRTP. It seems that given that security is desirable, we should use the agreed on keying solution.
2010-04-13
13 Robert Sparks [Note]: 'IETF LC ends Mar 10.
Marc Linsner (mlinsner@cisco.com) is the document shepherd.' added by Robert Sparks
2010-04-13
13 Robert Sparks Responsible AD has been changed to Robert Sparks from Cullen Jennings
2010-03-11
13 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2010-03-11
13 Russ Housley
[Ballot comment]
The Gen-ART Review by Francis Dupont on 2010-03-05 included some
  editorial comments.  Please consider them if an update to this
  document …
[Ballot comment]
The Gen-ART Review by Francis Dupont on 2010-03-05 included some
  editorial comments.  Please consider them if an update to this
  document is needed for any reason.
2010-03-11
13 Russ Housley
[Ballot discuss]
The Gen-ART Review by Francis Dupont on 2010-03-05 raised two minor
  issues.  What, if anything, was done to address this IETF Last …
[Ballot discuss]
The Gen-ART Review by Francis Dupont on 2010-03-05 raised two minor
  issues.  What, if anything, was done to address this IETF Last Call
  comment: "the Terminology is incomplete, no PSAP for instance"
2010-03-11
13 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2010-03-11
13 Magnus Westerlund
[Ballot comment]
Section 1:
PSAP is not explained in this section, please write out on first usage

Section 1:
NENA (National Emergency Number Association):

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

Section 1:
NENA (National Emergency Number Association):

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

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

In this type of reference it would be good to specify which fire brigade
that has this recommendations. I would be highly surprised if the California recommendations are exactly the same as the one in Stockholm.
2010-03-11
13 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2010-03-11
13 Robert Sparks
[Ballot discuss]
Last paragraph of section 5: These restrictions on UA design
are out of place for an IETF document.  If the intent is to …
[Ballot discuss]
Last paragraph of section 5: These restrictions on UA design
are out of place for an IETF document.  If the intent is to
just ask UI implementors and regulators to consider these
concerns, the language should be adjusted.

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

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

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

Section 15, paragraph 2 is missing a reference to PhoneBCP at the
beginning of the sentence.
2010-03-11
13 Robert Sparks [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks
2010-03-09
13 Russ Housley
[Ballot comment]
The Gen-ART Review by Francis Dupont on 2010-03-05 included some
  editorial comments.  Please consider them if an update to this
  document …
[Ballot comment]
The Gen-ART Review by Francis Dupont on 2010-03-05 included some
  editorial comments.  Please consider them if an update to this
  document is needed for any reason.
2010-03-09
13 Russ Housley
[Ballot discuss]
The Gen-ART Review by Francis Dupont on 2010-03-05 raised two minor
  issues.  What, if anything, was done to address these IETF Last …
[Ballot discuss]
The Gen-ART Review by Francis Dupont on 2010-03-05 raised two minor
  issues.  What, if anything, was done to address these IETF Last Call
  comments:

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

  (2) the GPS stuff seems a bit USA centric; you should show the
      document to a GPS (or Galileo) expert
2010-03-09
13 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2010-03-08
13 Amanda Baber IANA comments:

As described in the IANA Considerations section, we understand this
document to have NO IANA Actions.
2010-03-08
13 Cullen Jennings
[Ballot discuss]
AD needs to check if any new  LC comments came.

Few small comments as part of my AD review. Typically I would have …
[Ballot discuss]
AD needs to check if any new  LC comments came.

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

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

Section 9.1 - para 1. Typo with the xref.

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

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

Section 14. 2nd para. At the time this was first written, this was true, however, at this point of time the IETF does have consensus about keying for SRTP. It seems that given that security is desirable, we should use the agreed on keying solution.
2010-03-08
13 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from Yes by Cullen Jennings
2010-03-08
13 Cullen Jennings State Changes to IESG Evaluation from In Last Call by Cullen Jennings
2010-03-08
13 Cullen Jennings [Note]: 'IETF LC ends Mar 10.
Marc Linsner (mlinsner@cisco.com) is the document shepherd.' added by Cullen Jennings
2010-03-08
13 Cullen Jennings Placed on agenda for telechat - 2010-03-11 by Cullen Jennings
2010-03-08
13 Cullen Jennings [Ballot Position Update] New position, Yes, has been recorded for Cullen Jennings
2010-03-08
13 Cullen Jennings Ballot has been issued by Cullen Jennings
2010-03-08
13 Cullen Jennings Created "Approve" ballot
2010-02-25
13 Samuel Weiler Request for Last Call review by SECDIR is assigned to David McGrew
2010-02-25
13 Samuel Weiler Request for Last Call review by SECDIR is assigned to David McGrew
2010-02-24
13 Amy Vezza Last call sent
2010-02-24
13 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2010-02-24
13 Cullen Jennings State Changes to Last Call Requested from AD Evaluation by Cullen Jennings
2010-02-24
13 Cullen Jennings Last Call was requested by Cullen Jennings
2010-02-24
13 (System) Ballot writeup text was added
2010-02-24
13 (System) Last call text was added
2010-02-24
13 (System) Ballot approval text was added
2009-11-10
13 Cullen Jennings State Changes to AD Evaluation from Publication Requested by Cullen Jennings
2009-07-29
13 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 several of it¹s
meetings. Organizations participating include: 3GPP, 3GPP2, ETSI EMTEL,
NENA, IEEE, EENA, etc.

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

No further review required.

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

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


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

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


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

No known threats for an appeal.


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

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


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

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


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

No IANA considerations for this document are required.


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

This document is a BCP, no protocol validation required.


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

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


³The IETF has standardized various aspects of placing emergency calls. This
document describes how all of those component parts are used to support
emergency calls from citizens and visitors to authorities.²
2009-07-29
13 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2009-07-29
13 Cindy Morgan [Note]: 'Marc Linsner (mlinsner@cisco.com) is the document shepherd.' added by Cindy Morgan
2009-07-27
10 (System) New version available: draft-ietf-ecrit-framework-10.txt
2009-03-27
09 (System) New version available: draft-ietf-ecrit-framework-09.txt
2009-02-27
08 (System) New version available: draft-ietf-ecrit-framework-08.txt
2009-01-27
07 (System) New version available: draft-ietf-ecrit-framework-07.txt
2009-01-11
13 (System) Document has expired
2008-07-10
06 (System) New version available: draft-ietf-ecrit-framework-06.txt
2008-02-25
05 (System) New version available: draft-ietf-ecrit-framework-05.txt
2007-11-19
04 (System) New version available: draft-ietf-ecrit-framework-04.txt
2007-09-19
03 (System) New version available: draft-ietf-ecrit-framework-03.txt
2007-07-10
02 (System) New version available: draft-ietf-ecrit-framework-02.txt
2007-03-08
01 (System) New version available: draft-ietf-ecrit-framework-01.txt
2006-10-26
00 (System) New version available: draft-ietf-ecrit-framework-00.txt