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.
...