I reviewed the document draft-ietf-soc-overload-design in general
and for its operational impact.
Do not be alarmed -- Operations directorate reviews are solicited primarily to help
the Area Directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on documents requiring their attention
and spend less time on the trouble-free ones.
Improving the documents is important, but clearly a secondary purpose.
A third purpose is to broaden the OpsDir reviewers' exposure to work going
on in other parts of the IETF.
Reviews from OpsDir members do not in and of themselves cause the IESG to
raise issue with a document. The reviews may, however, convince individual
IESG members to raise concern over a particular document requiring further
discussion. The reviews, particularly those conducted in last call and
earlier, may also help the document editors improve their documents.
--
Review Summary:
Intended status: Informational
This document discusses models and design considerations for a SIP overload control mechanism.
As such it doesn't document in much detail exactly how the mechanisms will be implemented, and so many of the standard Ops Directorate questions are not hugely relevant.
Is the document readable?
Yes.
Is the document class appropriate?
Yes.
Is the problem well stated?
Yes.
Are there nits?
No:
No issues found here.
Summary: 0 errors (**), 0 warnings (==), 1 comment (--).
(comment is because of date!)
Is the problem really a problem?
Yes. (Taken as a given that devices can become overloaded, solving this is necessary).
Does the document consider existing solutions?
Yes (I am not a SIP geek and there may be other solutions that were not discussed).
Does the solution break existing technology?
No -- well, not to the best of my knowledge.
SIP is Dark Magic to me, and I don't know many of the existing technologies, but it all sounds benign!
Does the solution preclude future activity?
No.
Is the solution sufficiently configurable?
Yes.
Can performance be measured? How?
Yes -- integral to the design of the system is monitoring for overload. The document could possibly have better explained that this information should be exposed for monitoring purposes, but the other docs are probably a better place for this.
Does the solution scale well?
Dealing with overload is very much required for scaling (basically the point of the doc!).
Is Security Management discussed?
Yes, very well -- the Security Considerations is long, clear and well thought out
By dealing with / responding to overload, DoS situation can be avoided.
More specific information will be discussed in documents specific to the overload feedback mechanisms.
--
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf