[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

From: Tina TSOU [mailto:tena@xxxxxxxxxx]
Sent: Tuesday, July 21, 2009 1:04 PM
To: ops-dir@xxxxxxxx; 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?
  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?
  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?
  Is the solution sufficiently configurable?
  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.
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

[IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

Add to Google Powered by Linux