Hi Dan,
This is a review of
draft-ietf-sipping-config-framework-15.txt for its operational
impact.
Summary: This draft specifies the framework for
the profile delivery between the source and the device.
Review summary:.
In section 5.1.1, “Such temporary data is
not considered to be "configured" and is not expected to be
cached across resets.”
-- Would it be better to replace “is not
expected to be cached” to “SHOULD NOT be cached”?
In section 5.1.1, “A PDS receiving the enrollment
request SHOULD respond to the request, or proxy it to a PDS that can
respond. An exception is when a policy prevents a response (e.g.,
recognition of a DoS attack, an invalid device, etc.). The PDS then
verifies the identity presented in the request and performs any
necessary authentication. Once authentication is successful, the
PDS MUST either admit or reject the enrollment request, based on
applicable authorization policies. “
-- Would there be another
exception when a policy prevents forwarding the request to another PDS for the
same security concerns?
-----------
Possible Operational Issues: Below are listed a number of issues
that may
have significant operational impact. Further
explanation or
investigations is warranted on each of these.
---------
Review Questions:
Is the document readable?
Yes.
Does it contain nits?
In section 4.2, “Figure 4 illustrates the use case and highlights the
communications relevant to the framework specified in this document.”
-- “Figure 4” in this sentence should be replaced by “Figure
5”.
Is the document class appropriate?
The IETF draft for the framework or
architecture should usually be informational, while the definition or
extension of a protocol should usually be standard track. Would it be better
to split the draft into two, one for the framework, which is informational and
the other for the definition of the event, which is standard track?
Is the problem well stated?
The problem described by this
document is well-stated.
Is the problem really a problem?
Yes.
Does the document consider existing solutions?
The document considers the
existing SIP messages.
Does the solution break existing technology?
To the best of my
understanding, this will not break existing technology.
Does the solution preclude future activity?
No.
Is the solution sufficiently configurable?
Yes.
Can performance be measured? How?
There is no analysis of
performance in this draft.
Does the solution scale well?
The solution scales well in
multiple provider networks.
