RE: IPv6 Address Option

["MILES DAVID" <David.Miles@alcatel-lucent.com.au>]

Sorry Alan,

I missed that one.

My comments on each point:

>Uplink-IPv6-Address instead of IPv6-Address
	I know the supporting text says "is assigned to the uplink of
the user equipment" but uplink may be confusing (the uplink of what) -
Peer/Subscriber/Host-IPv6-Address perhaps?


>IPv6-Route-Option-Preference
	Per your review - I too agree that a signed integer is somewhat
confusing however this is a direct copy of a DHCP option from RFC 4191:
Prf (Default Router Preference)
            2-bit signed integer.  Indicates whether to prefer this
            router over other default routers.  If the Router Lifetime
            is zero, the preference value MUST be set to (00) by the
            sender and MUST be ignored by the receiver.  If the Reserved
            (10) value is received, the receiver MUST treat the value as
            if it were (00).

  Preference values are encoded as a two-bit signed integer, as
   follows:

      01      High
      00      Medium (default)
      11      Low
      10      Reserved - MUST NOT be sent



> IPv6-Route-Option-Lifetime:
> Auth-IPv6-Prefix-Valid-Lifetime:
> 
>   Defining a tag field *and* a 32-bit integer means that you're
> re-defining the meaning of a tag + integer attribute.  See RFC 2868,
> Section 3.1 for the historical definition.
> 
>   It would seem to be OK to have a 24-bit lifetime.  That would allow
> everyone to use this attribute by simply updating their dictionaries,
> rather than writing new code to handle a new format.

Again these 32-bit values are straight out of RFC 4191 and there is a
requirement to support a value of infinity (0xffffffff). I think you
could get away with a 24-bit value and a special recognition of
infinity, but it is not desirable. If we adopt a fixed tag definition
per Bernard's suggestion, do we still have a problem?

 
> Prefix-Lifetime-Service-Type
Re suggestion to make this a 32-bit integer instead of a 16-bit (2B)
integer. IMO this is not a big change one way or another - I have no
objection to changing this.



Cheers,

-David


-----Original Message-----
From: Alan DeKok [mailto:aland@deployingradius.com] 
Sent: Monday, 28 September 2009 3:13 PM
To: MILES DAVID
Cc: Bernard Aboba; sarikaya@ieee.org; radiusext@ops.ietf.org; David B.
Nelson; roberta.maglione@telecomitalia.it; Mark Townsley
Subject: Re: IPv6 Address Option

MILES DAVID wrote:
> I see no other outstanding issues in the minutes or on the RADEXT
issues
> list for draft-lourdelet-radext-ipv6-access.

  My review isn't listed as an issue, but it may be useful to address
the comments it makes.

  Alan DeKok.

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