Subject: Re: [Ieprep] draft-ietf-ieprep-framework-02.txt

From: [email-masked]
Date: Fri, 1 Nov 2002 13:07:55 EST

In a message dated 10/31/2002 6:15:09 PM Eastern Standard Time, [email-masked] 
writes:

>    > Primary Objectives in support of authorized emergency calls:
>     > 2) Interaction with PSTN
>     > The second objective involves the interaction of IP telephony
>     > signaling with existing PSTN support for emergency related voice
>     > communications.  As mentioned above in Section 1.2, standard
>     > T1.631 [26] specifies emergency code points for SS7.
>     > Specifically, the National Security and Emergency Preparedness
>     > (NS/EP) Calling Party Category code point is defined for ISUP IAM
>     > messages used by SS7 [26].  Hence, our objective in the
>     > interaction between the PSTN and IP telephony with respect to
>     > IEPS (and national indicators) is a direct mapping between
>     > related code points.
> 
> This seems problematic to me, in exactly the same way as if a user came
> before the IETF with a draft which stated that that their objective was
> to have carriers peer. That's nice, but that's a business decision to
> be made by the carriers, and it doesn't really serve any useful goal to
> say that it's nice in an official IETF document.  This seems like
> another statement of the "We like toast!" variety.
> 
> Simply stating that "interaction with the PSTN is a primary objective"
> isn't going to get the PSTN carriers to run around buying connections
> to all the different IP telephony networks, and I doubt the NCS would
> be really happy paying the marked-up pass-through cost of doing so,
> even if the telcos felt like doing it.
> 

[MAP] I would suggest you read more carefully before commenting and be more 
careful in your quoting. The above quote from the requirements document does 
not say "interaction with the PSTN is a primary objective" as you claim (and 
comment on).

It says "our objective is ... a direct mapping between related code points". 
This clearly refers to a case if interaction with the PSTN takes place.

Independent from whatever the IEPREP requirement is talking about, we must 
presume that there is interaction between any IP-based network providing 
"public" telephony service and the PSTN. I really can't believe you are 
questioning this aspect. If you want a statement that the requirements in 
this document do not apply to completely private Voice over IP networks, then 
that should be no problem. But it doesn't change the set of requirements in 
IEPREP which are designed to identify what protocol work is necessary to 
support other networks.

Mike Pierce
Artel

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 1 Nov 2002 10:16:08 -0800 (PST)

On Fri, 1 Nov 2002 [email-masked] wrote:
    > questioning this aspect.

Well, I certainly wouldn't _assume_ that the PSTN operators will connect
to the rest of the network.  They aren't _generally_ eager to
interconnect, certainly.  In nearly every case that I've experienced, they
actively avoid interconnecting.

                                -Bill

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Nov 2002 13:32:46 -0500

This also depends on what kind of interconnection you're talking about. 
Certainly, operators aren't eager to interconnect at the SS7 level, 
although in many cases they're legally obligated if the other party is a 
registered CLEC or IXC. LECs obviously connect to all kinds of IXCs, 
with little apparent difficulty. Whether the IXC or CLEC uses ISDN 
circuits or VoIP internally does not seem to matter, as long as the 
interface is something bell heads can understand.

For customer circuits, they have very little say about whether they want 
to connect to a "PBX with DID" that happens to be PSTN gateway into a 
large VoIP cloud. In many cases, the latter is perfectly sufficient.

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 1 Nov 2002 10:30:26 -0800 (PST)

> Certainly, operators aren't eager to interconnect at the SS7 level,

Nor am I willing to give them or sell them an SS7 interconnection.  I'm
williing to give them or sell them a SIP or H.323 connection, or if I'm in
a particularly generous mood, PRIs.

    > registered CLEC or IXC.

Uh, sorry, those are all PSTN operators, by definition.  We were talking
about whether the PSTN operators were going to connect to the network, not
whether they were going to connect to each other.  I realize that they
reluctantly connect to each other.

    > Whether the IXC or CLEC uses ISDN

Uh, sorry, that's not a requirement.  Whether they're able to progress
beyond ninteenth-century technology is their problem, not mine.

                                -Bill

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Nov 2002 13:55:42 -0500

The 19th century carriers have the billion customers. Nobody forces you 
to connect to anything if your customers would prefer not to talk to 
those poor souls stuck in the 19th century.

However, the IEPREP documents assume, not completely unrealistically, 
that the 19th century technology carriers and those connected to them 
will not upgrade immediately, but that talking to them is still 
desirable in whatever passes as near term.

This has nothing whatsoever to do with the way that the IP side is run 
or not run or whether the current operational Internet is "better" or 
not than the PSTN. Some of the requirements of reliable, high-quality 
service that well-run parts of the PSTN has strived for seem like 
reasonable objectives.

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 1 Nov 2002 10:57:09 -0800 (PST)

> those poor souls stuck in the 19th century.

Yep, and McDonalds has sold billions of what purport to be hamburgers.
This isn't useful information in the context of something that describes
itself as a requirements draft in the IETF.

    > desirable in whatever passes as near term.

The IEPREP documents appear to be documenting _one user's desire_ to
continue to talk to the PSTN.  If they want to continue to talk to the
PSTN, there is, as you point out, _nothing stopping them_.  This has
_nothing to do with the IETF_ and should have _nothing to do with me_.
The one user under discussion appears to be quite happy spending my tax
dollars to continue to buy ninteenth-century technology from PSTN
carriers.  They have that forum, their customer relationship, in which
they're perfectly welcome to discuss with those providers their desire
that those providers interconnect with the rest of the world.  This
doesn't require the IETF.  There's certainly no need to require anything
of me.

                                -Bill

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Nov 2002 14:17:13 -0500

Requirements should be phrased to be understood as "if you would like to 
do X, here are some things to consider". The IETF has a long tradition 
of doing interconnection to legacy technology, dating back as far as the 
significant efforts to connect SMTP to X.400. This did not mean that any 
ISP was forced by the IETF to run an X.400 gateway. I don't take a 
position on whether the current documents express the "if" part 
sufficiently clearly. Maybe you can help by suggesting appropriate wording.

If you're objecting to having the IETF discuss interconnection with the 
PSTN, you probably should take this discussion to a higher layer of IETF 
management, as this topic is part of the charter of at least the ENUM, 
SIPPING, MEGACO, IPTEL, AVT and SIP WGs. The IEPREP charter clearly 
contains this interconnection functionality, as in "These capabilities 
include: conventional telephone, cellular phones" and several other places.

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 1 Nov 2002 11:19:00 -0800 (PST)

On Fri, 1 Nov 2002, Henning Schulzrinne wrote:
    > of doing interconnection to legacy technology...

Yes, but please remember that this isn't an IETF-originated initiative,
this is a U.S. government-originated initiative.  The IETF has a long
tradition of calling things "requirements" and subsequently ignoring them.
The U.S. government has a long tradition of calling things "requirements"
and then killing people on the basis of them.  We have a basic difference
of institutional culture here, and a fundamentally dangerous ambiguity
surrounding the use of the word "requirement".

    > PSTN

Of course not.  The issue isn't _how_ or _whether_.  The former is clearly
the responsibility of the IETF to define, and the latter is a preexisting
real-world condition.  The question is one of _mandating_ interconnection,
which is clearly _not_ within the purview of the IETF, and unfortunately
_exactly_ the sort of thing that the U.S. government tries to do all the
time.  If that's _really not the intent here_, the document can be
withdrawn, and there won't be a problem.

                                -Bill

---

From: "Gary Thom" <[email-masked]>
Date: Fri, 1 Nov 2002 15:24:24 -0500

Is anyone else getting tired of listenning to this mis-conceived,
self-serving, never ending argument????

First, there is no intent to mandate anything for anyone. If the wording in
the document gives you that impression, PLEASE someone change the wording so
we can get passed this point and not have to hear this argument again.

Second, the intent IS to provide information on the functionality that is
necessary (hence the term requirements) to support emergency communications,
when desired, on IP networks. This information will be provided to the
people who develop the protocols (SIP in particular) so that they can add
the necessary OPTIONAL parameters and OPTIONAL procedures to the protocol to
support the the desired functionality.

If a user wants this OPTIONAL functionality, the user will have to pay for
it. If the service provider does not want to provide it, the user can go
somewhere else. Notice that no one is yet being killed by the government.

The desire of the user is to be able to give emergency calls a higher
probability of call completion than non-emergency calls in order to improve
emergency response efforts.

There are two levels effected by this need (better not say requirement).
First the protocol (SIP) may need to indicate to other elements in the
network that receive and interpret the protocol messages that this message
is related to an emergency call, so that the element can take action (if
appropriate) or make decisions to help improve the probability of call
completion (this means the probability that the call goes through). This is
where OPTIONAL additions may be needed in the protocol.

The other more complex issue relates to what happens the the media streams
after the call is established. Can we improve the probability that the media
streams related to the emergency call will get through and still be
inteligable.

It would be nice to see some technical / operational discussion of these
issues. nuff said.

Gary

 --------------------------------------------
 Name   : Gary A. Thom
 Company: Delta Information Systems, Inc.
 Address: 300 Welsh Rd., Bldg 3
          Horsham, PA 19044 USA
 Phone  : +1-215-657-5270 x123
 Fax    : +1-215-657-5273
 E-mail : [email-masked]
 Website: www.delta-info.com
--------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Bill Woodcock
> Sent: Friday, November 01, 2002 2:19 PM
> To: Henning Schulzrinne
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ieprep] draft-ietf-ieprep-framework-02.txt
>
>

---

From: "Stuart (Stu) Goldman" <[email-masked]>
Date: Sun, 03 Nov 2002 03:27:16 -0700

Gary,

Well said.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 4 Nov 2002 16:59:43 -0500

On Friday, Nov 1, 2002, at 14:17 America/Montreal, Henning Schulzrinne 
wrote:
> If you're objecting to having the IETF discuss interconnection with 
> the PSTN,

In draft-carlberg-ets-*, one of the suggestions I made was to 
editorially
clarify the scope of things by adding some words.  Things that might 
help
with regard to the above topic could look like (for example):

	IP Carriers who choose to offer IEprep services, choose to offer VoIP
	services (as an application-layer service, not just normal IP 
packets), and
	who choose to interconnect their VoIP service with the PSTN 
should...[whatever]

Words like that reassure operators who don't choose to offer one of the
required services of the IF clause, clarify the actual intent, and don't
remove any value, IMHO.

Editing several of our documents to have more words like that would be
generally helpful.  Putting words like "This document only applies to
operators who choose to offer [x], [y], and [z]." in a scoping paragraph
at the beginning of a document would also be helpful.

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 4 Nov 2002 17:02:30 -0500

On Friday, Nov 1, 2002, at 14:19 America/Montreal, Bill Woodcock wrote:
> The question is one of _mandating_ interconnection,

...or edited so that the real intent (no mandates) is crystal clear
to everyone who might read the document.  Kindly recall that most
folks who read an RFC do NOT read the charter of the WG that created
the RFC -- they ONLY read the actual RFC (and if you're lucky, maybe
some cross-referenced RFCs).

If the intent does not include levying mandates (funded or unfunded),
then PLEASE edit the documents to make that clear xor remove the
documents that say otherwise.

Thanks,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 4 Nov 2002 17:11:08 -0500

> we can get passed this point and not have to hear this argument again.

That change was requested by several people many months ago, but does 
not
appear to have permeated all the documents.  Now would be a fine time
to make those edits all over the place.

I think that draft-carlberg-ets-* largely have those edits in place 
today
(if not, someone please cite section/page/offending text in email to at 
least
Ken/me so the text can be fixed in that pair of documents).

> support the the desired functionality.

Which document(s) are you specifically referring to above ?
Henning's only ?

> somewhere else.

Could we please state that more clearly several places in several 
documents ?
It would really help improve consensus here.

Ran
[email-masked]