Subject: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-premature-disconnect-rqmts-00

From: "Brian Rosen" <[email-masked]>
Date: Tue, 29 Jul 2008 09:57:23 -0400

This draft is the requirements for the "Called Party Hold" and related
feature requests that relate to -phonebcp currently saying "don't send BYE".

This is the only open item in -phonebcp, and I will discuss this issue in
the slot in the ecrit agenda for -phonebcp.

This document represents the consensus NENA view of what the problem is,
since NENA raised the issue in the first place.

Brian

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 9:22 AM
To: [email-masked]
Subject: New Version Notification for
draft-rosen-ecrit-premature-disconnect-rqmts-00 

A new version of I-D, draft-rosen-ecrit-premature-disconnect-rqmts-00.txt
has been successfuly submitted by Brian Rosen and posted to the IETF
repository.

Filename:	 draft-rosen-ecrit-premature-disconnect-rqmts
Revision:	 00
Title:		 Requirements for handling abandoned calls and premature
disconnects in emergency calls on the Internet
Creation_date:	 2008-07-28
WG ID:		 Independent Submission
Number_of_pages: 7

Abstract:
The -phonebcp draft currently requires endpoints to disable sending a
BYE on an emergency call.  Insufficient justification and lack of
attention to the entire problem has caused comment on that section of
the document.  This document attempts to define the problem and the
requirements to controlling disconnect on emergency calls.

The IETF Secretariat.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 29 Jul 2008 10:21:41 -0500

I believe that there a enough scenarios in which no matter what is 
specified, even if the protocol/mechanism is done right, will still 
fail to accomplish the intended affect. Therefore, I do not believe 
this effort should move forward and the WG needs specific 
implementation experience  before we EVEN CONSIDER making this 
possible in any protocol or mechanism (for several reasons) -- 
especially a BCP-type guideline document.

As much as this is needed in some jurisdictions, we just don't know 
how to do it at this time for nearly all cases.

This, alone, is going to prevent phoneBCP *and* Framework from being 
RFC'd for more than a year.  I do not at all believe this one 
function is worth delaying these two documents.

That said, I believe this issue, by itself, should move forward 
towards a consensus solution *after* we reach consensus on the requirements.