Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments
Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 28 June 2013 15:15 UTC
Return-Path: <pkyzivat@alum.mit.edu>
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 04CEB21F9B0A for <sip-overload@ietfa.amsl.com>; Fri, 28 Jun 2013 08:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 kqXkdvmAto59 for <sip-overload@ietfa.amsl.com>; Fri, 28 Jun 2013 08:14:55 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE2021F9AFE for <sip-overload@ietf.org>; Fri, 28 Jun 2013 08:14:45 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta02.westchester.pa.mail.comcast.net with comcast id toCc1l00B0bG4ec51rElKr; Fri, 28 Jun 2013 15:14:45 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id trEk1l01X3ZTu2S3PrEkRM; Fri, 28 Jun 2013 15:14:45 +0000
Message-ID: <51CDA863.6030802@alum.mit.edu>
Date: Fri, 28 Jun 2013 11:14:43 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: sip-overload@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C3BD16D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BD239@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BD25A@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BD25A@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372432485; bh=bzSyGrIXAp6eGHnTM/0xBcIUcGwYsRNAf79tGLToKis=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eBAsw8jW99QycHtf1cxHZZdLbh069EeLPM3aV3Qmbpe/mjOTMVitXG6Z/p3lXjMko bKD3lJTDxHRm1/47+cDbiv/OpjUiNDyKI7o3BBHL0QGHnADpFxcuEhb9hQeDYit1BM X+NY1J1WazEPpPMwoII5mYh2AZQyvRhBrJAR3WwihKNX63H4Nj0txwp3a7qKoaMUcS l3civNHuE3vW0yxg9siBXLPPYbsb2uns1Pi2aCCdecOrDlV9yMWVR6b8M8aeb5RBR1 Q2++qSFc/h+8gKfNiAofxX1nfdahBHHamS5nxQOvB5O8aPoFo3druH0eCllDcA/oYp YvCtk0GKhY0hg==
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments
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: Fri, 28 Jun 2013 15:15:00 -0000
Sorry, I haven't been following the progress of this draft for a long time, but this just caught my eye... The ABNF of 3261 is no longer authoritative for header field parameters. This was changed by RFC3968. Now these are registered in the "Header Field Parameters and Parameter Values" sub-registry of the IANA "Session Initiation Protocol (SIP) Parameters" registry. So you need an IANA considerations section that provides the info in the form called out in Section 4.1 of RFC3968. There is some debate if need, or even if it is good to provide ABNF extension syntax relative to 3261. IMO it is sufficient for you to register the parameter in IANA and define the syntax of the parameter *value* using ABNF. Done that way, IMO the draft doesn't technically extend 3261, but that point has also been debated. If you want to reuse EQUAL and DIGIT from 3261 then you should probably say so, though if you are formally extending 3261 via =/ then of course you are implicitly inheriting everything defined in 3261. Thanks, Paul On 6/28/13 2:32 AM, Christer Holmberg wrote: > The following is obviously not needed in draft-ietf-soc-overload-control: > > "EQUAL" is defined in RFC 3261. "DIGIT" is defined in RFC 5234. > > *From:*sip-overload-bounces@ietf.org > [mailto:sip-overload-bounces@ietf.org] *On Behalf Of *Christer Holmberg > *Sent:* 28. kesäkuuta 2013 9:27 > *To:* Janet P Gunn > *Cc:* sip-overload-bounces@ietf.org; > draft-ietf-soc-overload-rate-control.all@tools.ietf.org; > sip-overload@ietf.org > *Subject:* Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control > - Christer's comments > > Hi, > > So, with the third alternative, Section 5 would look something like: > > 5. Syntax > > This specification extends the existing definition of the Via header > > field parameters of [RFC3261] as follows: > > via-params =/ oc-nan > > oc-nan = "NaN" > > BTW, I think the syntax in *draft-ietf-soc-overload-control *should look > like: > > ***via-params =/ oc / oc-validity / oc-seq / oc-algo* > > oc = "oc" [EQUAL oc-num] > > oc-num = 1*DIGIT > > oc-validity = "oc-validity" [EQUAL delta-ms] > > oc-seq = "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT > > oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) > > DQUOTE > > algo-list = "loss" / *(other-algo) > > other-algo = %x41-5A / %x61-7A / %x30-39 > > delta-ms = 1*DIGIT > > ** > > In both drafts, I would also suggest to rewrite the Syntax sections in > the following way: > > 5. Grammar > > 5.1. General > > This section extends the ABNF definition of via-params from [RFC3261] > > by adding a new Via header field parameter, "oc-nan". The ABNF defined > > in this specification is conformant to RFC 5234 [RFC5234]. "EQUAL" > > is defined in RFC 3261. "DIGIT" is defined in RFC 5234. > > 5.2. ABNF > > via-params =/ oc-nan > > oc-nan = "NaN" > > ** > > Regards, > > Christer > > ** > > ** > > ** > > *From:*Christer Holmberg > *Sent:* 28. kesäkuuta 2013 8:40 > *To:* Christer Holmberg; Janet P Gunn > *Cc:* sip-overload-bounces@ietf.org > <mailto:sip-overload-bounces@ietf.org>; > draft-ietf-soc-overload-rate-control.all@tools.ietf.org > <mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>; > sip-overload@ietf.org <mailto:sip-overload@ietf.org> > *Subject:* VS: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control > - Christer's comments > > Hi, > > A *third alternative* (probably the easiest one, at least from a syntax > perspective) would be to simply define a new “oc-nan” Via header field > parameter. > > *oc-nan = "nan"* > > …or something like that. > > It would *not* require any changes to draft-ietf-soc-overload-control . > > (Then, in the *procedure sections* you need to describe how/whether the > oc and oc-nan parameters can be used at the same time etc, but that is > not a syntax question.) > > Regards, > > Christer > > *Lähettäjä:*sip-overload-bounces@ietf.org > <mailto:sip-overload-bounces@ietf.org>[mailto:sip-overload-bounces@ietf.org] > *Puolesta *Christer Holmberg > *Lähetetty:* 27. kesäkuuta 2013 22:42 > *Vastaanottaja:* Janet P Gunn > *Kopio:* sip-overload-bounces@ietf.org > <mailto:sip-overload-bounces@ietf.org>; > draft-ietf-soc-overload-rate-control.all@tools.ietf.org > <mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>; > sip-overload@ietf.org <mailto:sip-overload@ietf.org> > *Aihe:* Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - > Christer's comments > > Hi, > > When taking a closer look, I actually think there is something > technically wrong with the syntax in Section 5 of > draft-ietf-soc-overload-rate-control. > > *draft-ietf-soc-overload-control * defines the oc parameter as: > > *oc = "oc" [EQUAL oc-num]* > > Now, it seems like *draft-ietf-soc-overload-rate-control* actually > *re-defines *the *same parameter*. In addition, it’s done in a backward > compatible manner, e.g. because the parameter can now contain a > non-numeric value (see the bullet list below what can go wrong): > > *oc = "oc" EQUAL oc-value* > > The following can happen: > > 1.If an entity that supports draft-ietf-soc-overload-control receives > *“oc=NaN”* it will *reject* it, as it expects a numeric value. > > 2.If an entity that supports draft-ietf-soc-overload-rate-control > receives *“oc”* it will *reject* it, as it expects an oc-value. But, in > draft-ietf-soc-overload-control the usage of oc-value is optional. > > One way to fix this could be to define oc-value as a separate Via header > field parameter (similar to oc-validity, oc-seq etc), instead of a value > of the oc parameter. But, then you would have oc-num > > Another way is to change the syntax in draft-ietf-soc-overload-control , > in order to allow what you want to do in > draft-ietf-soc-overload-rate-control. > > Regards, > > Christer > > *Lähettäjä:*Janet P Gunn [mailto:jgunn6@csc.com] > *Lähetetty:* 27. kesäkuuta 2013 22:04 > *Vastaanottaja:* Christer Holmberg > *Kopio:* draft-ietf-soc-overload-rate-control.all@tools.ietf.org > <mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>; > sip-overload@ietf.org <mailto:sip-overload@ietf.org>; > sip-overload-bounces@ietf.org <mailto:sip-overload-bounces@ietf.org> > *Aihe:* Re: VS: [sip-overload] WGLC: > draft-ietf-soc-overload-rate-control - Christer's comments > > Christer > > draft-ietf-soc-overload-control says > " 8. Syntax > > This specification extends the existing definition of the Via header > field parameters of [RFC3261] as follows: > > via-params = via-ttl / via-maddr > / via-received / via-branch > / oc / oc-validity > / oc-seq / oc-algo / via-extension > > > oc = "oc" [EQUAL oc-num] > oc-num = 1*DIGIT > oc-validity = "oc-validity" [EQUAL delta-ms] > oc-seq = "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT > oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) > DQUOTE > algo-list = "loss" / *(other-algo) > other-algo = %x41-5A / %x61-7A / %x30-39 > delta-ms = 1*DIGIT" > and > "11. IANA Considerations > > This specification defines four new Via header parameters as detailed > below in the "Header Field Parameter and Parameter Values" sub- > registry as per the registry created by [RFC3968]. The required > information is: > > Header Field Parameter Name Predefined Values Reference > __________________________________________________________ > Via oc Yes RFCXXXX > Via oc-validity Yes RFCXXXX > Via oc-seq Yes RFCXXXX > Via oc-algo Yes RFCXXXX > > RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC > number of this specification.]" > > The text of draft-ietf-soc-overload-control refers to both "loss" and > "rate" as values for oc-algo. > > The text of draft-ietf-soc-overload-control section 5.3 refers to the > use of oc for either rate or loss > > "As an example, a value of "oc=10" when the loss-based algorithm is > used implies that 10% of the total number of SIP requests (dialog > forming as well as in-dialogue) are subject to reduction at the > client. Analogously, a value of "oc=10" when the rate-based > algorithm [I-D.ietf-soc-overload-rate-control] is used indicates that > the client should send SIP requests at a rate of 10 SIP requests or > fewer per second." > > What are you suggesting would go in the "IANA Considerations" section of > draft-ietf-soc-overload-rate-control ? Does it just need a reference > to the IANA Considerations in draft-ietf-soc-overload-control? > > Janet > > > > > > > This is a PRIVATE message. If you are not the intended recipient, please > delete without copying and kindly advise us by e-mail of the mistake in > delivery. NOTE: Regardless of content, this e-mail shall not operate to > bind CSC to any order or other contract unless pursuant to explicit > written agreement or government initiative expressly permitting the use > of e-mail for such purpose. > > > > From: Christer Holmberg <christer.holmberg@ericsson.com > <mailto:christer.holmberg@ericsson.com>> > To: Janet P Gunn/USA/CSC@CSC > Cc: "draft-ietf-soc-overload-rate-control.all@tools.ietf.org > <mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>" > <draft-ietf-soc-overload-rate-control.all@tools.ietf.org > <mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>>, > "sip-overload@ietf.org <mailto:sip-overload@ietf.org>" > <sip-overload@ietf.org <mailto:sip-overload@ietf.org>>, > "sip-overload-bounces@ietf.org <mailto:sip-overload-bounces@ietf.org>" > <sip-overload-bounces@ietf.org <mailto:sip-overload-bounces@ietf.org>> > Date: 06/27/2013 12:54 PM > Subject: VS: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - > Christer's comments > > ------------------------------------------------------------------------ > > > > > Hi, > >>The IANA considerations section of draft-ietf-soc-overload-control > registers the new Via header field parameters. >> >>Is it needed here as well? > > The draft (Section 5) does extend the oc parameter, doesn’t it? I would > assume that needs to go to IANA. > > Regards, > > Christer > > _ > _sip-overload-bounces@ietf.org > <mailto:sip-overload-bounces@ietf.org>wrote on 06/27/2013 06:05:41 AM: > >> From: Christer Holmberg <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>> >> To: "sip-overload@ietf.org <mailto:sip-overload@ietf.org>" > <sip-overload@ietf.org <mailto:sip-overload@ietf.org>> >> Cc: "draft-ietf-soc-overload-rate-control.all@tools.ietf.org > <mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>" >> <draft-ietf-soc-overload-rate-control.all@tools.ietf.org > <mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>> >> Date: 06/27/2013 06:05 AM >> Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - >> Christer's comments >> Sent by:sip-overload-bounces@ietf.org <mailto:sip-overload-bounces@ietf.org> >> >> Hi, >> >> I have read draft-ietf-soc-overload-rate-control-04.txt as part of the WGLC. >> > ... >> Q7: In Section 7 you say that there are no IANA considerations. But, >> don’t you need to request IANA to register the new Via header field >> parameters? >> >> Regards, >> >> Christer >> >> >> >> >> _______________________________________________ >> sip-overload mailing list >>sip-overload@ietf.org <mailto:sip-overload@ietf.org> >>https://www.ietf.org/mailman/listinfo/sip-overload > > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload >
- [sip-overload] WGLC: draft-ietf-soc-overload-rate… Christer Holmberg
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… Janet P Gunn
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… Christer Holmberg
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… Janet P Gunn
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… Christer Holmberg
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… Christer Holmberg
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… Christer Holmberg
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… Christer Holmberg
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… Paul Kyzivat
- [sip-overload] NaN? RE: WGLC: draft-ietf-soc-over… Janet P Gunn
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… DRAGE, Keith (Keith)
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… Paul Kyzivat
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… Janet P Gunn
- Re: [sip-overload] NaN? RE: WGLC: draft-ietf-soc-… NOEL, ERIC C (ERIC C)
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… NOEL, ERIC C (ERIC C)
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… NOEL, ERIC C (ERIC C)
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… NOEL, ERIC C (ERIC C)
- Re: [sip-overload] WGLC: draft-ietf-soc-overload-… DRAGE, Keith (Keith)