Hi Ole Thank you your review. Please see my inline response.
Thanks Frank -----Original Message----- From: dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] On Behalf Of Ole Tr?an Sent: Thursday, December 06, 2012 7:21 PM To: Sheng Jiang Cc: <dh...@ietf.org> WG; IPv6 List Subject: Re: [dhcwg] Review of draft "Prefix Assignment in DHCPv6" Sheng, > Back in Atlanta, in DHC WG meeting, you said you would review the document. > Could you give the comments? I knew that would come back and haunt me. ;) comments below. also included dhc and 6man >> Draft: Prefix Assignment in DHCPv6 >> Presenter: Sheng Jiang >> URL: http://tools.ietf.org/html/draft-ietf-dhc-host-gen-id-04 >> Slot: 5 min > >> ** Ole will review the document and maybe bring it up on 6man > > Many thanks and best regards, in arbitrary order: - draft-ietf-mif-dhcpv6-route-option also supports prefix discovery using DHCP Frank=>Our draft is about prefix for a host's address formulation. - a host wanting a particular address, why can it not use the "hint" option in a vanilla IA_NA? Frank=>This draft is about prefix which is a part of address. - a prefix on a link must always be coordinated with the onlink router, so I don't understand the argument of why the "L-flag" isn't needed Frank=>we can discuss further. - we shouldn't create new DHCPv6 options with T1/T2 timers. those should be put in a separate option Frank=>Please give me a link so that I could check the "SHOULDN'T" rule. - what do you do if the prefix length is different from /64? Frank=>We can discuss later. in general I think the use case presented is already supported by DHCPv6 address assignment; the client puts the addresses it desire as hints in the IA_NA option in DHCPv6 requests. Frank=>I would like to highlight that we should give an option a clear definition. Wild usage of existing option is a double sword. I think the argument given in the draft for operators wanting a DHCPv6-managed network without ND is flawed. ND is required for router discovery, neighbour discovery etc anyway. and a router on the link must be configured with the onlink prefix regardless. Frank=> ND is not mandatory for network deployments. AFASIK, ND is optional, while DHCPv6 is mandatory for WiMAX network. while we can clearly make this work, I don't think it is justified to create a duplicate mechanism for prefix discovery. section 3.2 RFC1958. Frank=>I don't believe this is "a duplicate mechanism" for "THE SAME THING". cheers, Ole _______________________________________________ dhcwg mailing list dh...@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
