[cuss] AD review: draft-ietf-cuss-sip-uui-isdn-08

Alissa Cooper <alissa@cooperw.in> Tue, 29 April 2014 23:58 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: cuss@ietfa.amsl.com
Delivered-To: cuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC171A096B for <cuss@ietfa.amsl.com>; Tue, 29 Apr 2014 16:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG19iojpo8xV for <cuss@ietfa.amsl.com>; Tue, 29 Apr 2014 16:58:46 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 89DD71A096A for <cuss@ietf.org>; Tue, 29 Apr 2014 16:58:46 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C9D4221110 for <cuss@ietf.org>; Tue, 29 Apr 2014 19:58:44 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 29 Apr 2014 19:58:44 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=QFl3N3xjUznFwldIh1BDCqX swP4=; b=zYB2Z10PxugA5Rk5db+6L58pIvcgfeZ6n7jAgTHT68kivzfukFquHbo I27wqCvWk1n2taIyYmG13IpaCoPB0UpauXZ78q5KAuyUnsgPsra8Lplvlzb6Rw+T +YNmx0BMApKvZUUiECTvivkzXQwP0AMax5Cl8ai/Gm982uHyUZrE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=QFl3N3xjUznFwldIh1BDCqXswP4=; b=gUcrMcO5OG066dIsoAe9AAEOmPme AAsDKFkH5zrtO1k3QkRiBQz+/hHHkYXegfl5rPuXoeo5e/1oGWyGYxEst2kWfkgN /GQQIHkPOR2oG4qUNkMWSwUY3aCKc1cnbwo31e0sLKVSVI6KXD+jneAstYbA0VI2 a15YaKnM6oS1s0s=
X-Sasl-enc: HlQuXWzQz+OHmnZjxf6tCnF62zMnRM53bXQWTVphodd+ 1398815924
Received: from [171.68.18.132] (unknown [171.68.18.132]) by mail.messagingengine.com (Postfix) with ESMTPA id ECDE9C00005; Tue, 29 Apr 2014 19:58:42 -0400 (EDT)
User-Agent: Microsoft-MacOutlook/14.3.9.131030
Date: Tue, 29 Apr 2014 16:58:37 -0700
From: Alissa Cooper <alissa@cooperw.in>
To: cuss@ietf.org
Message-ID: <CF858ABC.36F8C%alissa@cooperw.in>
Thread-Topic: AD review: draft-ietf-cuss-sip-uui-isdn-08
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/6UZzrL8LCFrJT9XMAdlIcUW11W8
Cc: draft-ietf-cuss-sip-uui-isdn@tools.ietf.org
Subject: [cuss] AD review: draft-ietf-cuss-sip-uui-isdn-08
X-BeenThere: cuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" <cuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cuss>, <mailto:cuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cuss/>
List-Post: <mailto:cuss@ietf.org>
List-Help: <mailto:cuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cuss>, <mailto:cuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Apr 2014 23:58:48 -0000

I have reviewed this draft in preparation for IETF LC.  Overall, it's in
good shape, and I have requested the LC.  A couple of comments to address
with any LC comments:


Section 4 says:

"If the SIP-T method of encapsulation of ISDN instead of interworking is
used, this is a
   reasonable mechanism and does not require any extensions to existing
   SIP-T.  However, if true ISDN interworking is being done, this
   approach is not reasonable."

It’s not clear from this text why the mechanism is described as “not
reasonable.” This text should be clarified to explain that encapsulation
is not needed when ISDN interworking is being done.

Section 6 says:

"If an interworking point is reached, and
   the limitations are not met, then the UUI data will not be
   transferred, although the SIP request will otherwise be interworked.
   As a result there is also only one encoding value specified."


This text needs to be more explicit about which “limitations” it is
referring to. If it is the size limitation (128 octets plus the protocol
discriminator) or the limitation to one UUI data element, those should be
made explicit. Same goes for the text in section 7 about "the ISDN service
restrictions" — the restrictions should be made explicit.

Sections 7 and 8 say:

"When receiving UUI, when multiple User-to-User header fields are
   received in the same response with the "purpose" header field
   parameter to "isdn-uui", or with no "purpose" header field parameter,
   or with some combination of these, the UAC MUST discard all these
   header fields.  There are no mechanisms for determining which was the
   intended data packet so all are discarded."


s/data packet/UUI object/

Section 13:

The “Contact:” fields need to be filled in.

Thanks,
Alissa