Subject: [sip-overload] draft-ietf-soc-overload-control-07 - Too much "MUST"?

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 10 Mar 2012 15:40:18 +0100

Hi, as an initial reading of the draft (revision 07) I've found
various cases in which the text says things like:

-------------------------------
4.1.  The oc parameter

   This parameter is inserted by the SIP client and updated by the SIP
   server.

   A SIP client MUST add an "oc" parameter to the topmost Via [...]

   The downstream server MUST add a value to the "oc" parameter in the
   response going upstream.
-------------------------------

Reading that it seems that any SIP client and any SIP server/proxy
should implement this specification. I would suggest a "Terminology"
section in which is stated that this document describes a "SIP client"
as a SIP entity which implements this specification and wants to use
it, and "SIP server" as a SIP proxy or server that implements this
specification and, as well, wants to use it.

There is no "Require/Supported" negotiation mechanism here since
information is just added as Via parameters, so IMHO the document
should relax those "MUST" or clearly explain the scope of them.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Janet P Gunn <[email-masked]>
Date: Sat, 10 Mar 2012 11:31:10 -0500

See section 2

"   Unless otherwise specified, all SIP entities described in this
   document are assumed to support this specification.

   The normative statements in this specification as they apply to SIP
   clients and SIP servers assume that both the SIP clients and SIP
   servers support this specification.  If, for instance, only a SIP
   client supports this specification and not the SIP server, then
   follows that the normative statements in this specification pertinent
   to the behavior of a SIP server do not apply to the server that does
   not support this specification."

Janet

From:   Iñaki Baz Castillo <[email-masked]>
To:     [email-masked]
Date:   03/10/2012 09:40 AM
Subject:        [sip-overload] draft-ietf-soc-overload-control-07 - Too 
much "MUST"?
Sent by:        [email-masked]

-- 
Iñaki Baz Castillo
<[email-masked]>
_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 11 Mar 2012 16:56:17 +0100

>    not support this specification."

Ok, but maybe section 2 should describe a bit what "SIP client" and
"SIP server" means. A "SIP client" implementing overload control could
be a SIP proxy or a SIP UAC (B2BUA or whatever), and a "SIP server"
coould be a SIP proxy or a SIP UAS (B2BUA, gateway...).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 12 Mar 2012 09:48:55 -0500

> coould be a SIP proxy or a SIP UAS (B2BUA, gateway...).

Inaki: Thanks for your feedback.  Based on your and Janet's
conversation, I propose to add the following in Section 2:

   Note that the terms "SIP client" and "SIP server" are used
   in their generic forms.  Thus, a "SIP client" could refer to
   the client transaction state machine in a SIP proxy or it
   could refer to a user agent client.  Similarly, a "SIP server"
   could be a user agent server or the server transaction state
   machine in a proxy.  Various permutations of this are also
   possible, for instance, SIP clients and servers could also be
   part of back-to-back user agents (B2BUAs) or gateways.

   However, irrespective of the context (i.e., proxy, B2BUA, UAS,
   UAC), "SIP client" applies to any SIP entity that provides
   overload control to traffic destined downstream.  Similarly,
   "SIP server" applies to any SIP entity that is experiencing
   overload and would like its upstream neighbour to throttle
   incoming traffic.

Hope that helps.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 12 Mar 2012 15:52:44 +0100

>  overload and would like its upstream neighbour to throttle

It's clear now. Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>