Subject: [Ieprep] ieprep-requirements-01 - reqs 1-5 - discussion request

From: Scott Bradner <[email-masked]>
Date: Sat, 2 Nov 2002 11:39:45 -0500 (EST)

I'm going to follow Kimberly's lead and try to focus the discussion of
draft-ietf-ieprep-requirements-01.txt by going through it a few
requirements at a time. 

After we discuss the requirements we can go back to look at the other
material in the document.

(as an aside, it does help to number requirements as is done in the SIP
requirements - it makes it easier to talk about them and it makes it easier
for documents which talk about meeting requirements to talk about which
requirements they are talking about - I've numbered the requirements here
for ease of discussion)

As noted on the list yesterday - I think that we need to be quite careful
to specify whether we are talking about what requirements can be met on the
Internet (and private IP networks) with existing or near-term technology
and what would require significant new technology development.

I think that we also need to be careful to say what requirements can be met
with the current Internet architectural model (of autonomous
interconnecting with no particular service guarantees) and what would
require a change in this architectural model.  Along this line, we should
also be careful to say which requirements are targeted at use within an
enterprise (such as a telephone company using IP internally), at a single
ISP and which are expected to be able to be met for traffic spanning ISPs
in the open Internet.

my notes/questions at ">>"

User Requirements - 1-5

  The basic user requirements that need to be considered in providing
  emergency telecommunication capabilities to support recovery
  operations from serious disaster situations are summarized as
  follows.  Note that we assume the presence of Service Level
  Agreements in cases where user requirements cover expectations of  
  service providers:

>> see above - I'm not sure what the context is for the last
>> sentence - are we talking about the customer of a single ISP
>> using only that ISP for the emergency communications to other
>> sites on the same ISP?  If so I can see how a SLA could be 
>> used, otherwise I do not know what SLA is being referred to
   
  1  Users should be able to use public telecommunication
     resources for supporting emergency communications to help
     organize and coordinate immediate disaster recovery
     operations.
>> I do not know what is meant by "public telecommunication 
>> resources " - does this refer to the PSTN or to the Internet?

>> This seems more of a goal than a requirement.
>> Requirements should be specific enough to know if they are being 
>> met, use within an enterprise network, or within a single ISP
>> is quite different than use of the general Internet where
>> there is no guarantee where the other end of the communication
>> may be.
   
  2  Users that access emergency telecommunications service must
     be authenticated.  This should be accomplished in a timely
     manner.
>> see above, this does not seem specific enough to know if
>> its being met - for example, I can see a case where no 
>> authentication is needed over the IP part of an emergency
>> call because there are no facilities for authentication or
>> because the is no need to authenticate because there are 
>> adequate resources but that authentication might well be needed
>> with the PSTN side of a IP-to-PSTN gateway - maybe this needs
>> to say something like 'users of emergency telecommunications
>> services which require special allocation of network resources
>> must be authenticated'  
>> also there is no reason to think that authentication to one 
>> part of a communications path means authentication to the
>> rest of the path - for example, I have to go through an
>> authentication process to access part of the Harvard network
>> but that authentication is not forwarded to a IP-to-PSTN
>> gateway I might be using, nor would the Harvard authentication 
>> make any sense to the gateway 
   
  3  When networks reach traffic saturation emergency
     communication sessions should be provided with a
     higher probability of completion over non-emergency  
     communications.  We assume the presence of a service level
     agreement to accomplish this latter case. (Note: Sessions
     identified as emergency communication could be processed as
     normal traffic along with all non-emergency traffic when
     sufficient network bandwidth and resources are available.)
>> see above - this is very different within an enterprise, within
>> a single ISP and across the Internet
>> also - I would think that each ISP would decide how
>> to eet any emergency service requirement - in a few cases
>> this could mean prioritizing emergency traffic at the expense
>> of their normal customer traffic but I would expect that
>> would not be the normal case - I doubt that most ISPs
>> will be willing to starve their regular customers, who may be
>> trying to respond to the same emergency, I would expect that
>> it sis far more likely that an ISP will set aside some set
>> amount of network capacity to provide this service on
   
  4  Once an emergency communications session is established,
     the user should be able to complete the session without
     being interrupted or having the quality of the
     communications be degraded excessively.
>> I'm not sure what this means - what happens if the tail
>> circuit gets cut and there is no connectivity - or what 
>> happens if there is too much emergency traffic for the 
>> available resources?

  5  There must exist a mapping association between labels
     defined by various standards bodies.  This mapping will   
     help facilitate inter-working of services in cases where 
     gateways and networks support emergency telecommunications 
     services.
>> does this imply that the function of bridging two PSTN networks
>> over the Internet has to be able to translate between
>> two, potentially incompatible, label types?
>> it would seem to me that this would be a problem for a
>> standards organization that develops a new set of 
>> label set and not of the IP-based technology used to do 
>> bridging - i.e. it is a gateway not a transport problem

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

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 2 Nov 2002 11:59:38 -0800 (PST)

>      organize and coordinate immediate disaster recovery

This is a statement which appears to be of the form "Toast should exist."
It's confused, however, by the use of a number of phrases which appear to
have ambiguous meanings, as used by the authors.  I generally think of the
phrase "users" as meaning "members of the general computer-using public,"
whereas the authors seem to think "users" is synonymous with "NCS".  As
Scott points out, "public telecommunications resources" might or might not
mean the Internet, or the PSTN, or something else.  "Disaster recovery
operations" might mean my concept of a disaster, which would be packets
not being delivered, or it might mean NCS's concept of a disaster which
would presumably be something to do with middle-aged white Republicans in
funny hats fretting about something on the other side of the globe.

    >      be authenticated.  This should be accomplished in a timely

This appears to bring one potential definition of "user" into conflict
with one of the other goals, which as I understood it, required anonymity
for the answering party.  What the heck does "timely manner" mean?  Before
the end of the telco's monthly billing cycle?  Before data begins to flow?
Before it stops flowing?

Why would authentication be a requirement, anyway?  The content of the
call must not be very important, if it's less important than the identity
of the caller.  I don't think I want to clog up my network with
unimportant data.  I'd rather fill it with revenue-generating gamers and
porn-viewers and so forth.

    >      communications.

Network saturation and emergency communication sessions exist in
completely different, and relatively orthoganal temporal frames of
reference.  I would presume that emergency communication sessions (if
they're voice) would last seconds, or maybe even minutes.  This seems to
me sort of like requiring an elephant to interact with an electron.  Yes,
they'll interact, but not in a manner which is likely to be easily
governed by notional rules, rather than physical ones.

Besides, "emergency communications sessions" seems only to be defined as
"communications between authorized users," which itself is completely
undefined.  My authorized users may be completely different than your
authorized users.  My perception of an emergency is _quite likely_ to be
very different than your perception of an emergency.  In the unlikely
event of network congestion of a scale which would be addressable in the
manner posited here, it's likely that quite a lot of people's incompatible
notions of emergency would be simultaneously applicable.  If the Bahai'i
are paying me, and the RCMP are not, I think you know whose emergency will
receive priority service, in the event that such service exists.

    >    3 We assume the presence of a service level
    >      agreement to accomplish this latter case.

Yeah, so this sentence needs to go away, since we're a technical body.

    >    3 Sessions identified as emergency communication could be
    >      processed as normal traffic along with all non-emergency
    >      traffic...

Replace "identified as" with "which someone considers to be" and we're
doing okay so far...

    >    3 ...when sufficient network bandwidth and resources are
    >      available.

By what definition?

    >      being interrupted

"Toast SHOULD fly, though it won't."

Whether the session terminates at the behest of one of the parties, or
sooner, is not under the control of the users.  That would be a question
of luck.  Luck is unfortunately not swayed by the existence of IETF
documents.

    >   3  or having the quality of the communications be degraded
           excessively.

Ditto.

    >      gateways and networks support emergency telecommunications

"Toast MUST fly!"  This MUST is outside the capability of the IETF to
autonomously actualize, though it would be nice.

                                -Bill

---

From: Ken Carlberg <[email-masked]>
Date: Mon, 11 Nov 2002 15:12:05 +0000

Scott,

(sidenote, my apologies for the tardy response.  i was away on travel
most of last week).  I'll speak below in the form of a contributer and 
not the primary author to try and provide some additional comments to 
help clarify the issues & questions you bring up.

one observation taken from your comments and others.  it may be worth
considering changing the title of the document and replace the word
"requirements" to "expectations".  also, while the term is touched upon,
perhaps a more direct discussion of who the user is or can be expected to
be would be helpful.
______________________________

> >> used, otherwise I do not know what SLA is being referred to

this relates to the issue that Ran and I have brought up separately
about avoiding confusion that the document be misconstrued as an
IETF statement that X, Y, and Z must be done.  Rather, we wanted to 
reinforce the notion that if a service is available it is because
a business contract in some form exists -- ie, there is no such thing
as a free lunch.  Having stated that, we can make another pass at 
trying to further clarify this intent.

> >> there is no guarantee where the other end of the communication

understood.

> >> services which require special allocation of network resources

yes, agreed.  the original intent was to assume that a label was
used to convey a request for distinguishing traffic and requesting
a particular resource (be it at a gateway, or along the network).
this should be made clearer in the next version.

> >> make any sense to the gateway 

understood.  further explanation should be applied to the passage to
convey that authentication can be expected to operate within a given
context.  I should probably include this clarification in the 
carlberg-ets-* drafts as well.

> >> a single ISP and across the Internet

the understanding is that if it occurs, it would only be with those
providers that have been contracted to support the service.  outside
of that, its best effort the rest of the way.  

> >> would not be the normal case - I doubt that most ISPs

agreed.  the word "probability" was meant to avoid the direction or
the notion of absolute or guaranteed.  and as you point out, there can
be several solutions of how that could be achieved.  we have constant
reminders that these documents are not aimed at specific solutions, and
our hope was that this passage would reflect that.

> >> amount of network capacity to provide this service on

understood.  using the word "probability" should discourage the notion
that other resources would be starved.  we could add verbage to clarify
this some more.

> >> happens if there is too much emergency traffic for the 

understood.  if the above stays it will need additional clarity. 

> >> bridging - i.e. it is a gateway not a transport problem

there would seem to be a statement missing in the original passage.
we should convey the notion that a mapping must exist if there is
an expectation that services defined by different standards bodies
are expected to interoperate.  further, that this mapping can be
either in the form of internal policy within the gateway, or from
additional standards documents.

finally, as for items 6-10 in your subsequent email, I'll wait for
Hal to provide more incite/comments (and obviously others have 
provided their comments).

-ken

-ken

---

From: Scott Bradner <[email-masked]>
Date: Mon, 11 Nov 2002 10:16:40 -0500 (EST)

Ken - thanks for the thoughtful responses to my notes - I expect
a revised version of this document after the dicussion in Atlanta
will be a very helpful contribution to the understanding of
the ieprep issues

Scott

---

From: Bill Woodcock <[email-masked]>
Date: Mon, 11 Nov 2002 10:30:41 -0800 (PST)

> trying to further clarify this intent.

One thing you might look at as a way of defining the relationship is to
discuss it in terms of the business relationships which flow from the
Internet topology.  You're trying to get this into the ISP-customer
interface, it sounds like, in cases where the customer wants it; the
expectations of that interface are formalized in the transit contract.  So
saying something like "these suggestions may be of use to customers who
wish to receive GETS-like services, when negotiating their Internet
service provider's deliverables under the transit contract between ISP and
customer."

    > context.

By context, do you mean at the application layer, or within one ASN?

    > of that, its best effort the rest of the way.

That should be stated explicitly, so that customers who read the document
understand that their ISP cannot sell them an end-to-end service, no
matter how much they'd like to.

                                -Bill

---

From: Sean Donelan <[email-masked]>
Date: Mon, 11 Nov 2002 14:36:47 -0500 (EST)

> matter how much they'd like to.

Once a standard exists, will the FCC be asked to assit in gaining
compliance with the standard?

http://www.atis.org/pub/clc/niif/issues/0207.doc

Although words like voluntary are used, unless the capability is widely
deployed, it won't be very useful.  Its probably better to read the drafts
with the understanding you will be implementing them, one way or another.

---

From: Ken Carlberg <[email-masked]>
Date: Tue, 12 Nov 2002 09:15:24 +0000

>  So

ok, thanks.  small nit: it may be best to generalize the term "GETS-like
service" to take into account approaches like GTPS.

> By context, do you mean at the application layer, or within one ASN?

the context by which the authentication is being accomplished.  if at 
the application layer, then clearly an end-to-end issue.  we'll make 
sure this is clear in the next draft.

> matter how much they'd like to.

most definitely.

-ken

---

From: Ken Carlberg <[email-masked]>
Date: Tue, 12 Nov 2002 11:02:57 +0000

> with the understanding you will be implementing them, one way or another.

it depends on the capability and objectives one is speaking of.

folks running GETS will correct me on the following, but my understanding 
is that the NCS has business contracts with just a subset of telco 
carriers
to support additional functionality.  no contract, no special service.  
also, the current GETS system doesn't offer any special service within 
a land-line exchange.  finally, GETS doesn't allow preemption, just an 
increase in the probability that the call gets through -- with I believe 
caps on how many calls can receive the additional service.

taking a step back, this represents a nice design philosophy in that
added service does not have to span from end-to-end nor does it need
to be ubiquitous -- just try and focus on the perceived "hot spots".  
I would like to keep this philosophy in at least some of the drafts.

-ken

---

From: "Stuart (Stu) Goldman" <[email-masked]>
Date: Tue, 12 Nov 2002 05:52:05 -0700

Sean,

I am the Moderator of the NIIF. I was confused by your reference to NIIF issue
0207, as this issue is not asking the FCC for assistance.

Issue 0207 is part of a collection of related issues that are addressing call
failures. They seem to have some common characteristics such as wireless,
roaming, and toll free. We are in the process of working the issues by first
trying to get a better understanding of the failure mechanism and if there is a
common root cause. One high runner theory at the moment is that correct
population of the various SS7 IAM fields including the JIP may resolve the bulk
of the failures, although such a conclusion would be premature.

The NIIF invites contributions to help resolve our issues. The next meeting is
the week of Jan. 12, 2003. Please contact me or Maria Estefania directly if any
of you  have any interest.