[P2PSIP] Stephen Farrell's No Objection on draft-ietf-p2psip-sip-20: (with COMMENT)

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Tue, 19 April 2016 21:05 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: p2psip@ietf.org
Delivered-To: p2psip@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C5612E6D3; Tue, 19 Apr 2016 14:05:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160419210536.31629.14601.idtracker@ietfa.amsl.com>
Date: Tue, 19 Apr 2016 14:05:36 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/tVEloay72Unv_ZJUzS3X4r7dQKI>
Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-sip@ietf.org, p2psip@ietf.org
Subject: [P2PSIP] Stephen Farrell's No Objection on draft-ietf-p2psip-sip-20: (with COMMENT)
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/p2psip/>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2016 21:05:37 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-p2psip-sip-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


- 5.1: I guess it's too late to ask, but I'll ask
anyway, just in case this hasn't yet been implemented
and it's not too late... I can see why you want to
support SIP URIs and can't e.g. only support SIPS URIs
here.  But in supporting SIP URIs couldn't you have
taken an opportunistic security approach to using TLS
and e.g. maybe treated a SIP URI as if it's a SIPS URI
except for the certificate validation step? I do get
that that might restrict re-use of unmodified SIPS
stacks but maybe that'd be ok in this context. Any
chance of considering that or is it too late or a case
where there's not enough energy/interest?  (EIther form
of "no" is a very reasonable answer.)

- Just out of curiosity, are folks deploying this