Issue: Review of draft-chowdhury-mip6-radius-02

[<Pasi.Eronen@nokia.com>]

Review of draft-chowdhury-mip6-radius-02
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: August 23, 2006
Reference: 
Document: draft-chowdhury-mip6-radius-02
Comment type: T/E
Priority: 1
Section: various
Rationale/Explanation of issue:

1) The document should give all new attributes short names that 
don't contain spaces (e.g. "MIP6-Home-Link-Prefix" or just
"Home-Link-Prefix").

2) Section 5: "The attributes MAY be present in the Access-Accept and
the Accounting-Request." The accounting part is too ambiguous; does
e.g. requesting DNS update really make sense for accounting messages?
At the very least, the document should explicitly say what is 
included in accounting messages and what it means.

3) Section 5.2: This attribute should use the same data type as other
attributes containing FQDNs (i.e., just the FQDN, without the zeroes
in the beginning).

4) Section 5.3: This attribute should use the same data type as
other attributes containing IPv6 prefixes (e.g. Framed-IPv6-Prefix 
in RFC 3162).

5) Section 5.5: This section should describe that the status code
field uses values defined in "draft-ietf-mip6-bootstrapping-split-02";
now it gives the impression that totally number space is created
(but doesn't give any IANA considerations on how to manage it).

6) Section 5.5 first says "response to the request MAY not carry a
FQDN value" but then changes its mind "The data field MUST contain a
FQDN".

7) Section 5.5: This attribute should probably be split to 2..3
separate attributes (e.g. DNS-Update-FQDN and DNS-Update-Result);
this would be better in line with other recent RADIUS documents.

8) Section 5: Suggest rephrasing "All bits set to 0" to "The bits 
MUST be initialized to zero by the sender, and MUST be ignored by 
the receiver."

9) Section 8: According to Section 5, the first four attributes are
sent by the RADIUS server to the NAS, so the first column should be 
"0" instead of "0-1" (alternatively, Section 5 needs to specify what 
these attributes mean in Access-Requests). 

10) Section 8: The table should probably include accounting messages
and CoA-Request as well.

11) For the split scenario, the document should define what to 
put in Service-Type and NAS-Port-Type attributes (and maybe also
Calling-Station-Id and Called-Station-Id).

12) The document talks about doing EAP authentication over RADIUS,
but never mentions RFC 3579? 

13) The document should either point to RFC 2548, or explicitly say
that this document does not contain an interoperable solution for the
split scenario, since it does not specify (either here or by
referencing some other document) how to send the MSK from the RADIUS
server to the HA.

14) The document should probably have at least informative 
reference to RFC 4306.

15) And last (but not least, as everyone who has followed 
RADEXT knows :-): the document does not have a Diameter
considerations section.

Best regards,
Pasi

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>