[P2PSIP] Spencer Dawkins' Yes on draft-ietf-p2psip-sip-19: (with COMMENT)
"Spencer Dawkins" <spencer.dawkins@huawei.com> Tue, 19 April 2016 14:03 UTC
Return-Path: <spencer.dawkins@huawei.com>
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 177C012DAA8; Tue, 19 Apr 2016 07:03:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencer.dawkins@huawei.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160419140314.31496.8662.idtracker@ietfa.amsl.com>
Date: Tue, 19 Apr 2016 07:03:14 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/Bj95XapzkEowNogb7vXeHh-VCx0>
Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-sip@ietf.org, p2psip@ietf.org
Subject: [P2PSIP] Spencer Dawkins' Yes on draft-ietf-p2psip-sip-19: (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 14:03:14 -0000
Spencer Dawkins has entered the following ballot position for draft-ietf-p2psip-sip-19: Yes 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: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This was a bit confusing to me. AOR domain not supported by overlay? If the domain part of the AOR is not supported in the current overlay, the user SHOULD query the DNS (or other discovery services at hand) to search for an alternative overlay that services the AOR under request. Alternatively, standard SIP procedures for contacting the callee SHOULD be used. If you don't query the DNS (or other discovery services), and you don't use standard SIP procedures, are there any other choices? With both of these being SHOULDs, a conformant implementation might not do either of them. Is that expected? If you need this to be RFC 2119 language, I'm guessing this would be "MUST either do X or Y", but I'm not sure it needs to be RFC 2119. If you really do need two alternative SHOULDs, it's not required to explain why a SHOULD is not a MUST, but since the goal is that an implementer is making an informed choice, helping the implementer understand why one might not want to do what one SHOULD do is usually helpful. I think that A callee MAY choose to listen on both SIP and SIPS ports and accept calls from either SIP schemes, or select a single one. is using "SIP schemes" generically, but this might be clearer if you just said "either scheme". I'm not on top of SIPS these days, but I didn't think SIPS requires end-to-end protection that may include client links and endpoint certificates. was "end-to-end protection". Is it? I thought that it was protected-hop-by-protected-hop. Or maybe you only mean SIPS in P2PSIP? Sorry if I'm confused (and the SIP Forum will be thrilled to hear this, if I'm just confused). I can figure out what "fork explosion" and "fork bomb" are, but are these terms in common usage in the SIP community? Is there a definition or reference for them?
- [P2PSIP] Spencer Dawkins' Yes on draft-ietf-p2psi… Spencer Dawkins
- Re: [P2PSIP] Spencer Dawkins' Yes on draft-ietf-p… Thomas C. Schmidt
- Re: [P2PSIP] Spencer Dawkins' Yes on draft-ietf-p… Spencer Dawkins at IETF