Re: [Ieprep] Re: draft-ietf-ieprep-requirements-01

The IEPREP Charter (paragraph #1):

"Effective telecommunications capabilities are imperative to facilitate
immediate recovery operations for serious disaster events, such as,
hurricanes, floods,
earthquakes, and terrorist attacks. Disasters can happen any time, any
place, unexpectedly. Quick response for recovery operations requires
immediate access
to any public telecommunications capabilities at hand. These capabilities
include: conventional telephone, cellular phones, and Internet access via
online
terminals, IP telephones, and wireless PDAs. The commercial
telecommunications infrastructure is rapidly evolving to Internet-based
technology. Therefore,
the Internet community needs to consider how it can best support emergency
management and recovery operations. 

Three examples of emergency communications include: 

1. Conveying information about the priority of specific phone calls that
originate in a VoIP environment through gateways to the PSTN. "

Bill - this charter seems to describe networks *other* than yours (because
of your choice of interconnectivity issues); therefore I believe your
discussion is out of scope for this list until *you* can change the charter
to *not* state IEPREP directly involves the commercial telecommunications
industry (which means at least also interconnectivity to the PSTN/GSTN/CSN).

I have my own issues with the ID, but clearly don't want to hear your
ranting BS that doesn't apply to the charter (which the Reqs ID here
attempts to do).

BTW - this seems like a very good time for *you* to write an ID about the
issues and requirements involving Topology "End-to-End IP" from:
http://www.ietf.org/internet-drafts/draft-polk-ieprep-scenarios-01.txt
THE purpose for that ID is to bring overlapping and unique discussions
regarding the similarities and differences surrounding each of the 4 basic
Topologies. I have read through ~10 emails that you (and maybe Ran) want
your Topology to be overlapping in nature (therefore everything changed)
with respect to the other 3 Topologies - yet your unclear reasoning seems
to point to your uniqueness relative to the other Topologies. 

One problem I see with you doing this is your intent on *not* connecting to
IEPREP/ETS/GETS/GTPS services of any kind (so why are you commenting at all
to this discussion that will not involve you or your network?). 

Send text or write your own ID -- you seem to feel quite strongly about this.

nuff said (in your equally brash manner)!

At 09:56 AM 10/31/2002 -0800, Bill Woodcock wrote:
>    > the purpose of the passage about "4 basic configurations"
>    > was to acknowledge that more than one exists and that users of an
>    > authorized emergency service should keep this in mind.  what one
>    > cannot determine from Bill's original statement is *how* that one
>    > scenario he points out (and obviously relates to) is ignored.
>
>This was what I was principally objecting to at the Yokohama meeting:
>there seems to be an underlying assumption that the PSTN will connect to
>arbitrary other voice networks.  My own network appears to be the
>exception in that PSTN operators do in fact seem to be eager to connect to
>it and bear the costs of doing so, but in the general case, they don't
>seem to be interested in doing so.
>
>If the document or the expectant party which it represents wants to be
>able to pick up an arbitrary telephone and call an arbitrary other
>telephone, this presupposes interconnection between the two networks which
>serve the respective telephones.
>
>I would point out that the expectant party has historically been one of
>the main consumers of disconnected telephone networks, and was in fact
>proposing to create yet another just this week at NANOG.  So this is
>clearly not a useful expectation.
>
>    > > >> We assume the presence of Service Level Agreements
>    > > > Which are a marketing, sales, and collections fiction.
>    > > He's saying the assumption is not well founded.
>    > we have used the term "business agreement" instead of SLAs in our
>    > other documents.
>
>Right.  So isn't this CLEARLY OUTSIDE THE REALM OF THE IETF?  Since when
>does the IETF standardize business agreements?
>
>    >>>> Emergency traffic should be able to transit multiple service
>    >>>> providers.
>    > The original passage probably should have stated "labeled emergency
>    > traffic".  The traffic  itself could be diff-serv marked IP packets.
>    > Or they could be labeled application layer packets.  In either case,
>    > the user would have the expectation that the labeled traffic
>    > transits other providers as opposed to be dropped because it is
>    > unrecognized.
>
>Then the user's expectation would be unfulfilled.
>
>You're completely missing the point.  _No_ traffic is going to transit
>multiple service providers unless the service providers are
>interconnected.  Interconnection is a physical process, not a sales
>process.
>
>    > Further, that this expectation can only exist if "business
>    > contracts" have been set up... if the business contract doesn't
>    > exist... then expect normal (presumably best effort) service.
>
>No, no, no.  If the _physical interconnection_ doesn't exist, then expect
>_no_ service.  Has nothing to do with business contracts.
>
>    >>> Users are more than welcome to request degraded quality of service at
>    >>> any time.  Please speak loudly into the mouse, before dialing.
>    >> Bill's point seems to be that the real deployed Internet has no
>    >> concept of QoS -- not merely no concept of "good" QoS but no
>    >> concept of "QoS" at all.
>
>Correct.  We all tried, multiple times, but since it made everything
>worse, rather than better, and cost money rather than saving money, it
>died a well-deserved death quite a few years ago.
>
>End users are perfectly welcome to assume its existence and "request
>degraded service" all they like.  They can also wave magic wands and chant
>incantations.  We'll keep routing packets either way.
>
>    > the intent of the original passage
>    > was aimed at the QoS experienced by the end-user and not necessarily
>    > that offered by the network.  for example, using lower quality/bandwidth
>    > codecs, or adding FEC -- ie, something other than standard end-to-end
>    > service.
>
>Then it doesn't belong in the document, does it?  Users are welcome to do
>whatever users do.  That doesn't constitute an expectation of service
>providers.
>
>                                -Bill
>
>
>_______________________________________________
>Ieprep mailing list
>Ieprep@ietf.org
>https://www1.ietf.org/mailman/listinfo/ieprep

cheers,
James 

              *************************************
"People generally demand more respect for their own rights than 
                         they are willing to allow for others"

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep