I agree with Alan's "support"/"work should progress", and with his
suggestion that the parameter names might be clearer as rate-max, rate-min,
and rate-average. I would support moving all normative text out of Section 3
as Alan suggested, as well.
I'm also interested in Alan's question about the interaction between
limitations on the rate of notifications and limitations on the size of
notifications - but I hope that this question doesn't delay progressing the
work.
Thanks,
Spencer
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. At the very least, the abstract needs to be expanded to
explain what these parameters do instead of just listing them.
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.
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.
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
