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

Benoit Claise <bclaise@cisco.com> Mon, 24 September 2012 06:56 UTC

Return-Path: <bclaise@cisco.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 5047F21E803C for <dime@ietfa.amsl.com>; Sun, 23 Sep 2012 23:56:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.576
X-Spam-Level:
X-Spam-Status: No, score=-4.576 tagged_above=-999 required=5 tests=[AWL=-1.978, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 JAcZMPWEFkwn for <dime@ietfa.amsl.com>; Sun, 23 Sep 2012 23:56:12 -0700 (PDT)
Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 8341421E8043 for <dime@ietf.org>; Sun, 23 Sep 2012 23:56:11 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8O6uACA021826; Mon, 24 Sep 2012 08:56:10 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8O6u9oY002245; Mon, 24 Sep 2012 08:56:09 +0200 (CEST)
Message-ID: <50600409.6080900@cisco.com>
Date: Mon, 24 Sep 2012 08:56:09 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Glen Zorn <glenzorn@gmail.com>
References: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com>
X-Forwarded-Message-Id: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com>
Content-Type: multipart/alternative; boundary="------------080603090402020808090709"
Cc: dime mailing list <dime@ietf.org>
Subject: [Dime] Fwd: 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: Mon, 24 Sep 2012 06:56:13 -0000

Hi Glen,

The IETF LC is now finished.
Can you please answer/address David's points

Regards, Benoit.


-------- Original Message --------
Subject: 	Gen-ART review of draft-ietf-dime-rfc4005bis-11
Date: 	Mon, 17 Sep 2012 19:53:10 -0400
From: 	Black, David <david.black@emc.com>
To: 	glenzorn@gmail.com <glenzorn@gmail.com>, lionel.morand@orange.com 
<lionel.morand@orange.com>, gen-art@ietf.org <gen-art@ietf.org>
CC: 	dime-chairs@tools.ietf.org <dime-chairs@tools.ietf.org>, 
draft-ietf-dime-rfc4005bis@tools.ietf.org 
<draft-ietf-dime-rfc4005bis@tools.ietf.org>, Black, David 
<david.black@emc.com>, ietf@ietf.org <ietf@ietf.org>, dime@ietf.org 
<dime@ietf.org>, Benoit Claise <bclaise@cisco.com>



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.
2) Detailed string format for a string that is processed by a protocol	
	participant, e.g., the Callback-ID AVP (4.4.3).
3) Restriction of the string to ASCII-only, e.g., as already stated
	for the Framed-Route AVP (4.4.10.5.3).
4) Specification that the string is for display to human users only,
	e.g., as already stated for the Reply-Message AVP (4.2.9).
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.

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.

This should also be noted in the Security Considerations section.

[2] In the message formats in Section 3, QoS-Filter-Rule is inconsistently
capitalized.  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.

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?

   -- 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)?
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, as it's cited exactly once:

263	   PAP (Password Authentication Protocol)
264	      A deprecated PPP authentication process, but often used for
265	      backward compatibility [RFC1334].


Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------