Re: [dhcwg] FW: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt

[Ted Lemon <[e-mail]>]

> Thanks for your comments of the quick review and text revisions after '/s'. I will update these revision in the '-01'.
Great, thanks!

> Section 4 of this draft raised the discussion on the option design. 
> Design-1 employs the sub-option; Design-2 employs the same method
> of RFC4014. Hope we could figure out the best design in the WG. The
> code space of DHCPv6 option is 2-octect, so we don't need to worry
> about the exhaustion of DHCPv6 option codes. The draft could request
> the option code for Option_Pool_Name, Option_Address_Prefix_Auth
> from the same space for Option_Authorization, such as
> OPTION_IAPREFIX(26) in OPTION_IA_PD(25), or OPTION_IAADDR(5)
> in OPTION_IA_NA(3). That means the concept of sub-option is not
> necessary in this draft, the 'contained option' might be the substitute for the text.

It seems that Bernie is arguing in favor of Design-2.   I don't have a strong opinion on this, other than that it seems as if you want to emphasize the specific options you mention in your draft, and so from that perspective it makes sense to simply send them as DHCP options.

However, I do not understand why you need to encapsulate these options.   Doesn't this just waste space in the DHCP packet for no purpose?

> quoted as '8-bit binary data'. UTF-8 is used in 'text' data type of RADIUS.

Okay, so if the RADIUS option is binary data, you should say "8-bit binary data" in the DHCP option definition.   If it's text, you should say "UTF-8 encoded text" in the DHCP option definition.   But you can't just say "text."

> I am ok with re-define 2 options here. RADIUS employs one data type for 
>'IPv6 address' and the other data type for 'IPv6 prefix' per the section
> 2.1 of RFC6158 (or the section 2.1, 2.3 of RFC3162).

Great, thanks!

> As mentioned in section 6 of this draft, the relay includes Option_Authorization
> per the RADIUS attrbutes in the message of 'Access-Accept'. The server will respond
> (or do address allocation) per the indication in Option_Authorization, as the same
> behavior when the server locates on the NAS (BRAS). In fact, the idea in this draft
> expects the sever only do the address/prefix allocation. Hope it is clarified.

I may have expressed myself poorly.   I am not asking you to clarify how it works.   I am saying that I don't agree that it should work that way, and I would like the working group to consider the architecture you are proposing, and the two other architectures I proposed in my comments, and make a decision as to which architecture to use.   I understand that you are advocating the particular architecture you describe in the draft, and that's fine, but the working group should consider this question.