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(_at_)huawei(_dot_)com]
Sent: Saturday, September 12, 2009 4:15 PM
To: Bernard_Aboba(_at_)hotmail(_dot_)com
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(_at_)ietf(_dot_)org) within the next two weeks, and include the
authors of the
draft as well.
Thank you,
Tina
http://tinatsou.weebly.com/contact.html
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf