Subject: Re: [dhcwg] draft-lourdelet-radext-rfc3162bis-02

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Mon, 2 Mar 2009 16:27:31 +0100

Hello Alfred,

Since you wrote you comments, we changed course a bit and decided not to revise RFC3162
 but to come with as separate document that I should publish in the coming days.

Regards

benoit

-----Original Message-----
From: Alfred HÎnes [mailto:[email-masked]] 
Sent: Thursday, December 04, 2008 7:16 PM
To: [email-masked]; Benoit Lourdelet (blourdel)
Cc: [email-masked]
Subject: draft-lourdelet-radext-rfc3162bis-02

Hello,
after studying the Internet-Draft authored/edited by you,
          draft-lourdelet-radext-rfc3162bis-02,
I'd like to submit a few comments, mostly addressing textual
flaws and missed general requirements I observed in that memo.

The items below are presented in textual order.
To give more context, sometimes I quote larger blocks of text
literally and show the replacement proposed using the shorthand
notation:

   <original draft text>
---
   <modified text>

I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.  I also try to accomodate published
RFC-Ed policy on style and punctuation etc. in my proposals.

(1)  General

The front matter of the draft says, as the draft file name
already promisies:  Obsoletes: 3162 (if approved),
and this memo is intended for Standards Track.

Current IESG policy requires in this case to precisely
document the reason for the update and the major differences
from the original specification.

This can be done by a separate numbered section or an Appendix
giving the details, of by adding a summary paragraph or subsection
to the Introduction.

BL>> we decided not to  obsolete RFc3162.

At a minimum,

a) Informative Reference to RFC 3192 should be added.

b) The Abstract should be amended by the statement:
     This memo [or: document|RFC|... ] obsoletes RFC 3192.

c) A similar phrase should be added to the introduction.
   For instance, I envision adding to the first paragraph
   of Section 2 something like :

      This functionality originally has been specified in RFC 3162.
      This document adds ... [ / changes ...  etc.]
      and thereby obsoletes RFC 3192.

   or:

      This document obsoletes RFC 3192, the original specification
      of this functionality.  Important changes since RFC 3192 are
      listed in Section x [ / Appendix A ] .

(2)  Section 2, 3rd paragraph

In the last line, I suggest inserting the definite article in front
of "allocation" :

|  does not require the allocation of an IPv6 prefix.
                   ^^^^^

(3)  Section 3 -- repeated wording

The draft stereotypously repeats standard requirements on protocol
operation.  I suggest to coalesce that matter in the (currently empty)
Section 3:

 3.  Attributes
|
|  As usual, the fields shown in the diagrams below are transmitted from
|  left to right.

... and to drop the corresponding sentences from Sections 3.1 - 3.8.

BL>> Agreed.

(4)  Section 3.1

(4a) 1st paragraph

I suggest to clarify and improve the language, as follows:

                                              [...].  The NAS-IPv6-
|  Address Attribute is only used in Access-Request packets.  The NAS-
|  IPv6-Address and/or NAS-IP-Address MAY be present in an Access-
   Request packet; however, if neither attribute is present then NAS-
   Identifier MUST be present.
---
                                              [...].  The NAS-IPv6-
|  Address Attribute is only used in Access-Request packets.  Both the
                       vvvv               vvvvvvvvvvv         ^^^^^^
|  NAS-IPv6-Address and the NAS-IP-Address attribute MAY be present in an
   Access-Request packet; however, if neither attribute is present then
   NAS-Identifier MUST be present.

(4b)  diagram

The diagrams in Sections 3.1, 3.2, 3.3, 3.7, and 3.8 are overly
complicated.  Simplifying these should help to improve the clarity
 and enhance the readability of the memo.

For instance, in Section 3.1, the following diagram is depicted:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    |           Address
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 Address (cont)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 Address (cont)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 Address (cont)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Address (cont)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

That's rather arduous to comprise -- much more text than necessary.
Additionally, the surprising and unnecessary use of 'open' boxes
apparently has hidden the inconsistency in the field with that
becomes apparent on comparison with the leading ruler lines.

The first stage of simplfication could be:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              -+
      |                                                               |
      +-                                                             -+
      |                            Address                            |
      +-                                                             -+
      |                                                               |
      +-                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

However, adapting the diagram style from many IPv6 related protocol
specifications, an even more compact and concise representation can
be gained.  Two variants are found in RFCs:

either ...

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                            Address                            |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

or ...

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |     Type      |     Length    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                            Address                            |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

To allow easy cut & paste, below I will depict similar figures as the
last one for the subsequent affected diagrams in the draft.

BL>> agreed

(5)  Section 3.2, diagram

As in (4b), I suggest to simplify the diagram ...

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |             Interface-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Interface-Id (cont)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Interface-Id (cont)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

... to show:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |     Type      |     Length    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                         Interface-Id                          +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

BL>> agreed

(6)  Section 3.3

(6a)  diagram

As above; but additionally, I suggest to make use of a visual
indication of the variable length of the 'Prefix' field;
for instance, change ...

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |  Reserved     | Prefix-Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   Prefix
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   Prefix
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   Prefix
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   Prefix                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

... to:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |   Reserved    | Prefix-Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                        Prefix (variable)                      .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(6b)  explanations for 'Length' and 'Prefix-Lenght'

The typical use case according to RFC 4291 will be IPv6 addresses
with 64-bit Interface Identifier -- cf. Section 3.2 !!!
Therefore, IMO an indication of the typical case might give useful
hints to the reader.
For instance:

   Length

|     At least 4 and no larger than 20.
---
   Length

|     At least 4 and no larger than 20; typically 12 or less.

... and ...

   Prefix-Length

      The length of the prefix, in bits; at least 0 and no more than
|     128.
---
   Prefix-Length

      The length of the prefix, in bits; at least 0 and no more than
|     128; typically 64 or less.

BL>agreed

(7)  Section 3.4

(7a)  diagram

The proposals from (4b) above can be re-uesed here literally.

(7b)  explanation for 'Address'

I propose to use the standard IPv6 address representation style
specified in RFC 4291 in place of the hexadecimal 'C'-style notation,
i.e., to replace       0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
by:                 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF

This improves the conformance to adopted standards and the readability.

(8)  Section 3.5, last paragraph

The draft says:

                                         [...].  Prefixes and addresses
|     are formatted as described in [RFC2373].  For example, "2001:db8:
      0:106::/64 2001:db8:106:a00:20ff:fe99:a998 1".  Whenever the
      gateway address is the IPv6 unspecified address the IP address of
|     the user SHOULD be used as the gateway address.  The unspecified
|     address can be expressed in any of the acceptable formats
|     described in [RFC2373].  For example, "2001:db8:0:106::/64 :: 1".

First of all, RFC 2373 has been obsoleted twofold over the years,
first by RFC 3513, and then by RFC 4291.  There should be no reason to
remain stuck with RFC 2373, so please update the ref. --> RFC 4291 !

BL>agreed

The last three sentences are confusing.
IPv6 addresses are not assigned to *users*, but to *interfaces*.
So what's "the IP address of the user" ??
There's only one unspecified address, and per RFC 4291, it is denoted
by "::".  Since the preceding sentences already spcify the use of
the standard representation in the IPv6 Address Architecture RFC,
the second-to-last sentence should simply be omitted.

Taking altogether, I suggest to replace the above text fragment by:

                                         [...].  Prefixes and addresses
|     are formatted as described in [RFC4291].  For example, "2001:db8:
                                        ^^^^
      0:106::/64 2001:db8:106:a00:20ff:fe99:a998 1".  Whenever the
      gateway address is the IPv6 unspecified address the IP address of
|     the NAS interface to the user SHOULD be used as the gateway
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|     address; for example, "2001:db8:0:106::/64 :: 1".
             ^^^

(9)  Section 3.6, 1st paragraph

The term "assignment" in DHCP cntext is typically used to denote the
assignment of (single) *addresses* to DHCP clients.  Overloading this
term for other purposes might cause confusion, in particular if the
target process is not an automatic process; in this case a more
specific and expressive term should be used.
For instance, *address pools* are typically *configured*, and not
derived algorithmically, whereas the selection of a specific prefix
from such pool will be performed automagically -- i.e. it will indeed
be *assigned*.

Therefore, I suggest to change:
                                          vvvvvvvv
|  This Attribute contains the name of an assigned pool that SHOULD be
   used to assign an IPv6 prefix for the user.  If a NAS does not
   support multiple prefix pools, the NAS MUST ignore this Attribute.
---                                      vvvvvvvvvv
|  This Attribute contains the name of a configured pool that SHOULD be
   used to assign an IPv6 prefix for the user.  If a NAS does not
   support multiple prefix pools, the NAS MUST ignore this Attribute.

(10)  Section 3.7

(10a)  diagram

The proposals from (4b) above can be re-uesed here literally.

(10b)  new code point to be assigned by IANA

I strongly suggest to use distinguished identifiers for code points
to be assigned by IANA (e.g., "TBA1", "TBA2"), as called for in
RFC 5226.  Using arbitrary identifiers like 'x' (Section 3.7) and
'y' (Section 3.8) increases the risk of "clerical malfunction".

Thus, I suggest to change:

   Type

|     x for IPv6-Address
---   ^^
   Type

|     TBA1  for IPv6-Address
      ^^^^^^

(11)  Section 3.8

BL>> agreed

(11a)  1st paragraph

The draft says:

   The IPv6-DNS-Server-Address Attribute contains the IPv6 address of a
   DNS server.  This attribute MAY be included multiple times in both
|  Access-Accept and Accounting-Request packets.
                ^^^^^^^^^^^^^^^^^^^^^^^
Neither does the draft elaborate on that matter nor do I have an idea
what this option shall be good for in Accounting-Request packets.
I suspect that this is a copy & paste error and that the tagged words
should be deleted.
Otherwise, a precise explanation of the semantics is needed.

(11b)  diagram

The proposals from (4b) above can be re-uesed here literally.

(11c)  new code point to be assigned by IANA

As in (10b) above, I suggest to change:

   Type

|     y for IPv6-DNS-Server-Address
---   ^^
   Type

|     TBA2  for IPv6-DNS-Server-Address
      ^^^^^^^

(12)  Section 3.9

According to the proposals in (10b) and (11c) above, please
replace in the table:

                 x    -->    TBA1
                 y    -->    TBA2

(13)  Section 5

BL>>agreed

The draft says:

   This document requires the assignment of two new RADIUS attribute
   numbers for the following attributes:

   o  IPv6-Address

   o  IPv6-DNS-Server-Address

   IANA should allocate these numbers from the standard RADIUS
   Attributes space using the "IETF Review" policy [RFC5226].

Again, for clarity and to help avoid clerical mistakes,
I suggest to include the placeholders for the codepoints
to be assigned by IANA in this text.

The last paragraph is a bit confusing.  It looks like this memo
would install a new registry, which indeed would have made it
necessary to establish a specific IANA assignment policy in
accordance with RFC 5226.
However, in this case the policy is savely registered with IANA,
and IANA will follow it.  What really is needed here, in application
of the recommendations in BCP 26, is a precise identification of the
registry to be used for the codepoint assignment -- that might be
trivially clear for DHC WG participants, but don't extrapolate such
expectation to IANA !
Also, the text should precisely use the terms appearing in the
existing registry to ensure the proper sub-registry being applied.

Taking altogether, I suggest to replace the above section content by:

|  This document requires the assignment of two new RADIUS Attribute
|  Types in the "Radius Types" registry (currently located at
|  <http://www.iana.org/assignments/radius-types>)
|  for the following attributes:
|
|  Value   Description                  Reference
|  -----   --------------------------   ---------
|
|   TBA1   IPv6-Address                 [RFCthis]
|
|   TBA2   IPv6-DNS-Server-Address      [RFCthis]

BL>> agreed
(14)  Section 6

(14a)
With the above changes, BCP 26 is not referenced in a normative way
any more, and hence [RFC5226] should be demoted to Informative.
(Move it to the end of Section 6.2.)

BL>> agreed

(14b)
As indicated in item (8) above, the outdated ref. to RFC 2373
needs to be updated to point to RFC 4291.#

BL>>agreed

Best regards,
  Alfred HÎnes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+