Subject: RE: [Ieprep] overall issues and REQ-11 thru REQ-15

From: "King, Kimberly S." <[email-masked]>
Date: Wed, 2 Oct 2002 12:39:53 -0400

inline

> -----Original Message-----
> From: Ken Carlberg [mailto:[email-masked]]
> Sent: Wednesday, October 02, 2002 12:07 PM

> 
> > Do the requirements assume any underlying relationship 
> between the local IP
> > network or SIP carrier and the user?  Should they? 
> 
> which "requirements" are you referring to?  I ask because you talk of
> MLPP and the Pierce draft (which imo is presented more in terms of
> describing a service, and not really a set of requirements) as well
> as Henning's draft.
> 

I'm hoping that the requirements to be given to SIP/SIPPING will represent
the requirements of the ieprep community (thus include the Assured Service
needs).  
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 3 Oct 2002 15:51:42 -0400

>         REQ-11: Identity-independent: The user identity is insufficient
>              to identify the priority level of the request. The same
>              identity can issue non-prioritized requests as well as
>              prioritized ones, with the range of priorities determined
>              by the job function of the caller. The choice of the
>              priority is made based on human judgement, following a set
>              of general rules that are likely to be applied by analogy
>              rather than precise mapping of each condition. For example,
>              a particular circumstance may be considered similarly grave
>              compared to one which is listed explicitly.
> 
Also, as we discussed in other venues, I think it would be very useful 
if one could separate the notion of identity from privilege.

[JPG]  In the US, the FCC has made it clear that any priority service on the
PUBLIC CSN must be invoked on a call by call basis, not just on the basis of
the identity of the user or the instrument.  To the extent that IP telephony
services will wish to interface  with the US public phone network, it is
ESSENTIAL that the notion of identity be separated from the notion of
privilege.

---

From: [email-masked]
Date: Fri, 4 Oct 2002 13:30:40 EDT

In a message dated 10/2/2002 11:31:36 AM Eastern Standard Time, 
[email-masked] writes:

> First, some overall issues:  
> 
> High-level Question:
> 
> What involvement is needed by the local IP network or SIP carrier
> for the user to make use of a gateway's ability to invoke GETS, MLPP or some
> other service on the CSN?
> 
> <snip>
> 
> CASE B:  The gateway does support the priority scheme.  At that point, it is
> a matter of policy, if the gateway and user do some exchange
> authentication/authorization and gives the user preferential access to a
> gateway port.  Then the 710 call is routed to the CSN.  The IP network or
> SIP carrier may have no particular relationship with the user.
> 

[MAP] As described above in Case B, seems this is a case in which the gateway 
supports only a part of the service (authenticates the user who dialed 710-, 
but doesn't handle entry of the actual destination number. As commented 
before, this should not be an accaptable operation, since it requires the 
user to perform 2 authentication functions, one with the gateway and one with 
the CSN that gets the 710- call and then requests entry of the real 
destination number.

> <snip>
> 
> When moving MLPP to an IP environment (a.k.a. Assured Service) then it
> appears
> http://www.ietf.org/internet-drafts/draft-pierce-sipping-assured-service-02.
> txt
> 
> "It must be possible to verify that the calling party is authorized to
>    use the Assured Service and the requested precedence level value and
>    to take the appropriate action if the calling party attempts to use a
>    higher level."  
> The network operator and the assured service user seem to have a known
> established relationship.  It is my understanding (and I could be wrong)
> that Assured Service is to be deployed on a priviate network where the local
> IP networks and SIP carrier have an known relationship with the user.
> 

[MAP] This basic requirement to authenticate the user may be satisfied in 
different ways. Yes, Assured Service is intended for a "private network", but 
unfortunately, that term is losing its meaning, or becoming non-explicit. 
Yes, the network operator and the user must have a known relationship. (Note 
that this presumes that there really is a "network operator" here.)

> Do the requirements assume any underlying relationship between the local IP
> network or SIP carrier and the user?  

[MAP] Yes, there must also be a known relationship here.

> Onward...the remaining requirements
> 
> Comment:  I think we are in new territory here.  With MLPP, certain lines
> are provisioned to be able to make calls at a prescribed level(s).  With
> traditional landline circuit-switched GETS, the user identity (+ PIN) is
> sufficient to identify the priority of the call.  In the U.K's Government
> Telephone Preference Scheme, lines are divided into classes to determine
> what lines get to place outgoing calls.  So, I presume REQ-11 is directed
> 

[MAP] GETS had only one level because of the signaling limitations at the 
time. IEPS should be approached from the assumption that some users would 
need multiple levels, like MLPP, so that the priority is not automatically 
implied by the user identity.

<snip>
> 
>         REQ-15: Testing: It must be possible to test the system outside
>              of emergency conditions, to increase the chances that all
>              elements work during an actual emergency. In particular,
>              critical elements such as indication, authentication,
>              authorization and call routing must be testable.
> 
> I suspect what is really being requested is that the mechanism isn't
> something that is switched on only during emergencies but rather something
> that is always available if requested (and hence can be tested outside of
> 

[MAP} One could instead state the obvious requirement: "The system must be 
turned on at all times, that is, it must not require service provider actions 
to enable its use."

Mike Pierce
Artel

---

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 10 Oct 2002 15:28:11 -0400

-----Original Message-----
From: Ken Carlberg [mailto:[email-masked]]
Sent: Wednesday, October 02, 2002 12:07 PM
To: King, Kimberly S.
Cc: Ieprep (E-mail)
Subject: Re: [Ieprep] overall issues and REQ-11 thru REQ-15

> GETS Example:  User wishes to place GETS call from SIP phone to a phone in
> the CSN (via a gateway).
> 
> CASE A:  The gateway doesn't support the priority scheme.  It sure might
be
> nice if it understood that 710 was a valid area code and routed this to
the
> CSN for authorization and preferential treatment in the CSN using GETS.
The
> IP network or SIP carrier may have no particular relationship with the
user.

the 710 number and whatever services associated with it are two different
and cascading items.  710 should be recognized by all LECs, CLECs, etc
within the US.  additional high probability of completion (HPC) services 
is in addition to that and may exist depending on the service contracted
by the customer (ie, US govt).

[JPG] SHOULD is the operative word.  Unfortunately it is not something that
is guaranteed.  For that reason, there may also be other dialed sequences
(e.g., 800 numbers) that also invoke GETS.  The gateway should also
correctly handle those invocations (though it may "think" it is just
invoking an 800 call).  
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep