[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 []) 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-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 ([]) by localhost (core3.amsl.com []) (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 [] (pool-173-71-48-4.dllstx.fios.verizon.net []) (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: 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

*  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)".