Hi Alan,
thanks for the comments, see my answers in line
regards
Sal
Alan Johnston wrote:
Here are a few comments on this draft.
Overall, I support this mechanism and think the work should progress.
While I understand the use and motivation for each of the parameters
throttle, force, and average, I'm not thrilled with the names. Force
was decidedly nonintuitive to me ("Use the force, Luke"), and the
three definitely don't go together as a cohesive set. Something like
rate-max, rate-min, and rate-average is much clearer. However, if
there is deployment and running code, then this is a good reason not
to rename parameters.
[Sal] I don't have any particular problem in changing the name, however
I will check about deployment and running code especially about
"throttle" that is already largely referenced and used by OMA
At the very least, the abstract needs to be expanded to explain what
these parameters do instead of just listing them.
[Sal] sure, I'll do in the next version
In dealing with very large resource list-type presence subscriptions,
we have found the need to not only limit the rate of notifications but
also the size of the batches, i.e. the number of bodies present in a
single NOTIFY. This is described in
http://tools.ietf.org/id/draft-johnston-sipping-batch-notify which
uses a very similar mechanism. I wonder if the authors could comment
on this as a complementary mechanism. I wonder if this throttling
mechanism on its own could actually make this situation worse - i.e.
fewer NOTIFYs are sent, but each NOTIFY is bigger.
[Sal] I have read your draft, and I am going to comment it in a separate
mail
One other comment on organization is to perhaps make a cleaner split
between normative and non-normative text. Most of Section 3 seems to
be non-normative although 3.7 has normative language. Section 4 seems
like it would be the logical place to begin normative language,
perhaps including a statement about this.
This next comment is just a suggestion - not a criticism. Recently in
my own drafts, I have been analyzing the normative language to make
sure that it adequately covers expected behavior. One way of doing
this is to extract only the normative language from a draft and read
just that, and see if the mechanism is fully specified. I have found
a number of examples of missing and conflicting normative language in
doing this. I haven't yet done this to this draft but suspect that it
could use this analysis since it has nearly 10 pages of normative text.
[Sal] thanks for the suggestion
One nit: In the Abstract, it should be "force" not "forge".
Thanks,
Alan
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
