[sip-overload] Comments on draft-ietf-soc-load-control-event-package-01

Shida Schubert <shida@ntt-at.com> Mon, 03 October 2011 14:44 UTC

Return-Path: <shida@ntt-at.com>
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 55F4721F8B40 for <sip-overload@ietfa.amsl.com>; Mon, 3 Oct 2011 07:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
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 M+1zYd5C5CQF for <sip-overload@ietfa.amsl.com>; Mon, 3 Oct 2011 07:44:57 -0700 (PDT)
Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id D0A7121F8B3F for <sip-overload@ietf.org>; Mon, 3 Oct 2011 07:44:57 -0700 (PDT)
Received: from [122.133.87.237] (port=56987 helo=[192.168.1.14]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <shida@ntt-at.com>) id 1RAjoE-0005bf-2V for sip-overload@ietf.org; Mon, 03 Oct 2011 09:47:58 -0500
From: Shida Schubert <shida@ntt-at.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 3 Oct 2011 23:47:56 +0900
Message-Id: <15724199-7C27-4577-ADB3-3CB8A484C030@ntt-at.com>
To: sip-overload@ietf.org
Mime-Version: 1.0 (Apple Message framework v1244.3)
X-Mailer: Apple Mail (2.1244.3)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator465.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ntt-at.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: fl1-122-133-87-237.tky.mesh.ad.jp ([192.168.1.14]) [122.133.87.237]:56987
X-Source-Auth: shida@agnada.com
X-Email-Count: 5
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
Subject: [sip-overload] Comments on draft-ietf-soc-load-control-event-package-01
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: Mon, 03 Oct 2011 14:44:58 -0000

 I recently reviewed the draft and below are some comments.

A: Terminology

 First of all, I find that the document is rather hard to read 
because; 1. it uses different terminology for what I believe is 
the same thing. 2. introduce many terminology that 
is not defined anywhere and 3. the terminology used should 
probably be aligned with that of the other drafts 
that define some of these terminologies (RFC6537 etc).

 Here are some examples;

 1. "load control" - should this be "overload control"?
 2. What is "user load control information"?
 3. "edge server" - edge of what? At the edge of domain? 
 4. load document, load control document and load filter, are they the same thing?
 5. load filtering mechanism and load filter control the same thing?
 6. What is a dynamic filter? 
 7. What is a load control policy maker?
 8. What is a policy entry point?
 9. What is a filter computation decision maker?
10. Is load control policy, load control information and load control rule the same thing?
11. What is load control filter content definition?

 Also some terminology can be changed to common terminology used in SIP related RFCs

 e.g. SIP entity subscribers > SIP subscribers or subscribers
 e.g. local format/global format > local number / global number [RFC3966]


B: Requirements

 The draft does a really nice job evaluating whether the 
document meets the requirements set forth by RFC 5390 in 
section section 9. but the draft also has design requirements 
in section 3. This seems reasonable thing to have but shouldn't 
these requirements expressed with RFC2119 language?  
 

C: Behavior of Notifier and Subscriber is mixed in section 5.6
 - I think followings should be described as Subscribers' behavior. 

"SIP entity subscribers SHOULD try to subscribe to all those SIP entity
   notifiers with which they have regular signaling exchanges, although
   not all such SIP notifiers may permit such a subscription"

D: Technical questions

 1. section 5.7. 
   -  "Following the [RFC3265] specification, a notifier MUST send a NOTIFY
   with its current load control policy to the subscriber upon
   successfully accepting or refreshing a subscription.  The NOTIFY
   request MAY include a body. "

   - So it says MUST send a NOTIFY but it is followed by MAY include a body.
     If load control policy is carried in a body, I don't know there is a MAY following 
     the first paragraph. 

  - If what you want to say is to include the control policy in the body when 
     there is an active policy to be MUST and otherwise a MAY, this should be 
     clarified. 

 2. section 5.8.
  - "Upon receipt of a NOTIFY request with a Subscription-State header
   field containing the value "terminated", the subscriber MUST remove
   all previously received load control information and process all
   calls without applying any restriction"

 - This should be clarified that this applies only to the relevant filter and 
    not to all the policy that may be active at the time of receiving this NOTIFY. 

 Regards
  Shida