Framework for Emergency Calling Using Internet Multimedia
draft-ietf-ecrit-framework-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
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-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 |