|
I reviewed the document draft-ietf-dime-diameter-cmd-iana-01.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: Standards Track This document aligns the rules for allocation of Diameter commands with those for allocation of Diameter application IDs. Is the document readable? [BA] There is considerable text duplicated between the Abstract and Section 1. The repetition makes the document less readable than it should be. My recommendation is to provide a shortened abstract, leaving most of the material now in the Abstract to Secton 1. Does it contain nits? There are a number of grammar and spelling issues, but only 1 warning found in the NIT checker: idnits 2.11.14 tmp/draft-ietf-dime-diameter-cmd-iana-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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: ---------------------------------------------------------------------------- No issues found here. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-dime-rfc3588bis-18 Summary: 0 errors (**), 1 warning (==), 0 comments (--). Is the document class appropriate? [BA] Yes. Does the document consider existing solutions? [BA] Yes. The abstract of the document describes the problem, which is that allocation of Diameter Application IDs does not require IETF consensus, while defining new Diameter commands does, per RFC 3588. This creates an incentive for SDOs to define new applications on existing commands rather than requesting assignment of new command codes. The document revises RFC 3588 allocation procedures, in order to align the allocation procedures. Does the solution break existing technology? [BA] The document argues that the disparity in allocation procedures for Diameter Application IDs and commands creates incentives for utilizing new Application IDs, rather than new Diameter commands. By making aligning the allocation of Diameter commands to Application IDs, the incentives for poor design choices might be addressed. However, my take is that the underlying problem is that Diameter contains too many extensibility mechanisms that aren't well enough defined. We have extensibility via Attributes (which can have the M bit set), Application IDs, and commands. RADIUS has somehow gotten by largely with Attribute extensibility, with additional commands defined on occasion. By creating so many extensibility mechanisms, it seems to me that Diameter has invited upon itself a host of interoperability problems that have not plagued its predecessor. Given this, it's hard for me to tell whether the proposed changes will really help without first understanding how RFC 3588bis plans to clarify the issues with Diameter extensibility. IMHO, neither Diameter Application IDs nor new commands should be requested unless they are absolutely necessary, due to their effects on interoperability. Does the solution preclude future activity? [BA] I found the allocation procedures for vendor-specific command codes somewhat odd. While command code allocations are handled on a First Come, First Served basis, the request SHOULD include a reference to a publicly available specification. Not all SDOs make their specifications publicly available immediately upon publication, so it is not clear that they can satisfy this requirement. Also, if the allocation is to a vendor, then it's not clear how they can make the specification "publicly available". Does an Internet-Draft qualify? A posting on a web site? An RFC? Section 4 states that if there is no publicly available specification, then the contact information MUST be provided. Wouldn't it make more sense for contact info to be a MUST in all situations? I wouldn't necessarily assume that a specification, if provided, would include contact information. Is the solution sufficiently configurable? [BA] Inherently Can performance be measured? [BA] This document does not relate to performance. Does the solution scale well? [BA] This document does not relate to performance or scaling issues. Is Security Management discussed? [BA] This document does not relate to security. ------------------------------------------------ From: Tina TSOU [mailto:tena@xxxxxxxxxx] Sent: Saturday, September 12, 2009 4:15 PM To: Bernard_Aboba@xxxxxxxxxxx Cc: Romascanu, Dan (Dan); Ron Bonica Subject: Operations Directorate Review Hello Aboba, As a member of the Operations Directorate you are being asked to review the following document as part o IETF Last Call: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cmd-iana 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