Re: AW: [Dcpel] FWD: [Re: proposed charter]

"James M. Polk" <> Thu, 09 March 2006 17:40 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FHP8F-0000Yl-4n; Thu, 09 Mar 2006 12:40:59 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1FHP8E-0000Yd-DF for; Thu, 09 Mar 2006 12:40:58 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1FHP8E-0001N6-2f for; Thu, 09 Mar 2006 12:40:58 -0500
Received: from ([]) by with ESMTP; 09 Mar 2006 09:40:57 -0800
X-IronPort-AV: i="4.02,179,1139212800"; d="scan'208"; a="260824174:sNHT32062590"
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id k29Hev1l011763; Thu, 9 Mar 2006 09:40:57 -0800 (PST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 09:40:57 -0800
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 09:40:56 -0800
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 09 Mar 2006 11:40:55 -0600
To: Kathleen Nichols <>, "Tschofenig, Hannes" <>,
From: "James M. Polk" <>
Subject: Re: AW: [Dcpel] FWD: [Re: proposed charter]
In-Reply-To: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 09 Mar 2006 17:40:56.0587 (UTC) FILETIME=[9EDED5B0:01C643A0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for possible diffserv control plane elements WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


Long ago the IESG made the decision in the SIP community to break that WG 
up into two parts: SIP and SIPPING.  SIPPING handles the requirements and 
the "how to use SIP" aspects, and SIP focuses on the core specification and 
extending the protocol.

The reason I bring up that analogy is that what I read from you below is 
saying that you aren't particularly interested, not cavalierly, but for a 
reason, in how your "control" is sent around the Internet.  You're working 
on what to do with whatever control there can be when it gets to the 
destination elements.  Is this about right?

If so, taking the SIP example, you're looking at more of a "how to use 
*Diffserv* to elicit a level of control of traffic behaviors traversing 
elements in a domain" - which to me, is a BCP of what exists already.

If you do not have the necessary pieces or parts to write this BCP of how 
to do something regarding control and mgmt of QoS within a domain or 
interdomain, then the appropriate protocols need to be extended in order to 
get you (said in general terms) the tools to write an appropriate BCP.

This seems like it can be accomplished in one of two ways:

#1 - individual submissions into each protocol WG that will enable the 
functionality you seek


#2 - create a WG designed to extend, within that new WG, each protocol that 
will enable the functionality you seek.

Then, after all this is done, this BCP (or two) can be written.

Perhaps one for Intra-domain control and mgmt, and one for Inter-domain.

I think the endgame of this list is these two documents, the first of which 
you agreed to tackle, and the latter is what a few others on the list want 
to tackle right away too.

I believe there are more than a few out there that believe what you 
(speaking generally) need is a hub-and-spoke communication protocol to 
carry your control, which may or may not exist yet; but if it does, it 
certainly needs extending, which ought to occur first.

At 07:56 AM 3/9/2006 -0800, Kathleen Nichols wrote:

>So, I really must reply, in brief, to Hannes's email. It seems
>to be all about signaling. In my opinion, this has been a big
>problem in the QoS area in general and particularly at the IETF.
>That is, spending time talking about what information is going to
>be sent around and in what sort of containers rather than how to
>manage and control IP differentiated services. If the right
>information is being sent, then a useful control and management
>structure should be able to use it. But it seems like we need to
>have an infrastructure that is capable of realizing services on
>an IP network before we worry overly much about what is being
>sent. Particularly since signaling is not required for all
>         Kathie
>Dcpel mailing list

Dcpel mailing list