[stir] Comments on draft-ietf-stir-rfc4474bis-13.txt

N WEINRONK <nweinronk@btinternet.com> Wed, 05 October 2016 23:33 UTC

Return-Path: <nweinronk@btinternet.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 15E25129476 for <stir@ietfa.amsl.com>; Wed, 5 Oct 2016 16:33:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9xG5dHVxeMw2 for <stir@ietfa.amsl.com>; Wed, 5 Oct 2016 16:33:11 -0700 (PDT)
Received: from rgout02.bt.lon5.cpcloud.co.uk (rgout0207.bt.lon5.cpcloud.co.uk []) by ietfa.amsl.com (Postfix) with ESMTP id 97A0F129424 for <stir@ietf.org>; Wed, 5 Oct 2016 16:33:10 -0700 (PDT)
X-OWM-Source-IP: ()
X-OWM-Env-Sender: nweinronk@btinternet.com
Received: from webmail39.bt.ext.cpcloud.co.uk ( by rgout02.bt.lon5.cpcloud.co.uk ( (authenticated as nweinronk@btinternet.com) id 57F4D2C7001AE005 for stir@ietf.org; Thu, 6 Oct 2016 00:33:09 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1475710390; bh=4JkJ4UFkcMV7imPb+EXEUOdvt4UGD8hSZcOULBzosco=; h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version; b=fplhuUc3LPuT3TdgG4qwZc+GoGTAtR0HWWc9KnEvKxBdi+A8EjITMGDD88Ywd3lJK0lIgq9THOw6Khsmg5gMX7FRv/gJEibuivewKscISypmXvwtpnkfDJTxqgj7Kp84Eb198EZL1VrlCWf7tXdNzFHX5vqnG8OYdAI9895Qypw=
Date: Thu, 06 Oct 2016 00:33:09 +0100
From: N WEINRONK <nweinronk@btinternet.com>
To: stir@ietf.org
Message-ID: <24430040.96568.1475710389106.JavaMail.defaultUser@defaultHost>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_Part_96567_26113098.1475710389077"
Importance: 3 (Normal)
X-Priority: 3 (Normal)
X-Client-IP: IPv4[] Epoch[1475710389078]
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/nJ3C4Lw7-hsBt9tNij6TIx20w1w>
Subject: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: nweinronk@btinternet.com
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2016 23:33:13 -0000

Thanks for this document.
I have some comments on this version.
4.1.1 para 2: I note the recommendation of the compact form
of PASSporT here. 
I do have concern over B2BUAs actions on Date header. Will B2BUA
actions (stripping / replacing this header) actually mean that everyone in
reality will have to use the full format of PASSporT anyway and probably without does the repeat after failure on the compact form ?
General: Use of the “dest” identity:
I am aware of some services that alter the To header – for
example 3GPP diversion service can do this – does this mean that we should
remove reliance on “dest” ?
Is there any privacy concern with allowing the ‘verification
service’ to identify the original ‘to header’ (full form) when the request
could have been redirected ?
I am aware of some service codes that have * and # not just as
the leading number dialled eg. *24#1# - again could we do anything to remove
reliance on ‘dest’ ?
6.1 step 3: Certain features can cause INVITEs to arrive at
terminating UA more than 1 minute after the call originated – for example diversion
chains - these would fail the 60 second logic but are valid calls.
6.2 step 1: Identity request –> Identity header ? 
6.2 step 1: Here we ignore not supported ppt but above we
reject them – which is correct ?
6.2 step 4: “iat” value is later – do you really mean earlier
here not later – I think you are trying to cover the case where the Date header
has been added along the way so will the “iat” not be earlier ?
6.2 step 5: typo – that the that the
8 last para: Reword around - could itself could
8 para 2: Would you expect the p-asserted-id in the PASSporT
to be in a different field than the 1 the From is in so it can be distinguished
at the terminating end ?
8.3 Why is the ABNF here limited to 1 DIGIT – in fact do you
need tn-spec in this version of the document ?
11 para 5: I am a little confused here before in the document
you talked about using p-asserted-id instead of from (section 8) but now I
think this is a different case – but it is not clear to me.