comments on draft-maglione-radext-ipv6-acct-extensions-01

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 09 March 2010 20:14 UTC

Message-ID: <BLU137-W1CBE20CE168A8C58FD45C93340@phx.gbl>
Content-Type: multipart/alternative; boundary="_58a2a7eb-2536-4948-8f4a-b8b2eac4f905_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org>
Subject: comments on draft-maglione-radext-ipv6-acct-extensions-01
Date: Tue, 09 Mar 2010 12:09:36 -0800
Importance: Normal
MIME-Version: 1.0
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk

Date: Tue, 9 Mar 2010 12:13:45 +0700
From: "Glen Zorn" <gwz@net-zen.net>
Subject: comments on draft-maglione-radext-ipv6-acct-extensions-01
To: <roberta.maglione@telecomitalia.it>,
	<suresh.krishnan@ericsson.com>,	<alan.kavanagh@ericsson.com>,
	<varga.balazs@telekom.hu>,	<jkaippal@huawei.com>

Not sure why this is Standards Track since both RFC 2866 & RFC 2869 are
Informational.

It would be more in-line w/RADIUS tradition to name the Attributes
Acct-IPv6-* rather than IPv6-Acct-*.

References are pointers to objects, not the objects themselves.  Suggest
changing all instances of constructs like "[RFC2866]and [RFC2869] specify"
to "RFC 2866 [RFC2866] and RFC 2869 [RFC2869] specify" or simply rewriting
the sentences so that the use of pointers makes sense, in this case perhaps
to "Existing documents (RFC2866], [RFC2869]) specify".

TYPO: s/the IPv6 in broadband environment/IPv6 in broadband environments/ in
the Introduction.

TYPO: s/new RADIUS attribute have to be defined/new RADIUS attributes have
to be defined/ in the Introduction

The second paragraph of the Introduction says "This document describes
additional RADIUS attributes for collecting IPv6 specific statistics in
RADIUS Accounting messages"; suggest changing to "This document describes
additional RADIUS attributes for transporting IPv6-specific statistics in
RADIUS Accounting messages".

Section 3, second paragraph says:
   Existing RADIUS attributes like Acct-Input-Octets, Acct-Output-
   Octets, Acct-Input-Packets, Acct-Output-Packets, Acct-Input-Gigawords
   and Acct-Output-Gigawords, could be used to collect statistics for
   all traffic(including IPv4, IPv6 and other protocols), while the
   availability of IPv6 specific RADIUS attributes would allow the
   collection of IPv6 statistics.
Suggest changing to:
   Existing RADIUS attributes like Acct-Input-Octets, Acct-Output-
   Octets, Acct-Input-Packets, Acct-Output-Packets, Acct-Input-Gigawords
   and Acct-Output-Gigawords, could be used to collect statistics for
   all traffic (including IPv4, IPv6 and other protocols), while the
   availability of IPv6-specific RADIUS attributes would allow the
   collection of IPv6 statistics.

It's not at all clear to me why the first paragraph of section 4.1 exists.

The second paragraph of Section 4.1 says:
   If the Accounting-Request packet includes a Framed-IPv6-Prefix, that
   attribute MUST contain the IPv6 prefix allocated to the user.  In
   deployment scenarios where DHCPv6 prefix delegation is used, the
   Accounting-Request packet will contain a Delegated-IPv6-Prefix
   attribute that contains the IPv6 prefix delegated to the user.
The first sentence just repeats what RFC 3162 says about the
Framed-IPv6-Prefix Attribute.  This seems unnecessary.  The second sentence
says that "the Accounting-Request packet will contain a
Delegated-IPv6-Prefix attribute" but RFC 4818 doesn't say this.  As one may
have guessed, I would prefer that section 4 be deleted altogether, but if
the authors feel it necessary for it to be included, I suggest modifying it
to at least be accurate and to include references to RFC 3962 and RFC 4818.

In sections 5.*, a blank line should be added before "Length" in the
Attribute summaries.

In Section 7, an allocation policy must be specified; suggest just adding a
reference to RFC 3575.

comments on draft-maglione-radext-ipv6-acct-exten… Bernard Aboba
RE: comments on draft-maglione-radext-ipv6-acct-e… Maglione Roberta