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

From: "King, Kimberly S." <[email-masked]>
Date: Mon, 30 Sep 2002 14:03:52 -0400

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.

        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.

        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?

        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).  

"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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Sep 2002 20:15:02 -0400

> something satisfying the above requirement?

Yes, regular SIP default would be. Maybe saying this explicitly would 
help :-)

Translated, this means if you use a priority label that the network 
can't grok, the caller should be no worse off than if you had used no 
label. New wording suggestion:

"Network terminals configured to use a
priority scheme may occasionally end up making calls in a network that
does not support such a scheme.  In those cases, the protocol must
support a sensible default behavior that treats the call no worse than a
call that did not invoke the priority scheme."

> potential requirement in another thread covering this requirement).  

Indeed. I'll say that explicitly.

> name spaces or enough to be tell the name space is not supported)?

Not really. It could just mean that one should be able to find out if a 
network element supports any scheme. If the network element doesn't 
support the scheme at all, it can return the protocol equivalent of 
"Huh?", without having a clue whether this was a feature asking for 
priority treatment or a Big Mac.