Subject: [Ecrit] Design Team Status Update

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 12 Oct 2008 12:00:39 +0300

Hi all, 

so far, we have the following persons on the design team but a few
responses are still pending:

* Guy Caron (g.caron at bell.ca)
* James Polk (jmpolk at cisco.com) 
* Ted Hardie (hardie at qualcomm.com)
* Henning Schulzrinne (hgs at cs.columbia.edu) 
* Keith Drage (drage at alcatel-lucent.com) 
* Brian Rosen (Brian.Rosen at neustar.biz) 
* Theresa Reese (treese at telcordia.com)

The design team is lead by the working group chairs: Marc Linsner and
Hannes Tschofenig 

The rules for design teams are described in
http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt

We thought that we could re-use our IETF ECRIT mailing list for
discussions rather than creating a separate list. 
Let's see how that works out.

>From a procedural point of view we would start with reviewing Brian's
draft:
http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts-00
.txt

Marc, for example, recently provided a few review comments: 
http://www.ietf.org/mail-archive/web/ecrit/current/msg05511.html

There are some other review comments from the previous IETF meeting, see

http://www.ietf.org/mail-archive/web/ecrit/current/msg05450.html
http://www.ietf.org/mail-archive/web/ecrit/current/msg05447.html

If necessary, we will schedule phone conference calls. 

The initial goal is to agree on some of the requirements. 

At IETF#73 a status update will be given. Then, we will determine the
next steps. 

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Oct 2008 10:55:58 -0700

>* Ted Hardie (hardie at qualcomm.com)

Apparently, my private message to you didn't get through, so
I will say this publicly.  I do not support the creation of a design
team at this stage.  The whole working group should be involved
in the discussion of these requirements, at least in my opinion,
and the re-use of the ECRIT mailing list for discussion would tend
to support anyone who was interested making comments.
Why, in that context, are you forming a design team at all?

We should also be really clear on what the target is.  The desires
being expressed would likely result in mechanisms which would
be used in some jurisdictions or network contexts, but not all
jurisdictions and network contexts.  It will not, in other words,
result in a "best current practice".  At most, it will result in a
"for jurisdictions where X is required by regulators or desired
by PSAPs, the best available mechanism is Y".  Especially because
of the initial "this could get folded into the BCP, even at a late stage"
discussion, I think this requires pretty clear language now.

				Ted

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 13 Oct 2008 22:07:00 +0300

Hi Ted, 

>Apparently, my private message to you didn't get through, so I 
>will say this publicly. 

I indeed did not see your message. 

> I do not support the creation of a 
>design team at this stage.  The whole working group should be 
>involved in the discussion of these requirements, at least in 
>my opinion, and the re-use of the ECRIT mailing list for 
>discussion would tend to support anyone who was interested 
>making comments.

I want to make quick progress. The design team interestingly enough
gives me the possibility todo so (from my experience). 
Additionally, I can schedule phone conferences on a very short notice.
Also a very powerful mechanism to make sure that we agree on things (or
to determine on what we disagree). 

>
>We should also be really clear on what the target is.  The 
>desires being expressed would likely result in mechanisms 
>which would be used in some jurisdictions or network contexts, 
>but not all jurisdictions and network contexts.  It will not, 
>in other words, result in a "best current practice".  At most, 
>it will result in a "for jurisdictions where X is required by 
>regulators or desired by PSAPs, the best available mechanism 
>is Y".  Especially because of the initial "this could get 
>folded into the BCP, even at a late stage"

Regarding the document type: I am not sure BCP is the right document
type for the "Phone BCP document" depending on your view of what a BCP
should contain. 

My initial target is to figure out whether the requirements make sense.
What todo with the outcome later is hard to tell but I also want to make
sure that we FINALLY finish the Phone BCP/Framework document since folks
are already implementing their emergency services code and they are
looking at an unfinished document that gets postponed all the time. 

Ciao
Hannes

>>http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnec
>t-rqmts-0
>>0
>>.txt
>>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 14 Oct 2008 02:44:38 +0200

I was happy for the design team to do a round of tidying up the
requirements and making sure that they were understandable and precise
and motivated - which they are not currently not in my view.

I agree that once that has been done, the WG has to decide whether those
requirements (or some of them) have consensus for further work - before
any specification work starts based on those requirements.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Hardie
> Sent: Monday, October 13, 2008 6:56 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo); 
> [email-masked]; [email-masked]; ECRIT
> Subject: Re: [Ecrit] Design Team Status Update
> 
> I will say this publicly.  I do not support the creation of a 
> which would be used in some jurisdictions or network 
> contexts, but not all jurisdictions and network contexts.  It 
> will not, in other words, result in a "best current 
> practice".  At most, it will result in a "for jurisdictions 
> where X is required by regulators or desired by PSAPs, the 
> best available mechanism is Y".  Especially because of the 
> initial "this could get folded into the BCP, even at a late stage"
> >http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconne
> ct-rqmts-0
> >0
> >.txt
> >

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 13 Oct 2008 20:26:22 -0500

At 02:07 PM 10/13/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>I want to make quick progress.

If time is a factor, or goal, then putting whatever comes from this 
design team into a post WGLC doc shouldn't also be a goal.

This topic is not properly defined, thus it is not known how long it 
will be until it is in good/mature form to put into an 
RFC.  Therefore I don't believe this should go into the PhoneBCP doc 
at all; especially if you really want the PhoneBCP to be done.

>The design team interestingly enough

I'd be curious if you have examples of when a design team has 
finished work as fast as you want, when the point of the design team 
is to finish one very small aspect of a larger effort?

Seems to me that design teams are targeted mostly at topics that will 
become the main point of a complete doc...

>Additionally, I can schedule phone conferences on a very short notice.

You can, but given that it is now just 2 weeks until -00 cutoff, some 
of us might have the flexibility to have these calls are a moment's notice.

>to determine on what we disagree).

As an observation - I believe you have more people disagreeing that 
agreeing (on this topic) at this moment in time.

Ultimately, you want to overcome implementer's universal mode of 
disconnecting (or removing) state awareness once a UA has sent a BYE 
when this is not proper SIP procedures.  SIP procedures are to wait 
for the response before releasing the state of the call.  If proper 
procedures were followed, none of this would be an issue, because the 
BYE would merely need to be refused with a 488 (Not Acceptable Here) 
to address this.

Any solution is going to look redundant within SIP rules, which is in 
itself creating a broken solution.

> >
> >We should also be really clear on what the target is.

we NEED to be clear if there is a target that is acceptable here, first IMO.

>The

... yet you don't seem to want to take the time to have this process 
work itself out, but instead want to rush this whole thing along... 
which I also question (like Ted does).

>sure that we FINALLY finish the Phone BCP/Framework document

Finally finishing the Phone BCP/Framework documents means writing 
them in a way that follows existing SIP protocol procedures (which 
refusing the BYE mandates we specify, and nothing further).

That reality of implementers not waiting for the response to the BYEs 
doesn't mean we state anything different, or invent anything 
different.  We just emphasize that this function within SIP needs to 
be implemented as RFC 3261 states it should be.

I cannot believe either the Phone BCP or Framework documents will get 
by the RAI AD review without merely stating what already exists 
within SIP, much less by the IESG - the fact that implementers are 
ignoring 3261 functions - and this one is a basic one...

>since folks

These folks then should be implementing what 3261 mandates first and 
foremost, then implementing what is in both the Phone BCP/Framework 
documents to achieve good implementations of emergency 
services.  Anything else flies of the face of what the IETF is all 
about (IMO)...

James

BTW - Hannes, having this design team discussion on the ECRIT mail 
list means there really isn't a design team, since anyone that's on 
the ECRIT mailing list can respond, therefore any discussion is not 
limited to the number of folks on the design team... I'm wondering 
why there needs to be a design team in the first place - oh yeah, Ted 
already said that.  In that case, I second Ted's concerns about this ;-)

---

From: Randall Gellens <[email-masked]>
Date: Mon, 13 Oct 2008 21:18:27 -0700

>  ignoring 3261 functions - and this one is a basic one...

Can a BCP change a widespread situation where implementers ignore 
what the spec says?

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
In the United States the majority undertakes to supply a multitude of
ready-made opinions for the use of individuals, who are thus relieved
from the necessity of forming opinions of their own
      --Alexis de Tocqueville
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Oct 2008 08:48:31 +0300

Hi James, 

>If time is a factor, or goal, then putting whatever comes from 
>this design team into a post WGLC doc shouldn't also be a goal.

It is probably a bit early to say whether we can put it into the
document or not. That heavily depends on what the outcome of it is. Hard
to tell right now.
 
Remember that the entire discussion started with a sentence in the Phone
BCP document that triggered a discussion in NENA.  

Here is the relevant paragraph and the sentence: 

12.  Call termination

   ED-68 UACs with an active emergency call (i.e.  SIP Dialog) MUST NOT
   generate a BYE request (or equivalent for other non-SIP signaling).
   The PSAP must be the only entity that can terminate a call.  If the
   user "hangs up" an emergency call, the device should alert the user,
   and if the user responds by attempting to pick up the call, the
   device MUST reconnect the caller to the PSAP.

>
>This topic is not properly defined, thus it is not known how 
>long it will be until it is in good/mature form to put into an 
>RFC.  Therefore I don't believe this should go into the 
>PhoneBCP doc at all; especially if you really want the 
>PhoneBCP to be done.

It is true that it is somewhat hard to estimate the time it takes and I
explicitly mentioned the option of not putting the eventual outcome into
phone BCP. 

Currently, "a solution" is already in the phone BCP document, as
mentioned above. 

>finished work as fast as you want, when the point of the 
>design team is to finish one very small aspect of a larger effort?

Well. The GEOPRIV design teams are obviously not super good examples. 
However, I was quite happy about a recent design team I started on
Diameter extensibility (in DIME). 
We had a difficult problem to tackle. The DT ran for a few months; we
had a number of phone conferences and we got it done. 
It obviously depends a lot on the members of the design team...

>
>Seems to me that design teams are targeted mostly at topics 
>that will become the main point of a complete doc...

In the example I mentioned above the outcome was a short description on
a Wiki:
http://trac.tools.ietf.org/wg/dime/trac/wiki/DiameterExtensibility
The text was then folded into another document. 

>You can, but given that it is now just 2 weeks until -00 
>cutoff, some of us might have the flexibility to have these 
>calls are a moment's notice.

We don't need to get a document published for the submission deadline. 
I am already happy if we can put a presentation together for the next
IETF meeting. 

Marc and I naively requested only a short slot in the believe that our
work would largely be done already....

>As an observation - I believe you have more people disagreeing 
>that agreeing (on this topic) at this moment in time.

It depends on the group of people you talk to. NENA members are,
unfortunately, a bit shy when it comes to post mails to the ECRIT list
and hence they are often not heard. But, we are working on this. 

In any case, I got the impression that we don't have a common
understanding. 
Hence, we have to clarify the problem statement and flesh out the
requirements a bit better. 

>
>Ultimately, you want to overcome implementer's universal mode 
>of disconnecting (or removing) state awareness once a UA has 
>sent a BYE when this is not proper SIP procedures.  SIP 
>procedures are to wait for the response before releasing the 
>state of the call.  If proper procedures were followed, none 
>of this would be an issue, because the BYE would merely need 
>to be refused with a 488 (Not Acceptable Here) to address this.

Too early for solution discussions. 

>
>Any solution is going to look redundant within SIP rules, 
>which is in itself creating a broken solution.
>
>
>> >

That's why I suggested to disuss the requirements first. 

>which I also question (like Ted does).

I am not sure what you mean by "have this process work itself out". 

Regarding "I want to rush": Clearly, I want to finish the WG
deliverables. 
I wouldn't call this "a rush" given that they should have been finished
a long time ago. 
I also want to close the open issues.

If you look on the mailing list then you will notice that there is
silence after the Dublin IETF meeting (as it usually happens after IETF
meetings) since everyone is busy with other stuff etc. 

Wakeing folks up took a bit longer this time. Posting the announcement
of a design team formation has helped a lot to get your attention. 

>refusing the BYE mandates we specify, and nothing further).

Correct. 

>services.  Anything else flies of the face of what the IETF is all 

Thanks for sharing your view. 

So, if you look at the current Phone BCP: 
* Do you think that the current text is fine? 
* If you look at Brian's requirements draft do you understand all the
requirements? 
If not, which onces do you not understand? 

>already said that.  In that case, I second Ted's concerns 
The mailing list thing was just an idea. 
Maybe we should setup a separate mailing list --- not a big issue
either. 

I am still collecting a few folks for the design team ...

Ciao
Hannes

>> >>There are some other review comments from the previous 
>IETF meeting,
>> >>see
>> >>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 14 Oct 2008 01:16:20 -0500

>Can a BCP change a widespread situation where implementers ignore 

no, but what is the alternative, to specify that this time "we 
really, really mean it" (i.e., do this thing instead)?  How exactly 
isn't the IESG going to evaluate that as: SIP implementers are lazy, 
we shouldn't use another RFC to specify another mechanism they might 
ignore like they did the first one?  The IESG is going to ask why do 
anything if nothing is followed...

I'm asking the same question. Why do some of us think *this time* 
this new mechanism (say, lets pick on one proposal of a 
Supported/Require negotiation that is against everything the current 
model SIP is built upon)?

For those who aren't keeping track - Require is used in SIP requests, 
with a specific response mechanism (including when to error it) - 
which cannot be employed if the first instance of the Require header 
is present in a SIP response, which blows up the whole idea of 
erroring a Require option-tag.

Before it is said that the Supported option-tag had the initial 
offering of support for the feature/option-tag, why do we think this 
will be used when something as simple as maintaining state until the 
final response is received within a transaction?

that's a reach, and a false sense of security (that a feature exists or not)...

if it isn't implemented this way, it'll probably brick the phone

of course, this is only my opinion, I could be wrong

James

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 14 Oct 2008 01:23:01 -0500

>Too early for solution discussions.

ah, but this one is specified in RFC 3261 - which (way) predates ECRIT

therefore this "solution" exists already. This is not a new one

James

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Oct 2008 09:27:44 +0300

It would be great if we can fulfill the requirements using existing
mechanisms. 

BUT I hear some folks saying that they haven't understood all the
requirements. See, for example, the recent mails from Marc: 
http://www.ietf.org/mail-archive/web/ecrit/current/msg05511.html
http://www.ietf.org/mail-archive/web/ecrit/current/msg05512.html

As such, I thought it makes sort of sense to make sure that we
understand the context first. 

Have you understood all requirements listed in 
http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts-00
.txt

>From: ext James M. Polk [mailto:[email-masked]] 
>Sent: 14 October, 2008 09:23
>To: Tschofenig, Hannes (NSN - FI/Espoo); ext Ted Hardie; 
>Subject: RE: [Ecrit] Design Team Status Update
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 14 Oct 2008 01:38:51 -0500

>So, if you look at the current Phone BCP:

you mean the ID I'm the only other coauthor of (with Brian)?

>* Do you think that the current text is fine?

I'm not ecstatic with all of the text, but I am generally happy with it.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Oct 2008 09:54:30 +0300

>you mean the ID I'm the only other coauthor of (with Brian)?

Yup. That I-D. 

>I'm not ecstatic with all of the text, but I am generally 

OK. Good to hear that

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Oct 2008 08:47:06 -0400

You are ignoring the observation that refusing a BYE means all proxies in
the path have to be aware that this is possible.  That is much more of
change than we can probably expect.

Not sending a BYE doesn't have that problem.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
James M. Polk
Sent: Tuesday, October 14, 2008 2:23 AM
To: Tschofenig, Hannes (NSN - FI/Espoo); ext Ted Hardie;
[email-masked]; [email-masked]; ECRIT
Subject: Re: [Ecrit] Design Team Status Update

James

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 14 Oct 2008 11:27:09 -0400

Note that proxies, at least if you follow the SIP definition, aren't  
handling BYEs at all. I assume you are talking about B2BUAs, right?

On Oct 14, 2008, at 8:47 AM, Brian Rosen wrote:

> Nena-ltd mailing list
> [email-masked]
> https://lists.cs.columbia.edu/cucslists/listinfo/nena-ltd

---

From: Marc Linsner <[email-masked]>
Date: Tue, 14 Oct 2008 13:02:31 -0400

Brian,

So creating more mechanism that is ignored by implementers is better?

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Oct 2008 13:12:44 -0400

We have a shot at getting phone vendors to pay attention.  The more parts I
have to get upgraded, and the more difficult the upgrades, the less likely.
I talked with several sip experts about the "cancel the bye" idea.  While
feasible, it's a major stack change.

Doing something like enabling a feature because it's in Required is a heck
of a lot easier.

Getting just phones to do something as opposed to phones + B2BUAs and other
middleboxes is a lot easier

Also, you the failure mechanisms for the middleboxes is bad.  If they don't
understand the "cancel the BYE", then they tear down the connections as soon
as they see the BYE.  But they don't take the tag away in Supported - so the
PSAP and the phone think it's gonna work, but it actually breaks.  Yuck.

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Tuesday, October 14, 2008 1:03 PM
To: Brian Rosen; [email-masked];
[email-masked]; 'ECRIT'
Subject: Re: [NENA-ltd] [Ecrit] Design Team Status Update

Brian,

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Tue, 14 Oct 2008 13:28:13 -0400

Brian,

> middleboxes is a lot easier

Please explain why a B2BUA would not be involved in your 'existing
Supported/Required option negotiation mechanism'.

Please expand what middleboxes your are talking about.

-Marc-

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 14 Oct 2008 13:21:30 -0500

Brian

AS Henning said, only dialog stateful proxies are involved in the 
BYEs, so that will be rare, because most of these Proxies will 
actually be B2BUAs.  Meaning you have to get everyone's B2BUAs to 
implement this SIP extension to get it to even have a prayer of 
working on any scale.  Since B2BUAs do not look any different than 
Proxies to a UAC or UAS, you can't detect them, so how exactly is 
anyone going to deal with the frequent failures of this new mechanism?

I think you have the same challenge of getting existing Proxies to be 
upgraded to support BYE state until response, "for the good of the 
planet (i.e., to get emergency calling to support this one features 
that isn't really used by more than 1/3 of the existing emergency 
systems anyway)"...

James