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

Re: 6rd attribute compromise?

To: Jiangsheng <jiangsheng@huawei.com>
Subject: Re: 6rd attribute compromise?
From: Peter Deacon <peterd@iea-software.com>
Date: Mon, 11 Apr 2011 23:50:33 -0700 (Pacific Daylight Time)
Cc: Alan DeKok <aland@deployingradius.com>, radiusext <radiusext@ops.ietf.org>
In-reply-to: <5D36713D8A4E7348A7E10DF7437A4B9282BA3F@SZXEML504-MBS.china.huawei.com>
References: <5D36713D8A4E7348A7E10DF7437A4B9282BA3F@SZXEML504-MBS.china.huawei.com>
User-agent: Alpine 2.00 (WNT 1167 2008-08-23)

On Tue, 12 Apr 2011, Jiangsheng wrote:

The format design of this 6rd attribute was to be the same with 6rd DHCPv4 Option, please see section 7.1.1 of RFC 5969.

However, if this is not compatible with RADIUS, we would like to acceptany suggestion from RADEXT WG. So, the first question is whether ourcurrent 6rd attr design is NOT acceptable by RADIUS.

If the answer is NO, Peter's suggestion looks good for us except why aReserved byte.

Hi Jiangsheng, just included reserved /w ascii example to be a closermatch to the existing attribute format for prefix (RFC 3162 2.3)


regards,
Peter

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

Follow-Ups:
- Re: 6rd attribute compromise?
  - From: Alan DeKok <aland@deployingradius.com>

References:
- Re: 6rd attribute compromise?
  - From: Jiangsheng <jiangsheng@huawei.com>

Prev by Date: RE: 6rd attribute compromise?
Next by Date: Re: 6rd attribute compromise?
Previous by thread: RE: 6rd attribute compromise?
Next by thread: Re: 6rd attribute compromise?
Index(es):
- Date
- Thread