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

From: "Gunn, Janet" <[email-masked]>
Date: Fri, 11 Oct 2002 10:40:38 -0400

Thanks for the clarification on mechanism.

I agree that we shouldn't care about the technology dependant differences in
policy.  

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.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Friday, October 11, 2002 7:52 AM
To: Gunn, Janet
Cc: King, Kimberly S.; Ieprep (E-mail)
Subject: Re: [Ieprep] IEPREP SIP REQ-1 to REQ-5

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

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
> underlying technology.

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

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 12 Oct 2002 15:35:47 -0400

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