Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jun 2013 10:05:41 +0000

Hi,

I have read draft-ietf-soc-overload-rate-control-04.txt as part of the WGLC.

I don't have any technical issues, in general I think it's a will written document, and I think the draft can be passed to IESG for publication.

However, there are some editorial issues that you might want to fix at this point, because they might come up sooner or later anyway.

Q1: General: The draft uses "client" and "SIP client" terminology (similar for "server"). I suggest to use consistent terminology.

Q2: General: In some places the draft refers to draft-ietf-soc-overload-control-12 without the "[" and "]" characters around. I assume you have "hardcoded" the draft name, instead of using a reference?

Q3: My understanding is that the Abstract section shall not contain references, so please remove those.

Q4: In Section 3.1, I suggest to replace:

"When in overload, the server uses [draft-ietf-soc-overload-control-

      12] via header oc parameters of SIP responses to inform the clients

      of its overload state and of the target SIP request rate."

...with:

"When in overload, the server uses the Via header field oc parameters [draft-ietf-soc-overload-control-

of SIP responses in order to inform the clients of its overload state and of the target SIP request rate."

Q5: In Section 3.2, I suggest to change the section name from:

"3.2. Summary of via headers parameters for overload control"

...to:

"3.2. Via header field parameters for overload control"

Q6: In Section 3.2, I think it would be good to indicate whether the Via header field parameters are used in SIP Requests, SIP Responses, or both. I know that you describe it later, but I think it would be good to have it already in the overview section.

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

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 27 Jun 2013 09:32:40 -0400

Christer,

The IANA considerations section of  draft-ietf-soc-overload-control 
registers the new Via header field parameters.

Is it needed here as well?

Janet

[email-masked] wrote on 06/27/2013 06:05:41 AM:

> From: Christer Holmberg <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" 
> <[email-masked]>
> Date: 06/27/2013 06:05 AM
> Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control -
> Christer's comments
> Sent by: [email-masked]
> 
> Hi,
> 
...
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jun 2013 16:54:33 +0000

Hi,

>The IANA considerations section of  draft-ietf-soc-overload-control registers the new Via header field parameters.
>

The draft (Section 5) does extend the oc parameter, doesn’t it? I would assume that needs to go to IANA.

Regards,

Christer

[email-masked]<mailto:[email-masked]> wrote on 06/27/2013 06:05:41 AM:

> From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
> To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>
> Sent by: [email-masked]<mailto:[email-masked]>
>
> Hi,
>
...
> [email-masked]<mailto:[email-masked]>

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 27 Jun 2013 15:04:13 -0400

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 <[email-masked]>
To:     Janet P Gunn/USA/CSC@CSC
Cc:     "[email-masked]" 
<[email-masked]>, 
"[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>
Date:   06/27/2013 12:54 PM
Subject:        VS: [sip-overload] WGLC: 
draft-ietf-soc-overload-rate-control -  Christer's comments

Hi,

>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

...

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jun 2013 19:42:07 +0000

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:[email-masked]]
Lähetetty: 27. kesäkuuta 2013 22:04
Vastaanottaja: Christer Holmberg
Kopio: [email-masked]; [email-masked]; [email-masked]
Aihe: Re: VS: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments

Christer

       oc          = "oc" [EQUAL oc-num]
       oc-num      = 1*DIGIT

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

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 <[email-masked]<mailto:[email-masked]>>
To:        Janet P Gunn/USA/CSC@CSC
Cc:        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date:        06/27/2013 12:54 PM
Subject:        VS: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control -        Christer's comments
________________________________

Hi,

Regards,

Christer

...