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

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Jun 2013 05:40:01 +0000

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ä: [email-masked] [mailto:[email-masked]] Puolesta Christer Holmberg
Lähetetty: 27. kesäkuuta 2013 22:42
Vastaanottaja: Janet P Gunn
Kopio: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]]
Lähetetty: 27. kesäkuuta 2013 22:04
Vastaanottaja: Christer Holmberg
Kopio: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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 <[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,

>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

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Jun 2013 06:26:39 +0000

Hi,

So, with the third alternative, Section 5 would look something like:

5.  Syntax

        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
       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: [email-masked]; [email-masked]; [email-masked]
Subject: VS: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments

Hi,

oc-nan          = "nan"

…or something like that.

Regards,

Christer

Lähettäjä: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Puolesta Christer Holmberg
Lähetetty: 27. kesäkuuta 2013 22:42
Vastaanottaja: Janet P Gunn
Kopio: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Aihe: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments

Hi,

oc          = "oc" [EQUAL oc-num]

oc          = "oc" EQUAL oc-value

Regards,

Christer

Christer

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

Janet

Hi,

Regards,

Christer

...

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Jun 2013 06:32:00 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 28. kesäkuuta 2013 9:27
To: Janet P Gunn
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments

Hi,

5.  Syntax

        via-params =/ oc-nan
       oc-nan      = "NaN"

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

5.  Grammar

5.1.  General

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: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: VS: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments

Hi,

oc-nan          = "nan"

…or something like that.

Regards,

Christer

Hi,

oc          = "oc" [EQUAL oc-num]

oc          = "oc" EQUAL oc-value

Regards,

Christer

Christer

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

Janet

Hi,

Regards,

Christer

...

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Jun 2013 11:14:43 -0400

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:
> *From:[email-masked]
> [mailto:[email-masked]] *On Behalf Of *Christer Holmberg
> *Sent:* 28. kesäkuuta 2013 9:27
> *To:* Janet P Gunn
> *Cc:* [email-masked];
> [email-masked];
> [email-masked]
> *Subject:* Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control
> - Christer's comments
>
> Hi,
>
> 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
>
> **
> **
> **
> **
> **
> *From:*Christer Holmberg
> *Sent:* 28. kesäkuuta 2013 8:40
> *To:* Christer Holmberg; Janet P Gunn
> *Cc:* [email-masked]
> <mailto:[email-masked]>;
> [email-masked]
> <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *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ä:[email-masked]
> <mailto:[email-masked]>[mailto:[email-masked]]
> *Puolesta *Christer Holmberg
> *Lähetetty:* 27. kesäkuuta 2013 22:42
> *Vastaanottaja:* Janet P Gunn
> *Kopio:* [email-masked]
> <mailto:[email-masked]>;
> [email-masked]
> <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *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*
>
> 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]
> <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Aihe:* Re: VS: [sip-overload] WGLC:
> draft-ietf-soc-overload-rate-control - Christer's comments
>
> Christer
>
> 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.
>
>
>
> 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]>>
> ------------------------------------------------------------------------
>
>
>
>
> Hi,
>
>>The IANA considerations section of  draft-ietf-soc-overload-control
> registers the new Via header field parameters.
>>
> _
> [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]>
> [email-masked]

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 28 Jun 2013 11:16:08 -0400

Thanks Christer,

Syntax is definitely NOT my area of expertise, so I will let the authors 
follow up.

Eric and Philip,
What is supposed to happen when oc = "NaN"?  I do not see any reference to 
it in the rest of the document.  Is it even needed?

Janet

written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.

From:   Christer Holmberg <[email-masked]>
To:     Christer Holmberg <[email-masked]>, Janet P 
Gunn/USA/CSC@CSC
Cc:     "[email-masked]" <[email-masked]>, 
"[email-masked]" 
<[email-masked]>, 
"[email-masked]" <[email-masked]>
Date:   06/28/2013 03:25 AM
Subject:        RE: [sip-overload] WGLC: 
draft-ietf-soc-overload-rate-control - Christer's comments

From: [email-masked] [mailto:[email-masked]] 
On Behalf Of Christer Holmberg
Sent: 28. kesäkuuta 2013 9:27
To: Janet P Gunn
Cc: [email-masked]; 
[email-masked]; 
[email-masked]
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - 
Christer's comments
 
Hi,

5.  Syntax

        via-params =/ oc-nan
       oc-nan      = "NaN"

BTW, I think the syntax in draft-ietf-soc-overload-control should look 
like:

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

In both drafts, I would also suggest to rewrite the Syntax sections in the 
following way:
 
5.  Grammar
 
5.1.  General

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: [email-masked]; 
[email-masked]; 
[email-masked]
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.

(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ä: [email-masked] [
mailto:[email-masked]] Puolesta Christer Holmberg
Lähetetty: 27. kesäkuuta 2013 22:42
Vastaanottaja: Janet P Gunn
Kopio: [email-masked]; 
[email-masked]; 
[email-masked]
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.

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

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.

 
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 

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

[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]> 
> Sent by: [email-masked] 
> 
> Hi, 
>   
...

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 28 Jun 2013 16:46:18 +0000

Nowhere in RFC 3968 does it say that.

I agreed that what RFC 3968 does is ensure that new header field parameters have to be registered, and therefore an IANA registration section is required in this i-d to accomplish this. IANA registrations should be correct, but they are never "authorative".

However the defining i-d / RFC is still the normative specification of that parameter. If ABNF is the easiest way of defining this, then so be it.

Adding a header field parameter has never required the defining i-d / RFC to update RFC 3261, assuming the underlying RFC 3261 ABNF was extendable in the first place.

Regards

Keith

> -----Original Message-----
> On Behalf Of Paul Kyzivat
> Sent: 28 June 2013 16:15
> To: [email-masked]
> > perspective) would be to simply define a new "oc-nan" Via header field
> > parameter.
> >
> > *oc-nan          = "nan"*
> >
> > .or something like that.
> >
> > *re-defines *the *same parameter*. In addition, it's done in a backward
> > *"oc=NaN"* it will *reject* it, as it expects a numeric value.
> >
> > receives *"oc"* it will *reject* it, as it expects an oc-value. But, in
> > The draft (Section 5) does extend the oc parameter, doesn't it? I would
> >> don't you need to request IANA to register the new Via header field
> >> parameters?
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Jun 2013 13:36:52 -0400

Sorry to inflict this on the SOC wg, who probably just want to be told 
what to do. But this is not settled ground.

> Nowhere in RFC 3968 does it say that.

By "that" I presume you mean "3261 is no longer authoritative for header 
field parameters"?

> I agreed that what RFC 3968 does is ensure that new header field parameters have to be registered, and therefore an IANA registration section is required in this i-d to accomplish this. IANA regist…

I agree with you. Before 3968 there was no registry.

And while 3261 makes provision for parameters defined in the future via 
"generic-param", it doesn't say what the rules for defining new ones 
are. If you just infer from the names, then for Via the hook is called 
"via-extension". So I would be inclined to infer that it intended that 
an extension to 3261 was required.

Then a convention grew up where such extensions did so by redefining the 
3261 ABNF (e.g., 'via-params =/ ...') in a normative extension to 3261.

So at that time, to obtain an exhaustive list of header parameters, you 
could search 3261 and all declared extensions to it for syntax 
definitions of header field parameters.

RFC 3968 changed this by introducing a registry, and by saying that to 
add a new parameter you needed an RFC, but that it didn't need to be 
standards track. I *think* that also means it doesn't need to be 
declared as an *extension* to 3261. And so searching 3261 and extensions 
is no longer a sufficient mechanism to find all defined header field params.

> However the defining i-d / RFC is still the normative specification of that parameter. If ABNF is the easiest way of defining this, then so be it.

Agreed that ABNF is not required. But it must be clear.
And since this is intended to coordinate with the rest of sip that is 
defined by ABNF, it is strongly recommended. If it isn't, then some of 
use will probably complain if/when we notice.

> Adding a header field parameter has never required the defining i-d / RFC to update RFC 3261, assuming the underlying RFC 3261 ABNF was extendable in the first place.

The IANA registry is an authoritative list of all legitimate header 
field parameters.

I agree that the registry is not authoritative for the definitions 
themselves. The drafts containing those definitions, referenced by the 
registry, provide the actual authoritative definitions of the parameters.

The IANA registry is the only IETF supported way to discover *all* 
defined header field parameters other than reading each and every RFC.

	Thanks,
	Paul

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 28 Jun 2013 15:11:10 -0400

It seems to me that 
Either 
A
 draft-ietf-soc-overload-control-13 needs to register "loss" as an 
algorithm name with IANA
and 
draft-ietf-soc-overload-rate-control-04  needs to register "rate" as an 
algorithm name with IANA

OR
B
Neither needs to register  the algorithm name with IANA.

I don't have an opinion, I will let others make that decision 

But  it doesn't make sense to say that 
draft-ietf-soc-overload-rate-control-04  needs to register "rate" when 
draft-ietf-soc-overload-control-13 did not (if I am reading it correctly) 
register "loss".

I agree that it makes sense for   draft-ietf-soc-overload-rate-control  to 
extend the SYNTAX from
algo-list   = "loss" / *(other-algo) (from 
draft-ietf-soc-overload-control-13)
to be 
algo-list   = "loss" / "rate" /  *(other-algo)

But is "rate" already incorporated by being part of "other-algo"?

Janet

[email-masked] wrote on 06/28/2013 12:46:18 PM:

> From: "DRAGE, Keith (Keith)" <[email-masked]>
> To: Paul Kyzivat <[email-masked]>, "[email-masked]" 
> <[email-masked]>
> Date: 06/28/2013 12:46 PM
> I agreed that what RFC 3968 does is ensure that new header field 
> parameters have to be registered, and therefore an IANA registration
> section is required in this i-d to accomplish this. IANA 
> registrations should be correct, but they are never "authorative".
> 
> However the defining i-d / RFC is still the normative specification 
> of that parameter. If ABNF is the easiest way of defining this, thenso 
be it.
> 
> Adding a header field parameter has never required the defining i-d 
> / RFC to update RFC 3261, assuming the underlying RFC 3261 ABNF was 
> extendable in the first place.
> 
> Regards
> 
> Keith
> 
> > > In both drafts, I would also suggest to rewrite the Syntax sections 
in
> > > the following way:
> > > The text of draft-ietf-soc-overload-control  section 5.3 refers to 
the
> > > use of oc for either rate or loss
> > >
> > > "[email-masked] <mailto:[email-masked]
>"
> > > <[email-masked] <mailto:[email-masked]
>>
draft-ietf-soc-overload-rate-control -
> > >> I have read draft-ietf-soc-overload-rate-control-04.txt as part of 
the
> > WGLC.