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

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 10 Oct 2002 17:05:34 -0400

I am a little confused about the relationship between "protocol", "policy",
and "mechanism".

It seems to me that the "protocol" should definitely be independent of the
underlying technology (cable, 3GPP, etc.).

But similarly, it seems that the policy might very well be specific to the
underlying technology.

And I am not sure what is meant by "mechanism".

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

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

>         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?

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.)
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 11 Oct 2002 07:52:16 -0400

> underlying technology (cable, 3GPP, etc.).

By protocol in this context, I mean, SIP, since that's the subject of 
discussion. SIP is indeed completely oblivious as to whether it's 
running on 3GPP, cable or wet string, ignoring the desire by the Wet 
String Consortium to insert various special extensions into SIP.

> But similarly, it seems that the policy might very well be specific to the

I see no reason why it should be or, even if it is, why we should care. 
Even if it were the case that wet string gateways always and only 
support policy A (and nobody else does), the negotiation mechanism (as 
required by the requirement document) will discover this, without the 
originating side having to know or care that part of the path is made of 
twine and another of rubberbands. This avoids tying things together that 
shouldn't be. Thus, if wet strings suddenly support policy B in addition 
to A, the system can handle it. If rubber bands also are enhanced to 
support policy A, again, no need to encode the knowledge of rubber bands 
into every SIP device.

> And I am not sure what is meant by "mechanism".

The "how": how a policy is translated into concrete actions. Think of

policy = speed limit is 55 mph
mechanism = radar traps, police cruisers, speeding tickets