Subject: Re: [Ieprep] policy & labels

From: [email-masked]
Date: Fri, 11 Oct 2002 10:31:09 EDT

In a message dated 10/11/2002 8:41:39 AM Eastern Standard Time, 
[email-masked] writes:

> > So why is this now such a big deal? I think this whole thing about 
> "policy" 
> > vs" "label" (or "indication") is a non-issue and should be dropped so we
> > can get on with defining what is needed. 
> 
> the consensus on this list and at meetings has been that policy vs
> label is an issue.  

[MAP] Yes, I understand that the "consensus" has been that "policy" vs label" 
is an issue, but I think that the ongoing discussion indicates that no one 
knows what the issue is, or at least, everyone has a different idea of what 
it means. This is getting no where fast.

> my hope is that

[MAP] Yes, I guess Henning's comments are helping to make something clear 
(they usually do), but I still don't see what the impact is to the task at 
hand which is to define a way to carry an indication of the priority level of 
the call through SIP.

> 
> > 0 = treatment a 
> > 1 = treatment b 
> > 
> > and the "policy" in each device (not in the standard) would somehow
> > know that: 
> > a = normal delay 
> > b = low delay needed 
> 
> > If that approach were followed for every field or piece of information 
> > in the protocol, the specification would look pretty silly, and I 
> > seriously doubt that sufficient interoperability would ever occur. 
> 
> 

[MAP] It may be an incorrect interpretation, but it is not "poor". I really 
couldn't tell what you were trying to say, and the comments indicate that 
others couldn't either.

Mike Pierce
Artel

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 11 Oct 2002 10:51:47 -0400

On Friday, Oct 11, 2002, at 10:31 America/Montreal, [email-masked] 
wrote:
>
> [MAP] Yes, I guess Henning's comments are helping to make something 
> clear (they usually do), but I still don't see what the impact is to 
> the task at hand which is to define a way to carry an indication of 
> the priority level of the call through SIP.

That task is OUT OF SCOPE for the general IEprep Requirements document.

It might be IN SCOPE for a telephony-specific requirements document,
depending on how detailed one wanted to get.  Requirements should be
high-level, so independent of particular protocols (e.g. SIP).

Something in SIP itself (or in DiffServ itself) would be an example
of a *mechanism*.  High-level requirements must not specify mechanisms.

Ran
[email-masked]

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

---

From: Ken Carlberg <[email-masked]>
Date: Fri, 11 Oct 2002 15:57:11 +0100

> [MAP] Yes, I understand that the "consensus" has been that "policy" vs 
> label" is an issue, but I think that the ongoing discussion indicates 
> that no one knows what the issue is, or at least, everyone has a 
> different idea of what it means. This is getting no where fast. 

I don't agree with your assessment that no one knows what the issue is.

> [MAP] It may be an incorrect interpretation, but it is not "poor". I 
> really couldn't tell what you were trying to say, and the comments 
> indicate that others couldn't either. 

actually, the use of the word "poor" in the previous message, was a poor 
choice of words on my part.  so, my apologies.

my original comment was meant as a starting point.  it was stated in
a general sense, and as it has been mentioned in the past, there can be
a tradeoff by not being too specific.  

as for Henning's response, it seemed more of an extension of my original
thread with some additional thoughts regarding SIP.  I don't recall a
comment of confusion on his part (though if he wants to add that now in
retrospect, thats fine).  and I regret that my attempt to provide some
help has continued the confusion for you.

regards,

-ken

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Oct 2002 02:29:46 -0400

[General comment; addresses multiple documents]

Just for clarification: the document that triggered this discussion was
the requirements document authored by myself, which is specifically
meant to be handed to the SIPPING WG and thus addresses SIP
specifically. I suspect that mentioning of analogies in other arenas,
such as DSCPs, might have gotten us into the non-SIP space. The general
requirements document presumably addresses those, although it is not
clear (to me) as to who these requirements are currently addressed to.
We seem to have at least three different types of things that get tagged
with the label 'requirements':

(1) Things we believe networks (operators) should do, using existing
technology.

(2) Additional protocol requirements for existing protocols (such as SIP).

(3) Requirements calling for new protocols.

We clearly have one document in class 2 (for SIP), but it might help if
we could more clearly agree which parts of the other documents fall into
(1) or (3). As far as I can tell, we don't have much in category (2) and 
(3), except possibly concerns except concern expressed at the last WG 
meeting  that applying DiffServ at the packet level is
unwise without a yet-to-be-specified admission control mechanism.

Henning

RJ Atkinson wrote:
 >>  clear (they usually do), but I still don't see what the impact is
 >> to the task at hand which is to define a way to carry an indication
 >> of the priority level of the call through SIP.
 >
 >
 > Ran [email-masked]
 >
 > _______________________________________________ Ieprep mailing list
 > [email-masked] https://www1.ietf.org/mailman/listinfo/