[Simple] Comments on draft-ala-kurikka-simple-pidfconn-00

"Zisimopoulos, Haris, VF-Group" <Haris.Zisimopoulos@vodafone.com> Tue, 15 November 2005 08:38 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwKh-0003gg-CJ; Tue, 15 Nov 2005 03:38:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwKf-0003gY-Vj for simple@megatron.ietf.org; Tue, 15 Nov 2005 03:38:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09742 for <simple@ietf.org>; Tue, 15 Nov 2005 03:37:53 -0500 (EST)
Received: from rat01038.dc-ratingen.de ([195.233.129.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebwbn-0003uL-1V for simple@ietf.org; Tue, 15 Nov 2005 03:56:12 -0500
Received: from heinz.vodafone-is.de (heinz_e0 [195.233.128.26]) by rat01038.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id jAF8c2i0012390 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Nov 2005 09:38:02 +0100 (MET)
Received: from gpsmxr04.gps.internal.vodafone.com ([195.232.231.115]) by heinz.vodafone-is.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id jAF8bvk4003158; Tue, 15 Nov 2005 09:38:01 +0100 (MET)
Received: from gpsmx11.gps.internal.vodafone.com ([145.230.1.15]) by gpsmxr04.gps.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Nov 2005 09:37:58 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
Date: Tue, 15 Nov 2005 08:38:00 -0000
Message-ID: <6C742B4BEC7D1D4FB045E74BB625987B0569494E@gpsmx11.gps.internal.vodafone.com>
Thread-Topic: Comments on draft-ala-kurikka-simple-pidfconn-00
Thread-Index: AcXpv+KqkWOWcfQaS2CgVg1yovInMA==
From: "Zisimopoulos, Haris, VF-Group" <Haris.Zisimopoulos@vodafone.com>
To: jussi.ala-kurikka@ee.oulu.fi, simple@ietf.org
X-OriginalArrivalTime: 15 Nov 2005 08:37:58.0763 (UTC) FILETIME=[E1E1E3B0:01C5E9BF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: quoted-printable
Cc:
Subject: [Simple] Comments on draft-ala-kurikka-simple-pidfconn-00
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hello,

First I think that the concept of connectivity as part of the Presence information should be further exploited and this proposal provides a good start.

I have some comments though for this I-D:

- First of all I think it is unclear what is defined as connectivity. For example it can be (wireless) network attachement, allocation if IP adress, registration in the SIP domain with that contact? It needs to be clarified.
- Determining the QoS characteristics (eg throughput, delay etc) just from the type of the wireless technology is very naïve. Even wireless networks that perform over-the-air resource reservation keep these resources only if there is traffic flowing. Also the allocation of resources largely depends on the overall congestion in the network and can vary over time. Therefore here it would be wiser I think just to indicate the network attachment to a particular network type (eg UMTS,GPRS etc) which *generally* gives some static QoS characteristics indication. For example indicating to the watcher that I am attached in WLAN generally speaking gives the indication that I have better QoS than GPRS (apart from when I am in IETF :-)). I am very sceptical that you can go beyond that unless you do some real-time measurements in the terminal which is something not advisable.
- The idea of charging indication in an on/off manner is interesting but I think it becomes very complicated if you attempt to go beyond that. So the sentence under 2.3.2.1 that "... followed by any number of elements from different namespaces for an extended specification of the billing." is very difficult to be implemented in a real world. 

Best regards,
Haris

Haris Zisimopoulos
Vodafone Group Research & Development - UK

Telephone: +44 (0)7919994709
E-mail: haris.zisimopoulos@vodafone.com


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple