|
I reviewed the document draft-ietf-speermint-requirements-07.txt in general and for its operational impact. 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 requirements for session peering in voice, presence, instant messaging and multimedia. 1. Is the document readable? In general, the document provides a readable listing of requirements. However additional background on the requirements could have been provided, which would make the document easier to understand. 2. Does it contain nits? Yes. See below. 3. Is the document class appropriate? Yes. 4. Does the document consider existing solutions? This is a requirements document, so it largely focuses on requirements rather than solutions. However, there are instances where the document does not sufficiently discuss existing practices. For example, in Section 3.2 the document refers to limitations of DNS in providing different responses based on the querier: "However, this DNS-based solution may be limited in cases where the DNS response varies based on who sends the query (peer-dependent SBEs, see below).... Notes on solution space: For advertising peer-dependent SBEs (peer variability), the solution space based on [RFC3263] is under specified and there are no know best current practices. Is DNS the right place for putting data that varies based on who asks?" Content Distribution Networks (CDNs) have quite a bit of operational experience with use of DNS to provide "data that varies based on who asks". Information on existing approaches is provided in RFCs 3466, 3568, and 3570. CDNs also have experience in use of application re-direct for global load balancing. I was therefore somewhat surprised that this document did not discuss or reference work on CDNs. While the document focuses on layer 5 peering, it does seem like it would be worthwhile to at least have some discussion of lower layer load balancing techniques such as anycast (e.g. RFC 4786), which when combined with DNS can be used to provide "data that varies based on who asks". 5. Does the solution break existing technology? This is a requirements document, so that it doesn't specify solutions. However, as described above I would like to see a more in-depth discussion of the capabilities and limitations of existing technology. 6. Does the solution preclude future activity? As a requirements document, the goal is to guide future activity. 7. Is the solution sufficiently configurable? While the document focuses on requirements rather than solutions, I do think it would be valuable to discuss the potential service provider objectives in more detail. For example, specifying exit and entry points is a means, not an end. Within the CDN space, we have come to understand that the "best" server may depend on whether the goal is to optimize latency or throughput. 8. Can performance be measured? Performance metrics are discussed in Appendix A.1. 9. Does the solution scale well? Given that the document focuses on requirements, the scalability of the (as yet to be determined) solution is out of scope. 10. Is Security Management discussed? Section 5 discusses security requirements. Note that since the publication of RFC 3263, a number of additional documents have been dealt with the issue of TLS session establishment. These documents (such as draft-ietf-sip-sips) may be worth referencing in addition to RFC 3263 within Section 3.2: The mechanisms recommended for locating a peer's SBE MUST be able to convey how a peer should initiate secure session establishment. Notes : some mechanisms exist. For example, the required protocol use of SIP over TLS may be discovered via [RFC3263]. ------------------------------------------------ idnits 2.11.11 tmp/draft-ietf-speermint-requirements-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see http://trustee.ietf.org/license-info), which is required from December 16, 2008. Version 1.34 of xml2rfc can be used to produce documents with boilerplate according to the mentioned Trust License Policy document. -- Found old boilerplate from RFC 3978 Section 5.1 on line 15. The obsolete RFC 3978 Section 5.1 text: "By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79." -- Found old boilerplate from RFC 3978 Section 5.5 updated by RFC 4748 on line 971. The obsolete RFC 3978 Section 5.5 updated by RFC 4748 text: "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." -- Found old boilerplate from RFC 3979 Section 5 paragraph 1 on line 982. The obsolete RFC 3979 Section 5 paragraph 1 text: "The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79." -- Found old boilerplate from RFC 3979 Section 5 paragraph 2 on line 989. The obsolete RFC 3979 Section 5 paragraph 2 text: "Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr." -- Found old boilerplate from RFC 3979 Section 5 paragraph 3 on line 995. The obsolete RFC 3979 Section 5 paragraph 3 text: "The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@xxxxxxxxx" Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.). trust-12-feb-2009 Section 6.c.iii text: "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English." Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-05 == Outdated reference: A later version (-03) exists of draft-ietf-pmol-sip-perf-metrics-01 == Outdated reference: A later version (-13) exists of draft-ietf-sip-connect-reuse-11 == Outdated reference: A later version (-07) exists of draft-ietf-sip-dtls-srtp-framework-04 == Outdated reference: draft-ietf-sip-hitchhikers-guide has been published as RFC 5411 == Outdated reference: A later version (-08) exists of draft-ietf-speermint-architecture-06 == Outdated reference: draft-ietf-speermint-consolidated-presence-im-usecases has been published as RFC 5344 == Outdated reference: draft-ietf-speermint-terminology has been published as RFC 5486 == Outdated reference: A later version (-12) exists of draft-ietf-speermint-voip-consolidated-usecases-10 == Outdated reference: A later version (-05) exists of draft-niccolini-speermint-voipthreats-04 -- Obsolete informational reference (is this intentional?): RFC 3603 (Obsoleted by RFC 5503) Summary: 1 error (**), 12 warnings (==), 6 comments (--). ----------------------------------------------------------------------------- Date: Tue, 30 Jun 2009 09:57:49 +0800 From: tena@xxxxxxxxxx Subject: Operations Directorate Review To: bernard_aboba@xxxxxxxxxxx CC: rbonica@xxxxxxxxxxx; dromasca@xxxxxxxxx Hello Aboba, As a member of the Operations Directorate you are being asked to review the following IESG work item for it's operational impact. IETF Last Call: http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-07.txt Please provide comments and review to the Ops-dir mailing list (ops-dir@xxxxxxxx) within the next two weeks, and include the authors of the draft as well. Thank you, Tina http://tinatsou.weebly.com/contact.html |
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf