Re: [MEDIACTRL] MRB Publish interface suggestion

Lorenzo Miniero <lorenzo@meetecho.com> Mon, 23 May 2011 09:44 UTC

Return-Path: <lorenzo@meetecho.com>
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D14E076A for <mediactrl@ietfa.amsl.com>; Mon, 23 May 2011 02:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level:
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JV-SnHMYS8Y for <mediactrl@ietfa.amsl.com>; Mon, 23 May 2011 02:44:01 -0700 (PDT)
Received: from smtplq04.aruba.it (smtpweb21.aruba.it [62.149.158.21]) by ietfa.amsl.com (Postfix) with SMTP id 430B6E06F7 for <mediactrl@ietf.org>; Mon, 23 May 2011 02:43:59 -0700 (PDT)
Received: (qmail 11621 invoked by uid 89); 23 May 2011 09:43:55 -0000
Received: from unknown (HELO smtp3.aruba.it) (62.149.158.223) by smtplq04.aruba.it with SMTP; 23 May 2011 09:43:55 -0000
Received: (qmail 18591 invoked by uid 89); 23 May 2011 09:43:55 -0000
Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@79.30.35.197) by smtp3.ad.aruba.it with SMTP; 23 May 2011 09:43:54 -0000
Date: Mon, 23 May 2011 11:43:53 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Chris Boulton <chris@ns-technologies.com>
Message-ID: <20110523114353.50717b8d@rainpc>
In-Reply-To: <4DD52562.9020100@ns-technologies.com>
References: <2F41EF28ED42A5489E41742244C9117C03CD9A8B@gaalpa1msgusr7b.ugd.att.com> <4DD52562.9020100@ns-technologies.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtp3.ad.aruba.it 1.6.2 0/1000/N
X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N
Cc: mediactrl@ietf.org
Subject: Re: [MEDIACTRL] MRB Publish interface suggestion
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 May 2011 09:44:02 -0000

I'm ok with it as well, it sounds like a reasonable improvement which wouldn't add any additional or unrequired complexity to an implementation.

L.


On Thu, 19 May 2011 15:12:50 +0100
Chris Boulton <chris@ns-technologies.com> wrote:

> Gary - this seems reasonable to me.  Unless anyone objects I will look 
> at weaving into the text and submit a new version (which will also 
> include some final edits).  Any thoughts?  Shout.
> 
> On 13/04/2011 11:33, MUNSON, GARY A (ATTSI) wrote:
> > Thanks for posting mrb-08.
> >
> > I have one modification to suggest for the Publish interface.
> >
> > Currently the Publish subscription element has a 'frequency' child
> > element that says how often the MRB wants to receive notifications from
> > an MS on status of its resources.
> >
> > I find myself wondering whether a notification interval range min and
> > max might be more useful than frequency. I.e., so that the MRB would
> > tell the MS that the interval duration from the last notification to the
> > next notification should be no more than X seconds and no less than Y
> > seconds.
> >
> > That way the MS could optionally be allowed to decide, within
> > constraints, how often to send notifications to MRB. So, for example,
> > when things are working normally the MS might send updates every 30
> > minutes, but if all of a sudden its real time consumption gets clobbered
> > because of some system emergency audit running and the effective number
> > of idle ports is seriously diminished, it can send a next event
> > notification much sooner.
> >
> > Specifying max/min values instead of a single frequency adds a tiny bit
> > of complexity to the Publish interface but could have a significant
> > benefit. And one could still specify a single frequency by setting min
> > and max to the same value.
> >
> > BR,
> >
> > Gary
> >
> > Gary Munson
> > AT&T
> > _______________________________________________
> > MEDIACTRL mailing list
> > MEDIACTRL@ietf.org
> > https://www.ietf.org/mailman/listinfo/mediactrl
> > Supplemental Web Site:
> > http://www.standardstrack.com/ietf/mediactrl
> >
> 
> -- 
> Chris Boulton
> CTO & Co-founder
> NS-Technologies <http://www.ns-technologies.com>
> m: +44.7876.476681


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com