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

[Janet P Gunn <[e-mail]>]

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

[e-mail] wrote on 06/28/2013 12:46:18 PM:

> From: "DRAGE, Keith (Keith)" <[e-mail]>
> To: Paul Kyzivat <[e-mail]>, "[e-mail]" 
> <[e-mail]>
> Date: 06/28/2013 12:46 PM
> Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-
> control - Christer's comments
> Sent by: [e-mail]
> 
> 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, 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
> 
> > -----Original Message-----
> > From: [e-mail] [
mailto:[e-mail]]
> > On Behalf Of Paul Kyzivat
> > Sent: 28 June 2013 16:15
> > To: [e-mail]
> > Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control 
-
> > Christer's comments
> > 
> > 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:*[e-mail]
> > > [mailto:[e-mail]] *On Behalf Of *Christer 
Holmberg
> > > *Sent:* 28. kesäkuuta 2013 9:27
> > > *To:* Janet P Gunn
> > > *Cc:* [e-mail];
> > > [e-mail];
> > > [e-mail]
> > > *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:* [e-mail]
> > > <mailto:[e-mail]>;
> > > [e-mail]
> > > <mailto:[e-mail]>;
> > > [e-mail] <mailto:[e-mail]>
> > > *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ä:*[e-mail]
> > > <mailto:[e-mail]>[mailto:sip-overload-
> > [e-mail]]
> > > *Puolesta *Christer Holmberg
> > > *Lähetetty:* 27. kesäkuuta 2013 22:42
> > > *Vastaanottaja:* Janet P Gunn
> > > *Kopio:* [e-mail]
> > > <mailto:[e-mail]>;
> > > [e-mail]
> > > <mailto:[e-mail]>;
> > > [e-mail] <mailto:[e-mail]>
> > > *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:[e-mail]]
> > > *Lähetetty:* 27. kesäkuuta 2013 22:04
> > > *Vastaanottaja:* Christer Holmberg
> > > *Kopio:* [e-mail]
> > > <mailto:[e-mail]>;
> > > [e-mail] <mailto:[e-mail]>;
> > > [e-mail] <mailto:[e-mail]>
> > > *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 <[e-mail]
> > > <mailto:[e-mail]>>
> > > To: Janet P Gunn/USA/CSC@CSC
> > > Cc: "[e-mail]
> > > <mailto:[e-mail]>"
> > > <[e-mail]
> > > <mailto:[e-mail]>>,
> > > "[e-mail] <mailto:[e-mail]>"
> > > <[e-mail] <mailto:[e-mail]>>,
> > > "[e-mail] <mailto:[e-mail]
>"
> > > <[e-mail] <mailto:[e-mail]
>>
> > > 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
> > >
> > > _
> > > [e-mail]
> > > <mailto:[e-mail]>wrote on 06/27/2013 06:05:41 
AM:
> > >
> > >> From: Christer Holmberg <[e-mail]
> > <mailto:[e-mail]>>
> > >> To: "[e-mail] <mailto:[e-mail]>"
> > > <[e-mail] <mailto:[e-mail]>>
> > >> Cc: "[e-mail]
> > > <mailto:[e-mail]>"
> > >> <[e-mail]
> > > <mailto:[e-mail]>>
> > >> Date: 06/27/2013 06:05 AM
> > >> Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control 
-
> > >> Christer's comments
> > >> Sent by:[e-mail] <mailto:sip-overload-
> > [e-mail]>
> > >>
> > >> 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
> > >>[e-mail] <mailto:[e-mail]>
> > >>https://www.ietf.org/mailman/listinfo/sip-overload
> > >
> > >
> > >
> > > _______________________________________________
> > > sip-overload mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/sip-overload
> > >
> > 
> > _______________________________________________
> > sip-overload mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sip-overload
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload