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

From: "King, Kimberly S." <[email-masked]>
Date: Mon, 30 Sep 2002 13:06:07 -0400

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.

        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?

        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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Sep 2002 19:58:43 -0400

General remark: finding reasonable compromise between being unduly 
specific and uselessly vague is hard. Thus, concrete wording suggestions 
are always appreciated.

> particular operators or types of networks, does it mean it should work for

While you probably can't prove that something can work in every single 
network that anybody could ever dream up, you will definitely know when 
REQ-2 is *not* met. Without naming names, this is meant to ensure, for 
example, that there is no 3GPP-specific or PacketCable-specific 
solution. (Both organizations use SIP, with extensions, in their 
respective architectures, for 3G wireless and cable modems.)

> Does "network architecture" refer to these previously introduced items?

No, it refers to the protocol profiles and extensions mentioned in the 
paragraph.

> Is "restricted network" the Restricted SIP networks defined earlier?  If it

Left-over terminology from an earlier version. Restricted here means 
networks that are only SIP/RTP transparent. I'll modify the wording. 
(This is in line with the 'invisible to IP network', which might be 
better phrased as 'invisible to network (IP) layer'.)

> from adding protocol elements without the mechanism being part of the

See above.