IETF Logo Mail Archive

Re: [DNSOP] [v6ops] Fwd: New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

神明達哉 <jinmei@wide.ad.jp> Mon, 24 September 2018 18:14 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C7E130EFC; Mon, 24 Sep 2018 11:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.525
X-Spam-Level:
X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.146, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 t1foYxnNdZp1; Mon, 24 Sep 2018 11:14:54 -0700 (PDT)
Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (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 5D319130E8B; Mon, 24 Sep 2018 11:14:54 -0700 (PDT)
Received: by mail-lj1-f176.google.com with SMTP id p89-v6so2987595ljb.3; Mon, 24 Sep 2018 11:14:54 -0700 (PDT)
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=zcBO+tJLImc2WFepZpZXh0rAtt82jAxITUJ5SesR+i0=; b=TYOmjzuHAd29zhfO+Tyyd255OU6l3p/Fc1GNvhhVa4g3jPOxDPe9oXA4CjFKaXDSgl XsNDrbbMAlLtgXF06w04xh8wyFXfbVfMceZFv4p4zyTpqCAvS5WblAVA2OEpp6aQ2E5e 8deQDFBSH08NRghigmNSt4N3RoAHbigKUBc8+oRH6W52fw7vXzGKXMWSUX0hrK6r9n+8 mtwkLVcYKkzp1azwIENDx6bfCNFLhgUNgFOXtOlnuFdM0hsL7mCNLMmj7EbTeHmOvpRH Rl2Jx6U5c/V/jw8L2wb3R8nElWWuuAZR8dq/rvIkoXFGPO8WfFOTgo+Z+cpMNn2NolT2 UX1A==
X-Gm-Message-State: ABuFfojQKXwC5svtG9rrefChMJBxNWixN4ybqDfjvAy3bJTMJbsciU3d FrCoriyigeKHubsWeFiSccJVW7IXyza8u1LlazM=
X-Google-Smtp-Source: ACcGV60SuG4ZQvk4o8XRT4yR8w9zLzN6y6yuQFkfhcttl48qORNCaws1BVvqg0v1NWiKYuNXv6oHfFTEGOLzDknzVKY=
X-Received: by 2002:a2e:9dc7:: with SMTP id x7-v6mr18949ljj.142.1537812891742; Mon, 24 Sep 2018 11:14:51 -0700 (PDT)
MIME-Version: 1.0
References: <153751052820.5339.10049404273601155140.idtracker@ietfa.amsl.com> <CAAObRXLWpXVbPyyxuzJH8osi+R1rdV8N8=Woqvq3UR9nk8kDaA@mail.gmail.com>
In-Reply-To: <CAAObRXLWpXVbPyyxuzJH8osi+R1rdV8N8=Woqvq3UR9nk8kDaA@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Mon, 24 Sep 2018 11:14:40 -0700
Message-ID: <CAJE_bqd4jjeZy9Stp-v6O0VOyvEJiE9vW1BLuy-wzqPGvDagoQ@mail.gmail.com>
To: Song Linjian <songlinjian@gmail.com>
Cc: v6ops@ietf.org, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000024b6290576a1f7e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EEBLKyjathTNtIhZYjVl_uQq7Vc>
Subject: Re: [DNSOP] [v6ops] Fwd: New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Sep 2018 18:14:56 -0000

At Fri, 21 Sep 2018 14:31:50 +0800,
Davey Song <songlinjian@gmail.com> wrote:

> I just submited a new draft intending to provide better connectivity from
> network side function . Comments are welcome.

Some quick observations:

- I don't see why the intended status is Standards Track.  It seems to
  be a document about an operational practice rather than a new
  protocol feature.

- In general, I wouldn't be excited about placing such complicated
  functionality in the network rather than end hosts.  Sometimes it
  may be justified as a least evil option, but the current description
  of the draft didn't fully convince me

- I suspect the discussion on breaking DNSSEC is way too hand-waving.
  In my general understanding it's generally not accepted at dnsop to
  justify breaking DNSSEC just by saying "it's okay as validation at
  end hosts is not typical".  Especially if it really intends to be
  published as Standards Track I suspect some more detailed discussion
  with a stronger justification will be needed.

--
JINMEI, Tatuya

v2.23.0 | Report a Bug | By Email