Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4005bis-11

Glen Zorn <> Sun, 07 October 2012 07:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 859F921F84EC; Sun, 7 Oct 2012 00:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QJeOIyN2wjX8; Sun, 7 Oct 2012 00:28:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 38A9F21F84EA; Sun, 7 Oct 2012 00:28:19 -0700 (PDT)
Received: by with SMTP id ro8so3203714pbb.31 for <multiple recipients>; Sun, 07 Oct 2012 00:28:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Xa6g5o0xcjFHO82Ht242m0ngBDIZSArp/jH6CIuiQ6A=; b=WQYq2mEvCOMWxbDQO3asOtatYVP9P3lw6+8kbX6o064bJzsDjVqQZZNXnEkKazhXKH i7ifP2wxhaK1wErNv3SV5xxpRB6QVsvHgrSMCfAKipZiEs0ww9ogmEZnMcdGXuavobpQ q4FrgiuL7FkqXq6Hc126Ro7tOiVsIU2jGPQTJRp81EOkP1RVDSvZjUw36Q4YE9aMzOQM tEREvFP/ZquvStaBwOaSM9XXmV3PwOiFxJrrxHFT/5sXcSLRi+Xs6oz/ymekMXSCWpEm urdxlG1jEOB++nm6OXkeBHd9tgRFqz47iAJamydyfJaBQIXQNehyETOtWaGIkva4iMBA 2kqg==
Received: by with SMTP id ua7mr44345460pbc.91.1349594898753; Sun, 07 Oct 2012 00:28:18 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id oi2sm7531203pbb.62.2012. (version=SSLv3 cipher=OTHER); Sun, 07 Oct 2012 00:28:18 -0700 (PDT)
Message-ID: <>
Date: Sun, 07 Oct 2012 14:28:10 +0700
From: Glen Zorn <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Black, David" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>, "" <>, "" <>, "" <>, "" <>
Subject: Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4005bis-11
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 07 Oct 2012 07:28:20 -0000

On 09/18/2012 06:53 AM, Black, David wrote:

> I am the assigned Gen-ART  reviewer for this draft. For background on
 > Gen-ART, please see the FAQ at
 > <>;.
 > Please resolve these comments along with any other Last Call
 > comments you may receive.
 > Document: draft-ietf-dime-rfc4005bis-11 Reviewer: David L. Black
 > Review Date: September 17, 2012 IETF LC End Date: September 18, 2012
 > IESG Telechat date: (if known)
 > Summary:
 > This draft is on the right track but has open issues, described in
 > the review.
 > This draft is part of a set of drafts that updates the DIAMETER
 > protocol; this draft specifies the application of DIAMETER to AAA for
 > network access. The draft is heavily based on RFC 4005, which it
 > obsoletes, and requires significant DIAMETER familiarity (including
 > familiarity with its companion drafts, starting with the rfc3588bis
 > draft) for complete understanding.
 > The draft is in good shape and reads well. I found one major open
 > issue, a few minor issues, and several nits.
 > Major issues:
 > This draft makes significant use of UTF-8 in its formats (some
 > subsections of sections 4.2, 4.4 and 4.5) for strings that are
 > intended to be compared for equality or processed by protocol
 > participants, but does not contain considerations for Unicode
 > processing that are sufficient to support this usage. Examples of
 > UTF-8 usage in this draft include:
 > - 4.2.5 and 4.2.6: The NAS server may perform authorization based on
 > the Called-Station-Id and Calling-Station-Id AVPs under some
 > circumstances. - 4.4.3: The Callback-Id AVP is intended to be
 > interpreted by the NAS.
 > All use of UTF-8 in this draft relies upon the specification of the
 > UTF8String format in the rfc3588bis draft. That specification is
 > insufficient to support the usage in the above examples, and there
 > are no Unicode considerations in this draft. Even binary comparison
 > of Unicode strings for equality generally requires specification of
 > string preparation (e.g., normalization) in order for string
 > comparison to work as expected.
 > The variety of Unicode strings in this draft makes it important to
 > lay out the Unicode requirements and considerations for each AVP. I
 > see at least 5 classes of possible Unicode
 > requirements/considerations:
 > 1) String preparation so that tests for equality work as expected.
 > This may suffice for the Called-Station-ID AVP (4.2.5) and
 > Calling-Station-ID AVP (4.2.6) if the internal structure of those
 > strings is not used in authorization.

Both those AVPs are specified to contain ASCII encoded as UTF-8.  Is 
string preparation necessary in that case?

> 2) Detailed string format for a
 > string that is processed by a protocol participant, e.g., the
 > Callback-ID AVP (4.4.3).

That format is unknown in this case.
> 5) Statement that the string  contains an FQDN, as stated for one case of
 > the Tunnel-Client-Endpoint AVP in 4.5.4. That specific statement is
 > incomplete, as it needs to be accompanied by a normative reference to
 > a document that specifies the format of internationalized domain
 > names, and probably needs to also state which types of labels (e.g.,
 > A-label, U-label) are allowed.
 > Every use of UTF8String in this draft needs to be checked, and most
 > of them are likely to need some attention. The ongoing work in the
 > precis WG may help with some of this, and I would suggest talking to
 > the APP ADs, especially Pete Resnick (hi Pete) before embarking on
 > significant work in this area in order to avoid wasted or duplicated
 > efforts.

OK, this last one bothers me a lot: you /seem /to be suggesting that we 
hold up this draft to wait for the result of a WG which has yet to 
publish a problem statement.  I'm sure that that is not the case, but it 
sure sounds like it.

 > Minor Issues:
 > [1] End of Section 2 on p.8:
 > As a result, service cannot be started as a result of a response to
 > an authorization-only request without introducing a significant
 > security vulnerability.
 > Please explain what to do about this - a simple rewrite with a
 > "SHOULD NOT" would suffice, e.g.:
 > As a result, service SHOULD NOT be started as a result of a response
 > to an authorization-only request because that may introduce a
 > significant security vulnerability.

The text in question is descriptive, not said, however, 
I think that it's not really clear.  I think that it should say 
something like "As a result, a new session cannot be started as a result 
of a response to an authorization-only request without introducing a 
significant security vulnerability."

 > This should also be noted in the Security Considerations section.
 > [2] In the message formats in Section 3, QoS-Filter-Rule is
 > inconsistently capitalized.

OK, thanks.

> Also the use of QoSFilterRule  as the
 > format for the QoS-Filter-Rule AVP in Section 4.1.1 is potentially
 > confusing. Please add a sentence in 4.1.1 to say that QoSFilterRule
 > is the format for the QoS-Filter-Rule AVP.
 > [3] Section 4.2.1. In this and the other AVP Flag Rules tables,
 > please explain what the values in the MUST and MUST NOT columns
 > mean.
 > [4] Based on this text in 4.4.9:
 > The use of this AVP is NOT RECOMMENDED; the AVPs defined by
 > Korhonen, et al. [RFC5777] SHOULD be used instead.
 > I would have expected RFC5777 to be a Normative Reference, not an
 > Informative Reference.

I don't care particularly, but I don't think that it's really necessary 
to understand RFC 5777 to understand this document.

 > Nits/editorial comments:
 > After the command table in Section 3 and other similar tables, please
 > add a sentence to say that the -Request and -Answer commands in each
 > similarly-named command pair are distinguished by the value of the
 > 'R' bit in the Command Flags field of the command. This is already
 > stated in the command definitions, but the sentence should be added
 > after the table for clarity because each command pair shares a
 > Command Code.
 > idnits 2.12.13 found a few potential nits:
 > == There are 7 instances of lines with non-RFC5735-compliant IPv4
 > addresses in the document. If these are example addresses, they
 > should be changed.
 > That can probably be ignored, as these instances are likely generated
 > by text such as cross-references to Section
 > == Missing Reference: 'BASE' is mentioned on line 219, but not
 > defined
 > That's definitely a problem. Was [I-D.ietf-dime-rfc3588bis]
 > intended?

No.  The passage in question is a verbatim quote from RFC 4005.

 > -- Possible downref: Non-RFC (?) normative reference: ref.
 > 'ANITypes'
 > That reference would be:
 > [ANITypes] NANPA Number Resource Info, "ANI Assignments",
 > < number_resource_info/
 > ani_ii_assignments.html>.
 > Is that reference sufficiently stable (e.g., IANA-class or better
 > management)?

Yes, I think so.

> My guess is that it is  sufficiently stable, but I'm not
 > the expert.
 > -- Obsolete informational reference (is this intentional?): RFC 1334
 > (Obsoleted by RFC 1994)
 > That reference may be intentional,