[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: [dhcwg] Fwd: RADEXT WG Last Call on "RADIUS Delegated IPv6 PrefixAttribute"
Begin forwarded message:
From: "Bernie Volz \(volz\)" <volz@cisco.com>
Date: March 20, 2006 6:25:11 PM CST
To: "John Schnizlein \(jschnizl\)" <jschnizl@cisco.com>
Subject: RE: [dhcwg] Fwd: RADEXT WG Last Call on "RADIUS Delegated IPv6 PrefixAttribute"
John:
Feel free to forward this to the WG!
I just read the draft and it looks fine to me; I support its
publication.
There are a few minor nits though:
** 1. Why "another" in the second sentence of the introduction:
---
1. Introduction
The Delegated-IPv6-Prefix indicates an IPv6 prefix to be delegated to
the user. For example, the prefix in a Delegated-IPv6-Prefix
attribute can be delegated to another node through DHCP Prefix
Delegation [2].
---
Would not just "... can be delegated to a node through DHCP ..." be
sufficient?
----
** 2. And further in the introduction:
---
The Delegated-IPv6-Prefix MAY be used in Access-Accept packets, and
can appear multiple times. It MAY be used in an Access-Request
packet as a hint by the NAS to the server that it would prefer these
prefix(es), but the server is not required to honor the hint.
---
The table in section 3 lists Accounting Request (0+). So, it MAY also
appear there.
----
** 3. The use of bytes should be replaced by octets? This was a comment
I got on a recent round of documents from the IESG, so they'll raise it
and best to fix before it goes on to them? See section 3.
---
Note that the prefix field is only required to be long enough to hold
the prefix bits and can be shorter than 16 bytes. Any bits in the
prefix field that are not part of the prefix MUST be zero.
---
** 4. You might add "the":
In this table 0 indicates that an attribute MUST NOT be present in
the packet and 0+ means that zero or more instances of this attribute
MAY be present in the packet.
^^^
Best regards,
- Bernie