OPS-DIR review for draft-ietf-sipping-config-framework-15.txt

Please find below the OPS-DIR review of
draft-ietf-sipping-config-framework-15.txt performed by Tina Tsou. 
 
Regards,
 
Dan
 




________________________________

	From: Tina TSOU [mailto:[email protected]] 
	Sent: Tuesday, July 21, 2009 1:04 PM
	To: [email protected]; Romascanu, Dan (Dan)
	Subject: Re: [OPS-DIR] Request for a volunteer to perform an
early review
onhttp://www.ietf.org/id/draft-ietf-sipping-config-framework-15.txt
	
	
	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.
	 
	 
	 
	 
	B. R.
	Tina
	http://tinatsou.weebly.com/contact.html

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP