Subject: [MEDIACTRL] Re: WG Review: Media Server Control (mediactrl)

From: Eric Burger <[email-masked]>
Date: Wed, 21 Feb 2007 04:53:11 -0800

We had not considered the control framework to be a management framework.
Rather, we see it as a repeatable design pattern for how to find and
establish protocol connections to a media server.  What indicates that it is
a management protocol?  We do expect to use existing SNMP methods for the
input to the broker protocol.  However, that is passive monitoring and not
provisioning.

Have we missed something?

Good point on the milestones; check out the message to Magnus to see if
we've addressed the issues.

Thanks.

On 2/19/07 8:14 AM, "Pekka Savola" <[email-masked]> wrote:

> On Tue, 13 Feb 2007, IESG Secretary wrote:
>> Given the wide acceptance of the media server, we need a standard
>> way to control them.
> 
> This, and taking a look at draft-boulton-sip-control-framework-05.txt
> which seems to be relevant here, seems to imply this group is about to
> build a management framework for SIP services.  I'm not sure if such a
> framework has been chartered yet in other WGs, and if not, this would
> be the first time, bearing closer scrutiny how to do it correctly.
> 
> How much the manamgement part of O&M has been consulted?  What is the
> model of co-operation with the IETF management expertise?
> 
>> MILESTONES
>> 
>> APR 2007 Requirements Document
>> JUN 2007 Framework Document
>> NOV 2007 Conference Control Protocol
>> MAR 2008 IVR Control Protocol
>> JUN 2008 Broker Protocol or BCP
> 
> These are horribly vague.  Are the dates for WG adoption?  WGLC?
> Shipping off to the IESG?

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

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

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 21 Feb 2007 20:47:12 +0200

To help Pekka here, from an operator's perspective the difference
between 'control' and 'management' is quite blurred, as long as the same
type of functionality happens in an operational deployment. Speaking as
an individual I believe that your approach may be correct, but it's
better that the relationship with what you call management protocols and
their role in providing complementary functionality is explicitly
spelled out in the charter and framework documents. 

Dan

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]] 
> Sent: Wednesday, February 21, 2007 2:53 PM
> To: Pekka Savola
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: WG Review: Media Server Control (mediactrl) 
> 
> Rather, we see it as a repeatable design pattern for how to 
> find and establish protocol connections to a media server.  
> What indicates that it is a management protocol?  We do 
> expect to use existing SNMP methods for the input to the 
> broker protocol.  However, that is passive monitoring and not 
> provisioning.
> 
> Good point on the milestones; check out the message to Magnus 
> to see if we've addressed the issues.
> 
> Thanks.
> 
> 
> >> Given the wide acceptance of the media server, we need a 
> standard way 
> >> to control them.
> > 
> > This, and taking a look at 
> draft-boulton-sip-control-framework-05.txt
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
> 
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
>