Re: [BLISS] more comments on the CC draft

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Thu, 31 March 2011 17:26 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: bliss@core3.amsl.com
Delivered-To: bliss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90DD93A697A for <bliss@core3.amsl.com>; Thu, 31 Mar 2011 10:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.975
X-Spam-Level:
X-Spam-Status: No, score=-105.975 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKwHv94VP3rD for <bliss@core3.amsl.com>; Thu, 31 Mar 2011 10:26:51 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id A6DAA3A6850 for <bliss@ietf.org>; Thu, 31 Mar 2011 10:26:50 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2VHSCZB030836 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Mar 2011 19:28:28 +0200
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 31 Mar 2011 19:28:27 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "Martin.Huelsemann@telekom.de" <Martin.Huelsemann@telekom.de>, "bliss@ietf.org" <bliss@ietf.org>
Date: Thu, 31 Mar 2011 19:28:25 +0200
Thread-Topic: more comments on the CC draft
Thread-Index: AcvvtP8u4HqlfMucRyGWDU/f1cRubAAE6CMw
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE21EB8EBF3@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <9762ACF04FA26B4388476841256BDE020113D8897CC1@HE111543.emea1.cds.t-internal.com>
In-Reply-To: <9762ACF04FA26B4388476841256BDE020113D8897CC1@HE111543.emea1.cds.t-internal.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21EB8EBF3FRMRSSXCHMBSC3d_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
Cc: "j.dave.smith@siemens-enterprise.com" <j.dave.smith@siemens-enterprise.com>, "R.Jesske@telekom.de" <R.Jesske@telekom.de>
Subject: Re: [BLISS] more comments on the CC draft
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2011 17:26:56 -0000

I was kicked off to look at this further.

My brief skim identifies two issues:

1)         Generally throughout the document, "header" should be "header field" and "header parameter" should be "header field parameter".

2)         All instances of the words "SHOULD" and "RECOMMENDED" should be qualified by informative material indicating when the requirement applies / does not apply. The note below that some SHALLs have changed to SHOULD triggered me on this.

I'll try and have a closer look when not in a meeting.

Regards

Keith

________________________________
From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] On Behalf Of Martin.Huelsemann@telekom.de
Sent: 31 March 2011 16:05
To: bliss@ietf.org
Cc: j.dave.smith@siemens-enterprise.com; R.Jesske@telekom.de
Subject: [BLISS] more comments on the CC draft

Dear colleagues,

during the last WGLC I again received a lot of comments from Dave for editorials and spelling corrections, thanks again for checking, my apologies for not having detected them myself.

Besides the editorials, Dave commented that the procedures are based very much on the assumption of a underlying network architecture where there is a clear seperation between the UA on the user device and the CC agent/monitor which is located in the network. Dave proposed to better consider the case where the CC agent/monitor is colocated with the UA on the user device.
An example is a simple UA uses CC via a AS in the network, and when this UA is not available for CC recall, we said that the CC agent SHALL suspend the CC request. But the suspension policy of a more sophisticated agent of a CC App on a device could be different, therefore it was changed to 'SHOULD be suspended'. There are some other changes in this direction. There are no syntax changes.

Even though they were contributed post WGLC, in my opinion those changes are very useful for a more comprehensive CC solution, and therefore should be considered. I have provisionally provided a 09 version of the internet draft. You can find the changes at  http://bliss-ietf.org/drafts/diff_ccbs.html

Your opinions?



Regards, Martin