Subject: [Sipping] (no subject)

From: Rohan Mahy <[email-masked]>
Date: Wed, 6 Mar 2002 10:41:01 -0800 (Pacific Standard Time)

Peter,

My comments inline with ##

Peter Blatherwick said:
------------

First, I'd like to reiterate I believe this is important work to
undertake in some way in IETF, and overdue.  In this I include
not just the specific I-D on ep-config which this thread has
focused on, but also the other recently posted I-Ds on end-user
device requirements and auto-config framework.  I believe all
three should be treated together since they are strongly related,
however probably want to stay as separate documents to make them
easier to decide.

I would VERY MUCH like to see this as an agenda item for SIPPING
at IETF-53.  Chairs listening?

## as a SIPPING chair, yes I am listening.  Since we are discussing issues
and not drafts, there is a slot allocated for configuration issues.  I
asked Dan Petrie to present on these issues, also including issues raised
in draft-petrie-sip-config-fw, and draft-sinnreich-sipping-device-reqs
##

I resonate with some of the sentiments that seem to have been
coming out.  (I hope this is not just my rose coloured glasses
acting up again!)  Specifically:
- That we need a framework (or set of frameworks) that allow for
  multiple interoperating device classes to be defined (name
  spaces approach seems a good start)
- That the specs must be written to both enable interop and allow
  innovation (i.e. set minimal requirements, not constraints)
- That we are probably talking about some sort of set of profiles
  in the end, even though that particular "p" word often attracts
  negative attention in IETF

I think the *first* profile we should be going after, however, is
definitely phone-like devices, since that is both difficult (due
to tight footprint constraints) and most urgently needed for mass
deployment.
## (as an individual) I agree

In general the specs should be written in the form:
   *IF* you wish to comply with X (profile, method, whatever),
   then you MUST/SHOULD do the follow
   and MAY do more."
(The device requirements I-D in particular is currently not
written well in this way IMHO.)
## (as an individual) I agree

What about creating a BCP (or set of them)?  Just a random
thought.
## as a chair and an individual, i agree that a BCP would be the best
route
##

thanks,
-rohan

All that good stuff said, I have loads of comments on the drafts
themselves.  However, lets decide if we wish to address this area
before we get to the what and how....

-- Peter Blatherwick

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: March 5, 2002 10:20
To: Daniel G. Petrie
Cc: [email-masked]
Subject: RE: [Sipping] I-D
ACTION:draft-stredicke-sipping-ep-config-00.txt

One approach might be to first define the method or methods for telling an
endpoint about an arbitrary set of parameters. Make your current list of
parameters more into a set of example scenarios that justify the
requirements of an arbitrarily extensible configuration method. Of course,
even this mechanism may need to vary by domain.

Then build profiles of recommended parameters for specific application
domains. Support of specific profiles would be entirely optional from the
specification perspective, but perhaps not so optional from a market
perspective.

> -----Original Message-----
> From: Daniel G. Petrie [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 12:37 AM
> To: Ben Campbell
> Cc: [email-masked]
> Subject: Re: [Sipping] I-D
> ACTION:draft-stredicke-sipping-ep-config-00.txt
>
>
> I think your point on application domains is a valid one.  We
> have certainly focused on configuration that effect the phone-like
> behaviors.  One of the outstanding issues was what about presence
> and IM.  One could argue that  rigid domains or segmentation of
> data categories will inhibit innovation.  Some of the interesting
> applications might be the blurring of domains.
>
> As an UA vendor I am also very sensitive to differentiation, innovation
> and creativity.  The last thing I want to do is create a flat commodity
> based product space for SIP UAs.  However I feel the pain
> of my customers who have heterogeneous UA environments.
> I am frequently hearing the refusal to deploy anything beyond
> trial volumes of USA with out a stadard means to configure
> and deploy them.  I think that we have tried very hard to
> allow extensions and creativity in configuration.  This is a
> delicate balance all standards should try to achieve. We
> are certainly open to ways we can improve the openness of
> the configuration mechanism.
>
> I appreciate your input.
> Thanks
>
> Ben Campbell wrote:
>
> > I must admit sort of a general discomfort with the proposal. My
> concern is,
> > standards on how we configure an endpoint by necessasity create
> constrains
> > on endpoint capabilities, metaphors, etc. Any attempt to define the
core
> > attributes of an endpoint outside of some application domain
> strikes me as
> > not very useful.
> >
> > For example, the draft seems to be considering an application
> domain made up
> > of SIP endpoints that are intended to preserve a "phone-like" user
> > experience. The market may indeed limit sip endpoints to those that
fall
> > within that application domain, but the working group should not.
> >
> > Now, if we wish to create requirements for various application
> domains, e.g.
> > "things that act like phones", "bandwidth constrained mobile devices",
> > "video conference systems", "multiplayer games", etc, I think
> would have a
> > higher probability of success. (Or at least we would do less
> unintentional
> > harm)
> >
> > Failing that, the first requirement would be to describe how to
> configure an
> > arbitrary set of attributes, and leave the definition of those
> sets to some
> > sort of profiles.
> >
> > > -----Original Message-----
> > > From: [email-masked]
[mailto:[email-masked]]On Behalf Of
> > Daniel G. Petrie
> > Sent: Sunday, March 03, 2002 11:30 PM
> > To: [email-masked]
> > Subject: [Sipping] I-D ACTION:draft-stredicke-sipping-ep-config-00.txt
> >
> >
> > Folks:
> > I encourage anyone who thinks SIP UAs are an important part
> > of a VoIP system to have a good look at this draft which aims
> > to define the requirements for end point configuration data and
> > a standard format.  Your input can make this better.  One of the
> > largest barriors to any significant scale deployment of SIP UAs
> > will be the ease of configuration.
> > Cheers
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >         Title           : SIP End Point Configuration Data Format
> >         Author(s)       : C. Stredicke, I. Butcher
> >         Filename        : draft-stredicke-sipping-ep-config-00.txt
> >         Pages           : 25
> >         Date            : 22-Feb-02
> >
> > Mass deployment of SIP compliant devices requires a simple mechanism
> > for configuring and maintaining them. For the economical success of
> > SIP based devices on a large scale, a platform independent mechanism
> > for finding and exchanging the required information is vital. The
> > goal of this draft is to reduce the amount of effort required for
> > administrators to provision devices. This draft focuses on defining
> > a common data set to configure SIP end points. The mechanism for
> > providing and maintaining the configuration data to the end point is
> > defined elsewhere [7].
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-stredicke-sipping-ep-con
> > fig-00.txt
> >
> >
> >

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP