[sip-overload] AD review of draft-ietf-soc-load-control-event-package-08
Richard Barnes <rlb@ipv.sx> Wed, 17 April 2013 17:53 UTC
Return-Path: <rlb@ipv.sx>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4583421F8DE4 for <sip-overload@ietfa.amsl.com>; Wed, 17 Apr 2013 10:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.064
X-Spam-Level:
X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzCfas9rxGB0 for <sip-overload@ietfa.amsl.com>; Wed, 17 Apr 2013 10:53:37 -0700 (PDT)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 45B5F21F8E46 for <sip-overload@ietf.org>; Wed, 17 Apr 2013 10:53:36 -0700 (PDT)
Received: by mail-ob0-f169.google.com with SMTP id ta14so1683122obb.28 for <sip-overload@ietf.org>; Wed, 17 Apr 2013 10:53:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=pg1Jj7yf23VIbEG74qPXuTM4PygdnNp6lDSkNpW2i0o=; b=HrnTh44rpTM9wQpOkZ85bgWiuq/NMHG5AwSGPPvSsejdo58DAQ5guM43/qsK2LnZNk 3UD0XIec065PNtHSNPRiLbmjLz1UVbdOyPCVy5hboSKRtpc4scWb3f6c20YPPWps+ptt NsDWkblb/inL9VVZSUNB4fuSYFxmV/nz6qYGkZ5uZGLad0Hd+z9ylku7VHyQhMltD6n8 4TylSQZEvlRMCtQDt148oR3MMZFGPExUg0T1mIJCzRIuUoywqQGwjlMDxbo7TSXDFViJ X0xdBOAjA4P7x4JROHYZKnbpIEx2rJ8zfXh097M61OHaLNRhUQRXZ4iv3H0/Q6XhPw39 ZeXQ==
MIME-Version: 1.0
X-Received: by 10.60.103.165 with SMTP id fx5mr3360088oeb.4.1366221210616; Wed, 17 Apr 2013 10:53:30 -0700 (PDT)
Received: by 10.60.25.196 with HTTP; Wed, 17 Apr 2013 10:53:30 -0700 (PDT)
X-Originating-IP: [192.1.255.184]
Date: Wed, 17 Apr 2013 13:53:30 -0400
Message-ID: <CAL02cgQW3eJg+f0nwEwihJGRgE82o+B0gSx0LJ6vTP1M8F+n5w@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org
Content-Type: multipart/alternative; boundary="089e0112c404f18ec404da922956"
X-Gm-Message-State: ALoCoQn13MBwedsvkhRgS4/loLeppbQw+na95lPeY9XNNMl2KkiVPCrWgJ0VJXK/KtrpYP37yLLi
Subject: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 17:53:38 -0000
I have reviewed this document, and have a few questions before IETF LC: Major: In a few places, for example Section 5.3., the document suggests that this event package could be used to communicate load filtering policies between domains. This seems like a bad idea for a few reasons. First, policies can be based on "P-Asserted-Identity", which is itself limited to use within a trust domain / Spec(T). It doesn't make sense to have policies based on these identifiers outside of the domain in which they are used. Second, inter-domain policies can create subtle and dangerous security risks. For example, according to the current specification, Domain A could tell Domain B to drop all calls between Domain B and Domain C. It's not clear how you would prevent these sorts of attacks, especially where "tel:" URIs are involved. I think both of these issues go away if this event package is limited in a similar way to P-Asserted-Identity, i.e., limited to use within a trust domain. Section 6.3., "SUBSCRIBE Bodies" doesn't actually say anything about what goes in the body of a SUBSCRIBE message. On the one hand, it implies that there could be a body (since the last sentence considers a request without a body as a special case), but it doesn't say what goes in the body if there is one. Please either (1) define what may go in the body, (2) explicitly say that this document does not specify what goes in SUBSCRIBE bodies, or (3) require that the body be empty. (Also, the first paragraph of this section seems out of place here, since it also has nothing to do with the body.) In Section 6.5., the last sentence is wrong. The presence of an Accept header indicates that the response body should be one of the indicated types. The indicated behavior would only be acceptable if the Accept header included "multipart/mixed". Suggest deleting the last sentence. (Also, it would be clearer to change "the request body will contain" to "the request body MUST contain".) In Section 7.3.1, you need to specify how a "tel:" URI is matched against a domain value starting with "+". Your examples seem to indicate simple string prefix matching, but I doubt that's what you actually want, since non-digit characters can break things. For example, "+1212" should match " +1-212-555-1212". Please specify a matching algorithm here. In Section 7.3.2, please change "Non-initial requests ... are not subjected" to "Non-initial requests ... MUST NOT be subjected". Section 7.4. doesn't adequately define the actions to be taken. Each of the action elements (<rate>, <window>, <percent>) need to define a concrete action that the proxy should take. RFC 4745 allows rules to combine when multiple rules match a given call. This document needs to define combination rules for the actions defined here. What's the reason for having both the "drop" action and the "reject" action? It seems like the "drop" action is almost always harmful. With unreliable transport, it causes retransmits, and even with reliable transport, it causes the client to wait unnecessarily until the connection times out. In any case, the "simple drop" action is underspecified. For example, does the server simply ignore the SIP message, or does it close the transport connection? Minor: In Section 7.3, "we re-define" -- the document doesn't re-define any of the elements in RFC 4745 (that's good; redefinition is bad). Instead, you should say you define new identity elements. In Section 7.3.1, please break up paragraph starting "To include the two forms..." for greater readability. Suggested break points: Before "Note that the tradeoff...", and before "It should be noted..." In Section 7.3.3, it would be helpful to break up the paragraph starting "The following are two example...". Break before "Usecase I" and "Usecase II". Also, s/Usecase/Use case/g Thanks, --Richard
- [sip-overload] AD review of draft-ietf-soc-load-c… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Shida Schubert
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Shida Schubert
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Shida Schubert
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Shida Schubert
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen