Re: [sip-overload] Comments on draft-ietf-soc-load-control-event-package-01

["SHEN, CHARLES" <[e-mail]>]

Hi Shida,

[Shida] Overall it may be worthwhile adding a terminology
section, if not I think all the explicit text describing the
term should probably added where the term
appears for the first time.

[Shida] I for some reason thought the req draft would have some terminology section
but it didn't. I do think we should probably have consistent terminology uses
across all the drafts published under SOC WG if possible.

[CS] I agree.   I have also been pondering on adding a terminology section for this document. But for now, I think will probably add some description to the terms you mentioned where they first appear, and consolidate some of them as appropriate. If we still see a strong need for a terminology section after that, I am certainly open to add it.  

[Shida]  Is the load control filter content different from load control filter content definition?

[CS] The "definition" here probably more meant to be "format". I can rephrase them. 

[CS] I generally agree with all other comments. 

Thanks!

Charles



On Nov 8, 2011, at 4:23 AM, SHEN, CHARLES wrote:

> Hi Shida,
>
> Thank you very much for your review and I apologize for the late reply. Please find my comments inline.
>
>> -----Original Message-----
>> From: [e-mail] [mailto:sip-overload-
>> [e-mail]] On Behalf Of Shida Schubert
>> Sent: Monday, October 03, 2011 10:48 AM
>> To: [e-mail]
>> Subject: [sip-overload] Comments on draft-ietf-soc-load-control-event-
>> package-01
>>
>>
>> I recently reviewed the draft and below are some comments.
>>
>> A: Terminology
>>
>> First of all, I find that the document is rather hard to read
>> because; 1. it uses different terminology for what I believe is
>> the same thing. 2. introduce many terminology that
>> is not defined anywhere and 3. the terminology used should
>> probably be aligned with that of the other drafts
>> that define some of these terminologies (RFC6537 etc).
>
> We can look at those terms you referred to and improve as appropriate. But I could not find RFC6537, is it a typo or can you provide a link?
>

 I for some reason thought the req draft would have some terminology section
but it didn't. I do think we should probably have consistent terminology uses
across all the drafts published under SOC WG if possible.

>>
>> Here are some examples;
>>
>> 1. "load control" - should this be "overload control"?
>
> The reason for using load control instead of overload control is that the mechanism is more generically applicable. Although the motivation is driven by overload control, it could also be used for load control purely determined by QoS/service level agreements, for example. I am open to either terms depending on what the majority thinks.

 Okay. This makes sense.

>
>> 2. What is "user load control information"?
>
> Load control information is associated with user's identities, e.g., phone numbers, SIP addresses, which is mentioned in the abstract. But I can remove the word "user" there if that sounds clearer to you.

 Well, we can leave it as is but may be some
explanation such as the one you provided above
if the term is used will be useful.

>
>> 3. "edge server" - edge of what? At the edge of domain?
>
> SIP servers in the edge networks (as opposed to SIP servers in the core networks), would that sound better or do you have other suggestions?

 Sounds good.

>
>> 4. load document, load control document and load filter, are they the
>> same thing?
>
> Load document probably should be load control document. A load control document is (specifically) an XML document that inherits and enhances the common policy document defined in RFC4745 (Sec. 6.1). Load filter is a more generic term associated with the (filtering) mechanism. Any suggestion?

 I just think we should use consistent terminology, I don't really
care what term is picked as long as it is consistent across the document.

>
>> 5. load filtering mechanism and load filter control the same thing?
>
> They are, and they should probably be consolidated.

 Sounds good.

>
>> 6. What is a dynamic filter?
>
> Meaning the filtering contents are dynamically computed based on current network status. This is mentioned in Section 4.2 but could be made more explicit.
>

 Sounds good.

>> 7. What is a load control policy maker?
>
> The party that determines the policy for load control.

 With all the terminology used through out the document,
one can probably imagine what the entity do but I think
it is better to clarify so there is little misunderstandings.

>
>> 8. What is a policy entry point?
>
> The entity through which the policy is first injected (into the network).

 Same comment applies as above.

>
>> 9. What is a filter computation decision maker?
>
> The party which determines the filter contents (e.g., through some algorithm).

 Same comment applies as above.

>
>> 10. Is load control policy, load control information and load control
>> rule the same thing?
>
> I consider policy a type of information expressed in a set of rules here. I am open to the possibility of consolidating these terms if the meaning is clear.
>
>> 11. What is load control filter content definition?
>>
>
> Load control filter content refers to the set of rules (including conditions and actions) specified for the filtering.

 Is the load control filter content different from load control filter content definition?

 The rest sounds good.

 Regards
  Shida

>
>> Also some terminology can be changed to common terminology used in SIP
>> related RFCs
>>
>> e.g. SIP entity subscribers > SIP subscribers or subscribers
>> e.g. local format/global format > local number / global number
>> [RFC3966]
>>
>>
>
> I can change them accordingly.
>
>> B: Requirements
>>
>> The draft does a really nice job evaluating whether the
>> document meets the requirements set forth by RFC 5390 in
>> section section 9. but the draft also has design requirements
>> in section 3. This seems reasonable thing to have but shouldn't
>> these requirements expressed with RFC2119 language?
>>
>
> I can do that.
>
>>
>> C: Behavior of Notifier and Subscriber is mixed in section 5.6
>> - I think followings should be described as Subscribers' behavior.
>>
>> "SIP entity subscribers SHOULD try to subscribe to all those SIP entity
>>   notifiers with which they have regular signaling exchanges, although
>>   not all such SIP notifiers may permit such a subscription"
>>
>
> I will move that sentence as suggested.
>
>> D: Technical questions
>>
>> 1. section 5.7.
>>   -  "Following the [RFC3265] specification, a notifier MUST send a
>> NOTIFY
>>   with its current load control policy to the subscriber upon
>>   successfully accepting or refreshing a subscription.  The NOTIFY
>>   request MAY include a body. "
>>
>>   - So it says MUST send a NOTIFY but it is followed by MAY include a
>> body.
>>     If load control policy is carried in a body, I don't know there is
>> a MAY following
>>     the first paragraph.
>>
>>  - If what you want to say is to include the control policy in the
>> body when
>>     there is an active policy to be MUST and otherwise a MAY, this
>> should be
>>     clarified.
>>
>> 2. section 5.8.
>>  - "Upon receipt of a NOTIFY request with a Subscription-State header
>>   field containing the value "terminated", the subscriber MUST remove
>>   all previously received load control information and process all
>>   calls without applying any restriction"
>>
>> - This should be clarified that this applies only to the relevant
>> filter and
>>    not to all the policy that may be active at the time of receiving
>> this NOTIFY.
>>
>
> You are right in both. I will add clarification accordingly.
>
> Thanks again.
>
> Charles
>
>
>> Regards
>>  Shida
>>
>>
>> _______________________________________________
>> sip-overload mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sip-overload