Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4005bis-11
Glen Zorn <glenzorn@gmail.com> Sun, 07 October 2012 07:28 UTC
Return-Path: <glenzorn@gmail.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859F921F84EC; Sun, 7 Oct 2012 00:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJeOIyN2wjX8; Sun, 7 Oct 2012 00:28:19 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38A9F21F84EA; Sun, 7 Oct 2012 00:28:19 -0700 (PDT)
Received: by mail-pb0-f44.google.com 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; d=gmail.com; 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 10.68.234.7 with SMTP id ua7mr44345460pbc.91.1349594898753; Sun, 07 Oct 2012 00:28:18 -0700 (PDT)
Received: from [192.168.0.102] (ppp-115-87-90-243.revip4.asianet.co.th. [115.87.90.243]) by mx.google.com with ESMTPS id oi2sm7531203pbb.62.2012.10.07.00.28.15 (version=SSLv3 cipher=OTHER); Sun, 07 Oct 2012 00:28:18 -0700 (PDT)
Message-ID: <50712F0A.1050309@gmail.com>
Date: Sun, 07 Oct 2012 14:28:10 +0700
From: Glen Zorn <glenzorn@gmail.com>
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" <david.black@emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-dime-rfc4005bis@tools.ietf.org" <draft-ietf-dime-rfc4005bis@tools.ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "dime@ietf.org" <dime@ietf.org>, "dime-chairs@tools.ietf.org" <dime-chairs@tools.ietf.org>
Subject: Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4005bis-11
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=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 > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > 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 prescriptive.at 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 4.4.10.1 > > == 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", > <http://www.nanpa.com/ 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, Yes. ...
- [Dime] Fwd: Gen-ART review of draft-ietf-dime-rfc… Benoit Claise
- Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4… Glen Zorn
- Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4… Barry Leiba
- Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4… Black, David
- Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4… Black, David