[Dime] Gen-ART review of draft-ietf-dime-rfc4005bis-14

"Black, David" <david.black@emc.com> Tue, 03 December 2013 00:59 UTC

Return-Path: <david.black@emc.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 961201ADFEE; Mon, 2 Dec 2013 16:59:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BIjGFZNeEt-8; Mon, 2 Dec 2013 16:59:14 -0800 (PST)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8F5A31ADFF2; Mon, 2 Dec 2013 16:59:13 -0800 (PST)
Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com []) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB30x7C3007123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Dec 2013 19:59:07 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rB30x7C3007123
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386032348; bh=4jjfq1A0EIkaDjk77dsC6jk5Wt4=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=APNJ0/SjJBtYESpQ2LBQlCNIINsJgiHhvBWZOZ7z9PJ+jdlb1eTkFegfOeX0JUogz Hy3bsEZI7Bf5b95ZrW3Cv3bJBrhnEN4W85ECDwc6jhLZiiYDF1alDQG/eyMFykdow4 W22OxW2Df90dF6HCG/U637XTKKrH8MzLufadj/FU=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rB30x7C3007123
Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com []) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 2 Dec 2013 16:58:50 -0800
Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com []) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB30wn2N028367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 19:58:49 -0500
Received: from mx15a.corp.emc.com ([]) by mxhub35.corp.emc.com ([::1]) with mapi; Mon, 2 Dec 2013 19:58:49 -0500
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>
Date: Mon, 2 Dec 2013 19:58:48 -0500
Thread-Topic: Gen-ART review of draft-ietf-dime-rfc4005bis-14
Thread-Index: Ac7vwtMcr6PoiKsVTtusEDHn3V9Ylw==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026ADFB0E7@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com
X-RSA-Classifications: DLM_1, public
X-Mailman-Approved-At: Tue, 03 Dec 2013 08:49:00 -0800
Cc: "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-dime-rfc4005bis@tools.ietf.org" <draft-ietf-dime-rfc4005bis@tools.ietf.org>, "Black, David" <david.black@emc.com>, "dime@ietf.org" <dime@ietf.org>, "dime-chairs@tools.ietf.org" <dime-chairs@tools.ietf.org>
Subject: [Dime] Gen-ART review of draft-ietf-dime-rfc4005bis-14
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 03 Dec 2013 00:59:16 -0000

Going back to the original Gen-ART review of the -11 version of this draft,
all of the major and minor issues in that review have now been addressed.

The Unicode situation is not as clean and neat as one might like, courtesy
of the need to accommodate deployed implementations ("running code"), but
the new Unicode text in Section 6 should suffice ... confession: I wrote
that text, Glen pasted it into the draft, and I just hope the IESG thinks
the text is reasonable in light of the "running code".

OTOH, idnits found this slightly embarrassing nit:

  == Missing Reference: 'RFC4005' is mentioned on line 2805, but not defined

An RFC Editor Note will suffice to correct that.


> -----Original Message-----
> From: Black, David
> Sent: Monday, September 17, 2012 7:53 PM
> To: glenzorn@gmail.com; lionel.morand@orange.com; gen-art@ietf.org
> Cc: dime-chairs@tools.ietf.org; draft-ietf-dime-rfc4005bis@tools.ietf.org;
> Black, David; ietf@ietf.org; dime@ietf.org; Benoit Claise
> Subject: Gen-ART review of draft-ietf-dime-rfc4005bis-11
> 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) 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
>   == 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
> ----------------------------------------------------