[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
- [sip-overload] Comments on draft-ietf-soc-load-co… Shida Schubert
- Re: [sip-overload] Comments on draft-ietf-soc-loa… SHEN, CHARLES
- Re: [sip-overload] Comments on draft-ietf-soc-loa… Shida Schubert
- Re: [sip-overload] Comments on draft-ietf-soc-loa… SHEN, CHARLES