[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Review of draft-ietf-radext-fixes-00.txt

Review of draft-ietf-radext-fixes-00.txt

Overall, this document looks good.  Some comments:

Section 2.6

  For example, a NAS may offer multi-link services, where a user may
  have multiple simultaneous network connections. In that case, an
  Access-Reject for a later multi-link connection request does not
  necessarily mean that earlier multi-link connections are torn down.
  Similarly, if a NAS offers both dialup and VOIP services, the
  rejection of a VOIP attempt does not mean that the dialup session is
  torn down.

Please spell out VOIP on first usage.

Section 2.7.1

  Since Link-Local addresses are unique only on the local link, if the
  NAS and RADIUS server are not on the same link, then an IPv6 Link-
  Local address [RFC2462] or an IPv4 Link-Local Address [RFC3927]
  cannot be used to uniquely identify the NAS.  A RADIUS server
  receiving a NAS-IPv6-Address or NAS-IP-Address attribute containing a
  Link-Local address SHOULD NOT count such an attribute toward
  satisfying the requirements of [RFC3162] Section 2.1:

I think we also need advice for the RADIUS client.  For example:
"A NAS SHOULD NOT utilize a link-scope address within a NAS-IPv6-Address
or NAS-IP-Address attributes."

2.10.  Responses after retransmissions.

Remove the "." in the section heading.

2.11

  If an ISP desires to support Prefix Delegation at the same time that
  it would like to assign a prefix for the link between the NAS and
  customer premises equipment (CPE). In this situation, the sematics of
  Framed-IPv6-Prefix may be unclear, in that it is difficult to know
  which prefixes are to be used for delegation, and which one is to be
  used for the link.  The intent of the paragraph was to enable the NAS
  to advertise the prefix (such as via a Router Advertisement). If the
  Framed-Routing attribute is used, it is also possible that the prefix
  would be advertised in a routing protocol such as RIPNG.

The first sentence is not complete.  Also, the Delegated-IPv6-Prefix
document now states that Framed-IPv6-Prefix is not used for the purposes
of delegation.  Suggest the following rewording:

  An ISP may desire to support Prefix Delegation at the same time that
  it would like to assign a prefix for the link between the NAS and
  the user.  The intent of the paragraph was to enable the NAS
  to advertise the prefix (such as via a Router Advertisement). If the
  Framed-Routing attribute is used, it is also possible that the prefix
  would be advertised in a routing protocol such as RIPNG.

Also in Section 2.11:

  It appears that the Framed-IPv6-Prefix is used for the link between
  the NAS and CPE only if a /64 prefix is assigned.  When a larger
  prefix is sent, the intent is to provide the entire prefix to the
  CPE, enabling the CPE to assign sub-prefixes if it wishes to do so.

This would seem to conflict with the Delegated-IPv6-Prefix attribute.
Rather, I think that the result is probably for the NAS to send an
RA containing whatever is placed in the Framed-IPv6-Prefix attribute.

Issues still not addressed
----------------------------------

This draft does not address Issues 107 and 146 on the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

Is there an implicit recommendation that these issues be rejected?

IDNITs

I ran IDNITs on the document, and it found some issues:

idnits 1.123

tmp/draft-ietf-radext-fixes-00.txt:


 Checking nits according to http://www.ietf.org/ID-Checklist.html:

   Checking conformance with RFC 3978/3979 boilerplate...

 - In addition to a regular copyright notice, the document also has a
   copyright notice embedded in the text.

 Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
 - The page length should not exceed 58 lines per page, but there was 19
   longer pages, the longest (page 2) being 60 lines
 - It seems as if not all pages are separated by form feeds - found 0 form
   feeds but 20 pages

 Miscellaneous warnings:
 - The copyright year in the IETF Trust Copyright Line does not match the
   current year

 Experimental warnings:
 - Looks like a reference, but probably isn't: '1' on line 465 (?)
'[1] New RADIUS specifications and implementations MUST NOT use Access...' 

 - Looks like a reference, but probably isn't: '2' on line 468 (?)
'[2] Access-Reject MUST mean denial of access to the requested service...' 

 - Looks like a reference, but probably isn't: '3' on line 472 (?)
   '[3]  New deployments of ARAP [RFC2869] SHOULD use Access-Challenge...'

 - Missing Reference: 'Note 2' is mentioned on line 489, but not defined
   '[Note 2] As per RFC 3579, the use of the Password-Retry in EAP...'

 - Unused Reference: 'RFC2867' is defined on line 759, but not referenced
'[RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifi...' 

 - Unused Reference: 'RFC2868' is defined on line 763, but not referenced
'[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M....' 

 - Unused Reference: 'RFC2882' is defined on line 770, but not referenced
'[RFC2882] Mitton, D., "Network Access Servers Requirements: Extended R...' 

 - Unused Reference: 'RFC3575' is defined on line 776, but not referenced
'[RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July...' 


   No nits found.



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