Subject: Re: [Ecrit] HUM regarding draft-rosen-ecrit-premature-disconnect-rqmts

From: "Brian Rosen" <[email-masked]>
Date: Sat, 3 Jan 2009 09:17:45 -0500

Just a note that I was requested to issue an update to this document which
recasts the requirement in human observation/response language, completely
avoiding any signaling wording.  I have a draft which has been reviewed by
NENA.  They like the current version a lot more than the new one, but the
new one does capture the essence of the problem.  I will publish it to the
IETF today.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Wednesday, December 31, 2008 4:51 AM
To: ECRIT
Subject: [Ecrit] HUM regarding draft-rosen-ecrit-premature-disconnect-rqmts

Hi all, 

We had a fair amount of discussions regarding this item and, as
mentioned in my status update, we would like to resolve the deadlock we
currently have. 

We would like to get some feedback from the group. 

Are you OK with turning draft-rosen-ecrit-premature-disconnect-rqmts
into a working group item (after rechartering) (under the assumption
that the editor of the document is changed once the document is a WG
item)?

Deadline: 19. Jan. 2009

Ciao
Hannes & Marc

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

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 3 Jan 2009 19:48:35 +0200

This is good news. Thanks, Brian. 

Ciao
Hannes 

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Brian Rosen
>Sent: 03 January, 2009 16:18
>To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
>Subject: Re: [Ecrit] HUM 
>regardingdraft-rosen-ecrit-premature-disconnect-rqmts
>
>Just a note that I was requested to issue an update to this 
>document which recasts the requirement in human 
>observation/response language, completely avoiding any 
>signaling wording.  I have a draft which has been reviewed by 
>NENA.  They like the current version a lot more than the new 
>one, but the new one does capture the essence of the problem.  
>I will publish it to the IETF today.
>
>Brian
>
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
>Subject: [Ecrit] HUM regarding 
>draft-rosen-ecrit-premature-disconnect-rqmts
>
>Hi all, 
>
>We had a fair amount of discussions regarding this item and, 
>as mentioned in my status update, we would like to resolve the 
>deadlock we currently have. 
>
>into a working group item (after rechartering) (under the 
>assumption that the editor of the document is changed once the 
>document is a WG item)?
>
>Deadline: 19. Jan. 2009
>
>Ciao
>Hannes & Marc
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 6 Jan 2009 17:40:24 +0100

I am NOT OK with turning this document into a WG document.

In general I believe the requirements are written too much round an existing PSTN capability, rather than getting to the root of any real requirement. It is also clear that there are jurisdictions that do not require this capability and that needs to be reflected in the document.

More specifically.

Section 1.1 and section 1.2: Both these sections imply that the PSTN solution is the solution in SIP, rather than providing an overal discussion of what the real objective is. I would understand that the real need of 1.1 is in ensuring that the media path between the caller and the call taker is reinstated if the caller takes any action to remove it (or indeed not removed at all). 

At this point (section 1) there should also be a discussion of impacts of the user disconnecting just because they have made a mistake, and having realised that mistake - cleared down. There also needs to be a discussion of the phenomenum of certain parts of the world where they use the emergency call number to test the phone is working without a valid SIM or UICC.

PD-1: Not written as a requirement. User has essentially disabled the user interface of the UA - that cannot be prevented. PD-4 is about trying to get the user to reenable the user interface. Is the requirement that the existing media path must be retained between the UA and call taker, or that a media path must be provided is the user interface is reenabled?

PD-2: This is essentially two requirements. One of the user disabling the user interface. One of reenabling.

PD-5: This requirement is inadequately specified. The first and second sentences are contradictory. We don't know what the real requirement is as a result of the second sentence being there. If the user has more than one UA, what happens on the second UA. If the user is prepared to answer a call on the second UA, then why shouldn't the emergency call exist there?

Note that release 9 of 3GPP is looking at the ability to split the media of a single call between different UAs or a UA with two access technology interfaces so the text of all the requirements needs to encompass this idea as well.

PD-6: I like the idea of "converse roughly"! Typo "initialting".

PD-7: PD-7 is currently specified as the call taker requirement. Needs an additional requirement from the caller perspective, i.e. that in jurisdictions where the mechanism is not required, that the caller can clear the call normally with no impact. More importantly, this is a function of the jurisdiction, and as UAs can roam between jurisdictions, this cannot be prebuilt into the phone.

AC-1: There are several points in the sequence here which could be meant, and it is not clear which. For example, if the user has typed 911 into his user interface, but gets murdered by an assailant before hitting the send key, should an emergency call be made and completed?

AC-2: What is the real requirement here. Appears to be a caller requirement.

AC-3: Again the requirement is missing here. It would appear that the real requirement is that disconnect in not impacted in jurisdictions where the requirement is missing.

regards

Keith

> Sent: Wednesday, December 31, 2008 9:51 AM
> To: ECRIT
> as mentioned in my status update, we would like to resolve 
> the deadlock we currently have. 
> 
> assumption that the editor of the document is changed once 
> the document is a WG item)?
> 
> Deadline: 19. Jan. 2009
> 
> Ciao
> Hannes & Marc
>

---

From: <[email-masked]>
Date: Wed, 7 Jan 2009 13:59:53 -0500

Just to chime in that I HUM for turning this document as a WG item so it can evolve to satisfaction then.

Thanks,

Guy Caron, ENP

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Tschofenig, Hannes (NSN - FI/Espoo)
Envoyé : 31 décembre 2008 04:51
À : ECRIT
Objet : [Ecrit] HUM regarding draft-rosen-ecrit-premature-disconnect-rqmts

Hi all,

Deadline: 19. Jan. 2009

Ciao
Hannes & Marc