Re: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt

Sorry that we ran out of time at DHC wg today, but I think you got plenty of feedback in Sunset4.

- Bernie (from iPad)

On Aug 1, 2013, at 11:51 AM, "Prashanth Patil (praspati)" <praspati@cisco.com> wrote:

> 
> On 01/08/13 5:04 PM, "Bernie Volz (volz)" <volz@cisco.com> wrote:
> 
>> There were a lot of issues raised at the joint Sunset4/DHC session Wed
>> afternoon. It will be interesting to see what the authors of the draft
>> will do to address these. (That's not to say the other issues should not
>> be raised.)
>> 
>> We will wait to see if the authors continue this work (by addressing
>> issues in a new draft).
> 
> Yes, we plan to work on a revision that makes the draft more generic and
> also possibly address issues raised in sunset4 and on the mailing list.
> 
> -Prashanth
> 
> 
>> 
>> - Bernie (from iPhone)
>> 
>> On Aug 1, 2013, at 11:34 AM, "Mikael Abrahamsson" <swmike@swm.pp.se>
>> wrote:
>> 
>>> On Fri, 7 Jun 2013, Prashanth Patil (praspati) wrote:
>>> 
>>>> Hi all,
>>>> This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6
>>>> Relay
>>>> Agent can dynamically influence priority of DNS servers provided to a
>>>> host, so that a host can use an optimal DNS server for resolution.
>>> 
>>> I feel this proposal have two problems in my opinion:
>>> 
>>> I don't like "flags" that means the server responds differently with
>>> the same field. This means there must be server-side logic to handle the
>>> different cases. I believe other solutions which work with a static
>>> server-side configuration file without "if/then/else"-statements are
>>> preferred.
>>> 
>>> I don't like the chattyness of the proposed solution, where if a client
>>> goes between different states of dualstacked-ness, it needs to talk DHCP
>>> every time.
>>> 
>>> As I see it, it also doesn't address an additional problem, where if
>>> the client has gotten DNS resolvers from both DHCPv4 and DHCPv6, there
>>> currently is no sure way to know what the client will use (I know for a
>>> fact that different android phones from different vendors behave
>>> differently). If we're going to enhance this, it would be beneficial if
>>> this case would also be solved.
>>> 
>>> So I propose a change of the solution where the client would initially
>>> ask the following:
>>> 
>>> What resolver should I use if I am single stacked IPv6.
>>> What resolver should I use if I am dual stacked, and also please tell
>>> me if there is a preference if this resolver is better, same or worse
>>> than any other resolver I might have gotten provisioned any other
>>> dynamic way (DHCPv4 comes off my mind).
>>> 
>>> I am not knowledable about DHCP to know what the best way to actually
>>> implement this, but from an operational point of view, I would really
>>> like to see the above goals be achieved if we're enhancing the DHCPv6
>>> client and host stack behaviour anyway.
>>> 
>>> -- 
>>> Mikael Abrahamsson    email: swmike@swm.pp.se
>>> _______________________________________________
>>> dhcwg mailing list
>>> dhcwg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 