[sipcore] AD review: draft-ietf-sipcore-keep-08
Robert Sparks <rjsparks@nostrum.com> Tue, 23 November 2010 20:29 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6711C28C1A6 for <sipcore@core3.amsl.com>; Tue, 23 Nov 2010 12:29:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.238
X-Spam-Level:
X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, SPF_PASS=-0.001, 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 tB5O6V1wH5-C for <sipcore@core3.amsl.com>; Tue, 23 Nov 2010 12:29:58 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 05AD93A6933 for <sipcore@ietf.org>; Tue, 23 Nov 2010 12:29:57 -0800 (PST)
Received: from [192.168.2.105] (pool-173-71-48-4.dllstx.fios.verizon.net [173.71.48.4]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oANKUojN097324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Nov 2010 14:30:51 -0600 (CST) (envelope-from rjsparks@nostrum.com)
From: Robert Sparks <rjsparks@nostrum.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Nov 2010 14:30:50 -0600
Message-Id: <4892E0CC-52C7-4422-A5DA-C6A7553A4053@nostrum.com>
To: SIPCORE <sipcore@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Received-SPF: pass (nostrum.com: 173.71.48.4 is authenticated by a trusted mechanism)
Subject: [sipcore] AD review: draft-ietf-sipcore-keep-08
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Nov 2010 20:29:59 -0000
Summary: Revised ID needed The text needs to be adjusted to reflect the security issue I called out in a separate message to the list today. During that adjustment, there are a few other places to consider making changes: * Section 4.4, second paragraph "The parameter can contain" is confusing - it could be read to imply that the parameter can contain other things as well. I suggest rewriting this sentence as "The parameter value, if present, represents a recommended keep-alive frequency..." * The document talks about invoking keep for INVITE initiated dialogs, but not about SUBSCRIBE initiated dialogs. Was it the intent to not allow the use of the mechanism for SUBSCRIBE initiated dialogs? * Section 4.4 talks about normative server behavior for using this mechanism with INVITE initiated dialogs. where is the companion set of normative requirements for using the mechanism to keep alive a REGISTRATION flow? * In several places, the document refers to an element inspecting "its" Via header. This is imprecise and will lead to arguments among implementers. I suggest explicitly calling out "the topmost Via header field value" and being very specific about when you are talking about a message being received or a message being sent. * In section 5's fourth paragraph, it would help avoid confusion to say "adds a value the a 'keep' parameter to indicate willingness" instead of "uses the 'keep' parameter...". *In the last sentence of Section 5 - what value is "without forcing entities to re-write the value of Flow-Timer header field" adding? I suggest deleting the phrase. * Section 6's first paragraph says "Entities that want to reuse connections MUST use a another mechanism". (Note the spurious 'a'). Why is this a 2119 MUST? I suggest saying "would need to" instead. * The first sentence in 7.4 would be better if it said Figure 3 instead of "The figure". The end of the first paragraph has a spurious period. * All of the examples showing Via header fields use a shorthand, pseudo-code style representation of the header field format. It would be good to explicitly note that in the document. It would be better to provide one example that was syntactically correct. * In Section 10's section paragraph. I suggest that you be explicit that you are talking about hop-by-hop integrity protection (calling out TLS or DTLS), to avoid confusion with end-to-end integrity protection mechanisms (S/MIME) which will not help this case. * In section 10's third paragraph, you call out "(at high rates)". This is potentially misleading - the rates are at the highest somewhere just under once a second. I suggest replacing "(at high rates)" with "(up to approximately once a second)".
- [sipcore] AD review: draft-ietf-sipcore-keep-08 Robert Sparks
- Re: [sipcore] AD review: draft-ietf-sipcore-keep-… Christer Holmberg
- Re: [sipcore] AD review: draft-ietf-sipcore-keep-… Christer Holmberg
- Re: [sipcore] AD review: draft-ietf-sipcore-keep-… Robert Sparks
- Re: [sipcore] AD review: draft-ietf-sipcore-keep-… Robert Sparks
- Re: [sipcore] AD review: draft-ietf-sipcore-keep-… Christer Holmberg