Subject: RE: [Sipping] device-info-01

From: "Summers, Kevin" <[email-masked]>
Date: Thu, 11 Nov 2004 10:48:47 -0600

Clearly, as deployments of SIP endpoints spread, this cloying issue must be addressed for those who need to manage SIP endpoints at some level.

To Jonathan's last comment, assuming that certain descriptive config data that is end-user settable (e.g., SIP UA make/type, software rev. level, etc), a query result may not accurately reflect the true data. For example, I can set my browser to look like Microsoft IE even though I am using a different browser (of course I might do this to ease my user experience with those web sites that are Microsoft IE optimized).

While it certainly *could* be done using SIP, I am not sure that a SIP-based mechanism is the most appropriate.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thursday, November 11, 2004 8:45 AM
To: Mahfuz Rahman
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Sipping] device-info-01

I think there is an interesting question at the root of this draft. The 
interesting question is how to manage a "network" where the network 
includes all of the SIP user agents (and in particular, single user 
devices like softphones and hardphones). Management, in this context, 
includes configuration (where things like the config profile are 
targeted), but also includes fault management, accounting, performance 
and security management. This draft is targeted roughly in the area of 
device performance management, and thats a laudable goal.

However, I think the problem is fairly broad, and would benefit from a 
top-down look at what really needs to be done here, rather than jumping 
to an event package or OPTIONS or whatever. The problem is complicated 
because in many cases, these devices are run and managed by end users.

-Jonathan R.

Mahfuz Rahman wrote:

> Thanks Cullen for making some good comments. My response is as follows:  
> 
> OPTIONS method is used to query device capabilities such as supported methods,
> contnet types, codesc etc.. This draft defines data elements for device profile
> which is  different from the tags defined for OPTIONS. So if we like to define
> tags for each of the data elements we have defined in the profile it will be a long
> list. I am not sure if it is acceptable. Also, as you suggested to include multiple
> schemas and URLs for a device it would be difficult to represent using OPTIONS unless
> we allow attachment of a body in the OPTIONS response with the following content type: 
> application/device-profile+xml. 
> 
> I agree with you to add software version and also an optional UUID.
> 
> The status part will be extended in the future revision which might include a 
> common XML format. Currently it describes only how vendor specific status information
> can be retrieved. 
> 
> - mahfuz
> 
> -----Original Message-----
> From: [email-masked] [[email-masked]]On
> Behalf Of Cullen Jennings
> Sent: Saturday, November 06, 2004 6:19 PM
> To: sipping
> Subject: [Sipping] device-info-01
> 
> 
> Nice draft - few comments ...
> 
> As a completely alternative suggestions.... How much of this information can
> you get by just sending an OPTION request to the device.
> 
> I would remove all the discussion of the device status - you don't define
> anything about how to do it so the discussion does not help.
> 
> This reports things that should not change so rate of notifications is very
> very seldom.
> 
> I would add an optional UUID to the profile
> 
> You might want to add software version.
> 
> I would make the schema URL and name attributes of a schema object so that
> the device can lists multiple schema that it can support.
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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

_______________________________________________
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