Diameter Network Access Server Application
draft-ietf-aaa-diameter-nasreq-17

A late AUTH48 nit. Checking with WG chairs and making sure
it gets addressed if it is indeed an issue.

Bert
-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
Sent: donderdag 12 augustus 2004 14:03
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Small nits for NASREQ author's 48 hours


Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: August 12, 2004
Document: NASREQ-17
Comment type: Editorial
Priority: 2
Section: 6.4 and 3.2
Rationale/Explanation of issue:

One of the issues left for Diameter EAP was to sync the ABNFs
and AVP occurrence tables with the latest NASREQ version.
When doing this, I noticed two small inconsistencies
(which could be handled in author's 48 hours).

1)

ABNF and AVP occurrence tables say Idle-Timeout AVP is not
allowed in AAR. This was changed between -11 and -12 (issue
404). However, the text in Section 6.4 still says it may be
used as a hint in AAR.

Proposal: Remove the sentence "It MAY be used in an
authentication and/or authorization request (or challenge) as a
hint to the server that an idle timeout is desired, but the
server is not required to honor the hint in the corresponding
response."

2)

AVP occurrence table says AAA can contain 0-1 Multi-Round-
Time-Out AVP, but it's not listed in ABNF.
 
Proposal: Add it to AA-Answer ABNF in Section 3.2.

Best regards,
Pasi

AD (Bert) is checking with IESG.

Revision 16 addresses additional (last minute) mugs found in AAA WG.
The IESG DISCUSS items were all addressed (and cleared) with revision 15.

Changes in rev 16:
---------- Forwarded message ----------
Date: Mon, 19 Jul 2004 18:48:47 -0400
From: David Mitton
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Diameter NASreq draft 17

I've submitted a new version to ietf-drafts

A copy is availible at:

http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-17.txt

Changes are:

18-July-2004
Document Editor: David Mitton

---
Issue # 468

Summary Description: Missing "[Failed AVP]" in AAA ABNF

Document review found several inconsistencies in error reporting AVPs
in the message ABNFs and occurance tables.

a) Inserted in AAA, and ACA ABNF
              * [ Failed-AVP ]

b) Inserted missing  in ACA ABNF
[Error-Message]

c) Removed redundant from RAA ABNF
[Error-Message]
[Error-Reporting-Host]

d) Inserted Error-Message and Failed-AVP in Accounting occurence tables.
Section 10.2.

e) Corrected occurance of Error-Reporting-Host in Non-Framed ACA table
from 0+ to 0-1

Question: Why is Failed-AVP 0+ in Request messages?
(Table 10.1, page 75)
Can a Failed AVP be forwarded in a non-Answer message?

-----

Issue # 466

Description: Missing QoSFilterRule AVP

Inserted proposed text as section 6.9  (old 6.9++)
Assigned AVP code 407

Section renumbering and reference fixups.

Added the new AVP to the ABNF for AAA, ACR
Added the new AVP to table of Section 6.
Added the new AVP to the AVP occurance tables in Section 10.

Changed occurance of NAS-Filter rule to 0+ in ACR

Added DIFFSERV, DIFFSERVAF, and DIFFSERVEF as Informative references

----

Issue # 464

Application-Id usage

Section 1.3, Advertising Application Support,  now says:

Diameter applications conforming to this specification MUST advertise
support by including the value of one (1) in the Auth-Application-Id of
Capabilities-Exchange-Request (CER), AA-Request (AAR) and AA-Answer
(AAA) messages.  All other messages are defined by [Base] and use the
Base application id value.

----

Updated dates,
Realigned tables, page breaks

On hold to fix this issue:
-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: woensdag 16 juni 2004 02:55
To: iesg@ietf.org
Subject: Comment on Diameter NASREQ, EAP, MIPv4 (fwd)


Yoshi Ohba has found an error that exists within all several Diameter
Application drafts -- Diameter NASREQ, EAP and MIPv4.  This concerns the
use of Application-IDs in those documents.

Based on the Application-ID guidelines of RFC 3588, the Diameter NASREQ,
EAP and MIPv4 documents are not permitted to allocate new Application-IDs
because no new mandatory AVPs are defined in those documents.  Re-using
Diameter Base commands will enable Diameter agents (such as
Diameter/RADIUS gateways) to operate across a range of applications with
no code changes.

Diameter EAP & NASREQ use ACR/ACA, RAR/RAA, STR/STA and ASR/ASA commands.
Diameter MIPv4 uses ACR/ACA, STR/STA and ASR/ASA commands.

David Mitton is promising to have a new rev in a week:

-----Original Message-----
From: David Mitton [mailto:david@mitton.com]
Sent: donderdag 25 maart 2004 15:57
To: Wijnen, Bert (Bert); Bernard Aboba; John Loughney (E-mail)
Cc: David Kessens (E-mail)
Subject: Re: Where are we with documents


On 3/22/2004 01:35 PM +0100, Wijnen, Bert (Bert) wrote:
>...
>The nasreq document also got quite a set of comments, so I would expect
>a new revision and then a quick check to see if al WG members then
>have consensus to advance to AD review.
>
>Can you pls inform me about the plan of action or otherwise push the
>document authors to work on their revisions so we can move forward.

Bert, et.al.

        I've done the editorial and technical consistency editing already.
The only time consumer is closing the open issues.

I will push to close within the next week and produce a new draft copy.

Dave.

[Ballot comment]
Nit: LAT is defined, and heavily referred in the definition of attributes, but has no reference in the References. Should be fixed (informative reference).
Nit: [UTF-8] is in the References, but is not referred to. UTF8String is used, however, so it's reasonable to have this as a reference. Doesn't need fixing.
Does not show much thought about working in a multilingual environment, but this seems to be attempting to fit within existing practice rather than starting from scratch, so this is probably reasonable to let pass.

[Ballot comment]
Nit:

In section 7:

by a encapsulation method to a gateway---> by an encapsulation method

In section 7.5

The Tunnel-Server-Endpoint AVP (AVP Code 67) is of UTF8String--> of type UTF8String

In 9.1

If the RADIUS User-Password attribute is present, the password
        must be unencrypted using the link's RADIUS shared secret. And
        forwarded using Diameter security.

This could be read either as (unencrypt and forward encrypted password)
or (unencrypt, then forward unencrypted password).  I'd suggest rephrasing
it so the second sentence reads:  The unencrypted password should then
be forwarded using Diameter security.

IANA Considerations:

This document defines values in the namespaces that have created and
--->have been created and