Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package

[<[e-mail]>]

Hi!

Here are my comments about this I-D.

1) Section 4.3, move paragraph 7 (line 376 - 386) after paragraph 5 (i.e. after line 360) and modifies the first two sentences as follows:

"In the above case, the network entity where load filtering policy is first introduced is the SIP server providing access to the resource that creates the overload condition. In other cases, the network entry point of load filtering policy could also be an entity that hosts this resource. "

2) Section 5.8, line 525-528

The current text suggests that incoming requests are filtered irrespective of their actual destination. The subscriber should rather apply filters on requests that are outgoing to the pre-overloaded destination. One solution would be to rephrase the following text:

"A subscriber receiving the notification first installs these rules and then filter incoming requests to enforce actions on appropriate requests, for example, limiting the sending rate of call requests destined for a specific SIP entity."

With

"A subscriber receiving the notification first installs these rules and then filter outgoing requests towards the notifier to enforce actions on appropriate requests, for example, limiting the sending rate of call requests destined for a specific SIP entity."

This would however not permit the use of external state agents as described in section 5.12. Therefore it seems that a "target sip entity" parameter should be added to overload control documents. 

3) Section 5.8, add the following text (adapted from draft-ietf-soc-overload-control) after line 537:

"When enforcing actions on requests matching the filters, subscribers SHOULD honor the local policy for prioritizing SIP requests such as policies based on the content of the Resource-Priority header (RPH, RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may indicate high priority requests that should be  preserved as much as possible during overload.  The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload.  Other indicators, such as the SOS URN [RFC5031] indicating an emergency request, may also be used for prioritization."

4) Section 6.3.1, matching identities: After line 699, add the following text:

"Before evaluating call-identity conditions, the subscriber shall convert URIs received in SIP header fields in canonical form as per RFC 3261, except that the phone-context parameter shall not be removed, if present."

5) Section 6.3.1, local number grouping:

The proposed solution for local numbers is not suitable. For example, if the phone-context for short service numbers in a country is the country code, the solution does not permit to define a filter that excludes all E.164 numbers in that country but retain all short service numbers. I think we should either define another solution or state that grouping of local numbers is not supported or state that grouping of local numbers only works under specific assumptions on the use of phone-context values.

6) Section 6.3.1, line 746 - 753, remove the last but one sentence and reword the rest of the text accordingly. Reason: The use of local number 'tel' URI in the R-URI and To header field is not rare. In several countries, short numbers are used quite extensively to access special services.

"Second, use of the local number 'tel' URI in practice is expected to be rare."  

7) Clause 6.3.3, after line 800, add:

"SUBSCRIBE requests are not filtered if the event-type header field indicates the event package defined in this document."

8) Section 7, line 985 - 990: replace "call type" with "call identity type" (3 times)

9) Section 8.1

Line 1048, add "except in specific cases when the Intelligent Network architecture is used [AINGR].

Line 1060, remove the last part of the first sentence starting with "and the number of prefix to be matched.": ITU IN specifications allow for dynamic sets.

Line 1068, remove the last part of the first sentence staring with "with a fixed set.": Reason: ITU IN specifications allow for dynamic sets.

10)          Miscellaneous points
Section 1, line 106, replace RFC3265 with RFC3261
Section 4.1, line 231, replace "proxy" with "node" (this text should apply to any type of SIP entity)
Section 4.3, line 265, replace "proxy" with "node" (this text should apply to any type of SIP entity)
Section 4.3, Line 341, replace "singling" with "signaling"
Section 4.3, Line 342, replace "all signaling relationship in Figure 1 is" with "all signaling relationships in Figure 1 are"
Section 5.6, Line 503, add "request" after "SUBSCRIBE"
Section 5.11, Line 585, remove "is"
Section 6.5, Line 851, replace "vliad" with "valid"

Bruno


> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]]
> De la part de Salvatore Loreto
> Envoyé : lundi 2 juillet 2012 21:09
> À : [e-mail]
> Cc : Volker Hilt
> Objet : [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package
> 
> [as chair]
> 
> based on the mailing list discussion and the one we had during the last
> SoC f2f meeting in Paris,
> the chairs think the draft-ietf-soc-oload-control-event-package is ready
> for the WGLC.
> 
> Today we are starting a two-week working group last call.
> This call ends on Wednesday, July 16th.
> 
> the last version of the document can be retrieved here:
> http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-03
> 
> 
> reviews and comments are really appreciate and requested from all the
> participants
> 
> 
> cheers
> /Sal
> 
> --
> Salvatore Loreto, PhD
> www.sloreto.com
> 
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.