[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] draft-lourdelet-radext-rfc3162bis-02
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:ah at tr-sys.de]
Sent: Thursday, December 04, 2008 7:16 PM
To: gwz at net-zen.net; Benoit Lourdelet (blourdel)
Cc: dhcwg at ietf.org
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: ah at TR-Sys.de |
+------------------------+--------------------------------------------+