Subject: RE: [Ieprep] IEPREP SIP REQ-1 to REQ-5

From: "Gunn, Janet" <[email-masked]>
Date: Wed, 2 Oct 2002 18:23:07 -0400

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

It might be productive to go through Henning's
http://www.ietf.org/internet-drafts/draft-ietf-ieprep-sip-reqs-00.txt
document to fix ideas and generate remarks on outstanding issues.  We can
take a phased approach where the first 5 requirements are listed below.
Requirements 1,4,5 seem pretty clear and I asked a few questions of 2 and 3.
Any comments?

REQ-1: Not specific to one mechanism or country: The mechanism
             should not be specific to one country or particular
             priority mechanism.  For example, there are currently at
             least four priority schemes in widespread use: Q.735, with
             five levels, the U.S. defense network and NATO with five
             levels, the United States GETS (Government Emergency
             Telecommunications Systems) scheme with implied higher
             priority and the British Government Telephone Preference
             Scheme (GTPS) system.

JPG - Are Q.735, US DOD and NATO two different schemes, or just different
names for the same schemes?
Any particular implementation MAY be specific to a particular country or
scheme.  And not all schemes will be supported across IP networks.  For
instance, I find it hard to see how GTPS (which essentially addresses who
gets "dial tone" could be implemented in, or across, an IP network.

        REQ-2: Independent of particular network architecture: The
             mechanism should work in the widest variety of SIP-based
             systems. It should not be restricted to particular
             operators or types of networks, such as wireless networks
             or protocol profiles and dialects in certain types of
             networks.

How would one know if a proposed solution met REQ-2?  If not restricted to
particular operators or types of networks, does it mean it should work for
all?

The document lists 4 network models and 4 hybrid networks (or topologies).
Does "network architecture" refer to these previously introduced items?

JPG does this mean it should be consistent with the standardized protocol,
and not take advantage of customizations or proprietary enhancements?

        REQ-3: Invisible to IP network: It should be possible to use the
             mechanism in IP networks that are unaware of the mechanism
             and in restricted networks. Obviously, such networks will
             not be able to provide enhanced services.

Is "restricted network" the Restricted SIP networks defined earlier?  If it
must be possible to use the mechanism in restricted SIP networks yet in
those networks 
            "users may
             be restricted to particular SIP applications and cannot add
             SIP protocol elements such as header fields or use SIP
             methods beyond a proscribed set ", 
does this mean that the mechanism must be part of the default set of
allowable applications and protocol elements?  I recognize "such networks
will not be able to provide enhanced services" but I'm trying to understand
how the mechanism should be able to be used even if users are restricted
from adding protocol elements without the mechanism being part of the
default set.

        REQ-4: Usage of existing namespaces: Since there are a number of
             existing resource priority schemes for both the PSTN and
             private networks, it is likely that converged or VoIP
             networks will inherit these naming schemes.

        REQ-5: No loss of information: For the CN-IP-CN case, there
             should be no loss of signaling information caused by
             transiting the IP network.
_______________________________________________
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: "Gunn, Janet" <[email-masked]>
Date: Mon, 14 Oct 2002 09:31:45 -0400

I absolutely agree that the ORIGINATOR should not have to worry about
different mechanisms/policies on different parts of the path.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Saturday, October 12, 2002 3:36 PM
To: Gunn, Janet
Cc: King, Kimberly S.; Ieprep (E-mail)
Subject: Re: [Ieprep] IEPREP SIP REQ-1 to REQ-5

> I CAN see, though that it would make sense to implement, for instance,
> multiple priority classes when you have low bandwidth connections to be
> shared, and a single priority class when you have high bandwidth
connections
> to be shared, even if the relative utilization is the same.  I think these
> would count as different policies.

In those cases, I would favor declaring multiple classes and have 
devices that can confidently predict that they don't need this, merge 
multiple priorities into one. That way, the originator doesn't have to 
worry about the remote details and it only affects behavior of the one 
party with intimate knowledge of the local circumstances. This is indeed 
a good example of a different mechanism that achieves the policy goal 
("good treatment for the high-priority folks") with a locally-optimized 
mechanism ("do nothing special for them").