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

["DRAGE, Keith (Keith)" <[e-mail]>]

I think here you have a strange definition of authoritative, which is confusing the issue.

By my definition at least, the authoritative source for all IANA material is the RFCs or other material cited to create the IANA registration. In my view IANA is not authoritative because it is a secondary source.

Apart from that I think our only difference is whether extending the ABNF creates an update of the original RFC or not. As I have indicated before, I don't believe it does, but we do need the requirements that do the extension in the rate-control draft, whether that makes it an update or not. We haven't as far as I know entered that discussion for this particular issue.

Regards

Keith

> -----Original Message-----
> From: NOEL, ERIC C (ERIC C) [mailto:[e-mail]]
> Sent: 09 July 2013 00:41
> To: 'Paul Kyzivat'; DRAGE, Keith (Keith)
> Cc: [e-mail]; Hilt, Volker (Volker); Gurbani, Vijay K (Vijay)
> Subject: RE: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control -
> Christer's comments
> 
> Keith, Paul,
> 
> I will also defer this comment to draft-ietf-soc-overload-control authors
> and comply with the resolution.
> 
> Thanks,
> 
> Eric Noel
> AT&T Labs, Inc.
> Rethink Possible
> 
> Network Design and Performance Analysis
> 200 South Laurel Avenue, D5-3D19
> Middletown, NJ 07748
> P: 732.420.4174
> [e-mail]
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Paul Kyzivat
> Sent: Friday, June 28, 2013 1:37 PM
> To: DRAGE, Keith (Keith)
> Cc: [e-mail]
> Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control -
> Christer's comments
> 
> Sorry to inflict this on the SOC wg, who probably just want to be told
> what to do. But this is not settled ground.
> 
> On 6/28/13 12:46 PM, DRAGE, Keith (Keith) wrote:
> > 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 registrations
> should be correct, but they are never "authorative".
> 
> 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
> 
> > 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