Subject: [Ecrit] PhoneBCP

From: Marc Linsner <[email-masked]>
Date: Fri, 24 Apr 2009 14:23:48 -0400

http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt

At the San Francisco meeting and ensuing list threads, the last issue around
PhoneBCP was whether or not to include an Œapplicability statement¹.  The
hum during the meeting was inconclusive.  The draft editor has included text
in this latest version in an attempt to compromise on this issue.

Please review this version and respond by Friday May 1 to the list as to
your acceptance of this change.

Thanks,

Marc, Hannes, & Roger

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 24 Apr 2009 14:43:34 -0400

I assume you're referring to the following paragraph in the
introduction:

"   This document focuses on the case in which all three steps in the

   emergency calling process -- location configuration, call routing,

   and call placement - can be and are performed by the calling

   endpoint, with the endpoint's Access Service Provider supporting the

   process by providing location information.  Calls in this case may be

   routed via an application-layer Communications Service Provider

   (e.g., a Voice Service Provider), but need not be.  The underlying

   protocols can also be used to support other models in which parts of

   the process are delegated to the Communications Service Provider.

   This document does not address in detail either these models or

   interoperability issues between them and the model described here."

Yes, I accept this.

Barbara

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marc Linsner
Sent: Friday, April 24, 2009 2:24 PM
To: ECRIT
Subject: [Ecrit] PhoneBCP

At the San Francisco meeting and ensuing list threads, the last issue
around PhoneBCP was whether or not to include an 'applicability
statement'.  The hum during the meeting was inconclusive.  The draft
editor has included text in this latest version in an attempt to
compromise on this issue.

Thanks,

Marc, Hannes, & Roger 

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: Ted Hardie <[email-masked]>
Date: Fri, 24 Apr 2009 13:36:33 -0700

At 11:23 AM -0700 4/24/09, Marc Linsner wrote:
><http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt
>
>At the San Francisco meeting and ensuing list threads, the last issue around PhoneBCP was whether or not to include an 'applicability statement'.  The hum during the meeting was inconclusive.  The draft editor has included text in this latest version in an attempt to compromise on this issue.
>
>Please review this version and respond by Friday May 1 to the list as to your acceptance of this change.
>
>Thanks,
>
>Marc, Hannes, & Roger

I support the current draft going forward to publication requested.

				regards,
					Ted

>
>Content-Type: text/plain; name="ATT00001.txt"
>Content-Description: ATT00001.txt
>Content-Disposition: attachment; filename="ATT00001.txt"; size=194;
>	creation-date="Fri, 24 Apr 2009 11:24:11 GMT";
>	modification-date="Fri, 24 Apr 2009 11:24:11 GMT"
>
>Attachment converted: Macintosh HD:ATT00001 5171.txt (TEXT/ttxt) (003FF52C)

---

From: Richard Barnes <[email-masked]>
Date: Fri, 24 Apr 2009 22:32:23 -0400

+1

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 25 Apr 2009 03:51:20 -0500

So is this turning into a list "hum" as to whether we should have an applicability statement or not?

ISTM that this would be an appropriate course of action given the lack on consensus at the actually meeting.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Richard Barnes
Sent: Fri 4/24/2009 9:32 PM
To: Ted Hardie
Cc: ECRIT
Subject: Re: [Ecrit] PhoneBCP
 
+1

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 25 Apr 2009 14:04:47 -0400

Actually, I think the list hum is whether or not you accept the change, as
proposed, and consider the document ready to send to the IESG.  It's kind of
a combination of is an applicability statement acceptable, and is this
particular one acceptable (and are you otherwise okay with the document,
which is implied in Marc's message, but I think important to recognize).

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Winterbottom, James
Sent: Saturday, April 25, 2009 4:51 AM
To: Richard Barnes; Ted Hardie
Cc: ECRIT
Subject: Re: [Ecrit] PhoneBCP

So is this turning into a list "hum" as to whether we should have an
applicability statement or not?

ISTM that this would be an appropriate course of action given the lack on
consensus at the actually meeting.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Richard Barnes
Sent: Fri 4/24/2009 9:32 PM
To: Ted Hardie
Cc: ECRIT
Subject: Re: [Ecrit] PhoneBCP
 
+1

> At 11:23 AM -0700 4/24/09, Marc Linsner wrote:
<http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt>http:/
/www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt
>> At the San Francisco meeting and ensuing list threads, the last issue
around PhoneBCP was whether or not to include an 'applicability statement'.
The hum during the meeting was inconclusive.  The draft editor has included
text in this latest version in an attempt to compromise on this issue.

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 25 Apr 2009 16:57:47 -0500

My point is that because there was no consensus at the IETF, in fact the document should have remained unchanged.

I want a hum first as to whether the applicability statement is required at all. As I have stated more then one I don't believe it is, and no reasonable argument has yet been provided to changed my mind.

So let us first establish with a clear consensus that the applicability statement is required.

I HUM against the inclusion of an applicability statement.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Sat 4/25/2009 1:04 PM
To: Winterbottom, James; 'Richard Barnes'; 'Ted Hardie'
Cc: 'ECRIT'
Subject: RE: [Ecrit] PhoneBCP

Brian

-----Original Message-----

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Richard Barnes
Sent: Fri 4/24/2009 9:32 PM
To: Ted Hardie
Cc: ECRIT
Subject: Re: [Ecrit] PhoneBCP
 
+1

---

From: Richard Barnes <[email-masked]>
Date: Sat, 25 Apr 2009 21:26:30 -0400

I don't think there are separate hums necessary at this point.  If you 
don't think there should be any modification, just hum against the 
modification.
--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 25 Apr 2009 21:19:05 -0500

No, that is totally inconsistent with what occurs in other groups, Geopriv being a prime example.

If there is no consensus at the meeting for a change, then the change is not to be made until the consensus is reached.

There needs to be a hum on this list as to whether any change is required at all.

If that hum is in favour of a change, then we can hum on the wording.

At this point I would like the chairs and ADs to comment on this.

Cheers
James

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 26 Apr 2009 08:11:01 -0700

The document in question does not have an applicability statement section.  Looking at the diffs from -08, the only text change that would appear to qualify is the following:
   This document focuses on the case in which all three steps in the
   emergency calling process -- location configuration, call routing,
   and call placement - can be and are performed by the calling
   endpoint, with the endpoint's Access Service Provider supporting the
   process by providing location information.  Calls in this case may be
   routed via an application-layer Communications Service Provider
   (e.g., a Voice Service Provider), but need not be.  The underlying
   protocols can also be used to support other models in which parts of
   the process are delegated to the Communications Service Provider.
   This document does not address in detail either these models or
   interoperability issues between them and the model described here.
While this statement is accurate as far as it goes,  in practice it substantially reduces the applicability of the document. 

That's a pretty major change -- so as a matter of process, it would probably have been better to obtain consensus *before* inserting this text. 

However, I do think that the proposed text fairly describes the architectural assumptions.  The question of how widely those assumptions hold will ultimately be determined in the  marketplace, not in the IETF. 

Date: Fri, 24 Apr 2009 14:23:48 -0400
From: [email-masked]
To: [email-masked]
Subject: [Ecrit] PhoneBCP

PhoneBCP

At the San Francisco meeting and ensuing list threads, the last issue around PhoneBCP was whether or not to include an ‘applicability statement’.  The hum during the meeting was inconclusive.  The draft editor has included text in this latest version in an attempt to compromise on this issue.

Thanks,

Marc, Hannes, & Roger

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 27 Apr 2009 10:07:44 +0200

I hum for the applicability statement.

I would also note that if we go the way you want to go, we have a hum for whether the document is acceptable without this. Having had the discussion to agree an applicability statement, I warn that I will hum against a document without it.

You need some form of consensus to get the document out of the WG.

regards

Keith 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Winterbottom, James
> Sent: Saturday, April 25, 2009 10:58 PM
> To: Brian Rosen; Richard Barnes; Ted Hardie
> Cc: ECRIT
> My point is that because there was no consensus at the IETF, 
> in fact the document should have remained unchanged.
> 
> I want a hum first as to whether the applicability statement 
> is required at all. As I have stated more then one I don't 
> believe it is, and no reasonable argument has yet been 
> provided to changed my mind.
> 
> Actually, I think the list hum is whether or not you accept 
> the change, as proposed, and consider the document ready to 
> send to the IESG.  It's kind of a combination of is an 
> applicability statement acceptable, and is this particular 
> one acceptable (and are you otherwise okay with the document, 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Winterbottom, James
> ISTM that this would be an appropriate course of action given 
> the lack on consensus at the actually meeting.
> 
> 
> Cheers
> James
> 
> 
> The hum during the meeting was inconclusive.  The draft 
> editor has included text in this latest version in an attempt 
> to compromise on this issue.
> >>
> >> Please review this version and respond by Friday May 1 to 
> the list as 
> >> to

---

From: Marc Linsner <[email-masked]>
Date: Mon, 27 Apr 2009 08:22:49 -0400

James,

This is a consolidated hum.

If you don't agree that we need an applicability statement, hum against it.

If you agree that we need an applicability statement, but don't like the
current text, hum against it.

If you agree with the statement as written, hum for it.

If consensus is against the statement, it will be taken out of the draft.

-Marc- 

On 4/25/09 10:19 PM, "Winterbottom, James" <[email-masked]>
wrote:

> If there is no consensus at the meeting for a change, then the change is not
> to be made until the consensus is reached.
> 
>> I want a hum first as to whether the applicability statement is required at
>> all. As I have stated more then one I don't believe it is, and no reasonable
>> argument has yet been provided to changed my mind.
>>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 27 Apr 2009 15:34:52 +0300

I hum against the applicability statement. I cannot see why we need one.

Ciao
Hannes

>On Behalf Of ext Marc Linsner
>Sent: 27 April, 2009 15:23
>To: Winterbottom, James
>Cc: ECRIT
>If you agree that we need an applicability statement, but 
>don't like the current text, hum against it.
>
>> If there is no consensus at the meeting for a change, then 
>the change 
>> is not to be made until the consensus is reached.
>> 
>>> My point is that because there was no consensus at the 
>IETF, in fact 
>>> the document should have remained unchanged.
>>> 
>>> I want a hum first as to whether the applicability statement is 
>>> required at all. As I have stated more then one I don't believe it 
>>> is, and no reasonable argument has yet been provided to 
>changed my mind.
>>> 
>>> Actually, I think the list hum is whether or not you accept the 
>>> change, as proposed, and consider the document ready to send to the 
>>> IESG.  It's kind of a combination of is an applicability statement 
>>> acceptable, and is this particular one acceptable (and are you 
>>> otherwise okay with the document, which is implied in 
>Marc's message, but I think important to recognize).
>>> 
>>> Brian
>>> 
>>> 
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Winterbottom, James
>>> ISTM that this would be an appropriate course of action given the 
>>> lack on consensus at the actually meeting.
>>> 
>>> 
>>> Cheers
>>> James
>>> 
>>> 
><http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-09.txt
>>> >http:/ 
>>> The hum during the meeting was inconclusive.  The draft editor has 
>>> included text in this latest version in an attempt to 
>the list 
>>>>> as to
>>> This message is for the designated recipient only and may contain 
>>> privileged, proprietary, or otherwise private information.
>>> immediately and delete the original.  Any unauthorized use of this 
>>> email is prohibited.
>>> 
>---------------------------------------------------------------------
>>> --------
>>> -------------------
>>> This message is for the designated recipient only and may contain 
>>> privileged, proprietary, or otherwise private information.
>>> immediately and delete the original.  Any unauthorized use of this 
>>> email is prohibited.
>>> 
>---------------------------------------------------------------------
>>> --------
>>> -------------------
>>> [mf2]
>>> 
>>> 
>> 
>> 
>> 
>----------------------------------------------------------------------
>> --------
>> ------------------
>> This message is for the designated recipient only and may contain 
>> privileged, proprietary, or otherwise private information.
>immediately 
>> and delete the original.  Any unauthorized use of this email is 
>> prohibited.
>> 
>----------------------------------------------------------------------
>> --------
>> ------------------
>> [mf2]
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 27 Apr 2009 09:42:55 -0400

+1

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Apr 2009 17:25:22 -0700

I hum for the text, which doesn't constrain the use of the protocols, 
but merely describes the assumptions under which it works.  As such, 
it is useful and helpful.  Even for those who think the assumptions 
are obvious, it does no harm to state them.

We had a lot of debate on this in SFO, and the text in this version 
was discussed on the mailing list in the days during and following 
the meeting.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
One's need for loneliness is not satisfied if one sits at a table alone.
There must be empty chairs as well.                        --Karl Kraus

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 27 Apr 2009 19:27:21 -0500

I am sorry that that time was spent debating the text, since procedure
would dictate that before text be considered consensus on whether it is
needed must be reached. Since the former did not occur, the latter is
kind of moot.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randall Gellens
Sent: Tuesday, 28 April 2009 10:25 AM
To: ECRIT
Subject: Re: [Ecrit] PhoneBCP

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Apr 2009 00:42:06 -0400

Ok, we clearly need to revise the text, since that's a pretty serious 
misunderstanding.  The text doesn't constrain the use of the protocols 
at all -- in fact it says "they underlying protocols can also be used to 
support other models in which parts of the process are delegated to the 
Communications Service Provider".  For example, in the 3GPP model, an 
E-CSCF could do everything on behalf of the endpoint, but could still 
use SIP for calling, LoST for PSAP URI discovery, and HELD for location 
retreival.

The point of the current text is just that those scenarios aren't 
discussed in this draft, not that the overall model doesn't apply to 
those scenarios.

--Richard

Randall Gellens wrote:
> but merely describes the assumptions under which it works.  As such, it 
> is useful and helpful.  Even for those who think the assumptions are 
> obvious, it does no harm to state them.
> 
> We had a lot of debate on this in SFO, and the text in this version was 
> discussed on the mailing list in the days during and following the meeting.

---

From: "Edge, Stephen" <[email-masked]>
Date: Mon, 27 Apr 2009 22:42:00 -0700

All

The statement "The underlying protocols can also be used to support other models in which parts of the process are delegated to the Communications Service Provider" seems applicable to the 3GPP/3GPP2 solution - e.g. because it does not say that all the protocols must be used, nor does it say that other protocols must not be used, but is consistent with a selection of some subset. (That is also applicable to the preferred Ecrit solution which allows choice of LCP in the network.) 

So I support the current applicability statement and, based on the very long discussion that it took to get to that, foresee a possibly equally long discussion ahead if this issue has to be restarted.

Kind Regards

Stephen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Monday, April 27, 2009 9:42 PM
To: Gellens, Randall
Cc: ECRIT
Subject: Re: [Ecrit] PhoneBCP

--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 28 Apr 2009 01:05:30 -0500

The discussion for the need of an applicability statement was NEVER
resolved, as NO consensus was reached. So no applicability statement
should ever have been added to the document.

A number of people decided to construct an applicability statement and
have attempted to now have it ratified without the need for an
applicability statement being clearly demonstrated or agreed to by the
working group.

If, and only if, a consensus to include an applicability statement is
reached should the wording included by Brian be looked at. I still
vehemently oppose the inclusion of any applicability statement and I
don't want to consider any wording until a consensus is reached on us
requiring an applicability statement.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Edge, Stephen
Sent: Tuesday, 28 April 2009 3:42 PM
To: Richard Barnes; Gellens, Randall; ECRIT
Subject: Re: [Ecrit] PhoneBCP

All

The statement "The underlying protocols can also be used to support
other models in which parts of the process are delegated to the
Communications Service Provider" seems applicable to the 3GPP/3GPP2
solution - e.g. because it does not say that all the protocols must be
used, nor does it say that other protocols must not be used, but is
consistent with a selection of some subset. (That is also applicable to
the preferred Ecrit solution which allows choice of LCP in the network.)

So I support the current applicability statement and, based on the very
long discussion that it took to get to that, foresee a possibly equally
long discussion ahead if this issue has to be restarted.

Kind Regards

Stephen
-----Original Message-----
Of Richard Barnes

--Richard

> but merely describes the assumptions under which it works.  As such,
it 
> We had a lot of debate on this in SFO, and the text in this version
was

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 28 Apr 2009 02:12:34 -0500

+1 - and, quite particularly, on the basis that it isn't an
"applicability statement" it's a statement that effectively says that
there are some domains where the framework is applicable but there'll be
aspects to the domain that aren't specifically described by the
framework and that... well... you'll just have to think about.

Since this is a truism, its presence is a tautology and unnecessary.

Having said all that - and given the motives driving the creation of
this "sound bite" are transparent, I'd rather let the people playing
politics have their way with the document since, clearly, the threat is
that they'll just stonewall it indefinitely otherwise. Hopefully common
sense will out in time regardless.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Schulzrinne
Sent: Monday, 27 April 2009 11:43 PM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: ECRIT
Subject: Re: [Ecrit] PhoneBCP

+1

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 28 Apr 2009 09:59:30 -0400

I agree with this view, except I would say the text describes the
assumptions under which the BCP was created, rather than the assumptions
under which it works.
As such, I really wish people would stop referring to the proposed text
as an "applicability statement". 
It isn't. 
The proposed text has no title or header within the document (other than
being part of "Introduction"), and needs to be read without any
preconceived notion about what the motives were behind the text. That is
how most people will be reading the text.

As such, I continue to support the inclusion of the text. It does no
harm. It may be useful.
Some of the people humming against this are exactly the people who I
thought would want to try to get this document done and finished. I'm
surprised that they are prolonging our combined agony.
Since the text is *not* an applicability statement (no matter that our
illustrious chair may have called it such), and it does no harm, can't
we please just let the text be and move on?
Please? Pretty please?
Barbara

> Sent: Monday, April 27, 2009 8:25 PM
> To: ECRIT

*****

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Apr 2009 11:14:04 -0400

Barbara,

with all due respect, the delay is due to the people insisting that  
the text be added at the last minute. It is clear that the text has  
ulterior motives to restrict the applicability of the document. This  
should be patently obvious from the origin of this whole text-adding  
effort.

Henning

On Apr 28, 2009, at 9:59 AM, Stark, Barbara wrote:

>> Behalf
> The information transmitted is intended only for the person or  
> entity to which it is addressed and may contain confidential,  
> proprietary, and/or privileged material. Any review, retransmission,  
> dissemination or other use of, or taking of any action in reliance  
> upon this information by persons or entities other than the intended  
> recipient is prohibited. If you received this in error, please  
> contact the sender and delete the material from all computers. GA623
>
>

---

From: Randall Gellens <[email-masked]>
Date: Tue, 28 Apr 2009 09:52:27 -0700

At 12:42 AM -0400 4/28/09, Richard Barnes wrote:

>  Ok, we clearly need to revise the text, since that's a pretty 
> serious misunderstanding.  The text doesn't constrain the use of 
> the protocols at all

I think the text as written is pretty clear that there is no constraint.

>  -- in fact it says "they underlying protocols can also be used to 
> support other models in which parts of the process are delegated to 
> the Communications Service Provider".

Yes, exactly correct.

> discussed in this draft, not that the overall model doesn't apply 
> to those scenarios.

Yes, exactly.  The text merely clarifies what the draft discusses.

>  Randall Gellens wrote:
>>  I hum for the text, which doesn't constrain the use of the 
>> protocols, but merely describes the assumptions under which it 
>> works.  As such, it is useful and helpful.  Even for those who 
>> think the assumptions are obvious, it does no harm to state them.
>>
>>  We had a lot of debate on this in SFO, and the text in this 
>> version was discussed on the mailing list in the days during and 
>> following the meeting.

-------------- Randomly selected tag: ---------------
I love the smell of excessive quoting in the morning.
                                      --Steve Dorner

---

From: Randall Gellens <[email-masked]>
Date: Tue, 28 Apr 2009 09:56:43 -0700

At 11:14 AM -0400 4/28/09, Henning Schulzrinne wrote:

>  It is clear that the text has ulterior motives to restrict the 
> applicability of the document.

 From my view, the text does not restrict the applicability, nor is 
there a desire to do so.  The text does clarify the assumptions of 
the rest of the text in the document, which I think is helpful.

-------------- Randomly selected tag: ---------------
The solution to a problem changes the nature of the problem.

---

From: "Edge, Stephen" <[email-masked]>
Date: Tue, 28 Apr 2009 10:29:59 -0700

All

I would have thought that motivation should be irrelevant. There are a lot of motives at work here. Should we assume that the document was originally written with only the purest and most altruistic motives (e.g. no thought of business or academic interest at stake)?

The issue is whether the current statement serves a useful purpose in conveying the possibility (well known to be true) of alternative solutions not fully aligned with the current drafts. Nothing in the statement implies that the current drafts are necessarily deficient or that alternative solutions must necessarily be used for some scenarios (even though they optionally can be).

Kind Regards

Stephen

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Apr 2009 13:44:34 -0400

I still think we're disagreeing; let me try to clarify why.  I was wrong 
to focus on the word "constrain" in your message; the real issue is 
"assumptions".

This document doesn't have any "assumptions under which it works" other 
than those that need to be true for any emergency calling system, namely 
that
(1) the endpoint can be located,
(2) there's a location-to-service mapping system.
(3) relevant entities communicate over IP
These assumptions need to be true in whatever IP network you want to do 
emergency calling -- in the Internet, in a 3G network, in a WiMAX 
network, etc.  The IMS emergency calling architecture also makes these 
assumptions.

As a corollary, the solution described in this document works in any IP 
network where the above assumptions hold (including cellular networks as 
a case in point).

So one should not draw from the additional text in the latest draft that 
there are assumptions underlying the solution in this document that 
would prevent its applicability in some IP networks.  If that's how it 
is being interpreted, then we need to revise it again.

--Richard

Randall Gellens wrote:
>> at all
>>> works.  As such, it is useful and helpful.  Even for those who think 
>>> the assumptions are obvious, it does no harm to state them.
>>>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Apr 2009 11:55:48 -0700

> is being interpreted, then we need to revise it again.

In the consensus call, the paragraph in question was described as an "applicability statement".   If you are saying that the intent of the paragraph was not to provide an indication of the applicability of the solution described in the document, then we have an issue that cannot be solved merely by revising the text.   Rather, we need to figure out what the purpose of the statement is, and what problem it is trying to solve.  RFC 2026 Section 3.2 describes the purpose of applicability statements as follows:
3.2  Applicability Statement (AS)

   An Applicability Statement specifies how, and under what
   circumstances, one or more TSs may be applied to support a particular
   Internet capability.  An AS may specify uses for TSs that are not
   Internet Standards, as discussed in Section 7.

   An AS identifies the relevant TSs and the specific way in which they
   are to be combined, and may also specify particular values or ranges
   of TS parameters or subfunctions of a TS protocol that must be
   implemented.  An AS also specifies the circumstances in which the use
   of a particular TS is required, recommended, or elective (see section
   3.3).

   An AS may describe particular methods of using a TS in a restricted
   "domain of applicability", such as Internet routers, terminal
   servers, Internet systems that interface to Ethernets, or datagram-
   based database servers.

   The broadest type of AS is a comprehensive conformance specification,
   commonly called a "requirements document", for a particular class of
   Internet systems, such as Internet routers or Internet hosts.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Apr 2009 15:25:57 -0400

If the proposal is for an Applicability Statement in the sense of RFC 
2026, then I certainly vote against the proposition, for the reasons 
listed in the prior email.

Not to speak for the chairs, but my impression is that the intent was 
not to take such a limited definition, but rather to discuss adding some 
text to address concerns that had been raised.

Could the chairs clarify?

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Apr 2009 15:33:19 -0400

But the concerns were concerns about applicability, so this is an  
applicability statement, regardless of what labels get attached to the  
text to cover up this fact.

It is clear that the text is not necessary to implement the goals of  
the draft and it does not fix any technical problems or clarify any of  
the issues addressed in the document. So this is clearly meant to be  
lawyer-text of some form. Maybe we should leave writing of such text  
to lawyers...

Henning

On Apr 28, 2009, at 3:25 PM, Richard Barnes wrote:

> If the proposal is for an Applicability Statement in the sense of  
> RFC 2026, then I certainly vote against the proposition, for the  
> reasons listed in the prior email.
>
> Not to speak for the chairs, but my impression is that the intent  
> was not to take such a limited definition, but rather to discuss  
> adding some text to address concerns that had been raised.
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Apr 2009 16:06:36 -0400

Stephen,

As was noted in the meeting, it is *always* possible that there are 
alternative solutions out there when you're talking about the Internet. 
  TCP vs. UDP, POP vs. IMAP, FTP vs. HTTP vs. BitTorrent, SIMPLE vs. 
XMPP, SASL vs. TLS, S/MIME vs. OpenPGP.  None of the many RFCs out there 
have explicit statements that somebody else might do it differently 
because it's obvious that they can.

So I don't really think conveying the possibility of other 
implementations is actually useful at all, technically speaking.

That means that the only real purpose of such a statement is rhetorical, 
and as we've seen in a few messages here, some people misconstrue the 
rhetoric to mean that this system has constrained applicability.  Given 
that, I'd rather leave it off unless we can avoid that impression.

--Richard

---

From: Randall Gellens <[email-masked]>
Date: Tue, 28 Apr 2009 14:08:44 -0700

At 11:55 AM -0700 4/28/09, Bernard Aboba wrote:

Rather, we need to figure out what the
purpose of the statement is, and what problem it is trying to
solve.

The phonebcp and framework documents are unusual in that they
make very broad claims to cover all emergency calls over IP.
Since there are other mechanisms that are likely to be used in some
environments,  it's important to clarify that while these
documents describe a solution they do not describe these other
environments nor interoperbility with solutions used in those
environments.

Per the definition of an applicability statement, all of phonebcp
can be considered to be one.

RFC 2026 Section 3.2 describes the
purpose of applicability statements as follows:

3.2  Applicability Statement
(AS)

An Applicability Statement specifies how, and under
what

circumstances, one or more TSs may be applied to support
a particular

Internet capability.  An AS may specify uses for TSs
that are not

An AS identifies the relevant TSs and the specific way in
which they

are to be combined, and may also specify particular
values or ranges

of TS parameters or subfunctions of a TS protocol that
must be

implemented.  An AS also specifies the circumstances
in which the use

of a particular TS is required, recommended, or elective
(see section

3.3).

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

Television is simply automated day-dreaming.

--Lee Lovinger, _Quote_, July 30, 1967

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Apr 2009 17:51:19 -0400

> The phonebcp and framework documents are unusual in that they make very broad 
> claims to cover all emergency calls over IP.  

I don't think that's true.  From the Abstract and 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.
...
This document focuses on how devices using the Internet can place 
emergency calls and how PSAPs can handle Internet multimedia emergency 
calls natively.
"
Note the use of the word "can" (and we can switch the "are" in the 
abstract to "can" if that makes things better).  Could you provide a 
pointer to the text that leads you to a different interpretation?

> Per the definition of an applicability statement, all of phonebcp can be 
> considered to be one.

Technically speaking, that seems to be accurate, but irrelevant to the 
current discussion.

--Richard

> 
>>  RFC 2026 Section 3.2 describes the purpose of applicability statements as 
>> follows:

---

From: Randall Gellens <[email-masked]>
Date: Tue, 28 Apr 2009 17:12:53 -0700

At 1:44 PM -0400 4/28/09, Richard Barnes wrote:

>  So one should not draw from the additional text in the latest draft 
> that there are assumptions underlying the solution in this document 
> that would prevent its applicability in some IP networks.  If 
> that's how it is being interpreted, then we need to revise it again.

I don't think anyone who wants this text included is interpreting it 
to say anything about whether the solution could be used in any 
particular environment.

There is a separate discussion regarding whether the solution as 
written makes sense for cell phone environments, for example the 
mobile-centric aspects such as determining location and routes and 
the requirement for handsets to support protocols that are not used 
in their environments, but that's an unrelated discussion and the 
text clearly says nothing about this.

The text is a compromise that clarifies the documents without in any 
way limiting them.  I think the text helps the understanding of 
readers of the documents who have not been immersed in the protocols 
for the past few years.  I can't see how the text will help or hurt 
anyone's marketing efforts, so I think that is a red herring.  Are 
there really people who think that this clarifying text will impede 
their ability to market some product?  Or that some standards body 
would adopt this solution wholeheartedly if only this clarifying text 
is deleted?  Neither idea seems plausible to me.

-------------- Randomly selected tag: ---------------
Time is nature's way of making sure that everything doesn't
happen on schedule.

---

From: <[email-masked]>
Date: Wed, 29 Apr 2009 03:41:42 +0200

Hi Richard,

  >On Behalf Of ext Richard Barnes
  >Sent: Tuesday, April 28, 2009 2:51 PM
  >To: Randall Gellens
  >Cc: [email-masked]
  >> The phonebcp and framework documents are unusual in that they make 
  >> very broad claims to cover all emergency calls over IP.
  >
  >This document describes how all of those component parts are 
  >used to support emergency calls from citizens and visitors 
  >to authorities.
  >...
  >This document focuses on how devices using the Internet can 
  >place emergency calls and how PSAPs can handle Internet 
  >multimedia emergency calls natively.
  >"

Which version did you quote from? The Abstract of version -09 says: 

"The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks.  This memo describes best current
                                   ^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ practice on how devices, networks and services should use such standards to make emergency 
^^^^^^^^^^^^^^^^^^^^^^^
calls."

And I think here's the problem, as the text is too generic. IMS is also an "IP network" and has different "best current practices".

I think all these differences could be resolved if the Intended Status of the document would be changed to Proposed Standard (instead of BCP), its title to "Requirements for Internet based Emergency Calls" and the Abstract to "The IETF efforts are targeted at
   standardizing various aspects of placing emergency calls over the Internet.  This memo describes requirements for devices, networks and services that should be supported in order to make emergency calls over the Internet".

The above minimal changes should be enough to differentiate the scope of this document from the 3GPP solution, as 3GPP calls their solution "IMS Emergency Sessions", thus there would not be a need for the controversial applicability statement.

- Gabor

  >Note the use of the word "can" (and we can switch the "are" 
  >in the abstract to "can" if that makes things better).  
  >Could you provide a pointer to the text that leads you to a 
  >different interpretation?
  >
  >> Per the definition of an applicability statement, all of 
  >phonebcp can 
  >> be considered to be one.
  >
  >Technically speaking, that seems to be accurate, but 
  >irrelevant to the current discussion.
  >
  >--Richard
  >
  >
  >
  >
  >
  >>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Apr 2009 19:31:57 -0700

>Per the definition of an applicability statement, all of phonebcp can be considered to be one.

I think that is correct with respect to the "how" -- the document is all about how TSs may be applied. 

I'm not so sure about the "under what circumstances" part of it, though.  That seems to be the point under discussion.  

BTW, it is not only the cellular community that may have a point of view on that issue.  IEEE 802 has recently debated an Emergency Services PAR (see http://www.ieee802.org/21/email21/msg02957.html) that has been somewhat controversial.

---

From: [email-masked]
Date: Wed, 29 Apr 2009 11:12:31 +0100

> Richard Barnes <[email-masked]> 

I would be much happier if this said "may be used" rather then "are used".

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Randall Gellens <[email-masked]>
Date: Wed, 29 Apr 2009 11:38:27 -0700

There have been a couple of people asserting that the text in the 
document was added without consensus.  While it is certainly the 
chairs' prerogative to call for consensus on this point, there was a 
lot of discussion on the list five weeks ago.  It certainly had 
enough discussion then to warrant inclusion in a document version for 
discussion.  In fact, I think the current text is basically Richard's 
take on a compromise that would get us past the deadlock we seem to 
be revisiting.

-------------- Randomly selected tag: ---------------
Premature optimization is the root of all evil
                              --C. A. R. Hoare

---

From: Marc Linsner <[email-masked]>
Date: Wed, 29 Apr 2009 14:52:51 -0400

All,

*Remember, this hum closes tomorrow (Friday, May 1).

As I stated in an email on Monday.

"

"

I use the term 'applicability statement' as that was the term that
originally started this discussion.  It in no way implies the chairs
desires.  Changing the term now would cause an even bigger discussion, IMO.
My hope is that everyone followed the discussion and makes their choice
heard via this call for a hum.  Thank you to those that have already
expressed their choice.

We still have the old version of the draft.  If consensus fails as outlined
above, we'll bring back the old version.

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Wed, 29 Apr 2009 14:59:39 -0400

[chair hat off]

+1

-Marc-

---

From: Randall Gellens <[email-masked]>
Date: Wed, 29 Apr 2009 12:15:30 -0700

Using the term applicability statement only confuses things, since 
this text is not an applicability statement and does not limit the 
applicability of the solution.

We did have discussion in SFO on the need for an applicability 
statement, without clear consensus in the meeting.  We had some 
people who supported one, and some who objected to one.  We then had 
a compromise proposal on the list for text.  After much discussion, 
the text was added, but the text is not an applicability statement, 
and calling it such now only muddies things.

-------------- Randomly selected tag: ---------------
It is by the fortune of God that, in this country, we have three
benefits: freedom of speech, freedom of thought, and the wisdom never
to use either.                                           --Mark Twain

---

From: Byron Smith <[email-masked]>
Date: Wed, 29 Apr 2009 15:52:45 -0400

Add my hum against the statement.

Byron

Byron L. Smith
INdigital Telecom

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 29 Apr 2009 15:47:16 -0500

+1

James

-----Original Message-----
From: [email-masked] on behalf of Marc Linsner
Sent: Wed 4/29/2009 1:59 PM
To: ECRIT
Subject: Re: [Ecrit] PhoneBCP
 
[chair hat off]

+1

-Marc-

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 29 Apr 2009 16:22:11 -0500

Marc

I do not believe the applicability statement is necessary, regardless 
of how well or poor it is written.  The scope of this effort is clear 
- in the IETF community - and this is not an industry view of 
applicability, which is how I believe some are reacting as if it were.

Were this applicability to remain, then every IETF ID and RFC would 
require one, as I know of no situation in which any communication is 
ever entirely comprised of IETF technologies (i.e., every 
communication has a layer 2 - which the IETF has no charge of - or is 
contained entirely within the same physical entity, in which it is 
rare that maintaining standards based protocols are necessary). There 
may be corner cases that I'm not thinking about - but I believe this 
is generally true.

Therefore, I hum *no* to add this applicability statement.

James

At 01:23 PM 4/24/2009, Marc Linsner wrote:
>At the San Francisco meeting and ensuing list threads, the last 
>issue around PhoneBCP was whether or not to include an 
>'applicability statement'.  The hum during the meeting was 
>inconclusive.  The draft editor has included text in this latest 
>version in an attempt to compromise on this issue.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 29 Apr 2009 18:23:21 -0500

Having been the victim of "applicability statement" attacks in the past, let's just say I'm somewhat prejudiced against them.

I also think that we don't need to say what even the dullest of our audience should be able to work out for themselves.

No applicability statement, or whatever Randy thinks this is.

> Of James M. Polk
> Sent: Thursday, 30 April 2009 7:22 AM
> To: Marc Linsner; ECRIT
> ><http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-
> 09.txt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-
> 09.txt
> >
> >

---

From: "Edge, Stephen" <[email-masked]>
Date: Wed, 29 Apr 2009 16:23:22 -0700

Richard and all others

I wonder if those now humming against this statement (and who were all strangely silent 5 weeks ago) would support any kind of statement concerning applicability and scope. Or is it the case that the solution supported by both drafts is considered to apply to all devices, ANs and VSPs that provide some form of internet access. If so, is it irrelevant whether the solution is actually suitable for a particular type of AN or VSP (e.g. cellular AN, IMS based VSP)? For example, is it irrelevant whether significant additional support from an AN or VSP to which the solution might be applied would be needed in order to access legacy PSAPs, handoff to the circuit domain, authenticate the caller and provide access to non-subscribed users? Is it further irrelevant whether the solution would even work for a particular device, AN or VSP without substantial changes to the latter? In other words, is the solution now considered so sacrosanct that any adaptation must come from the rest of the infrastructure and not from the solution itself in the case of any mismatch? If the consensus answers to these questions are all yes, then I would have to agree that including the currently disputed statement or anything of a similar nature would be inconsistent and unnecessary. Of course, the representatives of the potentially affected portions of infrastructure should be forgiven for disagreeing with the basic premise - and may be expected to offer some type of protest!

Kind Regards

Stephen
-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Tuesday, April 28, 2009 1:07 PM
To: Edge, Stephen
Cc: Gellens, Randall; Henning Schulzrinne; Stark, Barbara; ECRIT
Subject: Re: [Ecrit] PhoneBCP

Stephen,

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 29 Apr 2009 19:12:25 -0500

Hi Stephen,

I'm convinced that the ECRIT architecture is the only solution that will work for ALL forms of Internet access.

I then offer you an alternative to the "applicability statement" you request:

  Where you believe that the ECRIT architecture does not apply, state why.  Include also a description of why interworking with such an architecture is not necessary.

The great thing about this is that you can do this in the forum of your choice.  You don't have to deal with the recalcitrant bunch at the IETF.  In fact, I'd encourage you to consider that approach.

--Martin

> Sent: Thursday, 30 April 2009 9:23 AM
> To: Richard Barnes; Gellens, Randall; Henning Schulzrinne; Stark,
> Barbara; ECRIT
> I wonder if those now humming against this statement (and who were all
> strangely silent 5 weeks ago) would support any kind of statement
> concerning applicability and scope. Or is it the case that the solution
> supported by both drafts is considered to apply to all devices, ANs and
> VSPs that provide some form of internet access. If so, is it irrelevant
> whether the solution is actually suitable for a particular type of AN
> or VSP (e.g. cellular AN, IMS based VSP)? For example, is it irrelevant
> whether significant additional support from an AN or VSP to which the
> solution might be applied would be needed in order to access legacy
> PSAPs, handoff to the circuit domain, authenticate the caller and
> provide access to non-subscribed users? Is it further irrelevant
> whether the solution would even work for a particular device, AN or VSP
> without substantial changes to the latter? In other words, is the
> solution now considered so sacrosanct that any adaptation must come
> from the rest of the
>   infrastructure and not from the solution itself in the case of any
> mismatch? If the consensus answers to these questions are all yes, then
> I would have to agree that including the currently disputed statement
> or anything of a similar nature would be inconsistent and unnecessary.
> Of course, the representatives of the potentially affected portions of
> infrastructure should be forgiven for disagreeing with the basic
> premise - and may be expected to offer some type of protest!
> 
> Kind Regards
> 
> Stephen
> > I would have thought that motivation should be irrelevant. There are
> a lot of motives at work here. Should we assume that the document was
> originally written with only the purest and most altruistic motives
> (e.g. no thought of business or academic interest at stake)?
> >
> > The issue is whether the current statement serves a useful purpose in
> conveying the possibility (well known to be true) of alternative
> solutions not fully aligned with the current drafts. Nothing in the
> statement implies that the current drafts are necessarily deficient or
> that alternative solutions must necessarily be used for some scenarios
> (even though they optionally can be).
> >
> > Kind Regards
> >
> > Stephen
> Behalf Of Randall Gellens

---

From: "Edge, Stephen" <[email-masked]>
Date: Wed, 29 Apr 2009 18:20:53 -0700

Martin

You are one of those humming against the current statement. You seemingly don't believe that any statement of applicability or scope is needed (or am I wrong?). Yet you have ducked my simple questions which are clearly relevant in that context.

I would appreciate some answers to those questions - perhaps from others.

Kind Regards

Stephen
-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Wednesday, April 29, 2009 5:12 PM
To: Edge, Stephen; Richard Barnes; Gellens, Randall; Henning Schulzrinne; Stark, Barbara; ECRIT
Subject: RE: [Ecrit] PhoneBCP

Hi Stephen,

--Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 29 Apr 2009 22:49:01 -0500

Stephen,

The consensus call was requested so that we could close this issue.  What you propose only adds delays.  Your questions are hardly "simple".  On the whole, your questions are either not of interest to this organisation (by definition), or conclusions have already been arrived at to the satisfaction of most.

Asking for an applicability statement is a nice, innocuous sounding request.  It's expedient because you can label opposition as "unreasonable".  Label me thus as you wish.  I've seen applicability statements abused too many times before.  I prefer now to let the audience decide what a specification is good for, because that's usually pretty clear.  Applicability statements only artificially constrain scope.

For interest, however, since you asked for answers, I'll humour you...

Q: "If so, is it irrelevant whether the solution is actually suitable for a particular type of AN or VSP (e.g. cellular AN, IMS based VSP)? "

A: Mu (Yes).

This is beyond questions of "suitability".  ECRIT will work for any AN, Device, or VSP that follows the (quite frankly, simple) rules.  This might not be an "easy" solution, or a JSTD-036-B lookalike, or whatever you'd like it to be.  No superior solution has been offered that meets all the requirements.

Of course, the solution has to be deployable.  But that's never been the concern, has it?

I have every confidence that ECRIT could be deployed in a 3GPP access network.  It might even work already in some networks, as long as no steps have already been taken to prevent it.  Give me MO-LR and an IP connection and I'm good to go.

However, that doesn't play well with visitors to the network.  Unless you maintain the illusion that you are able to control all devices that enter your network, you will need to support the mechanisms that they expect.  That is, as long as a network provides Internet access, ECRIT support is needed to provide emergency calling.

BTW, a LIS isn't really very hard to deploy when you already have location infrastructure, it looks a little like a protocol translator.  

There's a similar story for the voice service.  Location-based call routing is not especially complex to implement.  You can make it more complicated, but only if you'd prefer it that way.

Q: "For example, is it irrelevant whether significant additional support from an AN or VSP to which the solution might be applied would be needed in order to access legacy PSAPs, handoff to the circuit domain, authenticate the caller and provide access to non-subscribed users?"

A (legacy PSAPs): Yes.

Of course, the question of how to deal with legacy PSAPs is one of interest, but it's a not a problem that has been ignored.  Read NENA i2 for a description on how this is done.  (Oh yeah, and there is a good case of an applicability statement being abused - i2 is supposedly only applicable for non-mobile devices - which is wholly false.)

A (circuit handoff): Yes.

Again, nothing stops you from working this one out if you feel that way inclined.  The IETF does tend to limit its concerns to the Internet though, so I wouldn't expect to see any solution to that problem here.  It's a problem that could still be solved in a compatible way.

The basic paradigm is still applicable: device acquires location, device determines destination PSAP, device makes call, with the caveat that another entity can act on behalf of the device given sufficient constraints.

A (caller authentication and unauthenticated access): Mu (Yes).

Obviously, there are concerns to resolve.  Which did sort of authentication were you referring to?  AN or VSP?  Or are we authenticating users to PSAPs?  As far as the framework is concerned, these are not important questions - policy (legislation, terms of service for AN and VSP) determine what need, if any authentication is required before access is granted.

Q: "Is it further irrelevant whether the solution would even work for a particular device, AN or VSP without substantial changes to the latter? In other words, is the solution now considered so sacrosanct that any adaptation must come from the rest of the infrastructure and not from the solution itself in the case of any mismatch?"

A: Yes.

That is the way you have to do these things.  We pick a solution, and then everyone lives with it.  We do our best to pick a good solution, but there is no pretence of infallibility, or any assumption that a solution is "sacrosanct".  It's not like we are expected to produce a perfect solution on the first attempt.  The community isn't going to hold us to that impossible standard.  If there is a problem in the document, we'll just have to fix it.

I don't see that there is a mismatch, but then you continue to imply that there is.  ECRIT does something that has not been attempted before: emergency services for the entire Internet.  You can't reasonably expect there to be an existing solution to the problem.  That means changes to existing networks if they want to be part of the solution.

Since I've answered yes to all the relevant questions, I conclude that the applicability statement is "inconsistent and unnecessary".  The reasons I previously stated still equally apply.

--Martin

> From: Edge, Stephen [mailto:[email-masked]]
> Sent: Thursday, 30 April 2009 11:21 AM
> To: Thomson, Martin; Richard Barnes; Gellens, Randall; Henning
> Schulzrinne; Stark, Barbara; ECRIT
> You are one of those humming against the current statement. You
> seemingly don't believe that any statement of applicability or scope is
> needed (or am I wrong?). Yet you have ducked my simple questions which
> are clearly relevant in that context.
> 
> I'm convinced that the ECRIT architecture is the only solution that
> will work for ALL forms of Internet access.
> 
>   Where you believe that the ECRIT architecture does not apply, state
> why.  Include also a description of why interworking with such an
> architecture is not necessary.
> 
> The great thing about this is that you can do this in the forum of your
> choice.  You don't have to deal with the recalcitrant bunch at the
> IETF.  In fact, I'd encourage you to consider that approach.
> 
> --Martin
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 29 Apr 2009 22:59:35 -0500

Stephen,

As someone that has been vocal on this topic all along I will respond.

Would you agree that this solution does allow the ultimate destination
of the PSAP being reached using legacy TDM trunks? 
If you want to take the debate offline I can clearly show to you the
solution does, and as preparation please take a look at some of the NENA
i3 and i2 work.

So this makes quite a lot of your argument below irrelevant.

You have continually argued that there is something special about IMS
and cellular despite continual evidence being presented that there is
not. Voice is not special when it comes to IP traffic, it is just
another data stream. What you are doing is coming here and saying that
3GPP are introducing a whole bunch of complex machinations to maintain a
bundling of access and service, so please would we put an applicability
statement into our documents to say that they don't apply to 3GPP
networks. This is unreasonable.

If I read 23.167 correctly, then the calling device can obtain its
location directly from the IP CAN, at least one of the IETF LCP is even
mentioned, and I have seen a CR that suggested that HELD could also be
used.

23.167 also makes use of SIP location conveyance. So far, this is 2 of
the 3 elements we require for ECRIT to just work.

I think it is perfectly reasonable to assume that if I get my location
from the IP CAN, I can probably get the serving domain also, in which
case I can do a LoST lookup. Alternatively I can go back to my home LoST
server and rely on forest guides. In either case, these are quite
reasonable assumptions, and the onus on an infrastructure provider is a
provisioning record, rather than E-SLP.... hmmmm which is cheaper and
easier I wonder?

Now what does TS23.167 say to do if my SIP client directs a call to a
URI that it obtained from a LoST Server?
I would place odds that it would just deliver the call.

Further more, if that SIP INVITE included both a CID header and a
location URI what happens? For i2 and i3 we know what happens. Again,
the LRF in 23.167 at a minimum will provide a route to the PSAP based on
the provided location.

Now, lets take Martin's argument a bit more.
I have a device that can operate on 3G, 4G or WiFi. If it connect to a
non-IMS WiFi hotspot (basically all of them) what happens? Where is the
E-CSCF, where is the E-SLP, how can it help me?

The point I am making is that ECRIT will actually work even in IMS
architectures, but the IMS architecture doesn't work in the vast
majority of IP cases. Any applicability statement you want please go and
add it to 3GPP and not here, it is 3GPP that has the applicability
issues and not the IETF.

Cheers
James

-----Original Message-----

Richard and all others

I wonder if those now humming against this statement (and who were all
strangely silent 5 weeks ago) would support any kind of statement
concerning applicability and scope. Or is it the case that the solution
supported by both drafts is considered to apply to all devices, ANs and
VSPs that provide some form of internet access. If so, is it irrelevant
whether the solution is actually suitable for a particular type of AN or
VSP (e.g. cellular AN, IMS based VSP)? For example, is it irrelevant
whether significant additional support from an AN or VSP to which the
solution might be applied would be needed in order to access legacy
PSAPs, handoff to the circuit domain, authenticate the caller and
provide access to non-subscribed users? Is it further irrelevant whether
the solution would even work for a particular device, AN or VSP without
substantial changes to the latter? In other words, is the solution now
considered so sacrosanct that any adaptation must come from the rest of
the
  infrastructure and not from the solution itself in the case of any
mismatch? If the consensus answers to these questions are all yes, then
I would have to agree that including the currently disputed statement or
anything of a similar nature would be inconsistent and unnecessary. Of
course, the representatives of the potentially affected portions of
infrastructure should be forgiven for disagreeing with the basic premise
- and may be expected to offer some type of protest!

Kind Regards

Stephen
-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Tuesday, April 28, 2009 1:07 PM
To: Edge, Stephen
Cc: Gellens, Randall; Henning Schulzrinne; Stark, Barbara; ECRIT
Subject: Re: [Ecrit] PhoneBCP

Stephen,

--Richard

Edge, Stephen wrote:
> All
> 
> I would have thought that motivation should be irrelevant. There are a
lot of motives at work here. Should we assume that the document was
originally written with only the purest and most altruistic motives
(e.g. no thought of business or academic interest at stake)?
Of Randall Gellens

---

From: "Edge, Stephen" <[email-masked]>
Date: Thu, 30 Apr 2009 00:13:45 -0700

Martin

Thanks for the detailed reply. Actually the current delay (if any) is due to those now humming No to a statement added 5 weeks ago following support from a number of others who in general continue to support the statement now. I am in fact not proposing anything new at this moment.

Your interpretation of applicability is certainly extreme (yes or qualified yes to all questions) - removing any dependence on suitability or feasibility (which are the more normal benchmarks) and simply making a legalistic blanket assertion. (I can now more understand incidentally why the fictitious protocol police are so often invoked on matters of conformance.)

But do others have any views on this?

Kind Regards

Stephen
-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Wednesday, April 29, 2009 8:49 PM
To: Edge, Stephen
Cc: ECRIT
Subject: RE: [Ecrit] PhoneBCP

Stephen,

A: Mu (Yes).

A (legacy PSAPs): Yes.

A: Yes.

--Martin

---

From: Karl Heinz Wolf <[email-masked]>
Date: Thu, 30 Apr 2009 09:14:31 +0200

+1

Besides, ED-6 isn't back.
editorial: ED-9 isn't exactly the same text on it's two occurrences.

karl heinz

---

From: "Edge, Stephen" <[email-masked]>
Date: Thu, 30 Apr 2009 00:35:10 -0700

Hi James

The current statement being debated does not say that Ecrit is not applicable to 3GPP and 3GPP2. We got past that point 5 weeks ago and I and others more on the 3GPP/3GPP2 side are now perfectly willing to let that drop given the current statement which essentially characterizes the main principles of the Ecrit solution, admits the potential existence of other solutions and the fact that they are not defined within the Ecrit solution. 

The detailed points you raise below may not be worth answering if you also take the same view as Martin namely that suitability and feasibility are irrelevant when it comes to Ecrit (though not of course when it comes to 3GPP and 3GPP2 I should note).

But I am still awaiting answers to my original questions from others in the Ecrit community.

Kind Regards

Stephen
-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Wednesday, April 29, 2009 9:00 PM
To: Edge, Stephen; Richard Barnes; Gellens, Randall; Henning Schulzrinne; Stark, Barbara; ECRIT
Subject: RE: [Ecrit] PhoneBCP

Stephen,

Cheers
James

-----Original Message-----

Richard and all others

Kind Regards

Stephen
-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Tuesday, April 28, 2009 1:07 PM
To: Edge, Stephen
Cc: Gellens, Randall; Henning Schulzrinne; Stark, Barbara; ECRIT
Subject: Re: [Ecrit] PhoneBCP

Stephen,

--Richard

Of Randall Gellens

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Apr 2009 01:12:37 -0700

> But do others have any views on this?

Here is my 2 pence.   As noted in the Introduction, the Phone BCP document and framework documents are closely related documents that need to be read (and understood) together.  In looking at Phone BCP, there have been many situations in which  I wondered what the justification was for a requirement, only to find the (usually persuasive) explanation in the corresponding section of the framework document.

IMHO, the separation of the two documents is somewhat unnatural. It's a bit like taking a meal, freeze drying it, and then presenting the diner with a cup of powder and a cup of water and wondering why they are left with a quizical look on their faces.  Including cooking instructions along with the two cups is not a fully satisfactory answer.

Given this reality, if there is a need for text explaining the fundamental assumptions of the architecture, the place for that text is not in the BCP document, but in the framework document.  As has been noted by others, the entire BCP document is an applicability statement, and when viewed in that way, the proposed text is not only unnecessary, but somewhat confusing since required context for the BCP document belongs in the framework document.  If anything more is necesary, it would probably be some additional instructions for the reader  delving into the document set for the first time. 

Like any IETF effort, the framework and BCP documents will be evaluated on their own merits. Athough this is an area with a considerable regulatory component, I see little evidence that the world at large is so in awe of the IETF that every word will be taken as immutable truth.  No doubt other SDOs will take issue with these documents in whole or in part and will explain the basis of their assessments and where necessary, their alternatives. As a result, some portions of the architecture may be adopted, some portions may be ignored, and others will be revised in an effort to address the issues encountered and improve their chances for deployment. 

With respect to this process, the addition of cautionary text is a bit like the warning labels that we find on consumer products.  While it may be necessary in some legalistic sense, given the expertise of the individuals assessing these documents, one wonders what the practical effect will be.  Typically these are individuals who already understand that it is a good idea to double-cup hot coffee.

---

From: Marc Linsner <[email-masked]>
Date: Thu, 30 Apr 2009 08:47:52 -0400

Stephen,

As I pondered on the new text, I saw no great harm with it, but the reason I
hummed against it, I don't see that it adds any value.

If we declare in either/both drafts that this solution is based on the
requirements in RFC5012/RFC5069, would that satisfy your concern...??
(I'm somewhat surprised this isn't in either draft.)

-Marc-

On 4/30/09 3:35 AM, "Edge, Stephen" <[email-masked]> wrote:

> Hi James
> 
> The current statement being debated does not say that Ecrit is not applicable
> to 3GPP and 3GPP2. We got past that point 5 weeks ago and I and others more on
> the 3GPP/3GPP2 side are now perfectly willing to let that drop given the
> current statement which essentially characterizes the main principles of the
> Ecrit solution, admits the potential existence of other solutions and the fact
> that they are not defined within the Ecrit solution.
> 
> The detailed points you raise below may not be worth answering if you also
> take the same view as Martin namely that suitability and feasibility are
> irrelevant when it comes to Ecrit (though not of course when it comes to 3GPP
> and 3GPP2 I should note).
>

---

From: "Edge, Stephen" <[email-masked]>
Date: Thu, 30 Apr 2009 09:28:32 -0700

Bernard and others

This is an interesting view - an admission that the Ecrit solution will probably not be universally applied and when it is may be subject to modification. On the 3GPP/3GPP2 sides, solutions are defined with a specific and explicit scope and are expected to be - and nearly always actually are - supported exactly as defined in the appropriate spec.s for all scenarios covered by the scope. A solution whose deployment is unpredictable will be less useful because of the implied interworking problems between incompatible implementations. That is a main reason why I and others initially tried to include a more precise applicability/scope statement than the one we are now discussing. Specifically, the Ecrit solution will probably not be deployed by 3GPP/3GPP2 operators for cellular terminals because they have defined a somewhat different solution more suitable for cellular operation. That means that a terminal supporting only the Ecrit solution (based on an assertion of universal applicability) will encounter problems when its user attempts an emergency call on a 3GPP/3GPP2 network. If I can extend your analogies, this would be like not including a precise menu description for a meal containing meat and/or fish in a restaurant catering to both vegetarians and non-vegetarians.

Kind Regards

Stephen
________________________________
From: Bernard Aboba [mailto:[email-masked]]
Sent: Thursday, April 30, 2009 1:13 AM
To: Edge, Stephen; [email-masked]; [email-masked]
Subject: RE: [Ecrit] PhoneBCP

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 30 Apr 2009 11:48:40 -0500

Or would it be like a statement on the menu saying "You might find a
dish of the same name in other restaurants, this menu does not attempt
to describe the contents of their dish"? I'm surprised diners aren't
crying out for this sort of helpful note... not.

I think this is an object lesson in convergence. "On the 3GPP/3GPP2
sides, solutions are defined with a specific and explicit scope and are
expected to be - and nearly always actually are - supported exactly as
defined". This is exactly where walled-garden presumption collides with
convergence reality. Understanding ECRIT means understanding that
broadband Internet access is broadband Internet access is broadband
Internet access. Having to change the way the device initiates an
emergency call when something as prosaic as the access technology
changes is akin to having to change your web browser just because the
access technology has changed. It's neither helpful nor harmless to have
such a restriction.

A helpful statement to put in the BCP might be "Other architectures,
such as IMS Emergency calling defined by 3GPP and 3GPP2, which are not
based on the ECRIT framework are likely to not be compatible with
devices and emergency networks which assume this framework - e.g. such
as is defined by NENA as i3."

I don't endorse the inclusion of such a statement; it's commentary - as
is the proposed "applicability statement" and commentary is unnecessary.
Nevertheless, I think it's a more accurate characterization. That is,
it's more the case that the 3GPP IMS emergency architecture doesn't fit
ECRIT than it is that ECRIT doesn't fit a 3GPP access network.

Cheers,

Martin

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Edge, Stephen
Sent: Friday, 1 May 2009 2:29 AM
To: Bernard Aboba; Thomson, Martin; [email-masked]
Subject: Re: [Ecrit] PhoneBCP

Bernard and others

This is an interesting view - an admission that the Ecrit solution will
probably not be universally applied and when it is may be subject to
modification. On the 3GPP/3GPP2 sides, solutions are defined with a
specific and explicit scope and are expected to be - and nearly always
actually are - supported exactly as defined in the appropriate spec.s
for all scenarios covered by the scope. A solution whose deployment is
unpredictable will be less useful because of the implied interworking
problems between incompatible implementations. That is a main reason why
I and others initially tried to include a more precise
applicability/scope statement than the one we are now discussing.
Specifically, the Ecrit solution will probably not be deployed by
3GPP/3GPP2 operators for cellular terminals because they have defined a
somewhat different solution more suitable for cellular operation. That
means that a terminal supporting only the Ecrit solution (based on an
assertion of universal applicability) will encounter problems when its
user attempts an emergency call on a 3GPP/3GPP2 network. If I can extend
your analogies, this would be like not including a precise menu
description for a meal containing meat and/or fish in a restaurant
catering to both vegetarians and non-vegetarians.

Kind Regards

Stephen

> Your interpretation of applicability is certainly extreme (yes or
qualified yes to all questions) - removing any dependence on suitability
or feasibility (which are the more normal benchmarks) and simply making
a legalistic blanket assertion. (I can now more understand incidentally
why the fictitious protocol police are so often invoked on matters of
conformance.)
> But do others have any views on this?

Here is my 2 pence.   As noted in the Introduction, the Phone BCP
document and framework documents are closely related documents that need
to be read (and understood) together.  In looking at Phone BCP, there
have been many situations in which  I wondered what the justification
was for a requirement, only to find the (usually persuasive) explanation
in the corresponding section of the framework document.

IMHO, the separation of the two documents is somewhat unnatural. It's a
bit like taking a meal, freeze drying it, and then presenting the diner
with a cup of powder and a cup of water and wondering why they are left
with a quizical look on their faces.  Including cooking instructions
along with the two cups is not a fully satisfactory answer.

Given this reality, if there is a need for text explaining the
fundamental assumptions of the architecture, the place for that text is
not in the BCP document, but in the framework document.  As has been
noted by others, the entire BCP document is an applicability statement,
and when viewed in that way, the proposed text is not only unnecessary,
but somewhat confusing since required context for the BCP document
belongs in the framework document.  If anything more is necesary, it
would probably be some additional instructions for the reader  delving
into the document set for the first time. 

Like any IETF effort, the framework and BCP documents will be evaluated
on their own merits. Athough this is an area with a considerable
regulatory component, I see little evidence that the world at large is
so in awe of the IETF that every word will be taken as immutable truth.
No doubt other SDOs will take issue with these documents in whole or in
part and will explain the basis of their assessments and where
necessary, their alternatives. As a result, some portions of the
architecture may be adopted, some portions may be ignored, and others
will be revised in an effort to address the issues encountered and
improve their chances for deployment. 

With respect to this process, the addition of cautionary text is a bit
like the warning labels that we find on consumer products.  While it may
be necessary in some legalistic sense, given the expertise of the
individuals assessing these documents, one wonders what the practical
effect will be.  Typically these are individuals who already understand
that it is a good idea to double-cup hot coffee.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 30 Apr 2009 10:40:24 -0700

At 9:48 AM -0700 4/30/09, Dawson, Martin wrote:
>Understanding ECRIT means understanding that broadband Internet access is broadband Internet access is broadband Internet access.

To put it mildy, this is far from true.  There is a whole class of offerings that
is voice-as-a-service (the IMS/NGN group) which absolutely do not act like
voice-as-an-application.    The solution we've defined is for voice-as-an-application,
which has the natural result that the end user device has the primary role.

The root of the problem we're facing is that there is a difference between
using IP and using the Internet model.  IMS uses IP, but uses a different
model entirely (Whatever you think of that model, I don't think anyone
who looked at how it works could argue that it is the same as the Internet
model.)

The documents we're dealing with contrast the offering with PSTN, but
don't really see any differentiation among "packet-switched networks".
Take this early text from the Framework document:

>It is beyond the scope of this document to enumerate and discuss all
>   the differences between traditional (Public Switched Telephone
>   Network) and IP-based telephony, but calling on the Internet is
>   characterized by:
>   o  the interleaving over the same infrastructure of a wider variety
>      of services;
>   o  the separation of the access provider from the application
>      provider;
>   o  media other than voice (e.g. video and text in several forms);
>   o  the potential mobility of all end systems, including endpoints
>      nominally thought of as fixed systems and not just those using
>      radio access technology.  For example, consider a wired phone
>      connected to a router using a mobile data network such as EV-DO as
>      an uplink.
>
>   emergency calls and how PSAPs can handle Internet multimedia
>   emergency calls natively, rather than describing how circuit-switched
>   PSAPs can handle VoIP calls.  In many cases, PSAPs making the
>   transition from circuit-switched interfaces to packet-switched
>   interfaces may be able to use some of the mechanisms described here,
>   in combination with gateways that translate packet-switched calls
>   into legacy interfaces, e.g., to continue to be able to use existing
>   call taker equipment.  There are many legacy telephone networks that
>   will persist long after most systems have been upgraded to IP
>   origination and termination of emergency calls.  Many of these legacy
>   systems route calls based on telephone numbers.  Gateways and
>   conversions between existing systems and newer systems defined by
>   this document will be required.  Since existing systems are governed
>   primarily by local government regulations and national standards, the
>   gateway and conversion details will be governed by national standards
>   and thus are out of scope for this document.

The real contrast being made is between circuit-switched and Internet
model, but the terms used mix "packet-switched", "IP-based", and "Internet";
there is even an explicit mention of EV-DO, but in a mode that treats
it as a pure IP bearer (which is not what is being sold in most markets
today).  The reality on the ground today is that there are at least circuit-switched,
Internet model IP, and IP with operator services out there in the real
world.  This document set doesn't acknowledge that, and it treats all
packet-switched services/IP-based services as if they were Internet model.
That's simply not true.

The argument that Steven and others have made is that the document set
needs to have an explicit acknowledgement of the other model, so that
there is a realization by those reading them that just because they have
IP, doesn't mean they are dealing with the Internet model.   You could
argue that everyone knows that, but the document itself muddies it
far enough that it is far from evident.

Do I, personally believe the Internet model version is better?  Yep.  Do
I, personally believe that it will eventually subsume other versions?  Maybe,
and I think it would be nice.  But I also recognize that it is not the case now,
and we're trying to define a system that  will actually work to deliver emergency
calls in the real world.  Explicit acknowledgement seems to me valuable
in that case.  The other option is to re-write the documents to clarify that
not any packet-switched network nor any network using IP fits this set
of assumptions; that seems to me likely to take longer and not add much.

You've already had Keith note that he would object to the documents if
they did not contain language like that which was in -09.  If it is taken out,
I believe the documents will need a major editing pass to accomplish the
clarification without the explicit text.  This text is a compromise already,
and the issue it deals with is important.  Unless we are going to pretend
that the IMS model simply doesn't exist and won't be used to deliver a
substantial fraction of emergency calls for a good long time to come,
we need it.  If we are going to pretend that, I think we are being very foolish
indeed.

				Ted

>Having to change the way the device initiates an emergency call when something as prosaic as the access technology changes is akin to having to change your web browser just because the access technology has changed. It's neither helpful nor harmless to have such a restriction.
> 
>A helpful statement to put in the BCP might be "Other architectures, such as IMS Emergency calling defined by 3GPP and 3GPP2, which are not based on the ECRIT framework are likely to not be compatible with devices and emergency networks which assume this framework - e.g. such as is defined by NENA as i3."
> 
>I don't endorse the inclusion of such a statement; it's commentary - as is the proposed "applicability statement" and commentary is unnecessary. Nevertheless, I think it's a more accurate characterization. That is, it's more the case that the 3GPP IMS emergency architecture doesn't fit ECRIT than it is that ECRIT doesn't fit a 3GPP access network.
> 
>Cheers,
>Martin
> 
>
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Edge, Stephen
>	creation-date="Thu, 30 Apr 2009 09:49:15 GMT";
>	modification-date="Thu, 30 Apr 2009 09:49:15 GMT"
>
>Attachment converted: Macintosh HD:ATT00001 5257.txt (TEXT/ttxt) (0040366B)

---

From: Marc Linsner <[email-masked]>
Date: Thu, 30 Apr 2009 15:52:29 -0400

Ted,

I searched a small amount for comparison type language in other IETF drafts.
I'm struggling with the notion that anyone who would read IETF drafts would
get confused as to their solution/applicability space.

Since my search was small and cycles are short, are you aware if there is
any such language in any of the ream of SIP drafts that point out the
solution space and explicitly exclude IMS?

-Marc-

On 4/30/09 1:40 PM, "Ted Hardie" <[email-masked]> wrote:

>> Understanding ECRIT means understanding that broadband Internet access is
>> broadband Internet access is broadband Internet access.
> 
>> Having to change the way the device initiates an emergency call when
>> something as prosaic as the access technology changes is akin to having to
>> change your web browser just because the access technology has changed. It's
>> neither helpful nor harmless to have such a restriction.
>> 
>> A helpful statement to put in the BCP might be "Other architectures, such as
>> IMS Emergency calling defined by 3GPP and 3GPP2, which are not based on the
>> ECRIT framework are likely to not be compatible with devices and emergency
>> networks which assume this framework - e.g. such as is defined by NENA as
>> i3."
>> 
>> I don't endorse the inclusion of such a statement; it's commentary - as is
>> the proposed "applicability statement" and commentary is unnecessary.
>> Nevertheless, I think it's a more accurate characterization. That is, it's
>> more the case that the 3GPP IMS emergency architecture doesn't fit ECRIT than
>> it is that ECRIT doesn't fit a 3GPP access network.
>> 
>> Cheers,
>> Martin
>> 
>> 
>> Edge, Stephen
>> modification. On the 3GPP/3GPP2 sides, solutions are defined with a specific
>> and explicit scope and are expected to be - and nearly always actually are -
>> supported exactly as defined in the appropriate spec.s for all scenarios
>> covered by the scope. A solution whose deployment is unpredictable will be
>> less useful because of the implied interworking problems between incompatible
>> implementations. That is a main reason why I and others initially tried to
>> include a more precise applicability/scope statement than the one we are now
>> discussing. Specifically, the Ecrit solution will probably not be deployed by
>> somewhat different solution more suitable for cellular operation. That means
>> that a terminal supporting only the Ecrit solution (based on an assertion of
>> universal ap
>  plicability) will encounter problems when its user attempts an emergency call
> on a 3GPP/3GPP2 network. If I can extend your analogies, this would be like
> not including a precise menu description for a meal containing meat and/or
> fish in a restaurant catering to both vegetarians and non-vegetarians.
>> 
>> Kind Regards
>> 
>> Stephen
>> 
>>> Your interpretation of applicability is certainly extreme (yes or qualified
>>> yes to all questions) - removing any dependence on suitability or
>>> feasibility (which are the more normal benchmarks) and simply making a
>>> legalistic blanket assertion. (I can now more understand incidentally why
>>> the fictitious protocol police are so often invoked on matters of
>>> conformance.)
>>> 
>> Here is my 2 pence.   As noted in the Introduction, the Phone BCP document
>> and framework documents are closely related documents that need to be read
>> (and understood) together.  In looking at Phone BCP, there have been many
>> situations in which  I wondered what the justification was for a requirement,
>> only to find the (usually persuasive) explanation in the corresponding
>> section of the framework document.
>> 
>> IMHO, the separation of the two documents is somewhat unnatural. It's a bit
>> like taking a meal, freeze drying it, and then presenting the diner with a
>> cup of powder and a cup of water and wondering why they are left with a
>> quizical look on their faces.  Including cooking instructions along with the
>> two cups is not a fully satisfactory answer.
>> 
>> Given this reality, if there is a need for text explaining the fundamental
>> assumptions of the architecture, the place for that text is not in the BCP
>> document, but in the framework document.  As has been noted by others, the
>> entire BCP document is an applicability statement, and when viewed in that
>> way, the proposed text is not only unnecessary, but somewhat confusing since
>> required context for the BCP document belongs in the framework document.  If
>> anything more is necesary, it would probably be some additional instructions
>> for the reader  delving into the document set for the first time.
>> 
>> Like any IETF effort, the framework and BCP documents will be evaluated on
>> their own merits. Athough this is an area with a considerable regulatory
>> component, I see little evidence that the world at large is so in awe of the
>> IETF that every word will be taken as immutable truth.  No doubt other SDOs
>> will take issue with these documents in whole or in part and will explain the
>> basis of their assessments and where necessary, their alternatives. As a
>> result, some portions of the architecture may be adopted, some portions may
>> be ignored, and others will be revised in an effort to address the issues
>> encountered and improve their chances for deployment.
>> 
>> With respect to this process, the addition of cautionary text is a bit like
>> the warning labels that we find on consumer products.  While it may be
>> necessary in some legalistic sense, given the expertise of the individuals
>> assessing these documents, one wonders what the practical effect will be.
>> Typically these are individuals who already understand that it is a good idea
>> to double-cup hot coffee.
>> 
>> 
>>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 30 Apr 2009 12:54:55 -0700

>solution space and explicitly exclude IMS?

Besides the long-running argument over SBCs?  I am not sure; possibly
Keith would be able to point to comparison text.

					Ted

---

From: "Edge, Stephen" <[email-masked]>
Date: Thu, 30 Apr 2009 13:31:55 -0700

Hi Marc

It seems that RFC 5012 would be a useful acknowledgement (assuming that its requirements are all or mostly supported). But I do not have the impression that RFC 5069 is supported - but if it is, then it's also another good reference.

Neither of these, however, is an effective substitute for a clear simple statement like the one we are discussing (and I saw no equivalent statement in either of the RFCs).

Kind Regards

Stephen
-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Thursday, April 30, 2009 5:48 AM
To: Edge, Stephen; ECRIT
Subject: Re: [Ecrit] PhoneBCP

Stephen,

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 30 Apr 2009 20:10:00 -0500

Hi Keith,

So you are saying that you will object to the document leaving the WG
unless the statement is included, on the grounds that there have been
discussions about what the statement should say?  This is despite the
fact that no consensus was ever reached to include the statement in the
first place.

I believe that other than this debate these documents are good to go,
and that once this hum is completed the consensus will be reached and
the documents can leave the WG.

Cheers
James

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Monday, 27 April 2009 6:08 PM
To: Winterbottom, James; Brian Rosen; Richard Barnes; Ted Hardie
Cc: ECRIT
Subject: RE: [Ecrit] PhoneBCP

I would also note that if we go the way you want to go, we have a hum
for whether the document is acceptable without this. Having had the
discussion to agree an applicability statement, I warn that I will hum
against a document without it.

regards

Keith

---

From: "Edge, Stephen" <[email-masked]>
Date: Thu, 30 Apr 2009 19:06:12 -0700

Hi James

Never to return?

Kind Regards

Stephen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Winterbottom, James
Sent: Thursday, April 30, 2009 6:10 PM
To: DRAGE, Keith (Keith); Brian Rosen; Richard Barnes; Hardie, Ted
Cc: ECRIT
Subject: Re: [Ecrit] PhoneBCP

Hi Keith,

Cheers
James

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Monday, 27 April 2009 6:08 PM
To: Winterbottom, James; Brian Rosen; Richard Barnes; Ted Hardie
Cc: ECRIT
Subject: RE: [Ecrit] PhoneBCP

regards

Keith

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 30 Apr 2009 21:57:43 -0500

Only as RFCs I hope

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Friday, 1 May 2009 12:06 PM
To: Winterbottom, James; DRAGE, Keith (Keith); Brian Rosen; Richard
Barnes; Hardie, Ted
Cc: ECRIT

Hi James

Never to return?

Kind Regards

Stephen
-----Original Message-----
Of Winterbottom, James

Hi Keith,

Cheers
James

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Monday, 27 April 2009 6:08 PM
To: Winterbottom, James; Brian Rosen; Richard Barnes; Ted Hardie
Cc: ECRIT
Subject: RE: [Ecrit] PhoneBCP

regards

Keith 

> >> Attachment converted: Macintosh HD:ATT00001 5171.txt (TEXT/ttxt)
------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "Edge, Stephen" <[email-masked]>
Date: Thu, 30 Apr 2009 20:21:11 -0700

My hope also if the hum goes the right way!

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Thursday, April 30, 2009 7:58 PM
To: Edge, Stephen; DRAGE, Keith (Keith); Brian Rosen; Richard Barnes; Hardie, Ted
Cc: ECRIT
Subject: RE: [Ecrit] PhoneBCP

Only as RFCs I hope

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Friday, 1 May 2009 12:06 PM
To: Winterbottom, James; DRAGE, Keith (Keith); Brian Rosen; Richard
Barnes; Hardie, Ted
Cc: ECRIT

Hi James

Never to return?

Kind Regards

Stephen
-----Original Message-----

Hi Keith,

Cheers
James

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Monday, 27 April 2009 6:08 PM
To: Winterbottom, James; Brian Rosen; Richard Barnes; Ted Hardie
Cc: ECRIT
Subject: RE: [Ecrit] PhoneBCP

regards

Keith