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

["DRAGE, Keith (Keith)" <[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, 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-----
> 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