Subject: [AAA-WG]: REMINDER: AAA WG Last Call on NASREQ-10

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Dec 2002 13:58:07 -0800 (PST)

This is a reminder that AAA WG Last Call is ongoing on
draft-ietf-aaa-diameter-nasreq-10.txt, which is being considered for
advancement as an IETF Proposed Standard. The draft is available at:

http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-10.txt

So far, we have not had a single comment on this draft -- which only 4
people indicated they had read at IETF 55. Note that the ability of AAA
WG to take on new work items is in part constrained by our ability to
finish old ones. So even if NASREQ is not your main interest, please
put some time aside to read it and send in your comments during the
upcoming Holidays.

AAA WG last call on NASREQ-10 will run until December 28, 2002. Please
send comments to the authors or [email-masked], using the Issues
submission template found at:

http://www.drizzle.com/~aboba/AAA/issues.html

In particular, it is requested that commenters not only identify problems
in the draft, but send text to fix the identified issues.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 13 Dec 2002 13:41:13 +0200

Here's a few comments:

- Title and abstract contain abbreviations. Consider
   changing this to avoid complaints from the RFC editor.
   How valid is "NASREQ" for the name of a protocol anyway?
   How about "Diameter Application for Network Access Servers"?
   (But this could affect base too, but perhaps it can be
   done in authors 48 hours.)

   Expand AAA in abstract.

- " ... satisfies NAS-related requirements defined in RFC 2989 [AAACRIT]."
   => " ... satisfies typical requirements for in the network access
   domain" and then you can refer to the requirements in the intro.

- "Given that it is expected that initial deployments of the Diameter
    protocol will include legacy systems. This application was ..." =>
   "Initial deployments of the Diameter protocol are expected include
    legacy systems. Therefore, this application was..."

- Contents indentation could be prettier, e.g not change when
   the section numbers go from 9 to 10.

- Consider including only top 2..3 levels in the contents
   list and making a separate List of AVP Definitions page
   to follow the contents page, with each AVP definition section
   listed in alphabetical order.

- Shorten the title of 6.4 to "AVPs that can be Translated"
   and 6.3 to "Prohibited Attributes".

- In abstract, "re-using the RADIUS attribute space"... I
   wonder if we reuse the SPACE or the ATTRIBUTES. It seems
   to me that its the latter, we have a new Diameter space
   for new attributes. THe reader might be confused to think
   the radius avp space limitations apply here too.

- Reference [EAP] appears no longer necessary.

- Why are RADIUS references informative? We speak
   of RADIUS attrs in the document and the reference
   is still not normative?!

- Reference identities might be better aligned, e.g.
   RADTunnels, and RADTUNNLACCT.

- Is the 8.3 reference to IANAConsid correct? IANA holds
   the namespace but isn't it the Diameter base that defines
   the namespace?

- Add to section 9 the following: "The security considerations
   of the Diameter protocol itself have been discussed in
   [DiamBASE].".

- Section 8 should contain some statement about the IANA
   allocation policies of RADIUS attr enumerated values.
   Reference some document(s)?

- In section 5 at the text "Authentication or Authorization
   transaction or the end of a Session.": Isn't the last "or"
   really an and? I mean you want ACRs on both, right?

- Also, ar the ACRs sent on both auth and authz events if
   they are done separately? Perhaps you should break this
   text into a set of individual normative requirements.
   Please make sure you say how many messages are sent if
   authz and auth both happen in the same AA request.

- In 4.3.11 there's a missing space (?) in
   "proprietarySingleLink/MultiLink"

- There's a concatenation procedure mentioned in 6.4. Could
   we say explicitly for which attributes it can be
   done?

- Missing newline after the title of section 7.

- Having the 7.1 table start on a new page is useless
   because it will not fit a single page anyway.

- In 8.2. "This specification assigns the values 363-366 and
   400-414 from the". I'm not sure I understand the 400-414
   because only 400, 403, and 409-412 can be found from the
   nasreq document.

Jari