Re: [Driu] Fwd: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt

Bob Harold <rharolde@umich.edu> Thu, 05 July 2018 19:57 UTC

Return-Path: <rharolde@umich.edu>
X-Original-To: driu@ietfa.amsl.com
Delivered-To: driu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968E8130F6D for <driu@ietfa.amsl.com>; Thu, 5 Jul 2018 12:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZ5qKwH5760A for <driu@ietfa.amsl.com>; Thu, 5 Jul 2018 12:57:32 -0700 (PDT)
Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B091130EA8 for <driu@ietf.org>; Thu, 5 Jul 2018 12:57:32 -0700 (PDT)
Received: by mail-lf0-x243.google.com with SMTP id n96-v6so7940181lfi.1 for <driu@ietf.org>; Thu, 05 Jul 2018 12:57:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UayZ6ULY3Q0aWFyAKp32dsm9EWPZCDhs0q4e7gbCb+M=; b=JHTgtOHo9yBzoQ0KS6qaS8PVm+yXNHtS9zEtqiE1pqB5PHaHW655iPxTho5/gjpWFV vew+SU71bVGcSeMUGY55wz2WybOXpZtsPylGtpduFA/ZUtEsuGa9rZACga1DYrg3hNRW RmKCP8HuoqyzX9KB4zWOMwMBb3sAJlhUaDokMuNe2ayTrkOFjsNBnbobhJGhTCTWuPgs 0oj6AacMGUQbQu+z3w+JDDP7STo6uGpo7bJqqXL83/vvs8wsNmO08r//omwFlV8uHIVh lQvkSuQdNDP4walI1EnTE2F1T1MQLG3pcp5qIGvT9CdnzCTRPZZQWKhnKBFR7FgMSJ2O cdTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UayZ6ULY3Q0aWFyAKp32dsm9EWPZCDhs0q4e7gbCb+M=; b=sXjlucbH8lYOmL1/FSIMsAXbfte2T6Z8QvYb65gOX+pgZ6shszod2Ksxic5w8ag4O+ iSahPtjyzJzFNzNU9Oh1A9Lmxi0M0D8pOSwaGvS4gC/WdB17B/FIbDSqJAsfw8DlRVBd JfPFwxgYN/IWjDCvJuqoxf2MSqDMH+HyV1b9wVBpgktIQkuGbhXdgugyTZfoPapP1PFy /IcrY4aEKbVVuPtI8+db2hx8W1KuPqwAuCR8w20Ck/xKN6VKfM5DbNM2NY3SjceRYD6F jNppH+tlxjMCaZxHBnIHJHopyqdjBk8CK+P3aU4FJe8MTXR23ZHdTxXzC7Lpa19PIXVf PPDw==
X-Gm-Message-State: APt69E18hy8OST7AC5smVL28AnQgOa1pwnpDxiMkasZm2+jviwerupCl XfdDHWdoxQqgsrziTPN9+Ofx/YdV0gi6Qn6YmHaKcw==
X-Google-Smtp-Source: AAOMgpdR1vo33s5srvCxGgs/ZM7zRBLiXwrfjJgLx4+uzGOf4v1oeNW3xNO5ToeNhSsAIGEykcICUQDUHz29cxOR5UM=
X-Received: by 2002:a19:4344:: with SMTP id m4-v6mr5635511lfj.111.1530820650562; Thu, 05 Jul 2018 12:57:30 -0700 (PDT)
MIME-Version: 1.0
References: <153056107621.16040.1439553172883571734.idtracker@ietfa.amsl.com> <8354E402-C699-46FB-AC95-99BA7AAF03A1@bangj.com> <CA+nkc8BKC3SmfhjCcymE=euNbaw7TymBZbyHLsrDGZ5BqcTJiA@mail.gmail.com> <0AF05538-82F2-4F7E-892B-98E211CA596F@bangj.com> <CA+nkc8CpKuzD6oXMr7RDpnM8LrYVnLN8oSh2K+eoetc9UD+kEg@mail.gmail.com> <A1C27C1A-E1B9-4AB5-A72B-E80A4AB26438@bangj.com>
In-Reply-To: <A1C27C1A-E1B9-4AB5-A72B-E80A4AB26438@bangj.com>
From: Bob Harold <rharolde@umich.edu>
Date: Thu, 5 Jul 2018 15:57:19 -0400
Message-ID: <CA+nkc8DFawmPBDD6hGi9xvk389egsaryfwNruLMX94HY7cVG6Q@mail.gmail.com>
To: pusateri@bangj.com
Cc: driu@ietf.org
Content-Type: multipart/alternative; boundary="000000000000178713057045f53d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/4BQsf8di70e4JKzIfgcHG4NhPfQ>
Subject: Re: [Driu] Fwd: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt
X-BeenThere: driu@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <driu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/driu>, <mailto:driu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/driu/>
List-Post: <mailto:driu@ietf.org>
List-Help: <mailto:driu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/driu>, <mailto:driu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2018 19:57:36 -0000

On Thu, Jul 5, 2018 at 3:31 PM Tom Pusateri <pusateri@bangj.com> wrote:

>
>
> On Jul 5, 2018, at 2:49 PM, Bob Harold <rharolde@umich.edu> wrote:
>
>
> On Thu, Jul 5, 2018 at 2:02 PM Tom Pusateri <pusateri@bangj.com> wrote:
>
>>
>>
>> On Jul 5, 2018, at 1:39 PM, Bob Harold <rharolde@umich.edu> wrote:
>>
>> I have concern:
>>
>> 3. DHCPv6 Encapsulating Options
>>
>> "There is no order
>> implied by the order of options sent or received. It is up to the
>> receiving client to determine which order to use the DNS server
>> configurations."
>>
>> Let's not wait for some non-standard way to decide the order. Please add
>> 'priority' (and possibly 'weight') fields to the "OPTION_DNS_TLS" now, like
>> in MX and SRV records.
>>
>>
>> Willem has said that from experience with Stubby, that the client should
>> determine the order it uses the discovered DNS servers. The network
>> operator advertising the list doesn’t necessarily have real time data to
>> determine response times, delays, etc. I’m happy to discuss this more. Why
>> should the network operator dictate this?
>>
>> I would think that the network operator, who can set the option per
> subnet, would have a better idea where the subnet is, than a client machine
> that roams from place to place and usually does not know where it is
> located.  If the operator lists more than one server, there is likely to be
> a need to designate primary vs backup in some cases.  If the client knows
> better, it can certainly have its own list, and ignore or append what the
> network recommends.  But the network knows better what will be faster or
> even reachable from a given subnet, in my opinion.  (I run the DHCP servers
> at my location, so I am probably biased.)
>
>
> Since the option is probably only refreshed once per day on average, the
> list is fairly static. Assuming that an on subnet server will respond
> faster than a server several hops away is a bad assumption. It depends on
> many factors and these will change constantly depending on the number of
> clients, the number of TLS connections the server can manage, number of
> switches and congestion at the network level including APs, etc. Since
> these conditions change at the sub-second level, having the client figure
> out which server responds best seems more flexible.
>
> If all the servers in the list should respond, does the network operator
> care which one is used? Once you get past the access point, is there
> typically congestion in the wired network you’re trying to avoid?
>
> I’ll put this on my slides to discuss in Montréal.
>
> Thanks,
> Tom
>
> Thanks for the discussion.  If the client tries them all from time to time
and picks the fastest, that is probably best.  I was assuming that most
clients would be fairly simple-minded and use the first one, and only try
the next if the first failed.  For simple clients, an order might be
helpful.  (Some IOT devices have very limited computing power.)

I would be interested in what others think.  Sorry I cannot attend Montreal.

-- 
Bob Harold