Subject: RE: [Ieprep] IEPREP SIP REQ-6 to REQ-10

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 3 Oct 2002 11:40:21 -0400

-----Original Message-----
From: King, Kimberly S. [mailto:[email-masked]]
Sent: Monday, September 30, 2002 2:04 PM
To: Ieprep (E-mail)
Subject: [Ieprep] IEPREP SIP REQ-6 to REQ-10

Below are additional requirements from Henning's document
http://www.ietf.org/internet-drafts/draft-ietf-ieprep-sip-reqs-00.txt .  I
asked questions of 9 and 10.  Any comments on any of these requirements?

        REQ-6: Extensibility: New naming schemes may need to be defined
             as resource priority mechanism are applied in additional
             private networks, or if a VoIP-specific priority scheme is
             being defined.

[JPG] New priority schemes may be  defined in the Circuit Switched Network,
and will need to be able to interact with IP networks

        REQ-7: Separation of indication and policy: The indication
             should not describe a particular detailed treatment, as it
             is likely that this depends on the nature of the resource
             and local policy.  Instead, it should invoke a particular
             named policy. As an example, instead of specifying that a
             certain SIP request should be granted queueing priority,
             not cause preemption, but be restricted to three-minute
             sessions, the requests invokes a certain named policy that
             may well have those properties.

[JPG] Just a side note that this distinction also exists in the CSN side.
For instance setting the Precedence (aka MLPP) parameter results in quite
different behavior in a GSM mobile carrier's (wire line) network from the
behavior in a DOD network.  This also means that a CSN/IP gateway may need
to consider the source/destination of the indication in implementing any
associated policy.

        REQ-8: Request-neutral: The mechanism chosen should work for any
             SIP request, not just, say, INVITE. It is then a matter of
             policy as to whether marking a particular SIP request leads
             to differentiated treatment or whether a particular SIP
             request needs to request such treatment by non-SIP means.

        REQ-9: Default behavior: Network terminals configured to use
             priority scheme may occasionally end up making calls in a
             network that does not support such a scheme or the terminal
             may have an older list of priorities in a namespace. In
             those cases, the protocol must support a sensible default
             behavior that maximizes the chance for call completion
             without compromising network integrity.

What is a sensible default behavior that maximizes the chance for call
completion under circumstances where networks or terminals don't understand
the scheme or have outdated information?  Is regular SIP default call setup
an acceptable solution?  If not, does someone have an example solution of
something satisfying the above requirement?

[JPG] Again, a side note that may or may not be directly relevant. In the
CSN, some priority schemes are "fail open" and some are not.  I suspect a
single type of "default behavior" for all priority schemes involving IP
Telephony will not be appropriate.  

        REQ-10: Address-neutral: The mechanism cannot rely on
             identifying a set of destination addresses or URI schemes.
             For example, in GETS-like schemes, the caller can reach any
             PSTN destination with increased probability of call
             completion, not just a limited set.

It appears REQ-10 adds that any address or URI scheme is a valid
destination.  Let's assume REQ-14 is accepted (we can later debate this
potential requirement in another thread covering this requirement).  

[JPG] Another  side note/clarification.  In a "GETS-like scheme", it may not
be true that  "the caller can reach any PSTN destination with increased
probability of call completion."  For instance, some users may be authorized
to make international GETS calls, and other users may be restricted to
domestic GETS calls.  But it is certainly true that the mechanism cannot
rely on a pre-identified set of destinations.

"REQ-14: Discovery: A terminal should be able to discover which
             priority name spaces are supported by a network element.
             Discovery may be explicit, where a user agent requests a
             list of the supported name spaces or it may be implicit,
             where it attempts to use a particular name space and is
             then told that this name space is not supported."

Does REQ-10, taken along with  REQ-14, say all network elements must
understand the mechanism (at least enough to provide a list of supported
name spaces or enough to be tell the name space is not supported)?
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Oct 2002 12:36:38 -0400

> and will need to be able to interact with IP networks

Noted.

> to consider the source/destination of the indication in implementing any

Noted.

> Telephony will not be appropriate.  

Certainly.

> rely on a pre-identified set of destinations.

The "cannot rely on a pre-identified set" is the main point I'm trying 
to make here. Any restrictions would be a matter of local policy, but 
not a protocol mechanism.