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

From: [email-masked]
Date: Wed, 9 Oct 2002 09:04:50 EDT

In a message dated 9/30/2002 2:10:22 PM Eastern Standard Time, 
[email-masked] writes:

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

The above seems so intuitively obvious to me that I wonder why it is even 
necessary to state it. Or else, maybe it has some completely different 
meaning or connotation than what I think it means.

I don't think I have heard any proposal, nor can I think of one, that would 
not comply with this, but I'm afraid it means something more to someone. I 
believe there was a comment once, which I took as only half serious, to the 
effect that one would not code a priority as "Queue me first, preempt lower 
priority traffic, don't drop my packets". (Of course, SIP actually allows 
coding like this!)

If two priority values are "low" and "high", would someone claim that this 
violates the above requirement? The "indication" certainly describes 
something about the treament.

Mike Pierce
Artel

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Oct 2002 09:24:55 -0400

> The above seems so intuitively obvious to me that I wonder why it is 
> even necessary to state it. Or else, maybe it has some completely 
> different meaning or connotation than what I think it means.

There was fear that this might not be obvious to all.

> 
> I don't think I have heard any proposal, nor can I think of one, that 
> would not comply with this, but I'm afraid it means something more to 
> someone. I believe there was a comment once, which I took as only half 
> serious, to the effect that one would not code a priority as "Queue me 
> first, preempt lower priority traffic, don't drop my packets". (Of 
> course, SIP actually allows coding like this!)
> 
> If two priority values are "low" and "high", would someone claim that 
> this violates the above requirement? The "indication" certainly 
> describes something about the treament.

I think the litmus test is that one should be able to specify, for each 
such label, at least two independent and interoperable implementations 
that are different in the behavioral details (such as queueing, 
dropping, rerouting, traffic controls, etc.).

On the other hand, I don't think we can rule out that if some 
three-letter agency specifies the implementation precisely ("must 
implement absolute priority with preemption of existing calls"), that 
this is always achievable.

The classical example that would not necessarily satisfy this 
requirement would be the old IPv4 TOS bits ("low delay", "high 
reliability").

Also, in order to make progress, it may be useful to "forgive" some 
obviousness in the document and heave this thing (after another round) 
over the fence to SIPPING, even if one could save a few bytes in the RFC 
and I-D archive.

> Artel

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

---

From: Ken Carlberg <[email-masked]>
Date: Wed, 09 Oct 2002 14:48:59 +0100

> over the fence to SIPPING, even if one could save a few bytes in the RFC 

yes, please do!!! 

-ken