From nobody Tue Aug 1 02:53:08 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF12131F13 for ; Tue, 1 Aug 2017 02:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 MU-9VoSBcZGS for ; Tue, 1 Aug 2017 02:53:04 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02A3131FED for ; Tue, 1 Aug 2017 02:53:03 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1501581176; bh=zq3y541qALurqg6AhVHRYZUCFwWvYAJuf00fXhYEdNw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=S//0WwkklBXC+RDaJVcCaNGZqppL8eeypN4+E9jr7RCfHazc5QHzKEM0sTOqXyibK m4KH38IOI03rbG24pV8m77/4gd9t+/UZ0t0x650sWv+hywLRCDNjGT0inABnthElf+ xLdjbDH7sltzsjVck9rQRjy/bNFyVDIpfRtXqd6RdVfPsJbPN7IQzjAkwc1pF+Sm8O w2RMjfP20qJ7omifP2Ad3ykspWQFMn4IoBDuSl75sekeg1vbYJnDGkuQ+SwiHUE7wp sQEOuQT9aApLqqdIDbTNgo0bAu/rEaIzT/shVZyI0jBt/CWu1jrmoj7deGMJHxZzzN utpXY0LHc4HlA== To: "Walter H." , Ted Lemon Cc: homenet@ietf.org In-Reply-To: References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> Date: Tue, 01 Aug 2017 11:52:49 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87tw1r398u.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 09:53:06 -0000 >> you couldn't use the fact that you can publish in a name in it >> to do the ACME authentication. > > there SHOULD NOT be the ACME authentication or any neccessarity of any > other authentication, as these domain names need not be unique ... > > in case you use 'teddynet.home.arpa.' and I use this domain name, too; > we wouldn't have the same x509 SSL certificate, because each of us uses > its own private key ... > > why not just define the org. that hosts the ARPA TLD (IANA?), as the CA > for these domains and the root certificate as built in token to the common > browsers and/or operating systems? > there it should only be neccessary to upload the certificate request, > gicwn the '.home.arpa.' domain name, and an email address where the > certificate is sent to; > the certificate will be a wild card certificate for this .home.arpa. > domain .. > > I would want this to be added as additional section to this Draft/RFC; If you're going through all this trouble of having a central API that will hand out certificates, wouldn't it be possible to make that same authority hand out pseudo-random unique subdomains (of some suitable domain; not necessarily .home.arpa)? Then you are only an NS record from solving the globally visible naming problem... :) -Toke From nobody Tue Aug 1 03:41:23 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA13F13209F for ; Tue, 1 Aug 2017 03:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mathemainzel.info 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 kyvR76J6sAvd for ; Tue, 1 Aug 2017 03:41:18 -0700 (PDT) Received: from mx28lb.world4you.com (mx28lb.world4you.com [81.19.149.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81F8132CF1 for ; Tue, 1 Aug 2017 03:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mathemainzel.info; s=dkim11; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=MrSGSNs/Hx+z6oFGhP/NIamkf+6QqwbFeqT4CeXD2+c=; b=FvK0h2VRc+arTv25lQ0NF53tJ7W12l21zAjBs/yGfewkQnnDizh8jsu/1FMkj0FSq9g72TVlTb3weFDLlb9QV0opa4DCi/kIYf0B+/wycQEXDnk0qPNJr7HrcZzcCPH3aufD8NolOmd4NjN6GSJNV+2KE0tq3QPK8+UjLVM4xEU=; Received: from [90.146.55.206] (helo=home.mail) by mx28lb.world4you.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dcUbz-0002I4-10; Tue, 01 Aug 2017 12:41:15 +0200 Message-ID: <3a5145c7355a9dcdd0b737e46f3aa897.1501584074@squirrel.mail> In-Reply-To: <87tw1r398u.fsf@toke.dk> References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <87tw1r398u.fsf@toke.dk> Date: Tue, 1 Aug 2017 12:41:14 +0200 From: "Walter H." To: =?utf-8?B?IlRva2UgSMO4aWxhbmQtSsO4cmdlbnNlbiI=?= Cc: "Ted Lemon" , homenet@ietf.org User-Agent: Mozilla/5.0 (UNIX; U; Cray X-MP/48; en-US; rv:2.70) Gecko/20110929 Communicator/7.20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 90.146.55.206 X-SA-Exim-Mail-From: walter.h@mathemainzel.info X-SA-Exim-Scanned: No (on mx28lb.world4you.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 10:41:22 -0000 On Tue, August 1, 2017 11:52, Toke Høiland-Jørgensen wrote: >>> you couldn't use the fact that you can publish in a name in it >>> to do the ACME authentication. >> >> there SHOULD NOT be the ACME authentication or any neccessarity of any >> other authentication, as these domain names need not be unique ... >> >> in case you use 'teddynet.home.arpa.' and I use this domain name, too; >> we wouldn't have the same x509 SSL certificate, because each of us uses >> its own private key ... >> >> why not just define the org. that hosts the ARPA TLD (IANA?), as the CA >> for these domains and the root certificate as built in token to the >> common >> browsers and/or operating systems? >> there it should only be neccessary to upload the certificate request, >> gicwn the '.home.arpa.' domain name, and an email address where the >> certificate is sent to; >> the certificate will be a wild card certificate for this .home.arpa. >> domain .. >> >> I would want this to be added as additional section to this Draft/RFC; > > If you're going through all this trouble of having a central API that > will hand out certificates, this need not neccessarily be a central API, just a sort of rules, to make the existing CAs hand out the certificate without the need of any authentication ... > wouldn't it be possible to make that same > authority hand out pseudo-random unique subdomains (of some suitable > domain; not necessarily .home.arpa)? are you talking about a TLD e.g. ".home" which is as the other TLDs like .com or .net or even .at with the difference, that the authoritatativ DNS servers of such a domain needn't be accessible from internet ...; and this registration could hand out the certificates, too; > Then you are only an NS record from > solving the globally visible naming problem... :) with the thought above these aren't globally visible and there is no need to; but the risk that a misconfiguration tells the folks the LAN structure ... From nobody Tue Aug 1 06:22:27 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C58013215F for ; Tue, 1 Aug 2017 06:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 8ZXYOt80uGFe for ; Tue, 1 Aug 2017 06:22:22 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 CE574127868 for ; Tue, 1 Aug 2017 06:22:21 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id z18so8721862qka.4 for ; Tue, 01 Aug 2017 06:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=y7y3GCwLQz1vcM68bneLCVlosWIiel1ZGVhGIkWXS2Y=; b=tusse1opjg8Kp7+pheugBjHmARsAu4igWc1vkFiAOdZ8DfHKx/CBc2lXx9IKF/gUYH NXm7BnsCZXvanzzzzn+dl+dr5bNX2XDnOCi2+aEGajWrifYnzEUlwEOBmeXLwLv64s+I /pSy32X/vAOOTYf0DkuZ9v1tprdf0iMUBEnBNYRtHF+QRANhBpGtkmXlzwkpUMTrydyB 1T2z1Yo9sMrICBycWcho6piRQ7gh2KzZteY8hOJY9XV6vJqollE+BmFK7VEMI4WXSxLV Optwx9nN5h1jVoQZbl2LcncayCRvaUnT5dVzPCmBuNWm9w78zKSfM3z0uyNSk1NO78kQ ybTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=y7y3GCwLQz1vcM68bneLCVlosWIiel1ZGVhGIkWXS2Y=; b=IqEb3Qg7sBt/IL39mCYjDwJ+gy984iy5bxNTw7ThgW1Iu1lGPNv3yTie0t9vMTUa9c B72pHqGXimBmJzzvx8AhrDMt3NwiI2LLosKp5ithASpBadJ75vJbZJH4XolRpsI7tBLO xh8dgykSmhR9cWziYjP47AXlaem8iyZ8Y5NyEvQHWVFTEUdSHOhl5SRMDwG6Z3mhhHQi Opp+4qZO4OCZucQueJak1vLR1OKCW5lKaPD/oCUG3yhMhmUduIdCNljjyselic7Hu1kd g7ljmYwuHJND8XzNia5aNqc/cEgdbgOtf78QMY69VwQNHMC7tbT6zAACrSUfMIXEhfef EYuA== X-Gm-Message-State: AIVw110FpVNokuHH80oQUhUfSVC17wCxaezeqCMqELj0oIsYarGq1nKx W7N/l9lBlZ8/w/ZQfB/Dmg== X-Received: by 10.55.78.23 with SMTP id c23mr24012461qkb.323.1501593740977; Tue, 01 Aug 2017 06:22:20 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id q9sm22244476qki.73.2017.08.01.06.22.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 06:22:20 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C52B549F-6ADE-4254-93D5-62269924B33B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon X-Priority: 3 (Normal) In-Reply-To: Date: Tue, 1 Aug 2017 09:22:19 -0400 Cc: homenet@ietf.org Message-Id: <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> To: "Walter H." X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 13:22:24 -0000 --Apple-Mail=_C52B549F-6ADE-4254-93D5-62269924B33B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 1, 2017, at 2:01 AM, Walter H. = wrote: > there SHOULD NOT be the ACME authentication or any neccessarity of any > other authentication, as these domain names need not be unique ... In order for a PKI solution to work, it has to be possible for any given = cert to apply to a unique name, the ownership of which can be defended = somehow. The CABF has spoken unequivocally on this topic: https://www.digicert.com/internal-names.htm = The point of having PKI in the homenet is so that we have secure = connections between browsers and servers, and so that users aren't = trained to click through certificate warnings just to get things = working. Any solution to this problem has to meet those two = requirements. And to achieve the second requirement, the CABF is going = to want it to be the case that the cert identifies a specific endpoint = for communication. When I say "I don't know how to do that," this is what I'm talking = about. Actually, I do know how to do it: get a public delegation. --Apple-Mail=_C52B549F-6ADE-4254-93D5-62269924B33B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 1, 2017, at 2:01 AM, Walter H. <walter.h@mathemainzel.info> wrote:
there SHOULD = NOT be the ACME authentication or any neccessarity of any
other authentication, as these domain names need not be = unique ...

In order for a PKI solution to work, it has to be = possible for any given cert to apply to a unique name, the ownership of = which can be defended somehow.   The CABF has spoken unequivocally = on this topic:


The point of having PKI in the homenet is so that = we have secure connections between browsers and servers, and so that = users aren't trained to click through certificate warnings just to get = things working.   Any solution to this problem has = to meet those two requirements.   And to achieve the second = requirement, the CABF is going to want it to be the case that the cert = identifies a specific endpoint for communication.

When I say "I don't know how to do that," this is = what I'm talking about.   Actually, I do know how to do it: get a = public delegation.

= --Apple-Mail=_C52B549F-6ADE-4254-93D5-62269924B33B-- From nobody Tue Aug 1 06:23:10 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C888C127868 for ; Tue, 1 Aug 2017 06:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 7mg-uw69IpNT for ; Tue, 1 Aug 2017 06:23:07 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 2548F132160 for ; Tue, 1 Aug 2017 06:23:07 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id v29so8767707qtv.3 for ; Tue, 01 Aug 2017 06:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=y9Zg0alL6uZlJxQwHBb27jz7twofYFeXAlk7NJg0J5M=; b=PZVKUHjygFWXkr1Vo5Yu1zob3wTo5+2BsXfh8PQ7gM4edGcBPp1Yv5ogBsb0c1cyEU CeKpgqpMKGuv/1QveOKP1bsK+8ixIyzqBbH2dXNAJGSmAd2LfS5p5LyNLq+t1l7wfdOG /uPyNMxVXfz0VCbS1ll9z0B0lbvYXogKGg92h5ie/kOroQIoIXjinldRRf8DixtCQSyD y1AOjQVLZsQcFR1PIQ2Ek5i9IWct2dYU2ClRAw7c0BnuTGFdd8Q/ilHZLuvRKdbVLego 55aPw/A68dyxhXOhnBenI83SsQrSOQgMM4WvKhnQ1+lqRG9u5xsObipGuIzMUjfnEjKi rfFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=y9Zg0alL6uZlJxQwHBb27jz7twofYFeXAlk7NJg0J5M=; b=CeWsLi7aMl3rg+MYFdJxK/9RekjTbj63LOe5p61AJz04gbeDd9+lhVfahBc2kH+K9H nZ2EANLgHIQYHwHldYDDUSbqA3gG78GP0RMgcsT01d/fo4gzUUZjR5nQZP7X5ZUHt0gx 3Kc1sAOM8xnPhMGG08JifQ7ra7J3cWvQTaPfprnESQRX8yIUqgHrDxbNH0im0fNQCeWC v+6rrHF8xorK4igoKXqMLer2VR6KLULvX0AfdcnbIYIrC1S7qNpeDC6inanrS1fl3U1f 4CZlEiLtfOyDy5d4/0dLrgy9mS6SM3dWjAnTatE4TfBFhLRVfVNomtZKyVHDWiJiSrT/ A0ug== X-Gm-Message-State: AIVw111MM4tGVtyB2QxIeRLX+yy9xxEdombm7UmggRVyV+QXY9B9oUro YUCsS7LYNJIJtWJyewIpcw== X-Received: by 10.237.39.68 with SMTP id n62mr1603000qtd.218.1501593786258; Tue, 01 Aug 2017 06:23:06 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id q9sm22244476qki.73.2017.08.01.06.23.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 06:23:05 -0700 (PDT) From: Ted Lemon Message-Id: <042D3498-2947-4D68-A6D8-9F105E0252BF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_01EBEB25-8DE9-48BD-BD68-28440DA83876" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 1 Aug 2017 09:23:05 -0400 In-Reply-To: <87tw1r398u.fsf@toke.dk> Cc: "Walter H." , homenet@ietf.org To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <87tw1r398u.fsf@toke.dk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 13:23:09 -0000 --Apple-Mail=_01EBEB25-8DE9-48BD-BD68-28440DA83876 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 1, 2017, at 5:52 AM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: > If you're going through all this trouble of having a central API that > will hand out certificates, wouldn't it be possible to make that same > authority hand out pseudo-random unique subdomains (of some suitable > domain; not necessarily .home.arpa)? Then you are only an NS record = from > solving the globally visible naming problem... :) That's what section 4 of the old homenet naming architecture document = described. = https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-00#sec= tion-4 = --Apple-Mail=_01EBEB25-8DE9-48BD-BD68-28440DA83876 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 1, 2017, at 5:52 AM, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> = wrote:
If you're going = through all this trouble of having a central API that
will hand out certificates, wouldn't it be = possible to make that same
authority hand out = pseudo-random unique subdomains (of some suitable
domain; not necessarily .home.arpa)? Then you = are only an NS record from
solving the = globally visible naming problem... :)

That's what section 4 of the old homenet = naming architecture document described.

https://tools.ietf.org/html/draft-lemon-homenet-naming-architec= ture-00#section-4


= --Apple-Mail=_01EBEB25-8DE9-48BD-BD68-28440DA83876-- From nobody Tue Aug 1 07:48:54 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33A4132192 for ; Tue, 1 Aug 2017 07:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham 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 WjY4RF9PYNMh for ; Tue, 1 Aug 2017 07:48:51 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94FB9132191 for ; Tue, 1 Aug 2017 07:48:50 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v71EjLRb025516; Tue, 1 Aug 2017 10:48:44 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2c2u4f9k52-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Aug 2017 10:48:43 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v71Emg20019055; Tue, 1 Aug 2017 10:48:43 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v71EmVXD018667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Aug 2017 10:48:37 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi134.aldc.att.com (RSA Interceptor); Tue, 1 Aug 2017 14:48:24 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0319.002; Tue, 1 Aug 2017 10:48:24 -0400 From: "STARK, BARBARA H" To: Ted Lemon , "Walter H." CC: "homenet@ietf.org" Thread-Topic: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt Thread-Index: AQHTB92otx6a7dev+E6jYWNi3zasW6JuhxyAgAADOgCAAMBPAIAAexSA///KIVA= Date: Tue, 1 Aug 2017 14:48:23 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> In-Reply-To: <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.219.44] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-01_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708010241 Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 14:48:53 -0000 > In order for a PKI solution to work, it has to be possible for any given = cert to apply to a unique name, the ownership of which can be defended some= how. =A0 The CABF has spoken unequivocally on this topic: > https://www.digicert.com/internal-names.htm > The point of having PKI in the homenet is so that we have secure connecti= ons between browsers and servers, and so that users aren't trained to click= through certificate warnings just to get things working. =A0 Any solution = to this problem has to meet those two requirements. =A0 And to achieve the = second requirement, the CABF is going to want it to be the case that the ce= rt identifies a specific endpoint for communication. > When I say "I don't know how to do that," this is what I'm talking about.= =A0 Actually, I do know how to do it: get a public delegation. The CABF is about "publicly trusted certificates". There is no need or appl= icability of "publicly trusted certificates" in the context of a home netwo= rk. No certificate authority in the world is capable of certifying that a d= evice inside a specific home network actually belongs there. The only entit= y capable of identifying devices that belong in the home network is the hom= e (network) owner. This isn't about public trust. It's about private trust. In reading Stephen's email about what he did wrt certificates, what stood o= ut to me were: (1) The primary goal was to stop the annoying browser warnings. [note that= neither HNCP nor Babel would be expected to check against CAs stored in br= owsers, so they would not be subjected to this annoyance; but the annoyance= is something to prevent when considering the broader "naming architecture"= ] (2) Stephen (the home network owner) was the assigner of trust. He was the= root certificate authority. We had discussed (back in Chicago) that a first step should be to figure ou= t first what our goals were wrt "security". From the perspective of the end= user, here is my starter list of considerations: 1. End users would like to know that device software / firmware has no Troj= ans and is "good". This is not a good fit for X.509 certificates or PKI. Th= is would be something for some logo-based certification program (like a UL,= Good Housekeeping, IPv6 Ready, etc. stamp). I think this is outside the (c= urrent) scope of homenet and there are other orgs working on this sort of t= hing. In any case, it has nothing to do with encryption and X.509 certifica= tes. 2. End users are the absolute (root) authority as to what does and doesn't = belong on the home network. No one else. Even in the case of "unmanaged" ho= me networks. Verisign and others are incapable of telling me whether or not= a device belongs on my home network. 3. End users want it to be very easy to add devices/services to the home ne= twork.=20 4. End users want it to be very easy to remove devices/services. 5. End users want to know when devices on the home network are misbehaving,= and they want to easily identify such devices. 6. End users don't want annoying "untrusted" warnings for devices and servi= ces inside the home network that they have decided to add to it. Does this seem like a reasonable list? Are there items y'all disagree with?= Others to add? Thanks, Barbara From nobody Tue Aug 1 08:04:26 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513881321A1 for ; Tue, 1 Aug 2017 08:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 rCuImt1ugczo for ; Tue, 1 Aug 2017 08:04:22 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 8DE11132197 for ; Tue, 1 Aug 2017 08:04:22 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id x191so10604029qka.5 for ; Tue, 01 Aug 2017 08:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=P1B6OIe48J/3JWuH0PStGgxGsJYYF+qfDy2zQh9AeHk=; b=IP2aTOUkDAaX/hcYBLCu3LdimucP3IX+Atu7gjJXkDEzxfWMWgTJGJ4XdsdQz4ngc3 zDgtcKNDWM7WWmJmg5PuQbUzTPWt4XgkhKO/flcXfartW9FjCKs2QgumAU3aATBmPkGv YkPPayD6XsZ6deVTzV24RPYafiFE/2LdZfzXf45SS6piktZ2NBHi1n0K4Zvm6QV2e4UR TInGWYh1MenH9068DnW+O03JpqU3KF1YGl9mDv9P1FkIuJbKdZQHtZGF/EKPFkIEZ66t pQbs0Y7642jrEAlDgKMJHdUj2AXPApLmRTCu8ohUACqap7nYmHzs4OZksbme2A6h1DKm qvww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=P1B6OIe48J/3JWuH0PStGgxGsJYYF+qfDy2zQh9AeHk=; b=FE2c8807SVZNeNOWT9+H3zCazvRxD97tuKmkuyqO4cizuZcEI+jTbFlQMKeGuGkIis KYGYGI0JyAMm6g4HoowbB4vfSBbgj0GMSx4yS+a0U//u2ecVUSkM236YjRgJhj0Tdl7M 4ezxPC7cAdKkrTWcjJY8thcMELjDu2X28iLbAPNTB6pYKnRDBVuervgm8w0qluVrDvgK alW6LLsOalhHLKwWOIfegy8+yNcd5keJXS0/+xkxALbgsLQFfAYAnR/UF7isz9qb1CK8 WuajmMtAQs2G7Nbk+H8Ak5HBD9+MIR4DW0abXgf7jzMMhfAXXlxzjed5PZhMiailPTEZ fLVA== X-Gm-Message-State: AIVw112ZyzISHuL9F5G9N1P/jxkdBiHlm/+0/5kOhDFJ9U2M/kukIKgf LPBctkmuyfBis4Kj X-Received: by 10.233.232.149 with SMTP id a143mr27682226qkg.339.1501599861517; Tue, 01 Aug 2017 08:04:21 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id r49sm23365526qte.34.2017.08.01.08.04.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 08:04:20 -0700 (PDT) From: Ted Lemon Message-Id: <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A7DBD6C0-C7C8-4A7B-B76C-8BAFB8A4E09F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 1 Aug 2017 11:04:19 -0400 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: "Walter H." , "homenet@ietf.org" To: "STARK, BARBARA H" References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 15:04:25 -0000 --Apple-Mail=_A7DBD6C0-C7C8-4A7B-B76C-8BAFB8A4E09F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 1, 2017, at 10:48 AM, STARK, BARBARA H wrote: > The CABF is about "publicly trusted certificates". There is no need or = applicability of "publicly trusted certificates" in the context of a = home network. No certificate authority in the world is capable of = certifying that a device inside a specific home network actually belongs = there. The only entity capable of identifying devices that belong in the = home network is the home (network) owner. This isn't about public trust. = It's about private trust. This distinction is meaningless, unfortunately, because it's browsers = that we need to trust the network, and we absolutely do not want to = install a network-specific trust anchor in every end-user browser. = Even if that were possible, it would be a gaping attack surface. > In reading Stephen's email about what he did wrt certificates, what = stood out to me were: > (1) The primary goal was to stop the annoying browser warnings. [note = that neither HNCP nor Babel would be expected to check against CAs = stored in browsers, so they would not be subjected to this annoyance; = but the annoyance is something to prevent when considering the broader = "naming architecture"] (1) this isn't an issue for HNCP or babel. It's an issue for browsers. (2) the issue with browser warnings isn't that they are annoying. It's = that if we train users to click through them when managing the homenet, = we are also training them to click through them at other times. This = creates an attack surface in the user that we'd rather not create. > (2) Stephen (the home network owner) was the assigner of trust. He was = the root certificate authority. This doesn't work because there is no grammar for ascribing different = meanings to different trust anchors in browsers, as far as I know. = Attempts have been made, but it's ultimately binary: the end user = doesn't perceive the difference. Without such a grammar, we don't have = a way to make Stephen the assigner of trust for his network without = making him a potential assigner of trust for all networks for any device = that considers him an assigner of trust. > 1. End users would like to know that device software / firmware has no = Trojans and is "good". This is not a good fit for X.509 certificates or = PKI. This would be something for some logo-based certification program = (like a UL, Good Housekeeping, IPv6 Ready, etc. stamp). I think this is = outside the (current) scope of homenet and there are other orgs working = on this sort of thing. In any case, it has nothing to do with encryption = and X.509 certificates. I think that people are talking about code signing elsewhere in the = IETF; I would say that that is where this particular problem would need = to be addressed. I think there's work here relating to TEEP, but also = to just regular code signing. > 2. End users are the absolute (root) authority as to what does and = doesn't belong on the home network. No one else. Even in the case of = "unmanaged" home networks. Verisign and others are incapable of telling = me whether or not a device belongs on my home network. Sure. > 3. End users want it to be very easy to add devices/services to the = home network.=20 Sure. > 4. End users want it to be very easy to remove devices/services. Sure. > 5. End users want to know when devices on the home network are = misbehaving, and they want to easily identify such devices. Yes. > 6. End users don't want annoying "untrusted" warnings for devices and = services inside the home network that they have decided to add to it. Yes, but s/annoying/attack-surface-generating/ > Does this seem like a reasonable list? Are there items y'all disagree = with? Others to add? I think this is a good start. What might become interesting are the implications of this list: what it = would take to actually satisfy these requirements. :) --Apple-Mail=_A7DBD6C0-C7C8-4A7B-B76C-8BAFB8A4E09F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 1, 2017, at 10:48 AM, STARK, BARBARA H <bs7652@att.com> = wrote:
The CABF is about = "publicly trusted certificates". There is no need or applicability of = "publicly trusted certificates" in the context of a home network. No = certificate authority in the world is capable of certifying that a = device inside a specific home network actually belongs there. The only = entity capable of identifying devices that belong in the home network is = the home (network) owner. This isn't about public trust. It's about = private trust.

This distinction is meaningless, unfortunately, because = it's browsers that we need to trust the network, and we absolutely do = not want to install a network-specific trust anchor in every end-user = browser.   Even if that were possible, it would be a gaping attack = surface.

In reading Stephen's email about what he = did wrt certificates, what stood out to me were:
(1) The primary goal was to stop the annoying = browser warnings. [note that neither HNCP nor Babel would be expected to = check against CAs stored in browsers, so they would not be subjected to = this annoyance; but the annoyance is something to prevent when = considering the broader "naming architecture"]

(1) this isn't = an issue for HNCP or babel.   It's an issue for = browsers.
(2) the issue with browser warnings isn't that they = are annoying.   It's that if we train users to click through them = when managing the homenet, we are also training them to click through = them at other times.   This creates an attack surface in the user = that we'd rather not create.

(2) Stephen (the home network owner) was the = assigner of trust. He was the root certificate authority.

This doesn't = work because there is no grammar for ascribing different meanings to = different trust anchors in browsers, as far as I know.   Attempts = have been made, but it's ultimately binary: the end user doesn't = perceive the difference.   Without such a grammar, we don't have a = way to make Stephen the assigner of trust for his network without making = him a potential assigner of trust for all networks for any device that = considers him an assigner of trust.

1. End users would like to know that = device software / firmware has no Trojans and is "good". This is not a = good fit for X.509 certificates or PKI. This would be something for some = logo-based certification program (like a UL, Good Housekeeping, IPv6 = Ready, etc. stamp). I think this is outside the (current) scope of = homenet and there are other orgs working on this sort of thing. In any = case, it has nothing to do with encryption and X.509 = certificates.

I think that people are talking about code signing = elsewhere in the IETF; I would say that that is where this particular = problem would need to be addressed.   I think there's work here = relating to TEEP, but also to just regular code signing.

2. End users are = the absolute (root) authority as to what does and doesn't belong on the = home network. No one else. Even in the case of "unmanaged" home = networks. Verisign and others are incapable of telling me whether or not = a device belongs on my home network.

Sure.

3. End users want it to be very easy to = add devices/services to the home network. 

Sure.

4. End users want it to be very easy to = remove devices/services.

Sure.

5. End users want to know when devices on = the home network are misbehaving, and they want to easily identify such = devices.

Yes.

6. End users don't want annoying = "untrusted" warnings for devices and services inside the home network = that they have decided to add to it.

Yes, but = s/annoying/attack-surface-generating/

Does this seem like a reasonable list? = Are there items y'all disagree with? Others to = add?

I = think this is a good start.

What might become interesting are the implications of this = list: what it would take to actually satisfy these requirements.   = :)

= --Apple-Mail=_A7DBD6C0-C7C8-4A7B-B76C-8BAFB8A4E09F-- From nobody Tue Aug 1 08:38:27 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A58512EA95 for ; Tue, 1 Aug 2017 08:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 5PR5IDPKMHRA for ; Tue, 1 Aug 2017 08:38:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36C4131DB6 for ; Tue, 1 Aug 2017 08:38:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DE08F2009E; Tue, 1 Aug 2017 11:40:10 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 838DF8076D; Tue, 1 Aug 2017 11:38:22 -0400 (EDT) From: Michael Richardson To: Ted Lemon cc: homenet@ietf.org In-Reply-To: References: <3725.1501514462@obiwan.sandelman.ca> <52E1C5A0-FC0E-46A5-9016-AA95FB3DC1CB@fugue.com> <3184.1501522914@obiwan.sandelman.ca> <5A407EA3-AC8B-44A7-8EC2-8242480027FE@fugue.com> <27345.1501546823@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [homenet] Ted's security talk at IETF99: DNCP Security X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 15:38:26 -0000 --=-=-= Content-Type: text/plain Ted Lemon wrote: mcr> Christian's comments in DNSSD (which I also watched today) is right though: mcr> for many applications in *discovery* is important you probably don't want mcr> certs, because they reveal too much, and the relationship is too mcr> ephermeral. mcr> The link between Dave's Laptop and Dave's Cool Printer is probably mcr> longer. > Indeed, but we don't want Dave's Laptop going around asking for Dave's Cool > Printer when Dave's Laptop is not on the home network where Dave's Cool > Printer lives. You agree that it's a different problem right? The common part is that one might have a similar set of external (physical) signals. Should Dave bring his printer to the IETF network, and they happen to discovery each other via privacy-enhanced dnssd magic (cf: Arthur Clark's definition of magic), then it would be good that they can prove that it's really them. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmAoG4ACgkQgItw+93Q 3WUslgf/S/sr6xDS+V+sROfaI6PbruR6O4T4jOBuU79WgPp+ZPUkGrFgkdAWG8jE 1o43f1mZ2Rxn4pbWoXJJNMXJs0AQF4gjSw5ZvElNS2Ok/mpSZtgguazsPrDGU83E cweI2g5wNmczoCgzOT2ymoaDCokVyfEyqR/MMvAoaAQZK7uGQCr3RD8PEQq352MK AXl5seOZmrLDFM6aI4coqvC21r6hqTrvUelriKfLtfy3vFAK9Hp5P933n4E/O18+ m3SQsSIOHxW0a4DASorAqaIEruPcUi5mzM5AGOgqM07ARJ2WLnghXhNMse0DrYjQ fcFO3ZDyfvg1RskVAijbJlguFz4oTA== =7OlW -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 1 08:56:39 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A314312EC1D for ; Tue, 1 Aug 2017 08:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 pTiM1tH0kVho for ; Tue, 1 Aug 2017 08:56:36 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 28A4412EACC for ; Tue, 1 Aug 2017 08:56:36 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id d145so11665320qkc.2 for ; Tue, 01 Aug 2017 08:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ooUxhAQDR7aIHsMB4B4oCW8stj8X/ofunJnbC6841ZQ=; b=GgIcw6OWzq9PMLiFmGSBsD/YOHzlSPlMsd1Cb8aRsyCrXGXmsiNiZTbrOmt5Dcgw+Z VUC6dWep6m0BeYZHa1VIpLTC4UGXAPDZBf8763WRLChyAtYUtEiM1o7xUS58bC5XaNNL 3FJSJ1Z3Y12idVJreG8dXYgLl9XDqIPBZo0hLjIvS3j16Mmzdh23HIz9Zsn7xn5F6T6I cqOUOaIr4XW9m3+x/jyErqQJojD3SJFrQPwRfPMIY1hDHWyjJfa7R5BJW0B64miEgr4t m5WKmTGxCQHMhJ4ok1PDADovQhVM8Q3zr9l234iU3vpZViLoajn+tMJUgP0dnoD8Wkqd E5tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ooUxhAQDR7aIHsMB4B4oCW8stj8X/ofunJnbC6841ZQ=; b=OqGiFF72Sgd5gZ7Tn7z9yODRD4gcTBNZqn0B0NqYP6XVJiiAXZ0lLAaGICoP1b9kCu frJLQ636I8R8CPgaRqSNG5L/5fUdTslxWMZJwR7hVEkKKs/ZvapjlWUCG4yYi4RyKKZM d7W66IY5N6t7XNfcGj+4H0Og/mk6IbWtvza66GrGrqeW0vyZjzHpRaYhG6Ff1GnicJKJ VTgD7yJL/cJzCeJHFyYNQ30PhykNP48bkGS5mhStmvXI1TM/Q4vfHddpW4s/NDXl6y1Y mH8QDLio9Rh4KXR3gd+X4nP315I49AYZ2MNHLQFOB8uFvHgJGwpPca2yGhwjk2ALIWBK pAFQ== X-Gm-Message-State: AIVw113/IlvignZatB/DogLG6YEijc2JiW2Sr/m1sfkxmAGtJKfptMis WP06f1OKihjE/7TJ4Gc2kw== X-Received: by 10.55.27.145 with SMTP id m17mr27521800qkh.298.1501602995258; Tue, 01 Aug 2017 08:56:35 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id i18sm25652410qkh.18.2017.08.01.08.56.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 08:56:34 -0700 (PDT) From: Ted Lemon Message-Id: <6C42A593-3EBC-49BE-9A9F-0CF701FF68BF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7C9A0505-1F4F-4B90-A56B-11AFF3356FF8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 1 Aug 2017 11:56:33 -0400 In-Reply-To: <10182.1501601902@obiwan.sandelman.ca> Cc: homenet@ietf.org To: Michael Richardson References: <3725.1501514462@obiwan.sandelman.ca> <52E1C5A0-FC0E-46A5-9016-AA95FB3DC1CB@fugue.com> <3184.1501522914@obiwan.sandelman.ca> <5A407EA3-AC8B-44A7-8EC2-8242480027FE@fugue.com> <27345.1501546823@obiwan.sandelman.ca> <10182.1501601902@obiwan.sandelman.ca> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Ted's security talk at IETF99: DNCP Security X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 15:56:38 -0000 --Apple-Mail=_7C9A0505-1F4F-4B90-A56B-11AFF3356FF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 1, 2017, at 11:38 AM, Michael Richardson = wrote: > You agree that it's a different problem right? >=20 > The common part is that one might have a similar set of external = (physical) signals. >=20 > Should Dave bring his printer to the IETF network, and they happen to > discovery each other via privacy-enhanced dnssd magic (cf: Arthur = Clark's > definition of magic), then it would be good that they can prove that = it's really them. To be honest, I probably missed the point you were making=E2=80=94I just = went back and reviewed this exchange, and I don't actually understand = what the distinction is that you are making between ephemeral and = long-lived relationships. --Apple-Mail=_7C9A0505-1F4F-4B90-A56B-11AFF3356FF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 1, 2017, at 11:38 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
You agree that it's a different problem = right?

The common part is = that one might have a similar set of external (physical) = signals.

Should Dave bring = his printer to the IETF network, and they happen to
discovery each other via privacy-enhanced dnssd = magic (cf: Arthur Clark's
definition of = magic), then it would be good that they can prove that it's really = them.

To = be honest, I probably missed the point you were making=E2=80=94I just = went back and reviewed this exchange, and I don't actually understand = what the distinction is that you are making between ephemeral and = long-lived relationships.

= --Apple-Mail=_7C9A0505-1F4F-4B90-A56B-11AFF3356FF8-- From nobody Tue Aug 1 10:33:21 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C70E1321BD for ; Tue, 1 Aug 2017 10:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 nu0sRIfoSKeU for ; Tue, 1 Aug 2017 10:33:17 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA4B1321CD for ; Tue, 1 Aug 2017 10:33:16 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id v71HXEWs001192; Tue, 1 Aug 2017 19:33:14 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 076EEEB343; Tue, 1 Aug 2017 19:33:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id TcsyKbf8xtyk; Tue, 1 Aug 2017 19:33:13 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1FA47EB342; Tue, 1 Aug 2017 19:33:09 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1dcb2b-0002o6-Dq; Tue, 01 Aug 2017 19:33:09 +0200 Date: Tue, 01 Aug 2017 19:33:09 +0200 Message-ID: <7ilgn3xkfe.wl-jch@irif.fr> From: Juliusz Chroboczek To: Ted Lemon Cc: "homenet@ietf.org" In-Reply-To: <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 01 Aug 2017 19:33:14 +0200 (CEST) X-Miltered: at korolev with ID 5980BB5A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5980BB5A.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5980BB5A.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 17:33:20 -0000 > (1) this isn't an issue for HNCP or babel. It's an issue for browsers. It's an issue *with* browsers. > (2) the issue with browser warnings isn't that they are annoying. It's that if > we train users to click through them when managing the homenet, we are also > training them to click through them at other times. This creates an attack > surface in the user that we'd rather not create. Agreed. The problem, of course, is not Homenet-specific -- I've got exactly the same problem with my printer, or with Babelweb. The problem, in short, is that HTTP doesn't allow either BTN or TOFU security -- it's either creartext of CA-based (or big red warning). I think that Barbara expressed very clearly why the CA model is simply not adapted to the Homenet. I don't think we should be complicating the Homenet protocol stack in order to work around the limitations of the browser stack. -- Juliusz From nobody Tue Aug 1 11:02:35 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D46812ECB4 for ; Tue, 1 Aug 2017 11:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mathemainzel.info 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 9oDSMrJotsan for ; Tue, 1 Aug 2017 11:02:31 -0700 (PDT) Received: from mx05lb.world4you.com (mx05lb.world4you.com [81.19.149.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AAC41200C5 for ; Tue, 1 Aug 2017 11:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mathemainzel.info; s=dkim11; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=n7BJldlNQO4R4SlJd9l0R/8bNBnOh0IVxSAbJkWVmgI=; b=kS5/e1VY3tGHN7wRvN32CWILxHnEB603A9Gzp8iUQZcgR9hR0Cgt3EbKiMZJ4UF3vGjMoxIB8tVXoUMdhziVMuTqfvrvslE1QOlA8lshFOp+TrvuVUJOiJs3Ubcrt4oKvf4t7yJvgYuE3SepbLLJuixIqKsBzqA9d1NhY1Okhds=; Received: from [90.146.55.206] (helo=home.mail) by mx05lb.world4you.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dcbUz-0003S9-4k; Tue, 01 Aug 2017 20:02:29 +0200 Message-ID: <5980C234.305@mathemainzel.info> Date: Tue, 01 Aug 2017 20:02:28 +0200 From: "Walter H." Organization: Home User-Agent: Mozilla/5.0 (UNIX; U; Cray X-MP/48; en-US; rv:2.70) Gecko/20110929 Communicator/7.20 MIME-Version: 1.0 To: Juliusz Chroboczek CC: Ted Lemon , "homenet@ietf.org" References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> <7ilgn3xkfe.wl-jch@irif.fr> In-Reply-To: <7ilgn3xkfe.wl-jch@irif.fr> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060804080908000807080502" X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 90.146.55.206 X-SA-Exim-Mail-From: Walter.H@mathemainzel.info X-SA-Exim-Scanned: No (on mx05lb.world4you.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 18:02:34 -0000 This is a cryptographically signed message in MIME format. --------------ms060804080908000807080502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01.08.2017 19:33, Juliusz Chroboczek wrote: > I think that Barbara expressed very clearly why the CA model is simply = not > adapted to the Homenet. I don't think we should be complicating the > Homenet protocol stack in order to work around the limitations of the > browser stack. I'm not thinking about the homenet protocol I think of the fact that the '.home.arpa' is the general purpose domain which can be used in home=20 networks just for simple DNS, there is nothing said about the homenet protocol at = all; what is the real problem having stricht rules in this Draft/RFC to get an= SSL certificate that can be used inside such an environment; so that no own PKI is neccessary? by the way, when you look at the x509 certificate chain, that is used by = intel.com you find an intermediate, that this can only be used to sign requets for = domains that Intel own ... why not just having such a intermediate for '.home.arpa.' domains? this intermediate can even be public including its private key ... in a short time there will be no way to go over the warnings in browsers,= these will be errors, where any connection will be blocked. --------------ms060804080908000807080502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKBDCC BOgwggPQoAMCAQICDkgbagkTvYAkyl0i8BTzMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsT F0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQD EwpHbG9iYWxTaWduMB4XDTE2MDYxNTAwMDAwMFoXDTI0MDYxNTAwMDAwMFowXTELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24g UGVyc29uYWxTaWduIDIgQ0EgLSBTSEEyNTYgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALaWaJNl/SwB7GKjDVS/i8ukQ5Gimq+xg/K1bW/Z8OrczxZ71xnjhAOF+cYf cI8fbEnFaRkecJE4NX4CSF05axhEpmqlyHT0XfWEPmMfcUSCCD7tyaf26W4mQSmAyUm6/9l2 oKO7G/Z530so00p7nFHCD2VQoZ+oSp3lRgSNg0/cssg9z5ghCZhMwPGPeqk/NyZlR9hmj0km wsNAvmY9bP86rSlG8BOc4fLrmaeLwtNfUG2iDm/HBpc4L06hjkcCtIMA2KTjukEHYOXdN1ry B8E7p5yXaC6376lINrzpaaiZqkfpx/ZR0vmxLLbFSbWYnlNT2vty83wP+HE+1wP6Z8MCAwEA AaOCAbUwggGxMA4GA1UdDwEB/wQEAwIBBjBqBgNVHSUEYzBhBggrBgEFBQcDAgYIKwYBBQUH AwQGCCsGAQUFBwMJBgorBgEEAYI3FAICBgorBgEEAYI3CgMEBgkrBgEEAYI3FQYGCisGAQQB gjcKAwwGCCsGAQUFBwMHBggrBgEFBQcDETASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQW BBRpcoJiMWeVRIV3kYDEBDZJnXsLYTAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0b vDA+BggrBgEFBQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWdu LmNvbS9yb290cjMwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNv bS9yb290LXIzLmNybDBnBgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEG CSsGAQQBoDIBXzA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9y ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAqJ3NMsx8Z+ILUNelXHCjZuIl7+q0tlMw bocSN1wz4sIoVuOTvUWV81jYFXFM8+SCiRS+/qXMR73rBlSCPua/vvXqiPV5xCgiC4x69g4L 4yquSZoOm8In8my2G1VKAbYZ4WhQdFi8EkUYT67eXhsTMOdVJjSAov4UigSrB4RhUhGiUAC2 cuBy9BFnbhOiC2AI1+gUl0Q7RxXlD3XW+On+R3+a8yExi7J/QSKaDla4EvO/DuCZ31FkItvc gX5++R2o4nxbzwvrqp/q3FZ766S4LCzmBv+uJFl/xUR/PpoVXvpnEl98bFKXMSvavby01ba6 FP8iVJhAuDnB+XULGxwaozCCBRQwggP8oAMCAQICDDf7Me/cd27Vi+FlDzANBgkqhkiG9w0B AQsFADBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UE AxMqR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczMB4XDTE3MDQy NDEwNDQxOFoXDTIwMDQyNDEwNDQxOFowVTELMAkGA1UEBhMCQVQxGzAZBgNVBAMTEldhbHRl ciBIb2VobGh1Ym1lcjEpMCcGCSqGSIb3DQEJARYad2FsdGVyLmhAbWF0aGVtYWluemVsLmlu Zm8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDROn0wc2eBzHcRoKiSnUFz1H4T SN5QEKhssd+B8F0YMDxEzXyvnOeCLAN+8+ui/fyZ0g1A8qgWIGkerNeJJgVes9Xf5EpemE5b zksNPIoVQVB7sBfWezlJ6E12FUNssdLdcQlVqNtFnHtfZV0SD0BS87mW5GL75Ay8XpSkwwTV 6XpIAcKRyd7EFCw+7g2Udp/ZAjPZ4X7oZl8sFFlOClPvWu8LCjbnDcWHpE93QeXnmMx86LQg tACrTy1PDX0yAOeCTan6F3sX0tz5Cp8sWduQiMaKof8yxW/t2V7BJwXhZhiDhax3y/AFREOH NC5dJ2w1sFiwidK7sljogU7/orGHAgMBAAGjggHaMIIB1jAOBgNVHQ8BAf8EBAMCBaAwgZ4G CCsGAQUFBwEBBIGRMIGOME0GCCsGAQUFBzAChkFodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24u Y29tL2NhY2VydC9nc3BlcnNvbmFsc2lnbjJzaGEyZzNvY3NwLmNydDA9BggrBgEFBQcwAYYx aHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL2dzcGVyc29uYWxzaWduMnNoYTJnMzBMBgNV HSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxz aWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NwZXJzb25hbHNpZ24yc2hhMmczLmNybDAlBgNVHREE HjAcgRp3YWx0ZXIuaEBtYXRoZW1haW56ZWwuaW5mbzAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwHQYDVR0OBBYEFOQybe9sZCmROEwJqrOUU1qsTrgqMB8GA1UdIwQYMBaAFGly gmIxZ5VEhXeRgMQENkmdewthMA0GCSqGSIb3DQEBCwUAA4IBAQBY5Zn+1HTT58xtZQgu1IcN UI9t2PC0ps6sELyN3eCBvqYiqk5D8J58hNl9j0hnht5oM0aKVgTL1GNFu6J9DDd3Bk2sNmG6 8uIvo0NsJAFk23lMzKt+YOm3C6+oveuxICFhHeiTxn9z2jLfU+xYLg8UXpSl5U6m0uZcVoLA YYYhLgpaSM8jNYgAv8U2NVK+f8hd4AVEpwyF2edKbZTAdj/iDmjmOm9lkUIzacemNR8DRxiD Eb2XTZa5pcrsPOe1bisJ5wcHoIx+217fm8WJF7Vk2amB9fg8AM3cGU7V7D2Ynbg5tJdV5Et6 ff+sk9Fv1HRaFDqKQVorlDY1P5h1HsoxMYIDYTCCA10CAQEwbTBdMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczAgw3+zHv3Hdu1YvhZQ8wCQYFKw4DAhoFAKCCAckw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwODAxMTgwMjI4 WjAjBgkqhkiG9w0BCQQxFgQU+JCmUShTVrx2IRFuuxi7w409NCgwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB8BgkrBgEEAYI3EAQx bzBtMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYDVQQD EypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0gRzMCDDf7Me/cd27V i+FlDzB+BgsqhkiG9w0BCRACCzFvoG0wXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2Jh bFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBT SEEyNTYgLSBHMwIMN/sx79x3btWL4WUPMA0GCSqGSIb3DQEBAQUABIIBAECtzqgEvIFniZFk dqqUnc/Tnd8nlbC/pDPAPGnu47FV6qbT5J/KFrB+e+u2nbvSjIy+SaQZc9fwJxTvyDtrHpeo h1T0NLre8vt70D4DzoOd4wSy3W9cdJOABjWWnGMlvFhbEMl5ImJA74m3QrCu8M2CpMtbxlP+ Usq48d/Qi/pn4Z2n7gl+cqmNS+Ncm/z4vlLhLSPvTEbe8hZAcYfjfM+DKCeP6O6w2PNjaoSx M3TaYdm8CtB0TGxYG+MNGiIlnhzQhn+X9ioxNfQ743b3N9p+oMm5bM+uaHzyoSa7WrgOOVCD md8iEXsUmVzFNsWLyDRcco7r/Z53Wbqy450yzlYAAAAAAAA= --------------ms060804080908000807080502-- From nobody Tue Aug 1 11:02:49 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274EB1321DB for ; Tue, 1 Aug 2017 11:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 gIFplHnFEKPZ for ; Tue, 1 Aug 2017 11:02:46 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 37DEE1321CD for ; Tue, 1 Aug 2017 11:02:46 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id z18so13672340qka.4 for ; Tue, 01 Aug 2017 11:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=03fVkNVqjQ9Z7xSz1ID2jrq7M3u2dhdHYDr+upvj+Jw=; b=E0/KJG85hBVfJs1jnQ7tQ/9Jh97GroqmX10Y4lPHWOHCkwGT1+J3PEn7qM3CUA0nQX vnEzTWRe8tCLVY2uV8Rtyj8jOwh2iNbqHHmAAz5ibrM+4icydXjQO/Yu+edj6xK30oDd yW/Jkp1dzxlmOoYCuaSzvZYlw4LB7H6tafIdZrE1zZHcWyUdFKV3/OtKicTlj2ynDFom 70S65+xcPDWWRhQEn6RtCYwsIOioY+f6bLySQTTrqNHWVwlVjsh61UOvR0jk5gpfTF1O TMI2k7bO5SsxafIEMBQhliWl1Y8dKNvpW7L891Ol8e3+CbbhaMxWmJmj2UDWSrVCcF9/ Idbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=03fVkNVqjQ9Z7xSz1ID2jrq7M3u2dhdHYDr+upvj+Jw=; b=pEcb/DEr4nilcitLLT0cM+P8V7OqoIJa4EJr/kzyQj0W0mhI11OsYTCq9l3mtfTJqZ SgnHixz+cbFx/1+YsDEx54VRrS44ycBBeC1Emgwk3FHSHMD60bq0aTJeh0ZXT3C8M45N BIvD/7fpe3LtxvENa6jZdzd7Gf4cEc0UoulzHWx3DB76ZJFUpSChajk1oTKimDpA2TJ4 Vq4lzF8RnYhjEn+kqXI1hHn7UluGQS1AdtpXF8RZpst+6ZwZSPpi3RON/F+CoFQNNo3M aNsOFcf/CpGoPUGnyVpaTQ+1saXzsr/8r7u0iEJvtm8OAoB9wybvNfhkdacBA/c5Q7r9 +H0g== X-Gm-Message-State: AIVw112CFN3xMpeFb5hO25MWqqGPnMQJYhv7TdEsvKaRsWvpHd4iDWKg AWYYvaOt1iyJhuq5 X-Received: by 10.55.115.132 with SMTP id o126mr25475797qkc.130.1501610565397; Tue, 01 Aug 2017 11:02:45 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 55sm3301219qtm.51.2017.08.01.11.02.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 11:02:44 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CBA4937B-38C9-4872-A681-8C30B1E86168" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 1 Aug 2017 14:02:43 -0400 In-Reply-To: <7ilgn3xkfe.wl-jch@irif.fr> Cc: "homenet@ietf.org" To: Juliusz Chroboczek References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> <7ilgn3xkfe.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 18:02:48 -0000 --Apple-Mail=_CBA4937B-38C9-4872-A681-8C30B1E86168 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 1, 2017, at 1:33 PM, Juliusz Chroboczek wrote: > Agreed. The problem, of course, is not Homenet-specific -- I've got > exactly the same problem with my printer, or with Babelweb. The = problem, > in short, is that HTTP doesn't allow either BTN or TOFU security -- = it's > either creartext of CA-based (or big red warning). Yup. > I think that Barbara expressed very clearly why the CA model is simply = not > adapted to the Homenet. I don't think we should be complicating the > Homenet protocol stack in order to work around the limitations of the > browser stack. Best is the enemy of good enough. Also, you routinely overestimate how = complicated this stuff is. I appreciate that you value simplicity, but = the rule I prefer to follow is: "make it as simple as possible, and no = simpler." The bottom line is that a global delegation+ACME PKI is a knob I can = turn. Fixing browsers is a knob I can't turn, and the browser vendors = have spoken pretty unequivocally on this topic. If you want to tilt at = that windmill, I will gladly lend my voice, but I am not hopeful. --Apple-Mail=_CBA4937B-38C9-4872-A681-8C30B1E86168 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 1, 2017, at 1:33 PM, Juliusz Chroboczek <jch@irif.fr> = wrote:
Agreed.  The = problem, of course, is not Homenet-specific -- I've got
exactly the same problem with my printer, or = with Babelweb.  The problem,
in short, is that = HTTP doesn't allow either BTN or TOFU security -- it's
either creartext of CA-based (or big red = warning).

Yup.

I think that Barbara expressed very = clearly why the CA model is simply not
adapted to the = Homenet.  I don't think we should be complicating the
Homenet protocol stack in order to work around = the limitations of the
browser = stack.

Best = is the enemy of good enough.   Also, you routinely overestimate how = complicated this stuff is.   I appreciate that you value = simplicity, but the rule I prefer to follow is: "make it as simple as = possible, and no simpler."

The bottom line is that a global = delegation+ACME PKI is a knob I can turn.   Fixing browsers is a = knob I can't turn, and the browser vendors have spoken pretty = unequivocally on this topic.   If you want to tilt at that = windmill, I will gladly lend my voice, but I am not hopeful.

= --Apple-Mail=_CBA4937B-38C9-4872-A681-8C30B1E86168-- From nobody Tue Aug 1 11:04:10 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385E612ECB4 for ; Tue, 1 Aug 2017 11:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 LFWkgUIKU1Q8 for ; Tue, 1 Aug 2017 11:04:07 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 C011A1200C5 for ; Tue, 1 Aug 2017 11:04:07 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id v29so13762911qtv.3 for ; Tue, 01 Aug 2017 11:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=s9d3N+LaFbZApvBPaWZcvHKMnirOLwIUBlluu2FCtDA=; b=szwP/PQOaQ1PCU7IzB6apSA+mW20uDG3ydf//hqP1syiA1umNhG2cyAR9MWDv7yYHx 4E0G3YGoqomytAPlB8kiajxyyktsyDH0rtdiJpqeSzmKwcA59L1TGMoMZLJozhu1q0Y7 xu5pCFFqS7RU30e7U0ZSbAdSr28Ab2NBrxHc1RznI3rVymRNcCv6oT6XD6PF5wyMHqRI mu2WFpAmPEfK8uLKzQ4tI3wVZrH3eeMz3i525LNbcl8Pe5PanThaWLGfNZL8B10Ib1d2 Q8TEKIZ02mix/fbm+6hrnxGArJeMy11qLgE2AZo1z75pl40bBSrIJeC/6ke+YffIH4S2 GctQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=s9d3N+LaFbZApvBPaWZcvHKMnirOLwIUBlluu2FCtDA=; b=aOhPmsvtNXiSTdSJ+II5iy5QQukuRRDHF4MTmm/cMj1NLrJVA2gJsGXPhHGeg6l2GE gR1LcD2iEa8aCO3eKx9PgZerozbo25pVB7Q99Gfizm15nfW/ebT0AFCQQpE3HpIUa2s3 ryVR9lOf9n9aWF8nqx685maDYRMTSIIVVrtFMBA8KQiEHfUKdt6NnWfoFELMjG02x5J6 U5nwJ9Iv/jsCfjmoC6uQVFdRmE0sAbu7lyjXhCuxt8km2Fv6jBlRd+NOCqxPCaJBS9RS efiUZT6IjaCDgW+AQnoA96iSWrRuyCXOVbq8J1Oth3JCR3pXCU3r4aXEJI5PbQGsc5qa sIog== X-Gm-Message-State: AIVw110SayU4ykSp+FBrqAVO93HPA5yP8a5aFEhfrndVh1rwWn8Y/We3 vvPCWjjnrJ/YCvYBopMKFQ== X-Received: by 10.237.42.44 with SMTP id c41mr27494521qtd.74.1501610646906; Tue, 01 Aug 2017 11:04:06 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id n21sm22812580qkl.51.2017.08.01.11.04.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 11:04:05 -0700 (PDT) From: Ted Lemon Message-Id: <37733D96-1B94-47F4-BF74-E3E5C815823C@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AE6D34F0-F338-42D4-9E4E-62D4409F29E4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 1 Aug 2017 14:04:04 -0400 In-Reply-To: <5980C234.305@mathemainzel.info> Cc: Juliusz Chroboczek , "homenet@ietf.org" To: "Walter H." References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> <7ilgn3xkfe.wl-jch@irif.fr> <5980C234.305@mathemainzel.info> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 18:04:09 -0000 --Apple-Mail=_AE6D34F0-F338-42D4-9E4E-62D4409F29E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 1, 2017, at 2:02 PM, Walter H. = wrote: > what is the real problem having stricht rules in this Draft/RFC to get = an > SSL certificate that can be used inside such an environment; > so that no own PKI is neccessary? The problem is that it's not up to us to set these rules=E2=80=94it's up = to CABF, and they have ruled on this, and (IMO) not capriciously. --Apple-Mail=_AE6D34F0-F338-42D4-9E4E-62D4409F29E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 1, 2017, at 2:02 PM, Walter H. <Walter.H@mathemainzel.info> wrote:
what is the real problem having stricht = rules in this Draft/RFC to get an
SSL certificate = that can be used  inside such an environment;
so that no own PKI is neccessary?

The = problem is that it's not up to us to set these rules=E2=80=94it's up to = CABF, and they have ruled on this, and (IMO) not capriciously.

= --Apple-Mail=_AE6D34F0-F338-42D4-9E4E-62D4409F29E4-- From nobody Tue Aug 1 11:37:33 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470E31322A1 for ; Tue, 1 Aug 2017 11:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 1INuK_zs9yom for ; Tue, 1 Aug 2017 11:37:27 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C443B13218F for ; Tue, 1 Aug 2017 11:37:26 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id v71IbOO2014176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Aug 2017 20:37:24 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id v71IbJV8002841; Tue, 1 Aug 2017 20:37:24 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2AA73EB2D0; Tue, 1 Aug 2017 20:37:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 4iNj-qEGNi7W; Tue, 1 Aug 2017 20:37:18 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E98F3EB2CC; Tue, 1 Aug 2017 20:37:15 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1dcc2d-00032f-7p; Tue, 01 Aug 2017 20:37:15 +0200 Date: Tue, 01 Aug 2017 20:37:15 +0200 Message-ID: <7ibmnzxhgk.wl-jch@irif.fr> From: Juliusz Chroboczek To: Ted Lemon Cc: "homenet@ietf.org" In-Reply-To: References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> <7ilgn3xkfe.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 01 Aug 2017 20:37:24 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 01 Aug 2017 20:37:24 +0200 (CEST) X-Miltered: at korolev with ID 5980CA64.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5980CA5F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5980CA64.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5980CA5F.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5980CA64.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5980CA5F.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 18:37:28 -0000 > The bottom line is that a global delegation+ACME PKI is a knob I can turn. Think of it as a knob with a wasps' nest behind it. > Fixing browsers is a knob I can't turn, and the browser vendors have spoken > pretty unequivocally on this topic. If you want to tilt at that windmill, I > will gladly lend my voice, but I am not hopeful. Thanks for the offer, but no. -- Juliusz From nobody Tue Aug 1 11:51:15 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB981322AF for ; Tue, 1 Aug 2017 11:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 cs7C7sVOf1Nm for ; Tue, 1 Aug 2017 11:51:10 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 CB4AB1322A1 for ; Tue, 1 Aug 2017 11:51:09 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id p3so14472735qtg.2 for ; Tue, 01 Aug 2017 11:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kA8k7pdDIseXVJoOC3tEAmhQxINBQirYW+OvezSwcVQ=; b=SwO15gOHECM0k9huHnd/Hh1gOyc1994AXPgD4/MbtCwk9/K9fD6NZC9yx2kBYza+Py lKspT4ubGb4INqMt1w+RVYmdoaR/R2qzxOOEJG3x7vOBs6kVRFm8A8uavhRLYnxve7Lv 1XsS6nTkLz8XEKA0Nn4tCwT/lUdIKbgVUS0DBW3lEKf3pL/xyOLN6D7f8hgntetnw48p QIbxSizvRPhGIdbrM6avyjFBnoF5Npxt3tRW0hsswFj52xwaLUq9gNC5KqDIn0/AqiL1 r0x+nqEPWco4YqwXTsgwwPjB7/ZC8rj/ok3GH3E78k0tZ/4xOAWoPUkN0b9HwX4y/yxT Rt+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kA8k7pdDIseXVJoOC3tEAmhQxINBQirYW+OvezSwcVQ=; b=iC3B5+od4wRP2Gr5OfzEkQQrh8Zw9MyrXPR8fwDJ9oYKKnR9ZPAu7szjTnDTMW8eBg Mmx00rscv7MkaCssrh3qU5JjKGMz93VE7QV1BDv1IH1O3YkcXtl4Vi66Y3ktzeJnAtL1 brqaAH7KIlytZEQFKu4sxd991iuvg0pNqDPH25V41hA4q9Q+KzDQ/I/dsVRiD9j01ddB 1C48Mr9RRCiDM47MP5yRCtpbcSjuaeKjbgS5v0qqX9bYQhTE2Hi3Ko8zOAMYyIcq92ZU 3xcR+jCG/XL/OBgFcLxytrIsjzlwhyE+GEftQSoJv9CtUKWzpssVRVlC03lNFyd5TWYa 08bg== X-Gm-Message-State: AIVw1102KJ5Q7n3tLrudswBGtd29lOww647NYJ0EJwdWTQijaQqTIiIR jj8UNdoxEiEbITGi X-Received: by 10.237.63.67 with SMTP id q3mr30246381qtf.280.1501613469008; Tue, 01 Aug 2017 11:51:09 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id g206sm11142464qkb.13.2017.08.01.11.51.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 11:51:08 -0700 (PDT) From: Ted Lemon Message-Id: <7AFC1987-B964-47FC-8485-9AA561752E78@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DAFDC193-34F7-4E1A-BB86-77573ED162E3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 1 Aug 2017 14:51:06 -0400 In-Reply-To: <7ibmnzxhgk.wl-jch@irif.fr> Cc: "homenet@ietf.org" To: Juliusz Chroboczek References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> <7ilgn3xkfe.wl-jch@irif.fr> <7ibmnzxhgk.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 18:51:14 -0000 --Apple-Mail=_DAFDC193-34F7-4E1A-BB86-77573ED162E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 1, 2017, at 2:37 PM, Juliusz Chroboczek wrote: > Think of it as a knob with a wasps' nest behind it. I know how to build it, so no, I don't think of it that way. I can = think much worse wasp's nests. One example would be a network with no = trust model that encourages end-users to engage in very risky practices = in order simply to use it. I don't think we can fully mitigate that = problem, but I think it's worth thinking about what we _can_ do to = mitigate it. --Apple-Mail=_DAFDC193-34F7-4E1A-BB86-77573ED162E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 1, 2017, at 2:37 PM, Juliusz Chroboczek <jch@irif.fr> = wrote:
Think of it as a = knob with a wasps' nest behind it.

I = know how to build it, so no, I don't think of it that way.   I can = think much worse wasp's nests.   One example would be a network = with no trust model that encourages end-users to engage in very risky = practices in order simply to use it.   I don't think we can fully = mitigate that problem, but I think it's worth thinking about what we = _can_ do to mitigate it.

= --Apple-Mail=_DAFDC193-34F7-4E1A-BB86-77573ED162E3-- From nobody Tue Aug 1 11:54:28 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BEE1322D3 for ; Tue, 1 Aug 2017 11:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mathemainzel.info 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 p2C5ePLfVdFo for ; Tue, 1 Aug 2017 11:54:19 -0700 (PDT) Received: from mx27lb.world4you.com (mx27lb.world4you.com [81.19.149.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06361322CF for ; Tue, 1 Aug 2017 11:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mathemainzel.info; s=dkim11; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=qxu7AN1LUUJ4rHVr4FwaVIw2R3Xi3uh2lqJBqe8N3hg=; b=r3marrYEuXAxbsf68jz1w3pyNE2yY4ienKVHRCTyExR19B+LhuJZ7/bOMYsmVyayrvA8QH/mSPunH9Az4DP/rbAwz7lBjUT/hAOsRby5M0+ENKSHlCt9gFF53qtMoZXKlSjVx75L5OdH5JwFCglshT+nPO21HunbeWU2llkSd08=; Received: from [90.146.55.206] (helo=home.mail) by mx27lb.world4you.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dccIy-0005x7-S4; Tue, 01 Aug 2017 20:54:08 +0200 Message-ID: <5980CE3E.1030709@mathemainzel.info> Date: Tue, 01 Aug 2017 20:53:50 +0200 From: "Walter H." Organization: Home User-Agent: Mozilla/5.0 (UNIX; U; Cray X-MP/48; en-US; rv:2.70) Gecko/20110929 Communicator/7.20 MIME-Version: 1.0 To: Ted Lemon CC: "homenet@ietf.org" , Juliusz Chroboczek References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> <7ilgn3xkfe.wl-jch@irif.fr> <5980C234.305@mathemainzel.info> <37733D96-1B94-47F4-BF74-E3E5C815823C@fugue.com> In-Reply-To: <37733D96-1B94-47F4-BF74-E3E5C815823C@fugue.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000301060704050704080102" X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 90.146.55.206 X-SA-Exim-Mail-From: Walter.H@mathemainzel.info X-SA-Exim-Scanned: No (on mx27lb.world4you.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 18:54:22 -0000 This is a cryptographically signed message in MIME format. --------------ms000301060704050704080102 Content-Type: multipart/alternative; boundary="------------040304040609040702090206" This is a multi-part message in MIME format. --------------040304040609040702090206 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 01.08.2017 20:04, Ted Lemon wrote: > On Aug 1, 2017, at 2:02 PM, Walter H. > wrote: >> what is the real problem having stricht rules in this Draft/RFC to get= an >> SSL certificate that can be used inside such an environment; >> so that no own PKI is neccessary? > > The problem is that it's not up to us to set these rules=E2=80=94it's u= p to=20 > CABF, and they have ruled on this, and (IMO) not capriciously. is there a problem, to have the organization that has the delegation of=20 ".home.arpa." also provide such SSL certificates signed by an intermediate that got signed by any CA? and these should be a section in this Draft/RFC ... so that there is neither need of errors/warning neither red nor cowblue=20 or other color; and also no need of having an own PKI when not wanted to or or not having the knowledge about at all; it would be quite strange to think that anybody that use a browser for=20 electronic banking has the knowledge about SSL ... by the way knowledge about SSL is more common than knowledge about=20 DNSSEC ... in good old german we would say: "wo ein Wille da ein Weg" or in strange = English: "a way is open when its wanted to be open" --------------040304040609040702090206 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01.08.2017 20:04, Ted Lemon wrote:
On Aug 1, 2017, at 2:02 PM, Walter H. <Walter.H@mathemainzel.info> wrote:
what is the real problem having stricht rules in this Draft/RFC to get an
SSL certificate that can be used =C2=A0inside such an environment;
so that no own PKI is neccessary?

The problem is that it's not up to us to set these rules=E2=80= =94it's up to CABF, and they have ruled on this, and (IMO) not capriciously.

is there a problem, to have the organization that has the delegation of ".home.arpa." also provide such SSL certificates
signed by an intermediate that got signed by any CA?

and these should be a section in this Draft/RFC ...

so that there is neither need of errors/warning neither red nor cowblue or other color; and also no need of having an own PKI
when not wanted to or or not having the knowledge about at all;

it would be quite strange to think that anybody that use a browser for electronic banking has the knowledge about SSL ...
by the way knowledge about SSL is more common than knowledge about DNSSEC ...

in good old german we would say: "wo ein Wille da ein Weg" or in strange English: "a way is open when its wanted to be open"


--------------040304040609040702090206-- --------------ms000301060704050704080102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKBDCC BOgwggPQoAMCAQICDkgbagkTvYAkyl0i8BTzMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsT F0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQD EwpHbG9iYWxTaWduMB4XDTE2MDYxNTAwMDAwMFoXDTI0MDYxNTAwMDAwMFowXTELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24g UGVyc29uYWxTaWduIDIgQ0EgLSBTSEEyNTYgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALaWaJNl/SwB7GKjDVS/i8ukQ5Gimq+xg/K1bW/Z8OrczxZ71xnjhAOF+cYf cI8fbEnFaRkecJE4NX4CSF05axhEpmqlyHT0XfWEPmMfcUSCCD7tyaf26W4mQSmAyUm6/9l2 oKO7G/Z530so00p7nFHCD2VQoZ+oSp3lRgSNg0/cssg9z5ghCZhMwPGPeqk/NyZlR9hmj0km wsNAvmY9bP86rSlG8BOc4fLrmaeLwtNfUG2iDm/HBpc4L06hjkcCtIMA2KTjukEHYOXdN1ry B8E7p5yXaC6376lINrzpaaiZqkfpx/ZR0vmxLLbFSbWYnlNT2vty83wP+HE+1wP6Z8MCAwEA AaOCAbUwggGxMA4GA1UdDwEB/wQEAwIBBjBqBgNVHSUEYzBhBggrBgEFBQcDAgYIKwYBBQUH AwQGCCsGAQUFBwMJBgorBgEEAYI3FAICBgorBgEEAYI3CgMEBgkrBgEEAYI3FQYGCisGAQQB gjcKAwwGCCsGAQUFBwMHBggrBgEFBQcDETASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQW BBRpcoJiMWeVRIV3kYDEBDZJnXsLYTAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0b vDA+BggrBgEFBQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWdu LmNvbS9yb290cjMwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNv bS9yb290LXIzLmNybDBnBgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEG CSsGAQQBoDIBXzA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9y ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAqJ3NMsx8Z+ILUNelXHCjZuIl7+q0tlMw bocSN1wz4sIoVuOTvUWV81jYFXFM8+SCiRS+/qXMR73rBlSCPua/vvXqiPV5xCgiC4x69g4L 4yquSZoOm8In8my2G1VKAbYZ4WhQdFi8EkUYT67eXhsTMOdVJjSAov4UigSrB4RhUhGiUAC2 cuBy9BFnbhOiC2AI1+gUl0Q7RxXlD3XW+On+R3+a8yExi7J/QSKaDla4EvO/DuCZ31FkItvc gX5++R2o4nxbzwvrqp/q3FZ766S4LCzmBv+uJFl/xUR/PpoVXvpnEl98bFKXMSvavby01ba6 FP8iVJhAuDnB+XULGxwaozCCBRQwggP8oAMCAQICDDf7Me/cd27Vi+FlDzANBgkqhkiG9w0B AQsFADBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UE AxMqR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczMB4XDTE3MDQy NDEwNDQxOFoXDTIwMDQyNDEwNDQxOFowVTELMAkGA1UEBhMCQVQxGzAZBgNVBAMTEldhbHRl ciBIb2VobGh1Ym1lcjEpMCcGCSqGSIb3DQEJARYad2FsdGVyLmhAbWF0aGVtYWluemVsLmlu Zm8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDROn0wc2eBzHcRoKiSnUFz1H4T SN5QEKhssd+B8F0YMDxEzXyvnOeCLAN+8+ui/fyZ0g1A8qgWIGkerNeJJgVes9Xf5EpemE5b zksNPIoVQVB7sBfWezlJ6E12FUNssdLdcQlVqNtFnHtfZV0SD0BS87mW5GL75Ay8XpSkwwTV 6XpIAcKRyd7EFCw+7g2Udp/ZAjPZ4X7oZl8sFFlOClPvWu8LCjbnDcWHpE93QeXnmMx86LQg tACrTy1PDX0yAOeCTan6F3sX0tz5Cp8sWduQiMaKof8yxW/t2V7BJwXhZhiDhax3y/AFREOH NC5dJ2w1sFiwidK7sljogU7/orGHAgMBAAGjggHaMIIB1jAOBgNVHQ8BAf8EBAMCBaAwgZ4G CCsGAQUFBwEBBIGRMIGOME0GCCsGAQUFBzAChkFodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24u Y29tL2NhY2VydC9nc3BlcnNvbmFsc2lnbjJzaGEyZzNvY3NwLmNydDA9BggrBgEFBQcwAYYx aHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL2dzcGVyc29uYWxzaWduMnNoYTJnMzBMBgNV HSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxz aWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NwZXJzb25hbHNpZ24yc2hhMmczLmNybDAlBgNVHREE HjAcgRp3YWx0ZXIuaEBtYXRoZW1haW56ZWwuaW5mbzAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwHQYDVR0OBBYEFOQybe9sZCmROEwJqrOUU1qsTrgqMB8GA1UdIwQYMBaAFGly gmIxZ5VEhXeRgMQENkmdewthMA0GCSqGSIb3DQEBCwUAA4IBAQBY5Zn+1HTT58xtZQgu1IcN UI9t2PC0ps6sELyN3eCBvqYiqk5D8J58hNl9j0hnht5oM0aKVgTL1GNFu6J9DDd3Bk2sNmG6 8uIvo0NsJAFk23lMzKt+YOm3C6+oveuxICFhHeiTxn9z2jLfU+xYLg8UXpSl5U6m0uZcVoLA YYYhLgpaSM8jNYgAv8U2NVK+f8hd4AVEpwyF2edKbZTAdj/iDmjmOm9lkUIzacemNR8DRxiD Eb2XTZa5pcrsPOe1bisJ5wcHoIx+217fm8WJF7Vk2amB9fg8AM3cGU7V7D2Ynbg5tJdV5Et6 ff+sk9Fv1HRaFDqKQVorlDY1P5h1HsoxMYIDYTCCA10CAQEwbTBdMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczAgw3+zHv3Hdu1YvhZQ8wCQYFKw4DAhoFAKCCAckw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwODAxMTg1MzUw WjAjBgkqhkiG9w0BCQQxFgQUMPTtJ9cIDBfsqtleWn3ZOf3kSowwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB8BgkrBgEEAYI3EAQx bzBtMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYDVQQD EypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0gRzMCDDf7Me/cd27V i+FlDzB+BgsqhkiG9w0BCRACCzFvoG0wXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2Jh bFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBT SEEyNTYgLSBHMwIMN/sx79x3btWL4WUPMA0GCSqGSIb3DQEBAQUABIIBAJ2tWivhtnmSA9KM MYC4vB7FKwOvlTRKp+sNnVGqTY1he9exW9TSYWtO48hBKJG8s8nZKakU2eeIedkkRDiITTtO T/GOc9duIZ2HPJblgX89mHbJL/RdmQUPQnLlj/EH2BD2eW3SusDpnwMazkZNgQV9emb/f6ac GPgPY2ZsNwyalVBVF/G+EpTAKbH4w54MISg+zlL2z+2QvmRCRPMAe9BDFGIMECbZPMdsceZt Mtn2JiywN5KBZcFtROV/f7dHmQ59yMbGdnLoKNmnGW8o0rwuEZY/ShuUq2x8ULnzyd2Oi7sA vq5k2gz73hIcVd4kx31Tz2JdxWqtAYxDqEz5g+wAAAAAAAA= --------------ms000301060704050704080102-- From nobody Tue Aug 1 12:21:53 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8682D131C8B for ; Tue, 1 Aug 2017 12:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 9AxPKow0Fs70 for ; Tue, 1 Aug 2017 12:21:49 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 C0A341317CC for ; Tue, 1 Aug 2017 12:21:49 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id z18so14944839qka.4 for ; Tue, 01 Aug 2017 12:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=w8+2VWsM3StgkkGHfeE30yLvpHBFZRl+RFAixpWNCVU=; b=iWUuLgMiltJ/33aVe6gJJz9ldEgcLpuuLNPy88FwLhzvh9qFCAe8DenzjdQyCdv0i0 OAFOvRYd6xcVHYWZfvT9l0dOmLIutCQe0NH0pZBg7PzMk5gdmkRTe/rS4inNuowqeCyi YZ38u9PrK1+wRHb1A5XT8dryRJC7dbUhbSVfI6NBA9rYc0A+3lR+L+CzIWdEdJD+7Il3 dDpSmuA3fOpyX/COovBFT760G6z1IfO3goJ7i9vnf0ONHLUZ1C/jHqdhfZMDnfgbN6WL UxWp6D1w8hcqV0Rqtns6uZ0ldw7dlX2wi1a6pmxU19hRQTUsWF9dFT5TIRUlc3Hx1Y+6 +R6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=w8+2VWsM3StgkkGHfeE30yLvpHBFZRl+RFAixpWNCVU=; b=Mvy9t9kjK365qbuirq2fuZNSo1qMHAaGWdKcIvfRFmOYh9HUOooI+HHVbLdWkzQP9B nQTiGxRUNUg9lpT97VMm3dSPHTeoIh+MFpwPiX2ICCvp8teTVI4y9Ws7qVVp4ukaTUlM oXcqWRygzoGtyLCcof2+qsn0NJHf7gWVPUN2ARQ6RqdJFybZk4z9miqfr7QqHXBG27uA fp+52QRmb4kUybvEbw1JG15fmAcjg/jZgMEZGfqGVIFa5BnYBjSAvxQvzE0cp6GxzhVc m4trd+3sdnl0bFcWnI42v7AE38/m01udZA2JYBaw/NUACRXRnxkWL/BEtZtFU3wpU/L5 p9nQ== X-Gm-Message-State: AIVw113+mkFSpuqihPgV/DFC6CYKwniu9dbUXkYQZWZ0Tmv3tOzhQj6e MFsyVCJO0tyjBmlU7fuqsA== X-Received: by 10.55.115.132 with SMTP id o126mr25781437qkc.130.1501615308942; Tue, 01 Aug 2017 12:21:48 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id t5sm1160769qtb.89.2017.08.01.12.21.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 12:21:48 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6ED14A29-6B27-412A-833B-BADD7BEE2BE5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 1 Aug 2017 15:21:46 -0400 In-Reply-To: <5980CE3E.1030709@mathemainzel.info> Cc: "homenet@ietf.org" , Juliusz Chroboczek To: "Walter H." References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> <7ilgn3xkfe.wl-jch@irif.fr> <5980C234.305@mathemainzel.info> <37733D96-1B94-47F4-BF74-E3E5C815823C@fugue.com> <5980CE3E.1030709@mathemainzel.info> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 19:21:51 -0000 --Apple-Mail=_6ED14A29-6B27-412A-833B-BADD7BEE2BE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 1, 2017, at 2:53 PM, Walter H. = wrote: > is there a problem, to have the organization that has the delegation = of ".home.arpa." also provide such SSL certificates=20 > signed by an intermediate that got signed by any CA? This is not how PKI works. For a browser to trust a signing authority, = the signing authority has to be vetted as trustworthy. Honestly, PKI = is a bit of a dumpster fire, but the point is that adding this = requirement, even if we could, would not improve the situation. Please = understand that the goal of network security, including PKI, is not to = make warnings go away: it is to protect users from attacks on the = security of their information and devices. --Apple-Mail=_6ED14A29-6B27-412A-833B-BADD7BEE2BE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 1, 2017, at 2:53 PM, Walter H. <Walter.H@mathemainzel.info> wrote:
is there a problem, to have the organization that has the = delegation of ".home.arpa." also provide such SSL certificates 
signed by an intermediate that got signed by any = CA?

This = is not how PKI works.   For a browser to trust a signing authority, = the signing authority has to be vetted as trustworthy.   Honestly, = PKI is a bit of a dumpster fire, but the point is that adding this = requirement, even if we could, would not improve the situation.   = Please understand that the goal of network security, including PKI, is = not to make warnings go away: it is to protect users from attacks on the =  security of their information and devices.

= --Apple-Mail=_6ED14A29-6B27-412A-833B-BADD7BEE2BE5-- From nobody Tue Aug 1 13:48:26 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E78129ACD for ; Tue, 1 Aug 2017 13:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 WmEeLxzU8M5Q for ; Tue, 1 Aug 2017 13:48:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66486124B0A for ; Tue, 1 Aug 2017 13:48:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3A6582009E; Tue, 1 Aug 2017 16:50:11 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1CA2A8076D; Tue, 1 Aug 2017 16:48:22 -0400 (EDT) From: Michael Richardson To: Ted Lemon cc: homenet@ietf.org In-Reply-To: <6C42A593-3EBC-49BE-9A9F-0CF701FF68BF@fugue.com> References: <3725.1501514462@obiwan.sandelman.ca> <52E1C5A0-FC0E-46A5-9016-AA95FB3DC1CB@fugue.com> <3184.1501522914@obiwan.sandelman.ca> <5A407EA3-AC8B-44A7-8EC2-8242480027FE@fugue.com> <27345.1501546823@obiwan.sandelman.ca> <10182.1501601902@obiwan.sandelman.ca> <6C42A593-3EBC-49BE-9A9F-0CF701FF68BF@fugue.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [homenet] Ted's security talk at IETF99: DNCP Security X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 20:48:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: > You agree that it's a different problem right? mcr> The common part is that one might have a similar set of external mcr> (physical) signals. mcr> Should Dave bring his printer to the IETF network, and they happen= to mcr> discovery each other via privacy-enhanced dnssd magic (cf: Arthur = Clark's mcr> definition of magic), then it would be good that they can prove th= at it's mcr> really them. > To be honest, I probably missed the point you were making=E2=80=94I j= ust went back > and reviewed this exchange, and I don't actually understand what the > distinction is that you are making between ephemeral and long-lived > relationships. This thread started by being about the problem of getting devices in the ho= me to securely join the homenet. One sees a list of possible routers in the home, and identifies one that should belong, and tells your homenet that it should be allowed to join. (And the router also is told to join your network). The short-term exchange is where you discover the new router and do the out-of-band secured exchange to establish initial trust. Within that initi= al trust, longer-term credentials (asymmetric keys) are exchanged. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmA6RUACgkQgItw+93Q 3WVPlggAsF3mZ0uBD8u9nvLcFuY/lwjPUeUKIFzhlg4MO12u0SPJEmBXyB8XT55b WyBn/37+9zBSJPhhEO9MmJuT/E2n9kymZY+Qu3glmv2W6DLnPxFK4tOT3rSM3ueI TmxlbHpzbychPTFPx4tEqLkz9tXE8OdHsiEfbIR48C+qlr52OigBeIL7pC3Cinx8 t8zeXruHCM/FqDtcZlg70sS6JYxU2kkqS12e5gIIUTLJV7EyDdKy5UkRZ8Z+qHS4 1WxLd3u0coacYrWUHil1HCUkA2WiebTjmuDFMiyTb4AszawbLCoQCedanzXqL9Kt seCXnYnhzFs/qTDKNcenyf1Tpppl6w== =4sNj -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 1 13:53:48 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3593124B0A for ; Tue, 1 Aug 2017 13:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 a8e_pUZysLmU for ; Tue, 1 Aug 2017 13:53:44 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 AE0FC124217 for ; Tue, 1 Aug 2017 13:53:44 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id o86so8982471pfj.1 for ; Tue, 01 Aug 2017 13:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UiAZ84248qY5iOg8dLY17dBHCBDAMy3ygk2U7bQ73rQ=; b=eeC2roV/CXXJVDTzXhsQurU6i/WIiSwETY7THM1c4mAunjr8REE/b/Ir9fLTFZO0t5 DotU1Vtmy5+PfhdqQISigO4U8jmcWUCYNm0LZYpJUlbuV4jo6VSLppSaYH/sJE3Oj+oj 7oqn3LqRYvxB24lbG6aC0bZDi12KH8tqFSUMPk5AnxZ4coy9G9AxOeDXVMpiC9rV2UCu TpLnbUe5qAxc+aA3pFmBkWCoasP25M7AoxbwwjEBo3t9C1BpgSpE6aQYatHaHQHdGbu0 gPWoPpRXdTPo9nm0fep9u0fyFqjQM9nE5P7/oQ6xV3Xz6YZJe8pPPr/m79gb/0TkG7bl 3CJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UiAZ84248qY5iOg8dLY17dBHCBDAMy3ygk2U7bQ73rQ=; b=IeNcISattKbhkO/HNk9arWoORFAgLUgTc6QA80yPOSz8gsH0pGannJi/LtH55MV3dH LuJ8KfaMSPmUgBwSQad75QmyBTOFjGh66pU40GvFqaOjxIj2nsplFrXAypRqWi9GRTum Gu58r7eIOcI8N7pndtrRVfPzL6w/yRBnsAte+GMKtb6vBLY49dR0w7LxXaodPKJOAZYg j5XuadSRM7KQF4KacR2mTPQ67c19IWHkntlTIMn+Didwe3GPV8wqN2MZ/LoJ1tPZ4u30 BKN9egknPnIzfi/xD4HuiJoK8n4d5E+9E7zkghXZf1i0f0eGuO++jtdMn8Y9nURJa/oW zn3Q== X-Gm-Message-State: AIVw113+cldWiNvryHeEAm0ajWLAjHAHOfN/t+Eap/Jantyhtp6W3X6z GLaAAhIfJpyuds9zHHVTNX+emInCC991 X-Received: by 10.98.7.132 with SMTP id 4mr20840056pfh.216.1501620824280; Tue, 01 Aug 2017 13:53:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.131 with HTTP; Tue, 1 Aug 2017 13:53:03 -0700 (PDT) In-Reply-To: <20840.1501620502@obiwan.sandelman.ca> References: <3725.1501514462@obiwan.sandelman.ca> <52E1C5A0-FC0E-46A5-9016-AA95FB3DC1CB@fugue.com> <3184.1501522914@obiwan.sandelman.ca> <5A407EA3-AC8B-44A7-8EC2-8242480027FE@fugue.com> <27345.1501546823@obiwan.sandelman.ca> <10182.1501601902@obiwan.sandelman.ca> <6C42A593-3EBC-49BE-9A9F-0CF701FF68BF@fugue.com> <20840.1501620502@obiwan.sandelman.ca> From: Ted Lemon Date: Tue, 1 Aug 2017 16:53:03 -0400 Message-ID: To: Michael Richardson Cc: HOMENET Content-Type: multipart/alternative; boundary="001a1143ecf0d1a6b40555b7579c" Archived-At: Subject: Re: [homenet] Ted's security talk at IETF99: DNCP Security X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 20:53:46 -0000 --001a1143ecf0d1a6b40555b7579c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So what you're saying is ephemeral is the keying used for the initial exchange? On Tue, Aug 1, 2017 at 4:48 PM, Michael Richardson wrote: > > Ted Lemon wrote: > > You agree that it's a different problem right? > > mcr> The common part is that one might have a similar set of external > mcr> (physical) signals. > > mcr> Should Dave bring his printer to the IETF network, and they > happen to > mcr> discovery each other via privacy-enhanced dnssd magic (cf: Arthu= r > Clark's > mcr> definition of magic), then it would be good that they can prove > that it's > mcr> really them. > > > To be honest, I probably missed the point you were making=E2=80=94I= just > went back > > and reviewed this exchange, and I don't actually understand what th= e > > distinction is that you are making between ephemeral and long-lived > > relationships. > > This thread started by being about the problem of getting devices in the > home > to securely join the homenet. One sees a list of possible routers in the > home, and identifies one that should belong, and tells your homenet that = it > should be allowed to join. (And the router also is told to join your > network). > > The short-term exchange is where you discover the new router and do the > out-of-band secured exchange to establish initial trust. Within that > initial > trust, longer-term credentials (asymmetric keys) are exchanged. > > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > --001a1143ecf0d1a6b40555b7579c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So what you're saying is ephemeral is the keying used = for the initial exchange?

On Tue, Aug 1, 2017 at 4:48 PM, Michael Richardson <mcr= +ietf@sandelman.ca> wrote:
=
Ted Lemon <mellon@fugue.com> = wrote:
=C2=A0 =C2=A0 > You agree that it's a different problem right?

=C2=A0 =C2=A0 mcr> The common part is that one might have a simil= ar set of external
=C2=A0 =C2=A0 mcr> (physical) signals.

=C2=A0 =C2=A0 mcr> Should Dave bring his printer to the IETF network, an= d they happen to
=C2=A0 =C2=A0 mcr> discovery each other via privacy-enhanced dnssd magic= (cf: Arthur Clark's
=C2=A0 =C2=A0 mcr> definition of magic), then it would be good that they= can prove that it's
=C2=A0 =C2=A0 mcr> really them.

=C2=A0 =C2=A0 > To be honest, I probably missed the point you were makin= g=E2=80=94I just went back
=C2=A0 =C2=A0 > and reviewed this exchange, and I don't actually und= erstand what the
=C2=A0 =C2=A0 > distinction is that you are making between ephemeral and= long-lived
=C2=A0 =C2=A0 > relationships.

This thread started by being about the problem of getting devices in= the home
to securely join the homenet.=C2=A0 One sees a list of possible routers in = the
home, and identifies one that should belong, and tells your homenet that it=
should be allowed to join.=C2=A0 (And the router also is told to join your<= br> network).

The short-term exchange is where you discover the new router and do the
out-of-band secured exchange to establish initial trust.=C2=A0 Within that = initial
trust, longer-term credentials (asymmetric keys) are exchanged.


--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




--001a1143ecf0d1a6b40555b7579c-- From nobody Tue Aug 1 14:06:39 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CDA131C56 for ; Tue, 1 Aug 2017 14:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 lLb34wWG8fMv for ; Tue, 1 Aug 2017 14:06:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01932129B40 for ; Tue, 1 Aug 2017 14:06:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 744D92009E for ; Tue, 1 Aug 2017 17:08:25 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 49A9D80B17 for ; Tue, 1 Aug 2017 17:06:36 -0400 (EDT) From: Michael Richardson To: "homenet\@ietf.org" In-Reply-To: <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 21:06:38 -0000 --=-=-= Content-Type: text/plain Ted Lemon wrote: barbara> The CABF is about "publicly trusted certificates". There is no need or ... > (2) the issue with browser warnings isn't that they are annoying. It's that > if we train users to click through them when managing the homenet, we are > also training them to click through them at other times. This creates an > attack surface in the user that we'd rather not create. I was trying to understand how CABF was relevant. I guess the point was how to get a new trust anchor added *globally* that would somehow be able to issue certificates that were relevant/bound to home.arpa names? I don't think that this is an immediate concern; if we had some useful experiment that we could do we could do it with a sub-CA or with a private anchor. I think that Windows, OSX, and Android have system-wide ways to install new trust anchors that browser will generally trust. libnss on many Linux distros provides something similiar. I assume iOS does too. As such, it should be possible for an application/app on a home desktop to exist that would interact with all the devices involved (providing certificates from a private trust anchor), and to install the private trust anchor. How one spreads that trust anchor to the rest of the family, relatives, etc. is an issue. but, none of this is really relevant to delegation of home.arpa, I think. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmA7VsACgkQgItw+93Q 3WWa6Af7BNe/fBBbMCeKWNWCX6PfEFgIK2KPb3D93nGENng6NSVXG/wXTIgip9Rt KMwvE+8WLIfi/XNTkz+QQvUfdZMGtEnAkGO3C4uNxanOh6TThocvN+F9ZXtA5Hnq AYhAUk24I4lZGzrxuSBZhpQLkT+znMWbyG6qwUSVUiXoIhJggBxYTGueeUbXzioS a8UXjR+icaWkFu5kc6CxVoe8jOJuz8AfDcMg3jpzBCgQ+6A+285TA2tGfJEngAKz tCYUNb6ti9coDhVpRaOf8tv3tWeIxG3Lg5568/OrX1z9dKZQb8ybQdqbJpzjJF3i Wsc2zk1n3Dg8yip8OVIW7GUgu4ly0g== =yVVW -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 1 14:15:58 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038D6131C98 for ; Tue, 1 Aug 2017 14:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 VFVnX2AK6yej for ; Tue, 1 Aug 2017 14:15:55 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 0313F129B40 for ; Tue, 1 Aug 2017 14:15:55 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id u185so12701616pgb.1 for ; Tue, 01 Aug 2017 14:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oHYnDfRCsvHYAQ8GclU26+06oDCqy61HEObmo8HSvKs=; b=UBfTVUFrUidi7kj0e6cXP3HhC0u9Tsa3hvjx7h62OMdMTOpSWpn7dlh/aVmZJyQIB2 EVuljW+mBur1c4MwB/z77+c1QuZV/eoa+5yl/DsJxInLt7J22RnubQwmg4yG+yjivLJJ CjA3GNdZlQW0I1goe8/DFRSqVikbE/uoER26kKNeulh/XNMQ41zQZvTvN6l3rIdqoBxI lKp5tEXpkawt4ydqID7jMHoGFNIJQAi31oOtzMpbSevfWAVcuEzZtIyozxbxp4uaDBec fgcCuAv02V1EbljMoOaoDhKx3Ta5LaGCl6cvybNaXptDoibvqjK3jP26kWKD4DKDDdi4 rQFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oHYnDfRCsvHYAQ8GclU26+06oDCqy61HEObmo8HSvKs=; b=OoIcSm44uxgklrIAIJeeUcLO7KclL6KEnMkNHf3z9KTUADb4jUToSVhuI2OiBKdQMp QXEfb70GIoThJeKaMYwri21WCfwBgg9ehQ7kX7XWB7LYxXkNhPSbtFnUg3ETfrNOogi1 3dJcvUwglQ7peyJsnVTWBvcqDgax9llJBllNBYnxTLXtL/usPh7me89KDGoUM+Mmyqex xD6DujUeX7TgzN14kushse2yrGrvSuJj22RrA2YqR9PnsAElvavO+LZCaMwquy6iSPJE zN7qiOoLqekraDx1vH33inZni+fGq57eYpgYH0ftVqrJD+tLLACfhjO2fKBOKz5kJcBU PKXg== X-Gm-Message-State: AIVw111ZvwfVNNLZ0aKQbIkVvfc79OTWJJpllQ1G6iwHUzEb5KTsyxfZ +q1lP/Hd6AC9F+AA6/5tCcjeoi8mmTOy X-Received: by 10.99.54.201 with SMTP id d192mr7967431pga.310.1501622154366; Tue, 01 Aug 2017 14:15:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.131 with HTTP; Tue, 1 Aug 2017 14:15:13 -0700 (PDT) In-Reply-To: <25096.1501621596@obiwan.sandelman.ca> References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> <25096.1501621596@obiwan.sandelman.ca> From: Ted Lemon Date: Tue, 1 Aug 2017 17:15:13 -0400 Message-ID: To: Michael Richardson Cc: "homenet@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0de54c1925bf0555b7a7ce" Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 21:15:57 -0000 --94eb2c0de54c1925bf0555b7a7ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I addressed that question in a previous reply. Your home network does not have the equivalent security to letsencrypt.org's certificate signing infrastructure (I hope!!). Installing a trust anchor means that trust anchor has signing authority for any name=E2=80=94there's no way to install= one that doesn't. So now you've opened all those hosts to attack. Plus, you have to install the trust anchor on a bunch of hosts. Aside from the bit about our charter saying the host needn't be modified, that's an IT problem that would challenge a lot of fairly computer-literate people, and if apps are trusted to do it, that's a major security vulnerability waiting to be exploited. If you mean install a cert for every device that presents a web browser, well, eep. Aside from the "trusted app" issue and the "that's hard for end-users" issue, I guess that isn't quite as scary, but I'd really like an operational model that doesn't require it. I mean, honestly, if it were possible to get a CA to just issue certificates for "www.home.arpa" on request with no validation, I think that would be a better answer both from a security perspective and a usability perspective, but it's not a *good* answer, and I don't think it's possible anyway. On Tue, Aug 1, 2017 at 5:06 PM, Michael Richardson wrote: > > Ted Lemon wrote: > barbara> The CABF is about "publicly trusted certificates". There is > no need or > > ... > > (2) the issue with browser warnings isn't that they are annoying. > It's that > > if we train users to click through them when managing the homenet, > we are > > also training them to click through them at other times. This > creates an > > attack surface in the user that we'd rather not create. > > I was trying to understand how CABF was relevant. > > I guess the point was how to get a new trust anchor added *globally* that > would somehow be able to issue certificates that were relevant/bound to > home.arpa names? > > I don't think that this is an immediate concern; if we had some useful > experiment that we could do we could do it with a sub-CA or with a privat= e > anchor. > > I think that Windows, OSX, and Android have system-wide ways to install n= ew > trust anchors that browser will generally trust. libnss on many Linux > distros provides something similiar. I assume iOS does too. As such, it > should be possible for an application/app on a home desktop to exist that > would interact with all the devices involved (providing certificates from= a > private trust anchor), and to install the private trust anchor. > How one spreads that trust anchor to the rest of the family, relatives, > etc. is an issue. > > but, none of this is really relevant to delegation of home.arpa, I think. > > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > --94eb2c0de54c1925bf0555b7a7ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I addressed that question in a previous reply. =C2=A0 Your= home network does not have the equivalent security to letsencrypt.org's certificate signing infrastructure= (I hope!!). =C2=A0 Installing a trust anchor means that trust anchor has s= igning authority for any name=E2=80=94there's no way to install one tha= t doesn't. =C2=A0 So now you've opened all those hosts to attack. = =C2=A0 Plus, you have to install the trust anchor on a bunch of hosts. =C2= =A0 Aside from the bit about our charter saying the host needn't be mod= ified, that's an IT problem that would challenge a lot of fairly comput= er-literate people, and if apps are trusted to do it, that's a major se= curity vulnerability waiting to be exploited. =C2=A0 If you mean install a = cert for every device that presents a web browser, well, eep. =C2=A0 Aside = from the "trusted app" issue and the "that's hard for en= d-users" issue, I guess that isn't quite as scary, but I'd rea= lly like an operational model that doesn't require it.

I mean, honestly, if it were possible to get a CA to just issue certific= ates for "www.home.arpa" on request with no validation, I think t= hat would be a better answer both from a security perspective and a usabili= ty perspective, but it's not a good=C2=A0answer, and I don't= think it's possible anyway.

=
On Tue, Aug 1, 2017 at 5:06 PM, Michael Richards= on <mcr+ietf@sandelman.ca> wrote:

Ted Lemon <mellon@fugue.com> = wrote:
=C2=A0 =C2=A0 barbara> The CABF is about "publicly trusted certific= ates". There is no need or

...
=C2=A0 =C2=A0 > (2) the issue with browser warnings isn= 't that they are annoying. It's that
=C2=A0 =C2=A0 > if we train users to click through them when managing th= e homenet, we are
=C2=A0 =C2=A0 > also training them to click through them at other times.= This creates an
=C2=A0 =C2=A0 > attack surface in the user that we'd rather not crea= te.

I was trying to understand how CABF was relevant.

I guess the point was how to get a new trust anchor added *globally* that would somehow be able to issue certificates that were relevant/bound to
home.arpa names?

I don't think that this is an immediate concern; if we had some useful<= br> experiment that we could do we could do it with a sub-CA or with a private<= br> anchor.

I think that Windows, OSX, and Android have system-wide ways to install new=
trust anchors that browser will generally trust.=C2=A0 libnss on many Linux=
distros provides something similiar.=C2=A0 I assume iOS does too.=C2=A0 As = such, it
should be possible for an application/app on a home desktop to exist that would interact with all the devices involved (providing certificates from a=
private trust anchor), and to install the private trust anchor.
How one spreads that trust anchor to the rest of the family, relatives,
etc. is an issue.

but, none of this is really relevant to delegation of home.arpa, I think.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet<= br>

--94eb2c0de54c1925bf0555b7a7ce-- From nobody Tue Aug 1 17:42:17 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E82131919 for ; Tue, 1 Aug 2017 17:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 fEI9OhMN2nX4 for ; Tue, 1 Aug 2017 17:42:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47944131714 for ; Tue, 1 Aug 2017 17:42:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4934DE009; Tue, 1 Aug 2017 20:44:03 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9F04D80B17; Tue, 1 Aug 2017 20:42:13 -0400 (EDT) From: Michael Richardson To: Ted Lemon cc: HOMENET In-Reply-To: References: <3725.1501514462@obiwan.sandelman.ca> <52E1C5A0-FC0E-46A5-9016-AA95FB3DC1CB@fugue.com> <3184.1501522914@obiwan.sandelman.ca> <5A407EA3-AC8B-44A7-8EC2-8242480027FE@fugue.com> <27345.1501546823@obiwan.sandelman.ca> <10182.1501601902@obiwan.sandelman.ca> <6C42A593-3EBC-49BE-9A9F-0CF701FF68BF@fugue.com> <20840.1501620502@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [homenet] Ted's security talk at IETF99: DNCP Security X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 00:42:15 -0000 --=-=-= Content-Type: text/plain Ted Lemon wrote: > So what you're saying is ephemeral is the keying used for the initial > exchange? yes, it's probably more about authenticating the initial (DH/TLS/etc.) exchange. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmBH+UACgkQgItw+93Q 3WUO2Qf9F+fDGMUncwAy+HjKtInPQXW0FUQdOa7fF8IUIoNaRQeCs4DX2jYFXgNm f6EQ8eIjfzrUnUqUsOpvn2LCpz/7a2zTIWTvgvIl1+HgsmppAHgMpI9ZwzA6yP9E n+oXlmt8Z1/LbP42WHhSTZo9lpZ+lfIDY/l7JuTbEAC5+4F938rMjNY/sMjgKw5k e+KVWwVaZ/YMElul+kk49VaQNsmtO9Iag31wqfTgLZuwUUJE+HVKBtusAESSzqbi tzE7DAkMKzWp71HGihw/GGP+v7TqkfKslQ16X8RGW2oPNe1P0Vz51mXnupL9/9XB YgiYrGjmOOQ8Bhdfhf4p17n9/PDAlg== =hKF6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 1 17:56:20 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3241131714 for ; Tue, 1 Aug 2017 17:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 j_1whFt0IQsH for ; Tue, 1 Aug 2017 17:56:18 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 15B9812EB8C for ; Tue, 1 Aug 2017 17:56:18 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id v77so8790515pgb.3 for ; Tue, 01 Aug 2017 17:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Spht8q1GevahW9XVXszjlC6KwZBfXXbLOMA+FKYJDrU=; b=VrrhfKCE+UNZE8sWHD8gBw4J3/qZNdR2m97HVnHDBegM4JENkyPHXaE+DA5xcba+AT mAa9A04JRqee1Xgex/Ea4ESHJTf6xlinQ6gAHnVApEYbAdFQsWa7WgP5sfVIuXGNEjcq 8uGPz/goKp0c8STRSqaBjGYndfZ5GfuydNLnx3y1BMzbEz3Oe3mm+NItE9mToWY/MfIc v8txfCd9gPGUlqB6isWKlJjinXuJwTQ8aUDbgNtL9Pt15uu42pM/C/0Fb/W5v2rQ4Qpm xutBAB6nv4wcSIcXG/YgwLeQRzm0dcwImr71qvL7wixLowYkkjrLIcQpToog4BDkbA+T 6yfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Spht8q1GevahW9XVXszjlC6KwZBfXXbLOMA+FKYJDrU=; b=YYd69dW2gl4451RbWuipp3gVC1fPSZx3F7e5301TK0xBAiX5XWjQeHD3L7+vx+5jjZ pBXDcs49pihPjrEdPUUKWC8vKWdWP0QvIzYFjKqUT0jCHZuwDtKJhi9k7QxlVcB/o/gy i6VHCM8HN0+U99h/7+xZIQegpvQR4kxcSuVRG+wNaSgV5hm8mTaRDDkXvPXsTQEE53hH Jhiv1msjvqii3tFZjtQcc9YtRC8aCQ+A+5H2WFzEm5YKYB8EZWtdE48ZVur9hLcqTfzm zTuKnS1xtM0oKfsu8dnMq7Zd9dC8o8/Ctjby5sAE+3OIu+T5x2I5VvvTT11GoXFGGFlU SooQ== X-Gm-Message-State: AIVw1131vtixVwhxWwR2bJjlQMCi4J8zw0B5GZLVIY7q9xxXjcEIxy0D neP1vmXhLwYHFb60gHJtDzluhxPWPXVu X-Received: by 10.84.238.138 with SMTP id v10mr23285806plk.335.1501635377571; Tue, 01 Aug 2017 17:56:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.131 with HTTP; Tue, 1 Aug 2017 17:55:37 -0700 (PDT) In-Reply-To: <9927.1501634533@obiwan.sandelman.ca> References: <3725.1501514462@obiwan.sandelman.ca> <52E1C5A0-FC0E-46A5-9016-AA95FB3DC1CB@fugue.com> <3184.1501522914@obiwan.sandelman.ca> <5A407EA3-AC8B-44A7-8EC2-8242480027FE@fugue.com> <27345.1501546823@obiwan.sandelman.ca> <10182.1501601902@obiwan.sandelman.ca> <6C42A593-3EBC-49BE-9A9F-0CF701FF68BF@fugue.com> <20840.1501620502@obiwan.sandelman.ca> <9927.1501634533@obiwan.sandelman.ca> From: Ted Lemon Date: Tue, 1 Aug 2017 20:55:37 -0400 Message-ID: To: Michael Richardson Cc: HOMENET Content-Type: multipart/alternative; boundary="f403045ff902433bff0555babbde" Archived-At: Subject: Re: [homenet] Ted's security talk at IETF99: DNCP Security X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 00:56:19 -0000 --f403045ff902433bff0555babbde Content-Type: text/plain; charset="UTF-8" OK. So I think the comparison with me and my printer is probably a red herring. :) What I was getting at when talking about Christian's work is that the process of validating the initial leap of faith for homenet could be similar to the process that Christian is using for validating the pairing process in private service discovery. On Tue, Aug 1, 2017 at 8:42 PM, Michael Richardson wrote: > > Ted Lemon wrote: > > So what you're saying is ephemeral is the keying used for the initial > > exchange? > > yes, it's probably more about authenticating the initial (DH/TLS/etc.) > exchange. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --f403045ff902433bff0555babbde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK. =C2=A0 So I think the comparison with me and my printe= r is probably a red herring. :)

What I was getting at wh= en talking about Christian's work is that the process of validating the= initial leap of faith for homenet could be similar to the process that Chr= istian is using for validating the pairing process in private service disco= very.

= On Tue, Aug 1, 2017 at 8:42 PM, Michael Richardson <mcr+ietf@sandelman= .ca> wrote:

Ted Lemon <mellon@fugue.com> = wrote:
=C2=A0 =C2=A0 > So what you're saying is ephemeral is the keying use= d for the initial
=C2=A0 =C2=A0 > exchange?

yes, it's probably more about authenticating the initial (DH/TLS= /etc.) exchange.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




--f403045ff902433bff0555babbde-- From nobody Tue Aug 1 20:21:20 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F7C127201 for ; Tue, 1 Aug 2017 20:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mathemainzel.info 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 JkOy6nGqNdOy for ; Tue, 1 Aug 2017 20:21:16 -0700 (PDT) Received: from mx10lb.world4you.com (mx10lb.world4you.com [81.19.149.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC646124B09 for ; Tue, 1 Aug 2017 20:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mathemainzel.info; s=dkim11; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Ty5ba0tmRZegz5uHuSc2kRtXF9n7gUL6lyBMB91wmUY=; b=snqqhKGL21ZFBi0DBlPL/RUTrIDJ0kY4E1i0arJe0cbvf39nu6Nv4l9blBYgYanKp5VqwLqbJJA14zaDR7ZOubog2QXABEZw4EBrYytMAXlqO+/4IhFu9cOvsQdc3vkCaN6/ISNQSJuM7sTuVRGBFU198UQ9Q3q0Ds1F+hJOBHI=; Received: from [90.146.55.206] (helo=home.mail) by mx10lb.world4you.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dckDW-0006IL-Bf; Wed, 02 Aug 2017 05:21:02 +0200 Message-ID: <5981451D.8080609@mathemainzel.info> Date: Wed, 02 Aug 2017 05:21:01 +0200 From: "Walter H." Organization: Home User-Agent: Mozilla/5.0 (UNIX; U; Cray X-MP/48; en-US; rv:2.70) Gecko/20110929 Communicator/7.20 MIME-Version: 1.0 To: Ted Lemon CC: "homenet@ietf.org" , Juliusz Chroboczek References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> <7ilgn3xkfe.wl-jch@irif.fr> <5980C234.305@mathemainzel.info> <37733D96-1B94-47F4-BF74-E3E5C815823C@fugue.com> <5980CE3E.1030709@mathemainzel.info> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060602080705090505030404" X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 90.146.55.206 X-SA-Exim-Mail-From: Walter.H@mathemainzel.info X-SA-Exim-Scanned: No (on mx10lb.world4you.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 03:21:19 -0000 This is a cryptographically signed message in MIME format. --------------ms060602080705090505030404 Content-Type: multipart/alternative; boundary="------------090100070806040303080008" This is a multi-part message in MIME format. --------------090100070806040303080008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01.08.2017 21:21, Ted Lemon wrote: > On Aug 1, 2017, at 2:53 PM, Walter H. > wrote: >> is there a problem, to have the organization that has the delegation=20 >> of ".home.arpa." also provide such SSL certificates >> signed by an intermediate that got signed by any CA? > > This is not how PKI works. wrong exact this is it; a PKI has at least a root CA and end entity=20 certificates, and of course I never mentioned this, the browser does=20 validate checks - either CRL or OCSP, and all this is meant by running a = own PKI .... and this is not everyones thing to have this configured ... --------------090100070806040303080008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01.08.2017 21:21, Ted Lemon wrote:
On Aug 1, 2017, at 2:53 PM, Walter H. <Walter.H@mathemainzel.info> wrote:
is there a problem, to have the organization that has the delegation of ".home.arpa." also provide such SSL certificates 
signed by an intermediate that got signed by any CA?

This is not how PKI works. 
wrong exact this is it; a PKI has at least a root CA and end entity certificates, and of course I never mentioned this, the browser does validate checks - either CRL or OCSP, and all this is meant by running a own PKI ....
and this is not everyones thing to have this configured ...
--------------090100070806040303080008-- --------------ms060602080705090505030404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKBDCC BOgwggPQoAMCAQICDkgbagkTvYAkyl0i8BTzMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsT F0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQD EwpHbG9iYWxTaWduMB4XDTE2MDYxNTAwMDAwMFoXDTI0MDYxNTAwMDAwMFowXTELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24g UGVyc29uYWxTaWduIDIgQ0EgLSBTSEEyNTYgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALaWaJNl/SwB7GKjDVS/i8ukQ5Gimq+xg/K1bW/Z8OrczxZ71xnjhAOF+cYf cI8fbEnFaRkecJE4NX4CSF05axhEpmqlyHT0XfWEPmMfcUSCCD7tyaf26W4mQSmAyUm6/9l2 oKO7G/Z530so00p7nFHCD2VQoZ+oSp3lRgSNg0/cssg9z5ghCZhMwPGPeqk/NyZlR9hmj0km wsNAvmY9bP86rSlG8BOc4fLrmaeLwtNfUG2iDm/HBpc4L06hjkcCtIMA2KTjukEHYOXdN1ry B8E7p5yXaC6376lINrzpaaiZqkfpx/ZR0vmxLLbFSbWYnlNT2vty83wP+HE+1wP6Z8MCAwEA AaOCAbUwggGxMA4GA1UdDwEB/wQEAwIBBjBqBgNVHSUEYzBhBggrBgEFBQcDAgYIKwYBBQUH AwQGCCsGAQUFBwMJBgorBgEEAYI3FAICBgorBgEEAYI3CgMEBgkrBgEEAYI3FQYGCisGAQQB gjcKAwwGCCsGAQUFBwMHBggrBgEFBQcDETASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQW BBRpcoJiMWeVRIV3kYDEBDZJnXsLYTAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0b vDA+BggrBgEFBQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWdu LmNvbS9yb290cjMwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNv bS9yb290LXIzLmNybDBnBgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEG CSsGAQQBoDIBXzA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9y ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAqJ3NMsx8Z+ILUNelXHCjZuIl7+q0tlMw bocSN1wz4sIoVuOTvUWV81jYFXFM8+SCiRS+/qXMR73rBlSCPua/vvXqiPV5xCgiC4x69g4L 4yquSZoOm8In8my2G1VKAbYZ4WhQdFi8EkUYT67eXhsTMOdVJjSAov4UigSrB4RhUhGiUAC2 cuBy9BFnbhOiC2AI1+gUl0Q7RxXlD3XW+On+R3+a8yExi7J/QSKaDla4EvO/DuCZ31FkItvc gX5++R2o4nxbzwvrqp/q3FZ766S4LCzmBv+uJFl/xUR/PpoVXvpnEl98bFKXMSvavby01ba6 FP8iVJhAuDnB+XULGxwaozCCBRQwggP8oAMCAQICDDf7Me/cd27Vi+FlDzANBgkqhkiG9w0B AQsFADBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UE AxMqR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczMB4XDTE3MDQy NDEwNDQxOFoXDTIwMDQyNDEwNDQxOFowVTELMAkGA1UEBhMCQVQxGzAZBgNVBAMTEldhbHRl ciBIb2VobGh1Ym1lcjEpMCcGCSqGSIb3DQEJARYad2FsdGVyLmhAbWF0aGVtYWluemVsLmlu Zm8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDROn0wc2eBzHcRoKiSnUFz1H4T SN5QEKhssd+B8F0YMDxEzXyvnOeCLAN+8+ui/fyZ0g1A8qgWIGkerNeJJgVes9Xf5EpemE5b zksNPIoVQVB7sBfWezlJ6E12FUNssdLdcQlVqNtFnHtfZV0SD0BS87mW5GL75Ay8XpSkwwTV 6XpIAcKRyd7EFCw+7g2Udp/ZAjPZ4X7oZl8sFFlOClPvWu8LCjbnDcWHpE93QeXnmMx86LQg tACrTy1PDX0yAOeCTan6F3sX0tz5Cp8sWduQiMaKof8yxW/t2V7BJwXhZhiDhax3y/AFREOH NC5dJ2w1sFiwidK7sljogU7/orGHAgMBAAGjggHaMIIB1jAOBgNVHQ8BAf8EBAMCBaAwgZ4G CCsGAQUFBwEBBIGRMIGOME0GCCsGAQUFBzAChkFodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24u Y29tL2NhY2VydC9nc3BlcnNvbmFsc2lnbjJzaGEyZzNvY3NwLmNydDA9BggrBgEFBQcwAYYx aHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL2dzcGVyc29uYWxzaWduMnNoYTJnMzBMBgNV HSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxz aWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NwZXJzb25hbHNpZ24yc2hhMmczLmNybDAlBgNVHREE HjAcgRp3YWx0ZXIuaEBtYXRoZW1haW56ZWwuaW5mbzAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwHQYDVR0OBBYEFOQybe9sZCmROEwJqrOUU1qsTrgqMB8GA1UdIwQYMBaAFGly gmIxZ5VEhXeRgMQENkmdewthMA0GCSqGSIb3DQEBCwUAA4IBAQBY5Zn+1HTT58xtZQgu1IcN UI9t2PC0ps6sELyN3eCBvqYiqk5D8J58hNl9j0hnht5oM0aKVgTL1GNFu6J9DDd3Bk2sNmG6 8uIvo0NsJAFk23lMzKt+YOm3C6+oveuxICFhHeiTxn9z2jLfU+xYLg8UXpSl5U6m0uZcVoLA YYYhLgpaSM8jNYgAv8U2NVK+f8hd4AVEpwyF2edKbZTAdj/iDmjmOm9lkUIzacemNR8DRxiD Eb2XTZa5pcrsPOe1bisJ5wcHoIx+217fm8WJF7Vk2amB9fg8AM3cGU7V7D2Ynbg5tJdV5Et6 ff+sk9Fv1HRaFDqKQVorlDY1P5h1HsoxMYIDYTCCA10CAQEwbTBdMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczAgw3+zHv3Hdu1YvhZQ8wCQYFKw4DAhoFAKCCAckw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwODAyMDMyMTAx WjAjBgkqhkiG9w0BCQQxFgQU+Z65f56tC8gAASKo//44c/0VjGEwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB8BgkrBgEEAYI3EAQx bzBtMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYDVQQD EypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0gRzMCDDf7Me/cd27V i+FlDzB+BgsqhkiG9w0BCRACCzFvoG0wXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2Jh bFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBT SEEyNTYgLSBHMwIMN/sx79x3btWL4WUPMA0GCSqGSIb3DQEBAQUABIIBAB5LVnDNUZHDgoce xpTmaAj1ZM1MO6IyyHNWZx68ANbsjvaKK9fjfsrREEu54MFqetmVtFEl7GmwWWFPTU7+4/AP h5e5wzx8MBCqGhJQfPy2bTOQ9VjtGIixxlTVt6saSoUwi8WtTWsYzaixqbEG9iusmidBsGN/ /uAMIMdgufABYQTKzffUKm5AsbjeqRTyYEwlmlcELnE2t96we8diY0rtlyV1tOUKKQo+XB2z 4uu4iv0Ud5PC28oFyKwBSvLWwdYWitmYrPGhbJgCx4Wx01NzAmrGVSuJUpPdIksevSwrdYPQ ZvlNrGwrVKbATcxifDR7ztoMl1eHPc34ZuWMAZkAAAAAAAA= --------------ms060602080705090505030404-- From nobody Wed Aug 2 00:05:24 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB243131CA1 for ; Wed, 2 Aug 2017 00:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 S3FuE9ees6Nd for ; Wed, 2 Aug 2017 00:05:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4ED131C9C for ; Wed, 2 Aug 2017 00:05:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B313F2009E; Wed, 2 Aug 2017 03:07:10 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2F3A88076D; Wed, 2 Aug 2017 03:05:20 -0400 (EDT) From: Michael Richardson To: Ted Lemon cc: HOMENET In-Reply-To: References: <3725.1501514462@obiwan.sandelman.ca> <52E1C5A0-FC0E-46A5-9016-AA95FB3DC1CB@fugue.com> <3184.1501522914@obiwan.sandelman.ca> <5A407EA3-AC8B-44A7-8EC2-8242480027FE@fugue.com> <27345.1501546823@obiwan.sandelman.ca> <10182.1501601902@obiwan.sandelman.ca> <6C42A593-3EBC-49BE-9A9F-0CF701FF68BF@fugue.com> <20840.1501620502@obiwan.sandelman.ca> <9927.1501634533@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [homenet] Ted's security talk at IETF99: DNCP Security X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 07:05:22 -0000 --=-=-= Content-Type: text/plain Ted Lemon wrote: > OK. So I think the comparison with me and my printer is probably a red > herring. :) A bit, yes. The part where it's not, is that having established this out of band process (when the discovery was authorized), a secured channel remains, in which one can exchange credentials for next time. It's not TOFU. It's more like, "Trust After First Discovery" or something like that. > What I was getting at when talking about Christian's work is that the process > of validating the initial leap of faith for homenet could be similar to the > process that Christian is using for validating the pairing process in private > service discovery. I agree, exactly. That's the laudry list of processes. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmBea8ACgkQgItw+93Q 3WXnqwgAgi1F90XOgIa4gJ6GP5xQRgO5B28ps6X+zrPObnoRMXCPy8B76E2PMQIm OG1FISiXU1oxC1lr3N4J7EbIl1nNgcuZtA5PJUlHdMWNWktDSglN+wCbB696B9Am HzyN18+ZU3PIRXomb4p5qamW44YSB7Z3J4In02/XSVyyJv9thY8aX1+n3pkOjh2i bkq/CG79Xih35ZarCIUWVjBDMNg4vvwWV1NEqKoQ34ysEnkymorLmVPdtnD/DBlD /MSZxQJqFpC7KKDM1/aFcW4d3sdn4NgPQzRUjEWefJAj9ujY3ahtUx5qF1jE+Zm4 tjo/9GvZXHO9cxwEENpbjj8ZnpTZJg== =/kJl -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 2 06:07:53 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13328132085 for ; Wed, 2 Aug 2017 06:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mathemainzel.info 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 BILjKX54pi2h for ; Wed, 2 Aug 2017 06:07:47 -0700 (PDT) Received: from mx07lb.world4you.com (mx07lb.world4you.com [81.19.149.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FA613200D for ; Wed, 2 Aug 2017 06:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mathemainzel.info; s=dkim11; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=GmA2sJWXBFRlcUA6JrkBgEkgyZ6z8rDyCg4ipfRwps4=; b=KPsw6dMcAVD4X4LYSg8J085yUkR7NPJn7ehw9poRiNpeXvybbC4ryhoBzS/Cyl3FvQqmi8vh9feYCGy0RhaH74+mJATMNcrn+lF48MHB5AueLnY2tDAORkiS4kXENLZqNOZ6S9h353a3TlF0lRtsIlMwTFUyILLMaMKWH0JF/tw=; Received: from [90.146.55.206] (helo=home.mail) by mx07lb.world4you.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dctNH-0005Ab-DU; Wed, 02 Aug 2017 15:07:43 +0200 Message-ID: <5981CE9E.4070301@mathemainzel.info> Date: Wed, 02 Aug 2017 15:07:42 +0200 From: "Walter H." Organization: Home User-Agent: Mozilla/5.0 (UNIX; U; Cray X-MP/48; en-US; rv:2.70) Gecko/20110929 Communicator/7.20 MIME-Version: 1.0 To: Ted Lemon CC: Michael Richardson , "homenet@ietf.org" References: <150127266271.25329.18484770769960144@ietfa.amsl.com> <597F7545.9000702@mathemainzel.info> <757C1755-AD78-43DE-93F0-E3D19BFE6C66@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114DBE4251@GAALPA1MSGUSRBF.ITServices.sbc.com> <3A5D69EE-3F32-4773-90ED-D189E7523D9F@fugue.com> <25096.1501621596@obiwan.sandelman.ca> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000300090408010602030503" X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 90.146.55.206 X-SA-Exim-Mail-From: Walter.H@mathemainzel.info X-SA-Exim-Scanned: No (on mx07lb.world4you.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 13:07:51 -0000 This is a cryptographically signed message in MIME format. --------------ms000300090408010602030503 Content-Type: multipart/alternative; boundary="------------090200080102000303000701" This is a multi-part message in MIME format. --------------090200080102000303000701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 01.08.2017 23:15, Ted Lemon wrote: > I addressed that question in a previous reply. Your home network=20 > does not have the equivalent security to letsencrypt.org=20 > 's certificate signing infrastructure (I hope!!= ). that is not the question, the question is: is it possible to use some=20 self signed certificates without trust anchor installed, in the near futu= re? by the way how would you distinguish between LAN and WAN in an IPv6 world= ? in an IPv4 world it is done by RFC1918 addresses ... > Installing a trust anchor means that trust anchor has signing=20 > authority for any name---there's no way to install one that doesn't. there is a way, look at this one: -----BEGIN CERTIFICATE----- MIIJWTCCCEGgAwIBAgIQeRdKqRQXNv4Vp8qfLP9FiDANBgkqhkiG9w0BAQUFADBv MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF eHRlcm5hbCBDQSBSb290MB4XDTEzMDIwMTAwMDAwMFoXDTIwMDUzMDEwNDgzOFow UjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMScwJQYD VQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDCuISVQi3csKqYk5uz7IOhY8MXkiqBaTqagiht iM997G1mJhTojcR+8DCg3E8OQ3ZajByhxRkwlsR4Srl5sGSwWfF/XaAHGUhWIhjB kDO7toW+EMzI8pAjcLwIbRlIL0AFnUTe6Z0DcIS5406Y/9MKE2oKXbf4EbVBv88m SkA74Z+lZJWFNxXncx/9wq8UdyMY2vHN1Kir1/JbtrqB9wYRBjQtWSbAVZR8nTBP yRp4uvQTS2jOQh+jTUo1Y3O/o1xg/zRA4FEOUCla704OYRUkc8NuXHiPNNDcktr7 gO8E06NVQ6n6aBGaOJbSst2vHA7Eiog7A2PB4wKn+GDFf+FNAgMBAAGjggYMMIIG CDAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUVjpv F6skDOW3MWSwEe3b6iO+XrwwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQEwXgYDVR0lBFcwVQYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYI KwYBBQUHAwQGCCsGAQUFBwMIBgorBgEEAYI3CgMEBgorBgEEAYI3CgMMBgkrBgEE AYI3FQUwFwYDVR0gBBAwDjAMBgoqhkiG+E0BBQFpMEkGA1UdHwRCMEAwPqA8oDqG OGh0dHA6Ly9jcmwudHJ1c3QtcHJvdmlkZXIuY29tL0FkZFRydXN0RXh0ZXJuYWxD QVJvb3QuY3JsMIHCBggrBgEFBQcBAQSBtTCBsjBEBggrBgEFBQcwAoY4aHR0cDov L2NydC50cnVzdC1wcm92aWRlci5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5w N2MwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jcnQudHJ1c3QtcHJvdmlkZXIuY29tL0Fk ZFRydXN0VVROU0dDQ0EuY3J0MCoGCCsGAQUFBzABhh5odHRwOi8vb2NzcC50cnVz dC1wcm92aWRlci5jb20wggQXBgNVHR4EggQOMIIECqCCA9QwC4EJaW50ZWwuY29t MAuCCWFwcHVwLmNvbTAOggxjbG91ZG5wby5vcmcwE4IRZWRhY2FkdG9vbGtpdC5v cmcwC4IJZnRsMTAuY29tMAuCCWloY21zLm5ldDAOggxpbmMtbmVzdC5uZXQwFoIU aW5kaWFlZHVzZXJ2aWNlcy5jb20wDYILaW50ZWwuY28uanAwDYILaW50ZWwuY28u a3IwDYILaW50ZWwuY28udWswC4IJaW50ZWwuY29tMAqCCGludGVsLmZyMAuCCWlu dGVsLm5ldDATghFpbnRlbGFsbGlhbmNlLmNvbTAUghJpbnRlbGFwYWNzdG9yZS5j b20wFoIUaW50ZWxhc3NldGZpbmRlci5jb20wGYIXaW50ZWxiZXR0ZXJ0b2dldGhl ci5jb20wFIISaW50ZWxjaGFsbGVuZ2UuY29tMBOCEWludGVsY2xvdWRzc28uY29t MB6CHGludGVsY29uc3VtZXJlbGVjdHJvbmljcy5jb20wEoIQaW50ZWxjb3JlMjAx MC5ydTAWghRpbnRlbGZlbGxvd3NoaXBzLmNvbTAWghRpbnRlbGh5YnJpZGNsb3Vk LmNvbTAUghJpbnRlbHBvcnRmb2xpby5jb20wDoIMaW50ZWwtcmEuY29tMBSCEmlu dGVsLXJlc2VhcmNoLm5ldDAUghJpbnRlbHJtYXN1cnZleS5jb20wGIIWaW50ZWxz bWFsbGJ1c2luZXNzLmNvbTARgg9teWludGVsZWRnZS5jb20wEYIPbXktbGFwdG9w LmNvLnVrMBKCEG9yaWdpbi1hcHB1cC5jb20wHoIcb3JpZ2luLWludGVncmF0aW9u LWFwcHVwLmNvbTAIggZwYy5jb20wFIIScGN0aGVmdGRlZmVuY2UuY29tMBSCEnBj dGhlZnRkZWZlbnNlLmNvbTAOggxwdmF0cmlhbC5uZXQwGYIXcmVkZWZpbmV5b3Vy bmV0d29yay5jb20wD4INcmV0YWlsLWlhLmNvbTAUghJzZXJ2ZXItaW5zaWdodC5j b20wE4IRdGhlaW50ZWxzdG9yZS5jb20wHYIbdGhyZWFkaW5nYnVpbGRpbmdibG9j a3Mub3JnMBuCGXRodW5kZXJib2x0dGVjaG5vbG9neS5uZXQwIIIedWx0cmFib29r LXNvZnR3YXJlLWNvbnRlc3QuY29tMFCkTjBMMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExFDASBgNVBAcTC1NhbnRhIENsYXJhMRowGAYDVQQKExFJbnRlbCBDb3Jw b3JhdGlvbqEwMAqHCAAAAAAAAAAAMCKHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAMA0GCSqGSIb3DQEBBQUAA4IBAQBYb7/NQwdCE/y40K2BIfKKb++H vCaKfAC9aAwrGWQsEWezqdl5Cqw5XWUAFjtTRm6iprVnmdvov6IlrgSVEQk6L96s tz24vAF0MIBHSFRMoPtrqLiihLf0NOV7ztxSePQxbUJRroe/lKy+lhb7VeV5gmT9 rFA45NzLgSznd2+dmyNcfQQD9AeeftRX4maUTeu1XFxinowtg+ZGFOKhE4D92uCG JxGSK72HF0/LGRhLXozmDdmPfSN2b6T/oLo942031iY46BqcI5LIVh8aGo4A1jOm a5X6gh50Cw+kht8jM3yeNhSzXOKj7Uigjijx10z2wJu09Tyj5ahjoiwIpdX+ -----END CERTIFICATE----- > I mean, honestly, if it were possible to get a CA to just issue=20 > certificates for "www.home.arpa" on request with no validation, I=20 > think that would be a better answer both from a security perspective=20 > and a usability perspective, but it's not a /good/ answer, and I don't = > think it's possible anyway. > exakt this was the intention of my inital thoughts --------------090200080102000303000701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01.08.2017 23:15, Ted Lemon wrote:
I addressed that question in a previous reply.   Your hom= e network does not have the equivalent security to letsen= crypt.org's certificate signing infrastructure (I hope!!).
that is not the question, the question is: is it possible to use some self signed certificates without trust anchor installed, in the near future?
by the way how would you distinguish between LAN and WAN in an IPv6 world?
in an IPv4 world it is done by RFC1918 addresses ...
  Installing a trust anchor means that trust anchor has signing authority for any name—there's no way to install on= e that doesn't.
there is a way, look at this one:
-----BEGIN CERTIFICATE-----
MIIJWTCCCEGgAwIBAgIQeRdKqRQXNv4Vp8qfLP9FiDANBgkqhkiG9w0BAQUFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTEzMDIwMTAwMDAwMFoXDTIwMDUzMDEwNDgzOFow
UjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMScwJQYD
VQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kgQ0EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDCuISVQi3csKqYk5uz7IOhY8MXkiqBaTqagiht
iM997G1mJhTojcR+8DCg3E8OQ3ZajByhxRkwlsR4Srl5sGSwWfF/XaAHGUhWIhjB
kDO7toW+EMzI8pAjcLwIbRlIL0AFnUTe6Z0DcIS5406Y/9MKE2oKXbf4EbVBv88m
SkA74Z+lZJWFNxXncx/9wq8UdyMY2vHN1Kir1/JbtrqB9wYRBjQtWSbAVZR8nTBP
yRp4uvQTS2jOQh+jTUo1Y3O/o1xg/zRA4FEOUCla704OYRUkc8NuXHiPNNDcktr7
gO8E06NVQ6n6aBGaOJbSst2vHA7Eiog7A2PB4wKn+GDFf+FNAgMBAAGjggYMMIIG
CDAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUVjpv
F6skDOW3MWSwEe3b6iO+XrwwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB
Af8CAQEwXgYDVR0lBFcwVQYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYI
KwYBBQUHAwQGCCsGAQUFBwMIBgorBgEEAYI3CgMEBgorBgEEAYI3CgMMBgkrBgEE
AYI3FQUwFwYDVR0gBBAwDjAMBgoqhkiG+E0BBQFpMEkGA1UdHwRCMEAwPqA8oDqG
OGh0dHA6Ly9jcmwudHJ1c3QtcHJvdmlkZXIuY29tL0FkZFRydXN0RXh0ZXJuYWxD
QVJvb3QuY3JsMIHCBggrBgEFBQcBAQSBtTCBsjBEBggrBgEFBQcwAoY4aHR0cDov
L2NydC50cnVzdC1wcm92aWRlci5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5w
N2MwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jcnQudHJ1c3QtcHJvdmlkZXIuY29tL0Fk
ZFRydXN0VVROU0dDQ0EuY3J0MCoGCCsGAQUFBzABhh5odHRwOi8vb2NzcC50cnVz
dC1wcm92aWRlci5jb20wggQXBgNVHR4EggQOMIIECqCCA9QwC4EJaW50ZWwuY29t
MAuCCWFwcHVwLmNvbTAOggxjbG91ZG5wby5vcmcwE4IRZWRhY2FkdG9vbGtpdC5v
cmcwC4IJZnRsMTAuY29tMAuCCWloY21zLm5ldDAOggxpbmMtbmVzdC5uZXQwFoIU
aW5kaWFlZHVzZXJ2aWNlcy5jb20wDYILaW50ZWwuY28uanAwDYILaW50ZWwuY28u
a3IwDYILaW50ZWwuY28udWswC4IJaW50ZWwuY29tMAqCCGludGVsLmZyMAuCCWlu
dGVsLm5ldDATghFpbnRlbGFsbGlhbmNlLmNvbTAUghJpbnRlbGFwYWNzdG9yZS5j
b20wFoIUaW50ZWxhc3NldGZpbmRlci5jb20wGYIXaW50ZWxiZXR0ZXJ0b2dldGhl
ci5jb20wFIISaW50ZWxjaGFsbGVuZ2UuY29tMBOCEWludGVsY2xvdWRzc28uY29t
MB6CHGludGVsY29uc3VtZXJlbGVjdHJvbmljcy5jb20wEoIQaW50ZWxjb3JlMjAx
MC5ydTAWghRpbnRlbGZlbGxvd3NoaXBzLmNvbTAWghRpbnRlbGh5YnJpZGNsb3Vk
LmNvbTAUghJpbnRlbHBvcnRmb2xpby5jb20wDoIMaW50ZWwtcmEuY29tMBSCEmlu
dGVsLXJlc2VhcmNoLm5ldDAUghJpbnRlbHJtYXN1cnZleS5jb20wGIIWaW50ZWxz
bWFsbGJ1c2luZXNzLmNvbTARgg9teWludGVsZWRnZS5jb20wEYIPbXktbGFwdG9w
LmNvLnVrMBKCEG9yaWdpbi1hcHB1cC5jb20wHoIcb3JpZ2luLWludGVncmF0aW9u
LWFwcHVwLmNvbTAIggZwYy5jb20wFIIScGN0aGVmdGRlZmVuY2UuY29tMBSCEnBj
dGhlZnRkZWZlbnNlLmNvbTAOggxwdmF0cmlhbC5uZXQwGYIXcmVkZWZpbmV5b3Vy
bmV0d29yay5jb20wD4INcmV0YWlsLWlhLmNvbTAUghJzZXJ2ZXItaW5zaWdodC5j
b20wE4IRdGhlaW50ZWxzdG9yZS5jb20wHYIbdGhyZWFkaW5nYnVpbGRpbmdibG9j
a3Mub3JnMBuCGXRodW5kZXJib2x0dGVjaG5vbG9neS5uZXQwIIIedWx0cmFib29r
LXNvZnR3YXJlLWNvbnRlc3QuY29tMFCkTjBMMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExFDASBgNVBAcTC1NhbnRhIENsYXJhMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbqEwMAqHCAAAAAAAAAAAMCKHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAMA0GCSqGSIb3DQEBBQUAA4IBAQBYb7/NQwdCE/y40K2BIfKKb++H
vCaKfAC9aAwrGWQsEWezqdl5Cqw5XWUAFjtTRm6iprVnmdvov6IlrgSVEQk6L96s
tz24vAF0MIBHSFRMoPtrqLiihLf0NOV7ztxSePQxbUJRroe/lKy+lhb7VeV5gmT9
rFA45NzLgSznd2+dmyNcfQQD9AeeftRX4maUTeu1XFxinowtg+ZGFOKhE4D92uCG
JxGSK72HF0/LGRhLXozmDdmPfSN2b6T/oLo942031iY46BqcI5LIVh8aGo4A1jOm
a5X6gh50Cw+kht8jM3yeNhSzXOKj7Uigjijx10z2wJu09Tyj5ahjoiwIpdX+
-----END CERTIFICATE-----
I mean, honestly, if it were possible to get a CA to just issue certificates for "www.home.arpa" on request with no validation, I think that would be a better answer both from a security perspective and a usability perspective, but it's not a good answer, and I don't think it's possible anyw= ay.

exakt this was the intention of my inital thoughts
--------------090200080102000303000701-- --------------ms000300090408010602030503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKBDCC BOgwggPQoAMCAQICDkgbagkTvYAkyl0i8BTzMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsT F0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQD EwpHbG9iYWxTaWduMB4XDTE2MDYxNTAwMDAwMFoXDTI0MDYxNTAwMDAwMFowXTELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24g UGVyc29uYWxTaWduIDIgQ0EgLSBTSEEyNTYgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALaWaJNl/SwB7GKjDVS/i8ukQ5Gimq+xg/K1bW/Z8OrczxZ71xnjhAOF+cYf cI8fbEnFaRkecJE4NX4CSF05axhEpmqlyHT0XfWEPmMfcUSCCD7tyaf26W4mQSmAyUm6/9l2 oKO7G/Z530so00p7nFHCD2VQoZ+oSp3lRgSNg0/cssg9z5ghCZhMwPGPeqk/NyZlR9hmj0km wsNAvmY9bP86rSlG8BOc4fLrmaeLwtNfUG2iDm/HBpc4L06hjkcCtIMA2KTjukEHYOXdN1ry B8E7p5yXaC6376lINrzpaaiZqkfpx/ZR0vmxLLbFSbWYnlNT2vty83wP+HE+1wP6Z8MCAwEA AaOCAbUwggGxMA4GA1UdDwEB/wQEAwIBBjBqBgNVHSUEYzBhBggrBgEFBQcDAgYIKwYBBQUH AwQGCCsGAQUFBwMJBgorBgEEAYI3FAICBgorBgEEAYI3CgMEBgkrBgEEAYI3FQYGCisGAQQB gjcKAwwGCCsGAQUFBwMHBggrBgEFBQcDETASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQW BBRpcoJiMWeVRIV3kYDEBDZJnXsLYTAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0b vDA+BggrBgEFBQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWdu LmNvbS9yb290cjMwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNv bS9yb290LXIzLmNybDBnBgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEG CSsGAQQBoDIBXzA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9y ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAqJ3NMsx8Z+ILUNelXHCjZuIl7+q0tlMw bocSN1wz4sIoVuOTvUWV81jYFXFM8+SCiRS+/qXMR73rBlSCPua/vvXqiPV5xCgiC4x69g4L 4yquSZoOm8In8my2G1VKAbYZ4WhQdFi8EkUYT67eXhsTMOdVJjSAov4UigSrB4RhUhGiUAC2 cuBy9BFnbhOiC2AI1+gUl0Q7RxXlD3XW+On+R3+a8yExi7J/QSKaDla4EvO/DuCZ31FkItvc gX5++R2o4nxbzwvrqp/q3FZ766S4LCzmBv+uJFl/xUR/PpoVXvpnEl98bFKXMSvavby01ba6 FP8iVJhAuDnB+XULGxwaozCCBRQwggP8oAMCAQICDDf7Me/cd27Vi+FlDzANBgkqhkiG9w0B AQsFADBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UE AxMqR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczMB4XDTE3MDQy NDEwNDQxOFoXDTIwMDQyNDEwNDQxOFowVTELMAkGA1UEBhMCQVQxGzAZBgNVBAMTEldhbHRl ciBIb2VobGh1Ym1lcjEpMCcGCSqGSIb3DQEJARYad2FsdGVyLmhAbWF0aGVtYWluemVsLmlu Zm8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDROn0wc2eBzHcRoKiSnUFz1H4T SN5QEKhssd+B8F0YMDxEzXyvnOeCLAN+8+ui/fyZ0g1A8qgWIGkerNeJJgVes9Xf5EpemE5b zksNPIoVQVB7sBfWezlJ6E12FUNssdLdcQlVqNtFnHtfZV0SD0BS87mW5GL75Ay8XpSkwwTV 6XpIAcKRyd7EFCw+7g2Udp/ZAjPZ4X7oZl8sFFlOClPvWu8LCjbnDcWHpE93QeXnmMx86LQg tACrTy1PDX0yAOeCTan6F3sX0tz5Cp8sWduQiMaKof8yxW/t2V7BJwXhZhiDhax3y/AFREOH NC5dJ2w1sFiwidK7sljogU7/orGHAgMBAAGjggHaMIIB1jAOBgNVHQ8BAf8EBAMCBaAwgZ4G CCsGAQUFBwEBBIGRMIGOME0GCCsGAQUFBzAChkFodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24u Y29tL2NhY2VydC9nc3BlcnNvbmFsc2lnbjJzaGEyZzNvY3NwLmNydDA9BggrBgEFBQcwAYYx aHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL2dzcGVyc29uYWxzaWduMnNoYTJnMzBMBgNV HSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxz aWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NwZXJzb25hbHNpZ24yc2hhMmczLmNybDAlBgNVHREE HjAcgRp3YWx0ZXIuaEBtYXRoZW1haW56ZWwuaW5mbzAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwHQYDVR0OBBYEFOQybe9sZCmROEwJqrOUU1qsTrgqMB8GA1UdIwQYMBaAFGly gmIxZ5VEhXeRgMQENkmdewthMA0GCSqGSIb3DQEBCwUAA4IBAQBY5Zn+1HTT58xtZQgu1IcN UI9t2PC0ps6sELyN3eCBvqYiqk5D8J58hNl9j0hnht5oM0aKVgTL1GNFu6J9DDd3Bk2sNmG6 8uIvo0NsJAFk23lMzKt+YOm3C6+oveuxICFhHeiTxn9z2jLfU+xYLg8UXpSl5U6m0uZcVoLA YYYhLgpaSM8jNYgAv8U2NVK+f8hd4AVEpwyF2edKbZTAdj/iDmjmOm9lkUIzacemNR8DRxiD Eb2XTZa5pcrsPOe1bisJ5wcHoIx+217fm8WJF7Vk2amB9fg8AM3cGU7V7D2Ynbg5tJdV5Et6 ff+sk9Fv1HRaFDqKQVorlDY1P5h1HsoxMYIDYTCCA10CAQEwbTBdMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczAgw3+zHv3Hdu1YvhZQ8wCQYFKw4DAhoFAKCCAckw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwODAyMTMwNzQy WjAjBgkqhkiG9w0BCQQxFgQUgzj93TfhuJQ2NPTyasUGzL76XRIwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB8BgkrBgEEAYI3EAQx bzBtMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYDVQQD EypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0gRzMCDDf7Me/cd27V i+FlDzB+BgsqhkiG9w0BCRACCzFvoG0wXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2Jh bFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBT SEEyNTYgLSBHMwIMN/sx79x3btWL4WUPMA0GCSqGSIb3DQEBAQUABIIBALIkcVNIOY92pZ6p mzTwWMJVk7v9/JgEZM363slyr470mtimFxISB9nuP22+lFhh7rPK0Ck7h+f7tBRdHQZNDdO/ NHuMgVzfC4R092dojtyJLSA7nybNxaLf318iwDQbsijchAOMYxyATHcfeZzIErrgD/wDp6JE 3Hi4ZP5BTUg3Upa6IhZVgj9wAFHVv/8B6jTLhKrh4fVBNyf6cYo1CXO5OvNQOPTEcPVxC+B7 DPjJhykIAcMjZ6vtKNYkUXSw8mh2mdNcRBRxW2ixckAu04VEAKV0SWsTomNhOuylSWAD/S4p bepCtKxvcnG0FnZ9ZgiqpuJw+DQ/pr5IMeePjzYAAAAAAAA= --------------ms000300090408010602030503-- From nobody Tue Aug 8 15:31:55 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38216126B71; Tue, 8 Aug 2017 15:31:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: homenet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150223150804.3668.14190745110025046639@ietfa.amsl.com> Date: Tue, 08 Aug 2017 15:31:48 -0700 Archived-At: Subject: [homenet] I-D Action: draft-ietf-homenet-dot-11.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 22:31:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking WG of the IETF. Title : Special Use Domain 'home.arpa.' Authors : Pierre Pfister Ted Lemon Filename : draft-ietf-homenet-dot-11.txt Pages : 9 Date : 2017-08-08 Abstract: This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.', and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-homenet-dot-11 https://datatracker.ietf.org/doc/html/draft-ietf-homenet-dot-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dot-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 8 15:33:40 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39858126CB6 for ; Tue, 8 Aug 2017 15:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 oA6G2R-GEHpe for ; Tue, 8 Aug 2017 15:33:36 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 418A71241FC for ; Tue, 8 Aug 2017 15:33:36 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id u139so27186383qka.1 for ; Tue, 08 Aug 2017 15:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YMiW4+7p5DnT6hYuPXbnTjXzZhTGwbEeK4fBheyYExM=; b=1Zu1sV3qYzwd3dGp+jqHs1PQtCi5VnoqfAoihm+LdDq/t9sO4U7Ebx4TOrYgScuDMT jbbgZ3jynOBKmPYEX4OR6Midm6rQwNkglIvf8atfYdArEiz9sf4MPaXktm6ZcHjH1/YZ Jxi879nPfhc0TWpNqCE+0MfrFXctv2pcYS188O5OrfCu1M4pR6Iyf0OrEflF89D9ie4F ie5wkZ7Pqx0O3Trr9eJ+Z98FGsWzHwJoiECS6+oc4i1kVgEJzqgTf/IA1uadpFHnIWMg TAmQLOMAMQbjqOLItxCVJ/ukbvHOJRBDOO9znu8zkdm1jgxZShuFWjRmbDlubjKiAVwJ eBfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YMiW4+7p5DnT6hYuPXbnTjXzZhTGwbEeK4fBheyYExM=; b=rhz78aFGXijq9UOscw4OXNCnX/24JbA7k0UspQvTnC2/rbHUFG1KE1K/0LMnAoFo+X 6Cad7v7lkezSOPqmXN5c3/tbhgQke3AbPPgn44lIfFuTaT4S8YBC4TIX6JTlo2uHpZZM 4W4lwVEkdPeSdfYqdVAOtIhmV0cuwpsQMcU+FgMK58dSCv5H2aJjYR2hAQaTWd+vhAMi 6HvNVPdSUAdBS2k7Jx5mXRSaRCsHQ8gYxTnjljZ6NpUwM6NCOcw6qgfjGpPuWJSHtrIz RPWX3CPeIcbS4cPirO8U9yG5FGo3MAqeGxlHD+Qo2k8QZLGxSMhP9rnWdy0XeObKgJFV Rkcw== X-Gm-Message-State: AHYfb5i/G7ds7/RvdTItzc9La5HaoE+04FlHR+AEaWBFxOnF9Wlozr5r n6ea5uxYg7fjHQvCKqBSXQ== X-Received: by 10.55.5.132 with SMTP id 126mr7713454qkf.191.1502231615167; Tue, 08 Aug 2017 15:33:35 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id f187sm1087382qkb.97.2017.08.08.15.33.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Aug 2017 15:33:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <150223150804.3668.14190745110025046639@ietfa.amsl.com> Date: Tue, 8 Aug 2017 18:33:33 -0400 Cc: Mark Andrews , Warren Kumari Content-Transfer-Encoding: quoted-printable Message-Id: <79597E4D-DEC0-4622-A410-003B45EB5E6A@fugue.com> References: <150223150804.3668.14190745110025046639@ietfa.amsl.com> To: HOMENET X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-11.txt (FINAL?) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 22:33:38 -0000 I updated homenet-dot with the change that Mark requested regarding = signed, unsigned and insecure delegations. I believe the text is = correct now, but would appreciate a sanity check. Otherwise, I think = it's up to the chairs to make the next move. From nobody Tue Aug 8 20:17:30 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A42E124B09 for ; Tue, 8 Aug 2017 20:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 fHSTBl1Nb-gt for ; Tue, 8 Aug 2017 20:17:28 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4946A131CB6 for ; Tue, 8 Aug 2017 20:17:28 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 1C5AF34C26C; Wed, 9 Aug 2017 03:17:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DBD8716007B; Wed, 9 Aug 2017 03:17:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BED2116007C; Wed, 9 Aug 2017 03:17:24 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FOvFNj_pw5Is; Wed, 9 Aug 2017 03:17:24 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 60E5616007B; Wed, 9 Aug 2017 03:17:24 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 28F8F81C6FC7; Wed, 9 Aug 2017 13:17:22 +1000 (AEST) To: Ted Lemon Cc: HOMENET , Warren Kumari From: Mark Andrews References: <150223150804.3668.14190745110025046639@ietfa.amsl.com> <79597E4D-DEC0-4622-A410-003B45EB5E6A@fugue.com> In-reply-to: Your message of "Tue, 08 Aug 2017 18:33:33 -0400." <79597E4D-DEC0-4622-A410-003B45EB5E6A@fugue.com> Date: Wed, 09 Aug 2017 13:17:22 +1000 Message-Id: <20170809031722.28F8F81C6FC7@rock.dv.isc.org> Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-11.txt (FINAL?) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 03:17:30 -0000 In message <79597E4D-DEC0-4622-A410-003B45EB5E6A@fugue.com>, Ted Lemon writes: > I updated homenet-dot with the change that Mark requested regarding > signed, unsigned and insecure delegations. I believe the text is > correct now, but would appreciate a sanity check. Otherwise, I think > it's up to the chairs to make the next move. I would explictly list DS home.arpa as a exception. (I had to file a bug report against recursive server that failed to have this exception this week for AS112 zones. The bug has been fixed.) Also I wouldn't be using '.home.arpa.' as we also want to stop queries for 'home.arpa' leaving the home. There are a couple of references to '.home.arpa'. e.g. Old: DNS queries for names ending with '.home.arpa.' are resolved using local resolvers on the homenet. Such queries MUST NOT be recursively forwarded to servers outside the logical boundaries of the homenet. New: DNS queries for names ending with 'home.arpa.' are resolved using local resolvers on the homenet. Such queries MUST NOT be recursively forwarded to servers outside the logical boundaries of the homenet with the exception of DS lookups for 'home.arpa.'. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Aug 9 08:54:28 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8F51323FB for ; Wed, 9 Aug 2017 08:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 K7DAFFDkXfhJ for ; Wed, 9 Aug 2017 08:54:24 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 F0D541323FD for ; Wed, 9 Aug 2017 08:54:23 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id u185so29705121pgb.1 for ; Wed, 09 Aug 2017 08:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z1+xLIoJaGP6RZFlQg9k2x/PqkixM5OY/VeOC13X4WM=; b=ngGjDRWBaw+sla9W3amWsIacagXHkoNkli+3GkCMj8NXjxYgp9Ck5cmNfATwkC9ntU 8Q8/zJJ2BwIlKwnrObTo841GSL+LNMJENwC5CWE2nwXymHtLTZvhCdOWI6yj7I2sKq66 5XD/9QX3Sm5K80jQ7VJxdDwWu8iKCRWV4DIYTgj61a8bj/YIimXGCEVpdueFr4I7OHHV UEe97W4+Rkfj1XAxqCPApvoUH6G/VSQ4zWEwjkmwXBOZ/NMhN0y8+xXcUDPsTD6qwduG JUTRXB4VG9BseL573lTOrwBkyPIsSDaZMPH+9B+yI5brMAopYr3sr7CH3FRKDz1rrOPI ZpsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z1+xLIoJaGP6RZFlQg9k2x/PqkixM5OY/VeOC13X4WM=; b=AUbqiMvUON+76tZaqM/vg3nBUl0mARBWQwBhSqaA/ZStONNt6UCzp+oN+RZHhaiGvv AuUg+ZiAanhO89RXuVKioG1IoXH4OzXZXWUCJKY3qXtAamPc4e1m5040X39SzwRVvzTh 6J2E1EzjWWSQbm5iEPKu8Gxbyw47CWZ+v5ADCfgGe/KtSiLEsGbqLMIh4PNNdUNUpUV4 g78r/7d9V9GWehU0WgxqtTquxUHU+eYdF0s+BrzCJSilsYqRSYeemX9RgkEnPK8cUj5G jib5r0/49WYd6NFW5ZHHJN9vJmQuxzAK9PwfzD2/1PUiwXmVW7DU9ch1cTIHZGWvjJB1 l/WQ== X-Gm-Message-State: AHYfb5hewNv5FwA0GT0JSRDmf+GZ6x3CPltfuAVfCP/QTUou3k9Q/wyd HAah/enQL+60mD659nVFtgescEhOI36k X-Received: by 10.84.215.210 with SMTP id g18mr9623784plj.210.1502294063428; Wed, 09 Aug 2017 08:54:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.131 with HTTP; Wed, 9 Aug 2017 08:53:42 -0700 (PDT) In-Reply-To: <20170809031722.28F8F81C6FC7@rock.dv.isc.org> References: <150223150804.3668.14190745110025046639@ietfa.amsl.com> <79597E4D-DEC0-4622-A410-003B45EB5E6A@fugue.com> <20170809031722.28F8F81C6FC7@rock.dv.isc.org> From: Ted Lemon Date: Wed, 9 Aug 2017 11:53:42 -0400 Message-ID: To: Mark Andrews Cc: HOMENET , Warren Kumari Content-Type: multipart/alternative; boundary="94eb2c19f1420003e6055654182f" Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-11.txt (FINAL?) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 15:54:27 -0000 --94eb2c19f1420003e6055654182f Content-Type: text/plain; charset="UTF-8" What does forwarding DS lookups for home.arpa out of the homenet do? That is, suppose I implement a cache that doesn't do this: what bad thing happens? It's going to return NXDOMAIN, right? Isn't it the NSEC lookups that have to succeed, and the NS record lookup? And doesn't the NS record have to be forged? I think this actually means that it does have to be an unsigned delegation. Argh. Hm, thinking farther, no, it doesn't, because it's okay to return the right answer for the delegation as long as the stub resolver is willing to rely on the cache, which we've already specified it must do. So what's the failure mode that this new text prevents? Oh, you have to look up the DS record to get the NSEC that validates it? (I'm leaving in all of the stuff I typed while I was thinking this through because I'm not sure I got it right, and you can point out what I got wrong.) On Tue, Aug 8, 2017 at 11:17 PM, Mark Andrews wrote: > > In message <79597E4D-DEC0-4622-A410-003B45EB5E6A@fugue.com>, Ted Lemon > writes: > > I updated homenet-dot with the change that Mark requested regarding > > signed, unsigned and insecure delegations. I believe the text is > > correct now, but would appreciate a sanity check. Otherwise, I think > > it's up to the chairs to make the next move. > > I would explictly list DS home.arpa as a exception. (I had to file > a bug report against recursive server that failed to have this > exception this week for AS112 zones. The bug has been fixed.) Also > I wouldn't be using '.home.arpa.' as we also want to stop queries > for 'home.arpa' leaving the home. There are a couple of references > to '.home.arpa'. > > e.g. > > Old: > DNS queries for names ending with '.home.arpa.' are resolved using > local resolvers on the homenet. Such queries MUST NOT be recursively > forwarded to servers outside the logical boundaries of the homenet. > > New: > DNS queries for names ending with 'home.arpa.' are resolved using > local resolvers on the homenet. Such queries MUST NOT be recursively > forwarded to servers outside the logical boundaries of the homenet with > the exception of DS lookups for 'home.arpa.'. > > Mark > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --94eb2c19f1420003e6055654182f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What does forwarding DS lookups for home.arpa out of the h= omenet do? =C2=A0 That is, suppose I implement a cache that doesn't do = this: what bad thing happens? =C2=A0 It's going to return NXDOMAIN, rig= ht? =C2=A0 Isn't it the NSEC lookups that have to succeed, and the NS r= ecord lookup? =C2=A0 And doesn't the NS record have to be forged?
<= br>
I think this actually means that it does have to be an unsign= ed delegation. =C2=A0 Argh.

Hm, thinking farther, = no, it doesn't, because it's okay to return the right answer for th= e delegation as long as the stub resolver is willing to rely on the cache, = which we've already specified it must do. =C2=A0 So what's the fail= ure mode that this new text prevents?=C2=A0 Oh, you have to look up the DS = record to get the NSEC that validates it?

(I'm= leaving in all of the stuff I typed while I was thinking this through beca= use I'm not sure I got it right, and you can point out what I got wrong= .)

On = Tue, Aug 8, 2017 at 11:17 PM, Mark Andrews <marka@isc.org> wrote= :

In message <79597E4D-DEC0-4622-A410-003B45EB5E6A@fugue.com>, Ted Lemo= n writes:
> I updated homenet-dot with the change that Mark requested regarding > signed, unsigned and insecure delegations.=C2=A0 =C2=A0I believe the t= ext is
> correct now, but would appreciate a sanity check.=C2=A0 =C2=A0Otherwis= e, I think
> it's up to the chairs to make the next move.

I would explictly list DS home.arpa as a exception.=C2=A0 (I ha= d to file
a bug report against recursive server that failed to have this
exception this week for AS112 zones.=C2=A0 The bug has been fixed.)=C2=A0 A= lso
I wouldn't be using '.home.arpa.' as we also want to stop queri= es
for 'home.arpa' leaving the home.=C2=A0 There are a couple of refer= ences
to '.home.arpa'.

e.g.

Old:
=C2=A0 =C2=A0DNS queries for names ending with '.home.arpa.' are re= solved using
=C2=A0 =C2=A0local resolvers on the homenet.=C2=A0 Such queries MUST NOT be= recursively
=C2=A0 =C2=A0forwarded to servers outside the logical boundaries of the hom= enet.

New:
=C2=A0 =C2=A0DNS queries for names ending with 'home.arpa.' are res= olved using
=C2=A0 =C2=A0local resolvers on the homenet.=C2=A0 Such queries MUST NOT be= recursively
=C2=A0 =C2=A0forwarded to servers outside the logical boundaries of the hom= enet with
=C2=A0 =C2=A0the exception of DS lookups for 'home.arpa.'.

Mark

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0INTERNET: marka@isc.org

--94eb2c19f1420003e6055654182f-- From nobody Wed Aug 9 11:37:11 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAEE132443 for ; Wed, 9 Aug 2017 11:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VbHZESSTQXYA for ; Wed, 9 Aug 2017 11:36:57 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 D1628132452 for ; Wed, 9 Aug 2017 11:36:56 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id m86so31608656lfi.4 for ; Wed, 09 Aug 2017 11:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MdvQGmj+45FsFTWFg2+fdrofs+/7LzZruRdnTEqtWgg=; b=mHi/EXQ8k6V8TTpge+IwgMnG4nLFBsh+GBsIN+bQuEvFh6tGyWIkJnPESzzPGXY/v6 1SpD+buFXGhTT0UF8AnhLoFoII5Dq1M1IsKFUSLjv04sx/ZLKEhEVHnZGUMIAulMo4xp 3aPVm3912JqggdYlqBIoa1YO5A0Bp9LLaN+wZjIXaOrfbF/0/RqxZX4u79pWHl7R+qRf 6OqtG7nJKrAg1eA9pAwIIvyGKtPk9xA4BTgVpGRYvF/IfLCySmq1YBrBujLTaOLkTKZ/ /tX58Pk79rM8Zcmeko0hdc1GxdoriE4ShS+KC3UwgvXyBq1P5LghCC0jUHvu+BAkoPO9 B0sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MdvQGmj+45FsFTWFg2+fdrofs+/7LzZruRdnTEqtWgg=; b=iF74Zyke+3jPBGGIZ283DZm+rDQS8+0rE57oE/mwR7hH6FK5NwGHwUp3JHmtSj2RNW kID4DVPOV6yUOnAPFG6WSlSTcvxdoFyHO/OGHxbkv25ZV6CysWA5cTJ5zqgESeeUH6Xl nqJawyDv8Gk5lfMX14nXShPFURtft4CVWUz1Wq7uyPAd6xfcIgT2W8GmWpujBYfb1V1d vxtI8tZ8Dgwc2lMK+eRKcLFgWp+nfl3vEQuj4sn13x9K793yV5REeU15iVCA9ORpbBN6 4hj53kAxZqopT9K7ftRj+GD1lmYsCemTvYpwPV11xtHt10ZacY/lXGCQlLvAmvAZHdA1 RcAQ== X-Gm-Message-State: AHYfb5gIvN+XhSBG7JTe86Kna4op0MZu2C/RhcOcofcd6xNB2ywY5s8X 9I7ORUIwNiNMkzC8e+vCPeN0QB5meQ== X-Received: by 10.25.193.18 with SMTP id r18mr3514577lff.49.1502303815139; Wed, 09 Aug 2017 11:36:55 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.97.18 with HTTP; Wed, 9 Aug 2017 11:36:54 -0700 (PDT) In-Reply-To: <19178.1501510069@obiwan.sandelman.ca> References: <150124709279.25258.15094387920433065465.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DBE0147@GAALPA1MSGUSRBF.ITServices.sbc.com> <12743.1501435181@obiwan.sandelman.ca> <6265.1501464056@obiwan.sandelman.ca> <19178.1501510069@obiwan.sandelman.ca> From: Daniel Migault Date: Wed, 9 Aug 2017 14:36:54 -0400 X-Google-Sender-Auth: NkTRAGAWmKYLCNS4TRKrfhZKriQ Message-ID: To: Michael Richardson Cc: "homenet@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1a1ca23f06d10556565d34" Archived-At: Subject: Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued" X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 18:37:02 -0000 --94eb2c1a1ca23f06d10556565d34 Content-Type: text/plain; charset="UTF-8" Hi, I apology for the late response (I was off for two weeks). I will update the draft by the end of the month integrating numerous feed backs we received. As a co-author I am supporting the adoption of this document architecture. I believe that given the current situation regarding homenet and naming, the simple but useful scope of the draft will help the WG to move forward regarding naming and home network. I agree the document is not yet in a final version and feed back from the WG will be very helpful. That said I think, since last IETF, we have a pretty good view on where we are going. Yours, Daniel On Mon, Jul 31, 2017 at 10:07 AM, Michael Richardson wrote: > Ted Lemon wrote: > > to put the CFA on hold pending that update. There have been some good > > comments already, though; in particular, I think Juliusz' point that > it > > would > > be nice to actually try some of this in practice is good, and is what > > I'm > > We require interoperable implementations for Internet Standard, not to > adopt > a document. Implementation reports would be good for WGLC, not here! > We need to lower the bar here, not raise it. WGs can abandon documents > too. > > > That said, what I said in the working group is that we've been > spinning > > our wheels on this for several years, and I wanted to know if the > scope > > of this is reasonable and is what the working group wants to take > > on. If it's not, > > then I don't actually know how to proceed. > > I think that it's the right approach, and given the sort out of the MVDP, > I support adoption. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --94eb2c1a1ca23f06d10556565d34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I apology for the la= te response (I was off for two weeks). I will update the draft by the end o= f the month integrating numerous feed backs we received.

As a = co-author I am supporting the adoption of this document architecture. I bel= ieve that given the current situation regarding homenet and naming, the sim= ple but useful scope of the draft will help the WG to move forward regardin= g naming and home network. I agree the document is not yet in a final versi= on and feed back from the WG will be very helpful. That said I think, since= last IETF, we have a pretty good view on where we are going.

= Yours,
Daniel




=

On Mon, Jul 31, 2017 at 10:07 AM, Michael Richardson <= ;mcr@sandelman.ca= > wrote:
Ted L= emon <mellon@fugue.com> wrote= :
=C2=A0 =C2=A0 > to put the CFA on hold pending that update. There have b= een some good
=C2=A0 =C2=A0 > comments already, though; in particular, I think Juliusz= ' point that it
=C2=A0 =C2=A0 > would
=C2=A0 =C2=A0 > be nice to actually try some of this in practice is good= , and is what
=C2=A0 =C2=A0 > I'm

We require interoperable implementations for Internet Standard, not = to adopt
a document.=C2=A0 Implementation reports would be good for WGLC, not here!<= br> We need to lower the bar here, not raise it.=C2=A0 WGs can abandon document= s too.

=C2=A0 =C2=A0 > That said, what I said in the working group is that we&#= 39;ve been spinning
=C2=A0 =C2=A0 > our wheels on this for several years, and I wanted to kn= ow if the scope
=C2=A0 =C2=A0 > of this is reasonable and is what the working group want= s to take
=C2=A0 =C2=A0 > on. If it's not,
=C2=A0 =C2=A0 > then I don't actually know how to proceed.

I think that it's the right approach, and given the sort out of = the MVDP,
I support adoption.

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 | network architect=C2=A0 [
]=C2=A0 =C2=A0 =C2=A0mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0ruby on rails=C2=A0 =C2=A0 [

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet<= br>

--94eb2c1a1ca23f06d10556565d34-- From nobody Wed Aug 9 14:36:05 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81DB132339 for ; Wed, 9 Aug 2017 14:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 mPnqYwUzGSIP for ; Wed, 9 Aug 2017 14:36:02 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4CC132191 for ; Wed, 9 Aug 2017 14:36:02 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v79LZXs5024404; Wed, 9 Aug 2017 17:35:56 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2c89asj92c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Aug 2017 17:35:56 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v79LZs93005262; Wed, 9 Aug 2017 17:35:55 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v79LZl6O005033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Aug 2017 17:35:48 -0400 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 9 Aug 2017 21:35:40 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0319.002; Wed, 9 Aug 2017 17:35:40 -0400 From: "STARK, BARBARA H" To: Daniel Migault , Michael Richardson CC: "homenet@ietf.org" Thread-Topic: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued" Thread-Index: AQHTB6IeRf3yCgeiyk681hmkEW8nh6JpNx+QgAOsuYCAACnQAIAAXKYAgACPGoCAAEcqgIAOcCkA///t6gA= Date: Wed, 9 Aug 2017 21:35:39 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBED1F8@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <150124709279.25258.15094387920433065465.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DBE0147@GAALPA1MSGUSRBF.ITServices.sbc.com> <12743.1501435181@obiwan.sandelman.ca> <6265.1501464056@obiwan.sandelman.ca> <19178.1501510069@obiwan.sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.193.159] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114DBED1F8GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708090336 Archived-At: Subject: Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued" X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 21:36:05 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114DBED1F8GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIERhbmllbC4gQW5kIHlvdeKAmXJlIG5vdCB0b28gbGF0ZS4gVGhlIGNhbGwgZW5kcyB0 aGlzIGNvbWluZyBGcmlkYXkuIFNvIGlmIGFueW9uZSBlbHNlIHdhbnRzIHRvIGNoaW1lIGluLCBw bGVhc2UgZG8uIEnigJlsbCB0cnkgdG8gY3JlYXRlIGEgc3VtbWFyeSBUaHVyc2RheSBkZXNjcmli aW5nIHdoYXQgSSB0aGluayBJ4oCZdmUgaGVhcmQgc28gZmFyLiBUaGF0IHNob3VsZCBnaXZlIGV2 ZXJ5b25lIGEgYnJpZWYgY2hhbmNlIHRvIHRlbGwgbWUgaG93IGJhZGx5IEnigJl2ZSBtaXNpbnRl cnByZXRlZCB0aGVpciBzdGF0ZW1lbnRzIGJlZm9yZSB0aGUgY2FsbCBlbmRzLg0KQmFyYmFyYQ0K DQpGcm9tOiBob21lbmV0IFttYWlsdG86aG9tZW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgRGFuaWVsIE1pZ2F1bHQNClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDA5LCAyMDE3IDI6 MzcgUE0NClRvOiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jckBzYW5kZWxtYW4uY2E+DQpDYzogaG9t ZW5ldEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtob21lbmV0XSBUaGUgSE9NRU5FVCBXRyBoYXMg cGxhY2VkIGRyYWZ0LXRsZG0tc2ltcGxlLWhvbWVuZXQtbmFtaW5nIGluIHN0YXRlICJDYWxsIEZv ciBBZG9wdGlvbiBCeSBXRyBJc3N1ZWQiDQoNCkhpLA0KSSBhcG9sb2d5IGZvciB0aGUgbGF0ZSBy ZXNwb25zZSAoSSB3YXMgb2ZmIGZvciB0d28gd2Vla3MpLiBJIHdpbGwgdXBkYXRlIHRoZSBkcmFm dCBieSB0aGUgZW5kIG9mIHRoZSBtb250aCBpbnRlZ3JhdGluZyBudW1lcm91cyBmZWVkIGJhY2tz IHdlIHJlY2VpdmVkLg0KQXMgYSBjby1hdXRob3IgSSBhbSBzdXBwb3J0aW5nIHRoZSBhZG9wdGlv biBvZiB0aGlzIGRvY3VtZW50IGFyY2hpdGVjdHVyZS4gSSBiZWxpZXZlIHRoYXQgZ2l2ZW4gdGhl IGN1cnJlbnQgc2l0dWF0aW9uIHJlZ2FyZGluZyBob21lbmV0IGFuZCBuYW1pbmcsIHRoZSBzaW1w bGUgYnV0IHVzZWZ1bCBzY29wZSBvZiB0aGUgZHJhZnQgd2lsbCBoZWxwIHRoZSBXRyB0byBtb3Zl IGZvcndhcmQgcmVnYXJkaW5nIG5hbWluZyBhbmQgaG9tZSBuZXR3b3JrLiBJIGFncmVlIHRoZSBk b2N1bWVudCBpcyBub3QgeWV0IGluIGEgZmluYWwgdmVyc2lvbiBhbmQgZmVlZCBiYWNrIGZyb20g dGhlIFdHIHdpbGwgYmUgdmVyeSBoZWxwZnVsLiBUaGF0IHNhaWQgSSB0aGluaywgc2luY2UgbGFz dCBJRVRGLCB3ZSBoYXZlIGEgcHJldHR5IGdvb2QgdmlldyBvbiB3aGVyZSB3ZSBhcmUgZ29pbmcu DQpZb3VycywNCkRhbmllbA0KDQoNCg0KT24gTW9uLCBKdWwgMzEsIDIwMTcgYXQgMTA6MDcgQU0s IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyQHNhbmRlbG1hbi5jYTxtYWlsdG86bWNyQHNhbmRlbG1h bi5jYT4+IHdyb3RlOg0KVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPG1haWx0bzptZWxsb25A ZnVndWUuY29tPj4gd3JvdGU6DQogICAgPiB0byBwdXQgdGhlIENGQSBvbiBob2xkIHBlbmRpbmcg dGhhdCB1cGRhdGUuIFRoZXJlIGhhdmUgYmVlbiBzb21lIGdvb2QNCiAgICA+IGNvbW1lbnRzIGFs cmVhZHksIHRob3VnaDsgaW4gcGFydGljdWxhciwgSSB0aGluayBKdWxpdXN6JyBwb2ludCB0aGF0 IGl0DQogICAgPiB3b3VsZA0KICAgID4gYmUgbmljZSB0byBhY3R1YWxseSB0cnkgc29tZSBvZiB0 aGlzIGluIHByYWN0aWNlIGlzIGdvb2QsIGFuZCBpcyB3aGF0DQogICAgPiBJJ20NCg0KV2UgcmVx dWlyZSBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyBmb3IgSW50ZXJuZXQgU3RhbmRhcmQs IG5vdCB0byBhZG9wdA0KYSBkb2N1bWVudC4gIEltcGxlbWVudGF0aW9uIHJlcG9ydHMgd291bGQg YmUgZ29vZCBmb3IgV0dMQywgbm90IGhlcmUhDQpXZSBuZWVkIHRvIGxvd2VyIHRoZSBiYXIgaGVy ZSwgbm90IHJhaXNlIGl0LiAgV0dzIGNhbiBhYmFuZG9uIGRvY3VtZW50cyB0b28uDQoNCiAgICA+ IFRoYXQgc2FpZCwgd2hhdCBJIHNhaWQgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdGhhdCB3ZSd2 ZSBiZWVuIHNwaW5uaW5nDQogICAgPiBvdXIgd2hlZWxzIG9uIHRoaXMgZm9yIHNldmVyYWwgeWVh cnMsIGFuZCBJIHdhbnRlZCB0byBrbm93IGlmIHRoZSBzY29wZQ0KICAgID4gb2YgdGhpcyBpcyBy ZWFzb25hYmxlIGFuZCBpcyB3aGF0IHRoZSB3b3JraW5nIGdyb3VwIHdhbnRzIHRvIHRha2UNCiAg ICA+IG9uLiBJZiBpdCdzIG5vdCwNCiAgICA+IHRoZW4gSSBkb24ndCBhY3R1YWxseSBrbm93IGhv dyB0byBwcm9jZWVkLg0KDQpJIHRoaW5rIHRoYXQgaXQncyB0aGUgcmlnaHQgYXBwcm9hY2gsIGFu ZCBnaXZlbiB0aGUgc29ydCBvdXQgb2YgdGhlIE1WRFAsDQpJIHN1cHBvcnQgYWRvcHRpb24uDQoN Ci0tDQpdICAgICAgICAgICAgICAgTmV2ZXIgdGVsbCBtZSB0aGUgb2RkcyEgICAgICAgICAgICAg ICAgIHwgaXB2NiBtZXNoIG5ldHdvcmtzIFsNCl0gICBNaWNoYWVsIFJpY2hhcmRzb24sIFNhbmRl bG1hbiBTb2Z0d2FyZSBXb3JrcyAgICAgICAgfCBuZXR3b3JrIGFyY2hpdGVjdCAgWw0KXSAgICAg bWNyQHNhbmRlbG1hbi5jYTxtYWlsdG86bWNyQHNhbmRlbG1hbi5jYT4gIGh0dHA6Ly93d3cuc2Fu ZGVsbWFuLmNhLzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cC0zQV9fd3d3LnNhbmRlbG1hbi5jYV8mZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2akln JnI9TG9HemhDLThzYzhTWThUcTR2cmZvZyZtPXVxaGRwZkFPSVRLc3RFOW4xbTJjcVdRQmZVQjZS VTBMUkR0cU1DOGlielEmcz04cVpMNlBHYzQzU2VaZVZpMEFQZXd6N0ZhVFZwZnRITnBmLXlPY1lE eU9vJmU9PiAgICAgICAgfCAgIHJ1Ynkgb24gcmFpbHMgICAgWw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaG9tZW5ldCBtYWlsaW5nIGxpc3QNCmhv bWVuZXRAaWV0Zi5vcmc8bWFpbHRvOmhvbWVuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hvbWVuZXQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19o b21lbmV0JmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy04c2M4U1k4 VHE0dnJmb2cmbT11cWhkcGZBT0lUS3N0RTluMW0yY3FXUUJmVUI2UlUwTFJEdHFNQzhpYnpRJnM9 UDFDVDNyQlgtSm5OX2tjTVFXanN0R0dJNmFIQVhid3dVXy1lVHlqS1IxQSZlPT4NCg0K --_000_2D09D61DDFA73D4C884805CC7865E6114DBED1F8GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3Mg RGFuaWVsLiBBbmQgeW914oCZcmUgbm90IHRvbyBsYXRlLiBUaGUgY2FsbCBlbmRzIHRoaXMgY29t aW5nIEZyaWRheS4gU28gaWYgYW55b25lIGVsc2Ugd2FudHMgdG8gY2hpbWUgaW4sIHBsZWFzZSBk by4gSeKAmWxsIHRyeSB0byBjcmVhdGUgYSBzdW1tYXJ5IFRodXJzZGF5DQogZGVzY3JpYmluZyB3 aGF0IEkgdGhpbmsgSeKAmXZlIGhlYXJkIHNvIGZhci4gVGhhdCBzaG91bGQgZ2l2ZSBldmVyeW9u ZSBhIGJyaWVmIGNoYW5jZSB0byB0ZWxsIG1lIGhvdyBiYWRseSBJ4oCZdmUgbWlzaW50ZXJwcmV0 ZWQgdGhlaXIgc3RhdGVtZW50cyBiZWZvcmUgdGhlIGNhbGwgZW5kcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+QmFyYmFyYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IGhvbWVuZXQgW21haWx0bzpob21lbmV0LWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhbmllbCBNaWdhdWx0PGJyPg0KPGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgQXVndXN0IDA5LCAyMDE3IDI6MzcgUE08YnI+DQo8Yj5Ubzo8L2I+IE1p Y2hhZWwgUmljaGFyZHNvbiAmbHQ7bWNyQHNhbmRlbG1hbi5jYSZndDs8YnI+DQo8Yj5DYzo8L2I+ IGhvbWVuZXRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtob21lbmV0XSBUaGUg SE9NRU5FVCBXRyBoYXMgcGxhY2VkIGRyYWZ0LXRsZG0tc2ltcGxlLWhvbWVuZXQtbmFtaW5nIGlu IHN0YXRlICZxdW90O0NhbGwgRm9yIEFkb3B0aW9uIEJ5IFdHIElzc3VlZCZxdW90OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSwgPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+SSBhcG9sb2d5IGZvciB0aGUgbGF0ZSByZXNwb25zZSAoSSB3YXMgb2ZmIGZv ciB0d28gd2Vla3MpLiBJIHdpbGwgdXBkYXRlIHRoZSBkcmFmdCBieSB0aGUgZW5kIG9mIHRoZSBt b250aCBpbnRlZ3JhdGluZyBudW1lcm91cyBmZWVkIGJhY2tzIHdlIHJlY2VpdmVkLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPkFzIGEgY28tYXV0aG9yIEkgYW0gc3VwcG9ydGluZyB0aGUgYWRvcHRpb24gb2Yg dGhpcyBkb2N1bWVudCBhcmNoaXRlY3R1cmUuIEkgYmVsaWV2ZSB0aGF0IGdpdmVuIHRoZSBjdXJy ZW50IHNpdHVhdGlvbiByZWdhcmRpbmcgaG9tZW5ldCBhbmQgbmFtaW5nLCB0aGUgc2ltcGxlIGJ1 dCB1c2VmdWwgc2NvcGUgb2YgdGhlIGRyYWZ0IHdpbGwgaGVscCB0aGUgV0cgdG8NCiBtb3ZlIGZv cndhcmQgcmVnYXJkaW5nIG5hbWluZyBhbmQgaG9tZSBuZXR3b3JrLiBJIGFncmVlIHRoZSBkb2N1 bWVudCBpcyBub3QgeWV0IGluIGEgZmluYWwgdmVyc2lvbiBhbmQgZmVlZCBiYWNrIGZyb20gdGhl IFdHIHdpbGwgYmUgdmVyeSBoZWxwZnVsLiBUaGF0IHNhaWQgSSB0aGluaywgc2luY2UgbGFzdCBJ RVRGLCB3ZSBoYXZlIGEgcHJldHR5IGdvb2QgdmlldyBvbiB3aGVyZSB3ZSBhcmUgZ29pbmcuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdXJzLCA8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGFuaWVsPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIE1vbiwgSnVsIDMxLCAyMDE3IGF0IDEwOjA3IEFNLCBNaWNoYWVsIFJp Y2hhcmRzb24gJmx0OzxhIGhyZWY9Im1haWx0bzptY3JAc2FuZGVsbWFuLmNhIiB0YXJnZXQ9Il9i bGFuayI+bWNyQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlZCBMZW1vbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1lbGxvbkBmdWd1ZS5jb20iPm1lbGxvbkBmdWd1ZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ DQombmJzcDsgJm5ic3A7ICZndDsgdG8gcHV0IHRoZSBDRkEgb24gaG9sZCBwZW5kaW5nIHRoYXQg dXBkYXRlLiBUaGVyZSBoYXZlIGJlZW4gc29tZSBnb29kPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 IGNvbW1lbnRzIGFscmVhZHksIHRob3VnaDsgaW4gcGFydGljdWxhciwgSSB0aGluayBKdWxpdXN6 JyBwb2ludCB0aGF0IGl0PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IHdvdWxkPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7IGJlIG5pY2UgdG8gYWN0dWFsbHkgdHJ5IHNvbWUgb2YgdGhpcyBpbiBwcmFj dGljZSBpcyBnb29kLCBhbmQgaXMgd2hhdDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBJJ208YnI+ DQo8YnI+DQpXZSByZXF1aXJlIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zIGZvciBJbnRl cm5ldCBTdGFuZGFyZCwgbm90IHRvIGFkb3B0PGJyPg0KYSBkb2N1bWVudC4mbmJzcDsgSW1wbGVt ZW50YXRpb24gcmVwb3J0cyB3b3VsZCBiZSBnb29kIGZvciBXR0xDLCBub3QgaGVyZSE8YnI+DQpX ZSBuZWVkIHRvIGxvd2VyIHRoZSBiYXIgaGVyZSwgbm90IHJhaXNlIGl0LiZuYnNwOyBXR3MgY2Fu IGFiYW5kb24gZG9jdW1lbnRzIHRvby48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgVGhh dCBzYWlkLCB3aGF0IEkgc2FpZCBpbiB0aGUgd29ya2luZyBncm91cCBpcyB0aGF0IHdlJ3ZlIGJl ZW4gc3Bpbm5pbmc8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgb3VyIHdoZWVscyBvbiB0aGlzIGZv ciBzZXZlcmFsIHllYXJzLCBhbmQgSSB3YW50ZWQgdG8ga25vdyBpZiB0aGUgc2NvcGU8YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgb2YgdGhpcyBpcyByZWFzb25hYmxlIGFuZCBpcyB3aGF0IHRoZSB3 b3JraW5nIGdyb3VwIHdhbnRzIHRvIHRha2U8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgb24uIElm IGl0J3Mgbm90LDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyB0aGVuIEkgZG9uJ3QgYWN0dWFsbHkg a25vdyBob3cgdG8gcHJvY2VlZC48YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgaXQncyB0aGUgcmln aHQgYXBwcm9hY2gsIGFuZCBnaXZlbiB0aGUgc29ydCBvdXQgb2YgdGhlIE1WRFAsPGJyPg0KSSBz dXBwb3J0IGFkb3B0aW9uLjxicj4NCjxicj4NCi0tPGJyPg0KXSZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtOZXZlciB0ZWxsIG1lIHRoZSBvZGRz ISZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fCBpcHY2IG1lc2ggbmV0d29ya3MgWzxicj4NCl0mbmJzcDsgJm5ic3A7TWljaGFlbCBS aWNoYXJkc29uLCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfCBuZXR3b3JrIGFyY2hpdGVjdCZuYnNwOyBbPGJyPg0KXSZuYnNwOyAmbmJzcDsgJm5i c3A7PGEgaHJlZj0ibWFpbHRvOm1jckBzYW5kZWxtYW4uY2EiPm1jckBzYW5kZWxtYW4uY2E8L2E+ Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwLTNBX193d3cuc2FuZGVsbWFuLmNhXyZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9I VU1lTVRTUWljdmpJZyZhbXA7cj1Mb0d6aEMtOHNjOFNZOFRxNHZyZm9nJmFtcDttPXVxaGRwZkFP SVRLc3RFOW4xbTJjcVdRQmZVQjZSVTBMUkR0cU1DOGlielEmYW1wO3M9OHFaTDZQR2M0M1NlWmVW aTBBUGV3ejdGYVRWcGZ0SE5wZi15T2NZRHlPbyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHA6Ly93d3cuc2FuZGVsbWFuLmNhLzwvYT4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZu YnNwOyAmbmJzcDtydWJ5IG9uIHJhaWxzJm5ic3A7ICZuYnNwOyBbPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KaG9tZW5ldCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86aG9tZW5ldEBpZXRmLm9yZyI+aG9tZW5ldEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2hvbWVuZXQmYW1wO2Q9 RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9TG9HemhDLThzYzhTWThU cTR2cmZvZyZhbXA7bT11cWhkcGZBT0lUS3N0RTluMW0yY3FXUUJmVUI2UlUwTFJEdHFNQzhpYnpR JmFtcDtzPVAxQ1QzckJYLUpuTl9rY01RV2pzdEdHSTZhSEFYYnd3VV8tZVR5aktSMUEmYW1wO2U9 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9o b21lbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2D09D61DDFA73D4C884805CC7865E6114DBED1F8GAALPA1MSGUSRBF_-- From nobody Wed Aug 9 16:29:33 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211D31270AC for ; Wed, 9 Aug 2017 16:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 JLKHk-2Bo-pU for ; Wed, 9 Aug 2017 16:29:30 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 4A62B126B71 for ; Wed, 9 Aug 2017 16:29:30 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 9A1CA24AE12; Wed, 9 Aug 2017 23:27:59 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EEB9F1600A4; Wed, 9 Aug 2017 23:28:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DC9671600A3; Wed, 9 Aug 2017 23:28:04 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 19UCWkY1MhRX; Wed, 9 Aug 2017 23:28:04 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 630FA160041; Wed, 9 Aug 2017 23:28:04 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DA30381E1E05; Thu, 10 Aug 2017 09:28:01 +1000 (AEST) To: Ted Lemon Cc: HOMENET , Warren Kumari From: Mark Andrews References: <150223150804.3668.14190745110025046639@ietfa.amsl.com> <79597E4D-DEC0-4622-A410-003B45EB5E6A@fugue.com> <20170809031722.28F8F81C6FC7@rock.dv.isc.org> In-reply-to: Your message of "Wed, 09 Aug 2017 11:53:42 -0400." Date: Thu, 10 Aug 2017 09:28:01 +1000 Message-Id: <20170809232801.DA30381E1E05@rock.dv.isc.org> Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-11.txt (FINAL?) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 23:29:32 -0000 In message , Ted Lemon writes: > > What does forwarding DS lookups for home.arpa out of the homenet do? That > is, suppose I implement a cache that doesn't do this: what bad thing > happens? It's going to return NXDOMAIN, right? Isn't it the NSEC > lookups that have to succeed, and the NS record lookup? And doesn't the > NS record have to be forged? It will return a signed NOERROR nodata responses saying that there isn't a DS record for home.arpa but there is a delegation assuming DO=1 is set in the query and IANA has competed setting up the insecure delegation. If DO=0, or there isn't a OPT record, you still get a NOERROR nodata response but that isn't useful for downstream validating clients. Note for DNSSEC to work reliably all resolvers that are forwarding queries need to be DNSSEC aware (set DO=1) and validate responses. If they don't validate responses they will cache bad answers which will prevent down stream validators getting good answers. Validating allow the forwarding resolver to reject bad answers and to try alternate sources. It they don't validate DNSSEC will work most of the time because most answers you get back are actually correct and complete. Writing a recursive server these days that doesn't support DNSSEC should be a hanging offence. :-) > I think this actually means that it does have to be an unsigned delegation. > Argh. > > Hm, thinking farther, no, it doesn't, because it's okay to return the right > answer for the delegation as long as the stub resolver is willing to rely > on the cache, which we've already specified it must do. So what's the > failure mode that this new text prevents? Oh, you have to look up the DS > record to get the NSEC that validates it? Yes (proves its non existence). > (I'm leaving in all of the stuff I typed while I was thinking this through > because I'm not sure I got it right, and you can point out what I got > wrong.) > > On Tue, Aug 8, 2017 at 11:17 PM, Mark Andrews wrote: > > > > > In message <79597E4D-DEC0-4622-A410-003B45EB5E6A@fugue.com>, Ted Lemon > > writes: > > > I updated homenet-dot with the change that Mark requested regarding > > > signed, unsigned and insecure delegations. I believe the text is > > > correct now, but would appreciate a sanity check. Otherwise, I think > > > it's up to the chairs to make the next move. > > > > I would explictly list DS home.arpa as a exception. (I had to file > > a bug report against recursive server that failed to have this > > exception this week for AS112 zones. The bug has been fixed.) Also > > I wouldn't be using '.home.arpa.' as we also want to stop queries > > for 'home.arpa' leaving the home. There are a couple of references > > to '.home.arpa'. > > > > e.g. > > > > Old: > > DNS queries for names ending with '.home.arpa.' are resolved using > > local resolvers on the homenet. Such queries MUST NOT be recursively > > forwarded to servers outside the logical boundaries of the homenet. > > > > New: > > DNS queries for names ending with 'home.arpa.' are resolved using > > local resolvers on the homenet. Such queries MUST NOT be recursively > > forwarded to servers outside the logical boundaries of the homenet with > > the exception of DS lookups for 'home.arpa.'. > > > > Mark > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Aug 10 07:59:56 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCF71321DC; Thu, 10 Aug 2017 07:59:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: homenet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150237719431.11936.14960821103266980636@ietfa.amsl.com> Date: Thu, 10 Aug 2017 07:59:54 -0700 Archived-At: Subject: [homenet] I-D Action: draft-ietf-homenet-dot-12.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 14:59:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking WG of the IETF. Title : Special Use Domain 'home.arpa.' Authors : Pierre Pfister Ted Lemon Filename : draft-ietf-homenet-dot-12.txt Pages : 9 Date : 2017-08-10 Abstract: This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.', and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-homenet-dot-12 https://datatracker.ietf.org/doc/html/draft-ietf-homenet-dot-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dot-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 10 08:02:03 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B91C1321EB for ; Thu, 10 Aug 2017 08:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 z9PY9qbUcGVb for ; Thu, 10 Aug 2017 08:01:55 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 D6E371321A5 for ; Thu, 10 Aug 2017 08:01:54 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id u139so5605786qka.1 for ; Thu, 10 Aug 2017 08:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Q8msdiYfMpVMuM4AF8z2ePtzWzZEwAcIf2qNOXKu5BI=; b=2AxE8LigaHLEPY2XQnehqTYo9a08bDBO1Oxq6rxJRdoQC3XVEa+Bq9HCY+54mLKY/z J/ghVv/jWxLtf3jeUshAe7G1Z19LB+dEvctT7Kr8ksPQzWN8jS84/wmMOyet3yqVkt2e phR88PVVr8IzYHvHs2PrFYZzDNOHJEmgndxnbw9UjBMy0atQBtWRo/SDK9xLHHrzcsjB Yc05Hm7JXkOCsBP+EZVMDEhpXDd7LtmeAllWnEjtCNWlSCUsZICZwenb2ykBbgVxQNkb ESKRhARfJ2m0Kp3Rz2RbqYVkgog8zpN57CmmeW5w/vr/XGqj0/j7icWRPrHMsMlYMBqp sTaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Q8msdiYfMpVMuM4AF8z2ePtzWzZEwAcIf2qNOXKu5BI=; b=iepE/zfldWl7PR79IUiRATI2jzo2+GVOuNauQxtA1pTGzYbl7mn0lt7jKFWCj+0SDr 2XngCgzb+qdhr0e2zMX+zw/jJbbdqrN1qFWX5eLQVuzhUooiq+S+40DwACDOJKipcxax FQC5AfGnIPu8LzjuAoYlO5pcr+Duo2Ls580lePc5eiVznfE0JcocjNQOfRnDfPZaqmk7 JbqQGLXjdHtvXricN+KWhBIA1POdkW68Skn4y5+lZbsUKUXwwlpl9RK3eiaq3sACAGR9 0SyjbYwJb+cLq8EamrcAygmDmyiZRU4fShRcHQbuNE3zKs3yLQrg1Mwl7YI3EFDeUpOS MZzw== X-Gm-Message-State: AHYfb5ii9C8tJCvx0i8AHNFchfFjgHE9DJVqxszTxJepGOvQssMXFlUd XZ+N/lMfuZy5d12PJn18Pg== X-Received: by 10.55.154.10 with SMTP id c10mr14591388qke.197.1502377314035; Thu, 10 Aug 2017 08:01:54 -0700 (PDT) Received: from [192.168.43.27] (mobile-166-171-186-64.mycingular.net. [166.171.186.64]) by smtp.gmail.com with ESMTPSA id j62sm3591196qkc.28.2017.08.10.08.01.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 08:01:53 -0700 (PDT) From: Ted Lemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 10 Aug 2017 11:01:49 -0400 References: <150237719431.11936.14960821103266980636@ietfa.amsl.com> To: Ted and Andrea Lemon , HOMENET In-Reply-To: <150237719431.11936.14960821103266980636@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-12.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 15:02:02 -0000 This revision fixes the problem that Mark Andrews pointed out yesterday = with respect to queries for DS records for 'home.arpa.' Before any further action occurs, we should probably wait for Mark, who = I assume is enjoying a well deserved night's sleep right now, to see if = he's happy with the new version. Sorry for the churn, but the problem = Mark found was a very serious problem that would have prevented the = whole thing from working! From nobody Thu Aug 10 13:33:39 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEC21323BC for ; Thu, 10 Aug 2017 13:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham 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 ec-D7q7uR5PB for ; Thu, 10 Aug 2017 13:33:36 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AA0127735 for ; Thu, 10 Aug 2017 13:33:36 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v7AKP3FU037332 for ; Thu, 10 Aug 2017 16:33:33 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2c8x4u8yj8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 10 Aug 2017 16:33:33 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7AKXWF3003927 for ; Thu, 10 Aug 2017 16:33:33 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7AKXSbi003872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Aug 2017 16:33:30 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi134.aldc.att.com (RSA Interceptor) for ; Thu, 10 Aug 2017 20:33:12 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.30]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0319.002; Thu, 10 Aug 2017 16:33:12 -0400 From: "STARK, BARBARA H" To: "homenet@ietf.org" Thread-Topic: Status of draft-tldm-simple-homenet-naming CFA Thread-Index: AdMSExv6TskYwTm0TxW2ixuYvce/UA== Date: Thu, 10 Aug 2017 20:33:11 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.219.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-10_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708100321 Archived-At: Subject: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 20:33:38 -0000 With one day left in CFA for draft-tldm-simple-homenet-naming, here is my s= ummary of what I think I've read. Exactly 3 people have expressed support for adoption (Daniel [author], Mich= ael R, James). Hmm. That's not a lot. Juliusz expressed opposition to adoption, but Ray and Michael said the reas= oning for objection was flawed (that Juliusz was setting the bar too high a= nd the procedural objections were not valid in the context of IETF procedur= es). Ray said the purpose of a CFA is "to get agreement that a document is = an appropriate direction for the WG to explore, even if it might require su= bstantial work". Ted [author] said he thought it might be reasonable to put the CFA on hold = until Daniel did another update. Tim C said he thought it was early for adoption (for this and related dnssd= drafts). I hope I got this summary right. Did I miss anything important? Does anyone else have an opinion? Does anyone who has expressed an opinion = want to express a new and different opinion? Barbara From nobody Thu Aug 10 13:38:54 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F28132459 for ; Thu, 10 Aug 2017 13:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=gmPpuh9b; dkim=pass (1024-bit key) header.d=yitter.info header.b=Si1MWwM0 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 UBq_C2l9YWfd for ; Thu, 10 Aug 2017 13:38:47 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176A013244F for ; Thu, 10 Aug 2017 13:38:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 5AFD7BF590 for ; Thu, 10 Aug 2017 20:38:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1502397526; bh=Dbhm1cifAGRr2iHrRbpXFGbxqFZzLrmPq3AMdMLIZF8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=gmPpuh9b3XnIS2y7npJy8GgTNwOtb3nQ/SHXCDrLAOQyUORtqi/YLvr2fTpguc5kW 5NQMP+9ecxq8+UO2SMA1ETYmWmtojsZB9tm/BRHyUY5YRi7GSLAzxVtvzAvmbjtrpe SHY5Dx1u/IfsneCVycWQk9RmUhhFg3vTE6t1kyo4= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2q-ED1MBlya for ; Thu, 10 Aug 2017 20:38:45 +0000 (UTC) Date: Thu, 10 Aug 2017 16:38:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1502397525; bh=Dbhm1cifAGRr2iHrRbpXFGbxqFZzLrmPq3AMdMLIZF8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Si1MWwM016/8lIU4L9bkcz9IFxe38XeTGMX9XOHOzqZ0Oglo4t/BfEyA9zh9o3X/K xqUoKJprNjoMEkropqpv5BAyeTWfyXbnQUr9vOKPmIEEHGvo4KNCwxH7R8mfYX4O+F CezGkPPLs3IHykrlWKBI0DwkKXj6ejXVbYCVN7eE= From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 20:38:49 -0000 On Thu, Aug 10, 2017 at 08:33:11PM +0000, STARK, BARBARA H wrote: > Does anyone else have an opinion? Does anyone who has expressed an opinion want to express a new and different opinion? > Barbara I haven't weighed in because I can't make up my mind. On the one hand, I think this is a reasonable and limited set of things to do to get started with, and so I'd normally say we should adopt it and go ahead. On the other hand, as I suggested in Prague, it's quite a limited set of aspirations, and quite a bit short of what we had originally suggested we were trying to do. It even seems shy of various claims in the architecture document, which I see as a sort of requirements document. So, I'm not opposed to working on it. But I wish it were more ambitious. But I wish I were more ambitious, too :-) A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Aug 10 13:49:58 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AD913239F for ; Thu, 10 Aug 2017 13:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 r-DN9PNIoxwF for ; Thu, 10 Aug 2017 13:49:54 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 34E8F1321AC for ; Thu, 10 Aug 2017 13:49:54 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id v77so7385278pgb.3 for ; Thu, 10 Aug 2017 13:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U23xHkHYJCNkXRUYD+v5mIIknlWRhUC5D7+thazIzto=; b=BXq8thC5N289k596pEU0HXCKYATyA08YvctK9BpylkaUSV+JZX68E2/v5lPWZ+qppP aqeRc1ltb8bKHHM3a765I4NmsBjtWDXrH1F49vy5rK865/21QemC3tJPXq0j6Fc3HGcx /3wWOCBOwK+qxcXMrz+BqyYsIejj31rEIcUAEA22t3AcG/WOoxK1FzA6G3K+x0yBA2cm UGgIuL/wIpvFW+L6EMfH3Hc+Hxf+gUGXXgAecjWfhmGKQOHr+5kRYPJrbDUzP2XQkNa5 xn6B314+r6f+BcRFGsgRvi2yXYV1e2rCrgKttO2s86JX4hYZ8iQzH8039IhFD/Lw4VSJ +13Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U23xHkHYJCNkXRUYD+v5mIIknlWRhUC5D7+thazIzto=; b=rk8TAd1oMKA58eioGu4Hfl3VLbpNw4OPkBYylaT4Q45ff88lNeUfU8D+FZ3FgXylsc rry7LsuNULFiZJjWwv/3/8Ecaq8+11cXHOUBg5/ZQ6S0bH2jg14X7PMsIgHS2oUiVLY/ c0umN36km0z7OAm58I6DNTkMHKVOMJgXyVlXkUZlreyukWXCWj9oFgoQzl5v5JlRRKmx oPlBOp3W2x1c2+pBDcjTHBThOI+E0JB9kQ3hnIMfRxdjNp7+pxiqBWGfsShlHcAS6C80 K9EW/Duv1aJBlBWEmR8+dz59ChV/vtql8xlQiajKJMxncS3g5YVmSGBn2ID7+CP0RB+W th1w== X-Gm-Message-State: AHYfb5hQfpxDWW7NrNWu4pPewIKQ7WBbeiF9RQWQrPLOCHjGGh9TP3yW bkO0WfWsmo23jE4d5QU63IFPtTAjTCAa X-Received: by 10.84.167.2 with SMTP id c2mr15231636plb.368.1502398193509; Thu, 10 Aug 2017 13:49:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.131 with HTTP; Thu, 10 Aug 2017 13:49:12 -0700 (PDT) In-Reply-To: <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> From: Ted Lemon Date: Thu, 10 Aug 2017 16:49:12 -0400 Message-ID: To: Andrew Sullivan Cc: HOMENET Content-Type: multipart/alternative; boundary="94eb2c145baea2b93905566c5621" Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 20:49:56 -0000 --94eb2c145baea2b93905566c5621 Content-Type: text/plain; charset="UTF-8" Barbara, I seem to recall that you were enthusiastic about the work when it was discussed in the meeting. You're allowed to be one of the people who's in favor of it, despite being chair. Indeed, as chair, you can just adopt it by fiat if you want. I actually agree with Ray and Michael that Juliusz reasoning was flawed, and am definitely in favor of adopting it and working on it. I also agree with Andrew that it shouldn't be the final word on naming in the homenet. On Thu, Aug 10, 2017 at 4:38 PM, Andrew Sullivan wrote: > On Thu, Aug 10, 2017 at 08:33:11PM +0000, STARK, BARBARA H wrote: > > Does anyone else have an opinion? Does anyone who has expressed an > opinion want to express a new and different opinion? > > Barbara > > I haven't weighed in because I can't make up my mind. > > On the one hand, I think this is a reasonable and limited set of > things to do to get started with, and so I'd normally say we should > adopt it and go ahead. > > On the other hand, as I suggested in Prague, it's quite a limited set > of aspirations, and quite a bit short of what we had originally > suggested we were trying to do. It even seems shy of various claims > in the architecture document, which I see as a sort of requirements > document. > > So, I'm not opposed to working on it. But I wish it were more > ambitious. But I wish I were more ambitious, too :-) > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --94eb2c145baea2b93905566c5621 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Barbara, I seem to recall that you were enthusiastic about= the work when it was discussed in the meeting. =C2=A0 You're allowed t= o be one of the people who's in favor of it, despite being chair. =C2= =A0 Indeed, as chair, you can just adopt it by fiat if you want. =C2=A0 I a= ctually agree with Ray and Michael that Juliusz reasoning was flawed, and a= m definitely in favor of adopting it and working on it. =C2=A0 I also agree= with Andrew that it shouldn't be the final word on naming in the homen= et.

On Thu, = Aug 10, 2017 at 4:38 PM, Andrew Sullivan <ajs@anvilwalrusden.com&= gt; wrote:
On Thu= , Aug 10, 2017 at 08:33:11PM +0000, STARK, BARBARA H wrote:
> Does anyone else have an opinion? Does anyone who has expressed an opi= nion want to express a new and different opinion?
> Barbara

I haven't weighed in because I can't make up my mind.

On the one hand, I think this is a reasonable and limited set of
things to do to get started with, and so I'd normally say we should
adopt it and go ahead.

On the other hand, as I suggested in Prague, it's quite a limited set of aspirations, and quite a bit short of what we had originally
suggested we were trying to do.=C2=A0 It even seems shy of various claims in the architecture document, which I see as a sort of requirements
document.

So, I'm not opposed to working on it.=C2=A0 But I wish it were more
ambitious.=C2=A0 But I wish I were more ambitious, too :-)

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet<= br>

--94eb2c145baea2b93905566c5621-- From nobody Thu Aug 10 14:07:34 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E4613242D for ; Thu, 10 Aug 2017 14:07:31 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 mFTbB4SNSYeg for ; Thu, 10 Aug 2017 14:07:27 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7AB1323C3 for ; Thu, 10 Aug 2017 14:07:27 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502399242; bh=nHUdzYZ/PBDHbsf6gvIJQLLQ4NwGC/V4E6qUpPkK3s4=; h=From:To:Subject:In-Reply-To:References:Date:From; b=fpyGexEkq8svSeQ92PMcM47PtkrZOpGphTvh2ChMy36clI9/Smu9u+IeD5u9jxqX4 7pzFdru/oe2T2a/YYeBRZMw4o7yvSYAVax1c7WqSuyoXkd8xbbm93O3bl9YlCmSeTU J4k4qT4qKjPwg9SMPMUrLDrFkjQw9MBaSEmr8PIpriX5ywVMUohv/8v3GPeIXbMLYN ibFAHeCc5BvKil3nR7PRvWFHE0ju2upvl2OwXQ83742k+Vtq96G0gjC4uk8p2ZooBE cwhwxh7uvD+I1LMgpq7bJxiQoq8sSYHMVyvfmxEuZbqJpD8eiZBaAIblANqr4Qa1nT 3oPr3QNCew13w== To: Andrew Sullivan , homenet@ietf.org In-Reply-To: <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> Date: Thu, 10 Aug 2017 23:07:22 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wp6byvw5.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 21:07:32 -0000 Andrew Sullivan writes: > On Thu, Aug 10, 2017 at 08:33:11PM +0000, STARK, BARBARA H wrote: >> Does anyone else have an opinion? Does anyone who has expressed an opinion want to express a new and different opinion? >> Barbara > > I haven't weighed in because I can't make up my mind. > > On the one hand, I think this is a reasonable and limited set of > things to do to get started with, and so I'd normally say we should > adopt it and go ahead. > > On the other hand, as I suggested in Prague, it's quite a limited set > of aspirations, and quite a bit short of what we had originally > suggested we were trying to do. It even seems shy of various claims in > the architecture document, which I see as a sort of requirements > document. I am in a bit of the same boat. I think most of the things in the document are reasonable things to do (with the possible exception of the requirement for supporting multiple provisioning domains), but I would also like to solve some of the other problems that are deemed out of scope in the current version of the document. At a minimum, I would like to solve the "services should be visible from the outside" problem. I guess I'm fine with adopting the document, as long as it's still possible to make these kinds of adjustments in scope further along the way... :) -Toke From nobody Thu Aug 10 14:23:11 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507DF132459 for ; Thu, 10 Aug 2017 14:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 j2TQPB1uZEL5 for ; Thu, 10 Aug 2017 14:23:07 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 8611013245F for ; Thu, 10 Aug 2017 14:23:06 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id p3so11946257qtg.2 for ; Thu, 10 Aug 2017 14:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LvDwon82c/u4uI1ebidfS9RO8bPmQGRJjdADu2xNkjw=; b=SYk8+I2CK74glm8L++fHoUzSeu9bDEVYDlD0EWWeHHxoSYQmW5MqyCublhYcKNjhqn aU9QyBUtNLXMYm6qxxXXLturr1VWofSMXBEP2polL8qq4L3mAjOlcLiUdQb0mA2qcuFl mQc/2yY0SfVX2aR11SCmyov6vzZsvMKl5G895kM4j1I3Iap6NKp7Vof76Tc7koljfsFi 8Tf7WVElKfETh6bE4ei1e4s3CtaeImw5e2TVKNQ0Upqc1qfbieXAy0rTvnK9CkapX3UG sUfCuwIKQSqy61q9WkjIzPTzVPQzB0DlXO4g5qPfMJ27Twgh/G3epdYW8ShbOfSyAYPw numw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LvDwon82c/u4uI1ebidfS9RO8bPmQGRJjdADu2xNkjw=; b=oQ0Hy/av1Sw5FKy8GGsQtb+x3laR6bVsFgLCsXggkDOS6D6tlVLAaD1XrEriIrFGJk IoAMaydsEnM7mIsJqMH0u/IpvJLbNXcyoEmVHJqOFk8j/tWJGIem3LTeBIbYVlzZZ+sQ qNUYKn0kFjEeopXvnQGwu6wmNGSM+G6GvqKCtG4w4YzNokRTOPAqWIzvNUxyJbrRmg5w USs89E9u0KrWYPdjfNNpMEJhP3E5aGf+5/ngSHXeieRyb9roB7kefkIqtTvbA/SLOqJu DmRjKsjywc1gQ4PCdjLx+dNCAYGtrJfywwMKC7mV6P8F56dbx5W6EC8JLwRxEN/OAtEX sX2Q== X-Gm-Message-State: AHYfb5gLR45aJAQ2siZaQLvwwti87YTEpwSc0fXWmkmC4WzjIPQHAAo8 sFCYOUt5p59MxhLLwjrbAA== X-Received: by 10.200.35.23 with SMTP id a23mr18628862qta.258.1502400185627; Thu, 10 Aug 2017 14:23:05 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id v87sm4163232qkv.24.2017.08.10.14.22.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 14:22:55 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_229F416B-F6D6-4001-827C-4FD87E78274B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 10 Aug 2017 17:22:53 -0400 In-Reply-To: <87wp6byvw5.fsf@toke.dk> Cc: Andrew Sullivan , homenet@ietf.org To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 21:23:09 -0000 --Apple-Mail=_229F416B-F6D6-4001-827C-4FD87E78274B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 10, 2017, at 5:07 PM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: > with the possible exception of the > requirement for supporting multiple provisioning domains How would you solve the problem of dual-homing without the multiple = provisioning domain support described in the document? --Apple-Mail=_229F416B-F6D6-4001-827C-4FD87E78274B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 10, 2017, at 5:07 PM, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> = wrote:
with the possible = exception of the
requirement for = supporting multiple provisioning = domains

How = would you solve the problem of dual-homing without the multiple = provisioning domain support described in the document?

= --Apple-Mail=_229F416B-F6D6-4001-827C-4FD87E78274B-- From nobody Thu Aug 10 14:48:25 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B087132433 for ; Thu, 10 Aug 2017 14:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham 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 GB5cvNUPp2ZR for ; Thu, 10 Aug 2017 14:48:21 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 758F6132379 for ; Thu, 10 Aug 2017 14:48:21 -0700 (PDT) Received: from a91-155-69-187.elisa-laajakaista.fi ([91.155.69.187] helo=poro.lan) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dfvJT-0003ad-CV; Fri, 11 Aug 2017 00:48:19 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Markus Stenberg In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Fri, 11 Aug 2017 00:48:18 +0300 Cc: "homenet@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <296D97E1-29AA-4D25-A559-BF9D4F7D2023@iki.fi> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> To: BARBARA H STARK X-Mailer: Apple Mail (2.3273) X-SA-Exim-Connect-IP: 91.155.69.187 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 21:48:24 -0000 On 10 Aug 2017, at 23.33, STARK, BARBARA H wrote: >=20 > With one day left in CFA for draft-tldm-simple-homenet-naming, here is = my summary of what I think I've read. >=20 > Exactly 3 people have expressed support for adoption (Daniel [author], = Michael R, James). Hmm. That's not a lot. >=20 > Juliusz expressed opposition to adoption, but Ray and Michael said the = reasoning for objection was flawed (that Juliusz was setting the bar too = high and the procedural objections were not valid in the context of IETF = procedures). Ray said the purpose of a CFA is "to get agreement that a = document is an appropriate direction for the WG to explore, even if it = might require substantial work". > Ted [author] said he thought it might be reasonable to put the CFA on = hold until Daniel did another update. > Tim C said he thought it was early for adoption (for this and related = dnssd drafts). >=20 > I hope I got this summary right. Did I miss anything important? > Does anyone else have an opinion? Does anyone who has expressed an = opinion want to express a new and different opinion? I find it desirable that a work in this direction goes on. However, = there=E2=80=99s details due to which I am not very keen about this = particular document (or the related dns-sd documents for that matter, = but this is not the forum for those). In order I encountered them during = a browse through the document: - requiring every link on every router to have local DNS = forwarder/server seems very broken to me. _one_ in-home DNS server is = probably enough. ( external dns update could be prevented also by e.g. knowing = prefix(es) allocated to homenet, by using ULA, or by judicious = firewalling; I prefer ULA but YMMV ) - 3.3 - it implies that homenet exposes DNS outside home (by default?) and = uses instead custom dns server logic to handle .home.arpa from = =E2=80=98outside=E2=80=99; why not just firewall it and be done with it = (or listen only on e.g. ULA prefix) - why filter out global IPs? - 3.5 (PVD madness) - WHY? can=E2=80=99t we get just rid of split horizon DNS madness and = use _a_ DNS instead of N DNS servers? - round-robin =3D bad (think why happy eyeballs came up for example of = why) I=E2=80=99d much rather see some detail on how selected subset of = services can be exposed outside home (including also how related = firewalling works), than the PVD stuff, and some of the things seem just = misguided from implementation point of view; a set of DNS = forwarders/servers seems like overkill if one is implementing N+1 device = (which assumes there is =E2=80=99smarter=E2=80=99 router already in the = home, look at the current mesh wireless solutions for example). Anyway, this is my yearly post quota used for the WG, I=E2=80=99ll be = back in 2018 :) Looking forward to using this someday, but given it = requires host changes (notably parts of 3.3 and 3.5), I am not holding = my breath on that yet. Cheers, -Markus From nobody Thu Aug 10 14:59:06 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9BF132445 for ; Thu, 10 Aug 2017 14:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 3tO4Nin5nRR8 for ; Thu, 10 Aug 2017 14:59:03 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 6327D1321C6 for ; Thu, 10 Aug 2017 14:59:03 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id u139so11833023qka.1 for ; Thu, 10 Aug 2017 14:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KjMMlCdOMPj88SPyY2Sdk48jfot3TuaGxbJb1lpWsqY=; b=t0r8Nd+gib60LIlXYN9Zn4N6APchFT03fuyEWEWRK1JaUJJ/nKmRQM+1yMX7ujtNk7 CFurlUm6Few50ieHwumGBPbdnRJ3yk5hdBkvhXElWYhy7nnlxEQovPP0qiH6N0zp0U0O N2V0XL42Lpjg3XJAscSA7cj/PFYlYQ37o7E1s7TH4t5oL8IzdRMaeI9UXjQsQ+8AacQO TsUKNArHYWfbbwCdjeAtgg6kuP6beSH/LoO8TSvhJi8Cq6pbc0QriNgm6BYcc+FN0bNm LNq5+B0ipOnBVD28aaYbgdKThpK1OmDJuOqeo+fW160dqIXR7roBsU5v9UA5XqJkPCil 8cMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KjMMlCdOMPj88SPyY2Sdk48jfot3TuaGxbJb1lpWsqY=; b=OtWryr4bJd3UZiUgXkixMvKoQZzf/QYbEZ9HVpXfdGFBxceVZPtUd7f1yLhxOE9+2o JOHhoQjpdNN6iuhvyG6oplqvORTlT7PXUKAc/Dyxd3cz7yf5sLqJrDFL7tg3jhvOQkAt MjQRVaH4ujlXznt0SP7Pa18eklJr7oUoEADj1388GPStZG79PyjVVnlzNFV+OlbUZbLf y5DnAj0ycofbke7eK1yW1P2SKRzWS4k49A2En/qbei/5Dnm2EBLAK2JC7KW/u1ei1rqa 6N3L6Mk8dE8N2ZA/uMzQ6O09EiTQrs9iPbn8zpM3wa/A5ns9n9h9NmAWA9LdUD1Eja1u hr/w== X-Gm-Message-State: AHYfb5gSHUyyNI2TmglSEIIY50EUvmcS2pYbV/CHEnhCZzulZqitmX6Q 0hVG+wLhcPl0mBly X-Received: by 10.55.52.201 with SMTP id b192mr16068558qka.213.1502402342301; Thu, 10 Aug 2017 14:59:02 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id y66sm3182975qke.21.2017.08.10.14.59.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 14:59:01 -0700 (PDT) From: Ted Lemon Message-Id: <0F31651E-77F1-433F-831D-424B21D6CDA4@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9BDE46C0-956E-4BEE-8D9C-A811A28C7E60" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 10 Aug 2017 17:59:00 -0400 In-Reply-To: <296D97E1-29AA-4D25-A559-BF9D4F7D2023@iki.fi> Cc: BARBARA H STARK , "homenet@ietf.org" To: Markus Stenberg References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <296D97E1-29AA-4D25-A559-BF9D4F7D2023@iki.fi> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 21:59:06 -0000 --Apple-Mail=_9BDE46C0-956E-4BEE-8D9C-A811A28C7E60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 10, 2017, at 5:48 PM, Markus Stenberg = wrote: > - 3.3 > - it implies that homenet exposes DNS outside home (by default?) and = uses instead custom dns server logic to handle .home.arpa from = =E2=80=98outside=E2=80=99; why not just firewall it and be done with it = (or listen only on e.g. ULA prefix) No, it doesn't say that. > - why filter out global IPs? Because if you don't, then when you lose your global prefix, you lose = access to your printer. > - 3.5 (PVD madness) > - WHY? can=E2=80=99t we get just rid of split horizon DNS madness and = use _a_ DNS instead of N DNS servers? If you tell me how to implement that, I will be excited. Otherwise, = not solving this problem will produce brokenness. The simplest way to = solve it is to have the network advertise only one external prefix on = the homenet if the homenet is multiply-homed. Is that your preferred = solution? Also, this isn't necessarily split-horizon madness. It's valid for the = same query to yield different answers; this is operationally normal, and = trying to do something to stop it in homenet isn't going to work. Like = you, I would prefer to do CDNs in a way that doesn't involve all of this = brokenness, but if you want to watch Netflix on your homenet, we need to = make this work. > - round-robin =3D bad (think why happy eyeballs came up for example of = why) DNS resolvers use round-robining. That's how the protocol works. I = can think of ways to improve on that, but they all involve changing the = DNS packet format. So I don't think that's in scope. The draft just = specifies how DNS round robining should work in the context of mpvd on a = homenet=E2=80=94it didn't invent it. --Apple-Mail=_9BDE46C0-956E-4BEE-8D9C-A811A28C7E60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 10, 2017, at 5:48 PM, Markus Stenberg <markus.stenberg@iki.fi> wrote:
- 3.3
- it implies that = homenet exposes DNS outside home (by default?) and uses instead custom = dns server logic to handle .home.arpa from =E2=80=98outside=E2=80=99; = why not just firewall it and be done with it (or listen only on e.g. ULA = prefix)

No, it doesn't say that.

- why filter out = global IPs?

Because if you don't, then when you lose your global = prefix, you lose access to your printer.

- 3.5 (PVD = madness)
- WHY? can=E2=80=99t we get just rid of = split horizon DNS madness and use _a_ DNS instead of N DNS = servers?

If you tell me how to implement that, I will be = excited.   Otherwise, not solving this problem will produce = brokenness.   The simplest way to solve it is to have the network = advertise only one external prefix on the homenet if the homenet is = multiply-homed.   Is that your preferred solution?

Also, this isn't necessarily split-horizon = madness.   It's valid for the same query to yield different = answers; this is operationally normal, and trying to do something to = stop it in homenet isn't going to work.   Like you, I would prefer = to do CDNs in a way that doesn't involve all of this brokenness, but if = you want to watch Netflix on your homenet, we need to make this = work.

- round-robin =3D bad (think why happy eyeballs = came up for example of why)

DNS resolvers use round-robining.   = That's how the protocol works.   I can think of ways to improve on = that, but they all involve changing the DNS packet format.   So I = don't think that's in scope.   The draft just specifies how DNS = round robining should work in the context of mpvd on a homenet=E2=80=94it = didn't invent it.

= --Apple-Mail=_9BDE46C0-956E-4BEE-8D9C-A811A28C7E60-- From nobody Thu Aug 10 15:07:57 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACECC131D19 for ; Thu, 10 Aug 2017 15:07:56 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 4iGjyF2uWVA0 for ; Thu, 10 Aug 2017 15:07:54 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98FC3132464 for ; Thu, 10 Aug 2017 15:07:54 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502402871; bh=8lWHqUDAOYW2q0rLjaAWse0A+7r1NujQLCuYIKHoi48=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nzO0W2ugEFJ+UPyuIFDL80efP07rswLkXk4rdKk9dXeI2t3Fvxb7DcsVIHgp84g1m 6zfRZTnpKn8HJkFWYITkU+UY1GhmIs99wgiLCy/xCc1YRzqSaeH0BKxbwguI6NanPU qM86BbAfhd4LOwN+xdEEMY9HmQcej22i1BLZL85YZY3T0zaAqtqvGxbw2XrV6JOScG 4tAZDRNDLjrwPqY3J86NwSNhfCspPVHaDFhk68tMcIikz8xmC1hFpFg2VAXonHPx/C EIXc4cC/3wAsE5rPlZ5mn+BI99SFPGmy4eeFBzkRk5CMCBq04MQlGe3mGrBecaZx23 dEs5WPxo5gQsw== To: Ted Lemon Cc: Andrew Sullivan , homenet@ietf.org In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> Date: Fri, 11 Aug 2017 00:07:50 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87poc3yt3d.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 22:07:57 -0000 Ted Lemon writes: > On Aug 10, 2017, at 5:07 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> with the possible exception of the >> requirement for supporting multiple provisioning domains > > How would you solve the problem of dual-homing without the multiple > provisioning domain support described in the document? We're talking about the "oh no, my netflix streams is coming from the wrong ISP" kind of problem here, right? I.e., same DNS request gives different answer depending on which ISP I send it to? For one thing, I'm not convinced this is that big of a problem. I happen to live in a country that likes to apply censorship by messing with DNS; so I generally don't use my ISP's name servers, and have never had any issues arising from this. So in this case a solution could just be to ignore the issue... :) Now, assuming that I am wrong and this is actually a serious issue that we need to solve (of which I am not opposed to being convinced), I think it would be feasible to come up with a solution where we could at least allow less capable routers that do not implement the full MPvD support. I can think of at least two ways off the top of my head: 1. Allow the router in question to offload queries to a more capable router elsewhere in the homenet. 2. Allow the router in question to just query all upstreams and combine the results (and so offload the problem to the client). -Toke From nobody Thu Aug 10 17:02:51 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD5713254F for ; Thu, 10 Aug 2017 17:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Eu0ZvLTW12Qe for ; Thu, 10 Aug 2017 17:02:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44E413253C for ; Thu, 10 Aug 2017 17:02:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 82D5D2009E; Thu, 10 Aug 2017 20:05:06 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 90240806BA; Thu, 10 Aug 2017 20:02:46 -0400 (EDT) From: Michael Richardson To: Markus Stenberg cc: BARBARA H STARK , "homenet\@ietf.org" In-Reply-To: <296D97E1-29AA-4D25-A559-BF9D4F7D2023@iki.fi> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <296D97E1-29AA-4D25-A559-BF9D4F7D2023@iki.fi> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 00:02:50 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Markus Stenberg wrote: > - 3.5 (PVD madness) > - WHY? can=E2=80=99t we get just rid of split horizon DNS madness and= use _a_ DNS instead of N DNS servers? I am not happy with PVD stuff either, but it's not enough to block the document. Rather, I want to adopt it so that we discuss this. I understand we have to adopt the PVD document too. > Anyway, this is my yearly post quota used for the WG, I=E2=80=99ll be= back in > 2018 :) Looking forward to using this someday, but given it requires ha. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmM9CYACgkQgItw+93Q 3WWOpQf/SWNN4b30DVCZyyGxK3zsnh3ASIlbewHDrM+9diUyfw0FRWtZyRArz+MB aSGMW1IH9pdm187ibYd+BCv5LyeOnXZdCIofLi0J/3gjlyZw/lgAlBFp96pcgVUJ ufwhiSmsoHyL2fsjYGpgF0GZj9D6ss8dfO4y+4hgSxJ9DTZF6tJ+gMW5HBqi7tiL fjVhILX6PhFWB3o0S9AhkBPd+zbwtDAu9f2/35Ieie2nLgKI+RFPsY/EdaKYs2Ga goLG1kTIxnAOTCFyVOMSmMuXlp+GqgrUzWcbe2KRUrCqT54NqOpG3fRO9Kn0pvsz qU8Z6HR8Yiy+VKDLnSxgdnlKpgstrg== =+385 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 10 17:33:06 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D3F131D01 for ; Thu, 10 Aug 2017 17:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 JOsWmB32HSdm for ; Thu, 10 Aug 2017 17:33:02 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 30BC012EC11 for ; Thu, 10 Aug 2017 17:33:01 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id s6so13861256qtc.1 for ; Thu, 10 Aug 2017 17:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=U3OuPZ7RRY/PYKh4RGIylU+G4Yww19kHUjLiONoCkJ4=; b=YZ500R2Licy7wP3IOkQa5ugKZPeNBWSstCGwFpkkavZwHCm3ipSiKHzf9XfaCfqm2D ORFJ8Z+/rTzN7k0ymg+6XcccNQBRN85Cp9CCxjr4PRty8aQkJ63jdHocPlikLNo6DDCO 3w/BKhM4BkL+5aBw3AEKjRWlVX5q/jV3XaAcLnIuLck46GADvspSCUteng0ktrXbRktz ugiasemltjuOxCmpC4Df1BeUBOv060JO5kAGi9VtRd3ikaKK4VqX/Lm2a5QlpHSbC/aw MCg1rAEE7ZLqr+8cGeC3KEMLzxrDK82foyIM/RAtqQQ74ycIOO+XFOo0RnsVWaNqdxub JeYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=U3OuPZ7RRY/PYKh4RGIylU+G4Yww19kHUjLiONoCkJ4=; b=G+0umSGIfksHswL8x+pF2LIU5y6iUdJw2lRshtjQDnrONmarWNR4+PzvLkUkaXUBT2 ox1CWy4aonxp6Ok6cSjXwtsA3YNq0mPZVbwCNLl8PXy255Eyik4ZSmX9ecPVgCylqo01 lRMw5k1CjdHypoRQJ93Du+NDO3xEPufMyTzo4rRdzcDIRTdA7n13IZ+3Dnu+tF+oc/lk wnX7HmqzTz1Z80BD/pRbK7u3Bn45KjILE9xyVWJXu2d8cGZPUzPWz+BdpRXO8DYCbLFz XTLOHPdJPaKPthxgu6HUZ8gKlYd0NZyNzqYmzsI6CqyqHc9x7oTPx+Lc46pnMRqz7P92 tDgQ== X-Gm-Message-State: AHYfb5jZ6gRhaz6Jmi+8kkM0VbF3pcD9m7rpopUEbmpXJQxW9BUi3XuK p+6PIG8NHdNRCra1 X-Received: by 10.200.55.53 with SMTP id o50mr19204432qtb.211.1502411581087; Thu, 10 Aug 2017 17:33:01 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id c39sm4496350qta.40.2017.08.10.17.32.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 17:32:59 -0700 (PDT) From: Ted Lemon Message-Id: <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_78A8E208-F645-45F7-918F-E5183AEBE63F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 10 Aug 2017 20:32:58 -0400 In-Reply-To: <87poc3yt3d.fsf@toke.dk> Cc: Andrew Sullivan , homenet@ietf.org To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 00:33:05 -0000 --Apple-Mail=_78A8E208-F645-45F7-918F-E5183AEBE63F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 10, 2017, at 6:07 PM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: > Now, assuming that I am wrong and this is actually a serious issue = that > we need to solve (of which I am not opposed to being convinced), I = think > it would be feasible to come up with a solution where we could at = least > allow less capable routers that do not implement the full MPvD = support. > I can think of at least two ways off the top of my head: >=20 > 1. Allow the router in question to offload queries to a more capable > router elsewhere in the homenet. >=20 > 2. Allow the router in question to just query all upstreams and = combine > the results (and so offload the problem to the client). Great. Can you explain, step by step, how to do either of these = things? --Apple-Mail=_78A8E208-F645-45F7-918F-E5183AEBE63F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 10, 2017, at 6:07 PM, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> = wrote:
Now, assuming that = I am wrong and this is actually a serious issue that
we need to solve (of which I am not opposed to = being convinced), I think
it would be = feasible to come up with a solution where we could at least
allow less capable routers that do not implement = the full MPvD support.
I can think of at = least two ways off the top of my head:

1. Allow the router in question to offload = queries to a more capable
  router = elsewhere in the homenet.

2. Allow the router in question to just query = all upstreams and combine
  the = results (and so offload the problem to the = client).

Great.   Can you explain, step by step, how to do either = of these things?

= --Apple-Mail=_78A8E208-F645-45F7-918F-E5183AEBE63F-- From nobody Fri Aug 11 03:15:49 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4BD132630 for ; Fri, 11 Aug 2017 03:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 sMWG2WR2m5EX for ; Fri, 11 Aug 2017 03:15:46 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B8C132635 for ; Fri, 11 Aug 2017 03:15:45 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502446538; bh=dGjjlnhDVoGY60jShRfo4S/ppETSAW4YG33yq6Vr6kI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=izIw0w/0A+MgklRSAO60EFrN0wi4AR5FGS/8K8QuoijGj33pff9GrSJSpzo46ytLJ qcAvGSo1ali9FB6xmCRmRP8RcFq1uDMLrlwuMv/nj25nPW5CscKD5irAbr0ClOykYX 6evMvlwP+3GQIn7vN3aXKQs9lAF4qf+K+uzQk7WtI5/unX2YNfAnec9QY/zuudtnhb eTDVheUfTWm8oiy1IHbyqWXBipd76BPXxT37tnuriBPQhjjUKZsHGN2auR856aQwqN PcyFwXfon/zWbHU1NJwuJwNtxPv3al3vAqXP1JsLM1dudiVjC5ldEcO65nmFKaogvW tyq7EaMOviGvg== To: Ted Lemon Cc: Andrew Sullivan , homenet@ietf.org In-Reply-To: <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> Date: Fri, 11 Aug 2017 12:15:39 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87h8xez9ys.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 10:15:48 -0000 Ted Lemon writes: > On Aug 10, 2017, at 6:07 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> Now, assuming that I am wrong and this is actually a serious issue that >> we need to solve (of which I am not opposed to being convinced), I think >> it would be feasible to come up with a solution where we could at least >> allow less capable routers that do not implement the full MPvD support. >> I can think of at least two ways off the top of my head: >>=20 >> 1. Allow the router in question to offload queries to a more capable >> router elsewhere in the homenet. >>=20 >> 2. Allow the router in question to just query all upstreams and combine >> the results (and so offload the problem to the client). > > Great. Can you explain, step by step, how to do either of these > things? Given that router A supports MPvD and router B doesn't: 1a. Router A exports over HNCP that it supports MPvD. Router B forwards all queries to router A, using a source address in the same prefix as the original request was received from. 1b. Router A exports over HNCP that it supports MPvD. Router B uses router A's address (which would need to be routable inside the homenet, obviously) as the DNS server in RAs. 2. Router B simultaneously forwards the query to all upstream DNS servers known to the homenet, waits for replies from N of them, creates the union set of all those replies and sends that back to the client. If N=3D1 in 2, that corresponds to just ignoring MPvD. Router B could also fall back to 2 if no router A is available on the network. Now, please feel free to explain why you think these would break things... ;) -Toke From nobody Fri Aug 11 04:59:25 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52A5132530 for ; Fri, 11 Aug 2017 04:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 nh91bhYW5bzc for ; Fri, 11 Aug 2017 04:59:22 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8D31324E9 for ; Fri, 11 Aug 2017 04:59:22 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id v7BBxIuE026706; Fri, 11 Aug 2017 13:59:18 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id BE9F8EB344; Fri, 11 Aug 2017 13:59:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id PjMc2-nlhkfw; Fri, 11 Aug 2017 13:59:17 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6D178EB342; Fri, 11 Aug 2017 13:59:17 +0200 (CEST) Date: Fri, 11 Aug 2017 13:59:16 +0200 Message-ID: <87fucygvsb.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "homenet@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 11 Aug 2017 13:59:19 +0200 (CEST) X-Miltered: at korolev with ID 598D9C16.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 598D9C16.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 598D9C16.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 11:59:25 -0000 > Juliusz expressed opposition to adoption, but Ray and Michael said the > reasoning for objection was flawed (that Juliusz was setting the bar too > high and the procedural objections were not valid in the context of IETF > procedures). I probably expressed myself badly -- my objections were technical, not procedural. In simple terms, I said "Why don't we try implementing bits of this document before we adopt". I never said "We need seven interoperable independent implementations before adoption". -- Juliusz From nobody Fri Aug 11 05:01:07 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256B1132663 for ; Fri, 11 Aug 2017 05:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 6xU-2IrF7Xap for ; Fri, 11 Aug 2017 05:01:04 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA3513265D for ; Fri, 11 Aug 2017 05:01:04 -0700 (PDT) Received: from [46.227.151.81] (port=61272 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1dg8cf-0001rh-7C (Exim 4.72) for homenet@ietf.org (return-path ); Fri, 11 Aug 2017 13:01:01 +0100 To: homenet@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87fucygvsb.wl-jch@irif.fr> From: Ray Bellis Message-ID: <21a46afd-bd38-b413-8724-d931a8b64f9d@bellis.me.uk> Date: Fri, 11 Aug 2017 13:01:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <87fucygvsb.wl-jch@irif.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 12:01:06 -0000 On 11/08/2017 12:59, Juliusz Chroboczek wrote: > In simple terms, I said "Why don't we try implementing bits of this > document before we adopt". I never said "We need seven interoperable > independent implementations before adoption". Juliusz, IMNSHO, that's still too high a bar. kind regards, Ray From nobody Fri Aug 11 05:13:26 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AAE131D2C for ; Fri, 11 Aug 2017 05:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 ZJPJjDxiRl4j for ; Fri, 11 Aug 2017 05:13:22 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8629D126B6D for ; Fri, 11 Aug 2017 05:13:22 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id v7BCDJYM031886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Aug 2017 14:13:20 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id v7BCDE8K007382; Fri, 11 Aug 2017 14:13:19 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 519C9EB342; Fri, 11 Aug 2017 14:13:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id tQgVBx_61mGg; Fri, 11 Aug 2017 14:13:13 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 46BF3EB343; Fri, 11 Aug 2017 14:13:09 +0200 (CEST) Date: Fri, 11 Aug 2017 14:13:08 +0200 Message-ID: <87d182gv57.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: Ted Lemon , homenet@ietf.org In-Reply-To: <87h8xez9ys.fsf@toke.dk> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 11 Aug 2017 14:13:20 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 11 Aug 2017 14:13:19 +0200 (CEST) X-Miltered: at korolev with ID 598D9F5F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 598D9F5A.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 598D9F5F.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 598D9F5A.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 598D9F5F.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 598D9F5A.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 12:13:24 -0000 > 1a. Router A exports over HNCP that it supports MPvD. Router B forwards > all queries to router A, using a source address in the same prefix > as the original request was received from. > 1b. Router A exports over HNCP that it supports MPvD. Router B uses > router A's address (which would need to be routable inside the > homenet, obviously) as the DNS server in RAs. This has the significant advantage of not requiring a DNS proxy on each Homenet router. It has the disadvantage of not requiring a DNS proxy on each Homenet router. I like it. (Aside: what's the fallback mode if there's no A in the network? One could either advertise all of the ISPs' DNS servers in RAs, or advertise oneself notwithstanding no support for MPvD. I guess both should be allowed.) (Second aside: what happens when there are multiple As in the network? One could either elect the "master" DNS server, so that all links use the same DNS proxy, or let each router pick one at random, so you get load balancing. I guess only one should be allowed.) -- Juliusz From nobody Fri Aug 11 05:41:09 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EA3132585 for ; Fri, 11 Aug 2017 05:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 zQ1ipn4tCeWk for ; Fri, 11 Aug 2017 05:41:06 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35299132551 for ; Fri, 11 Aug 2017 05:41:06 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id v7BCf0T4006561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Aug 2017 14:41:00 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id v7BCf0Fo013582; Fri, 11 Aug 2017 14:41:00 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 89107EB2F0; Fri, 11 Aug 2017 14:41:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id kwVUKIO5Xv2Q; Fri, 11 Aug 2017 14:40:59 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id CCD73EB36A; Fri, 11 Aug 2017 14:40:54 +0200 (CEST) Date: Fri, 11 Aug 2017 14:40:54 +0200 Message-ID: <87bmnmgtux.wl-jch@irif.fr> From: Juliusz Chroboczek To: Ted Lemon Cc: Markus Stenberg , "homenet@ietf.org" , BARBARA H STARK In-Reply-To: <0F31651E-77F1-433F-831D-424B21D6CDA4@fugue.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <296D97E1-29AA-4D25-A559-BF9D4F7D2023@iki.fi> <0F31651E-77F1-433F-831D-424B21D6CDA4@fugue.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 11 Aug 2017 14:41:00 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 11 Aug 2017 14:41:00 +0200 (CEST) X-Miltered: at korolev with ID 598DA5DC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 598DA5DC.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 598DA5DC.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 598DA5DC.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 598DA5DC.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 598DA5DC.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 12:41:08 -0000 > - round-robin = bad (think why happy eyeballs came up for example of why) > DNS resolvers use round-robining. That's how the protocol works. Does that mean that dnsmasq breaks the protocol? http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h=f22556a595673c7478706f17a22af2095e1068f8;hb=HEAD#l366 -- Juliusz From nobody Fri Aug 11 05:42:41 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5424113239E for ; Fri, 11 Aug 2017 05:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 656FTjJQTAPK for ; Fri, 11 Aug 2017 05:42:38 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A0D1324DB for ; Fri, 11 Aug 2017 05:42:32 -0700 (PDT) Received: from [46.227.151.81] (port=62195 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1dg9Gn-0002kS-TE (Exim 4.72) for homenet@ietf.org (return-path ); Fri, 11 Aug 2017 13:42:29 +0100 To: homenet@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <296D97E1-29AA-4D25-A559-BF9D4F7D2023@iki.fi> <0F31651E-77F1-433F-831D-424B21D6CDA4@fugue.com> <87bmnmgtux.wl-jch@irif.fr> From: Ray Bellis Message-ID: <21305637-264b-823a-acc0-1c726b2d83a4@bellis.me.uk> Date: Fri, 11 Aug 2017 13:42:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <87bmnmgtux.wl-jch@irif.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 12:42:39 -0000 On 11/08/2017 13:40, Juliusz Chroboczek wrote: >> DNS resolvers use round-robining. That's how the protocol works. > > Does that mean that dnsmasq breaks the protocol? AFAICR, that's one of those niggly parts of the DNS protocol that is not strictly specified. Ray From nobody Fri Aug 11 05:46:51 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1653013266D for ; Fri, 11 Aug 2017 05:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 dT9eE2IGzIs1 for ; Fri, 11 Aug 2017 05:46:46 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 5E4A0132668 for ; Fri, 11 Aug 2017 05:46:46 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id u185so15260682pgb.1 for ; Fri, 11 Aug 2017 05:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=09C0fdMXfP8r41aeXP25iZuXXxMoh2XbMH5Vbb0cwXo=; b=ME51XnACt1oouBLfp6bzj8XZ8qMn9ur4+Ij5fcVUX0INbc2UL91iE/6wPMJ9IXwS1g Do61ZN4M8a7oA1r3JqMljgVNJ53a/jYTfyI+2oM0bw4jgcW6eDsPRpEBYdK1vqMXIJKB GS9dhg4lYK76uuGYD+2eHK7OjyKMmZ3TM25qzZwBlE2Kel4381wco3aPUgiKuKLOhF0V 5ybkyaoPKyqIo2Ks70Bxb4kJYnC3HZarv38CVIKxZEdTytlfiYVEK5Q8/oSWdpbp9rQ0 uU4OLV7Me/7XlkIp+C9DFAOPUsYRqvT7o8JFGV9bqeXGUgnEpLU3yK+cLYNoRzg2b+1u ZCng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=09C0fdMXfP8r41aeXP25iZuXXxMoh2XbMH5Vbb0cwXo=; b=DJwrwBlPB67sY2ftNQmUbP5NXQb/V9/0nOjGdas1axelfEeMlFxgZp5bk3xUmvYhI5 v0W/9H0oXFL8KESDuLj+MXxtXEdBNOfQgFUMdYGADRk/f0x8cbw4MFrdfWmR8qfggk/i zW1Z77F7at2j041Ckre2IBftArUaOeEV+y15J9cMxf2hBKVG/MneL6YNugSuiqJkCjtP WYV4L0F10ybwY8xgJ9b52yBVWeecosiEibDnUcZTWMOu8cp81X0ezEPl21uxMV+Dx+ZT /KVzGGviXOkX0JZRXIlhLEPD/EJtYzL4H6xZv26y2Nskbw8tPzIqwWS2OXluXYE0BGTN QMXA== X-Gm-Message-State: AHYfb5hA74PkwUeQv99kKXa7QKd6REdZbZW6qHuSfDMNMUpGAErl5Hc7 d0/iRF7Y55RbyLUbDJNHy8uZs0r6R9ED X-Received: by 10.98.80.208 with SMTP id g77mr16462765pfj.139.1502455605901; Fri, 11 Aug 2017 05:46:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.131 with HTTP; Fri, 11 Aug 2017 05:46:45 -0700 (PDT) Received: by 10.100.180.131 with HTTP; Fri, 11 Aug 2017 05:46:45 -0700 (PDT) In-Reply-To: <87h8xez9ys.fsf@toke.dk> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> From: Ted Lemon Date: Fri, 11 Aug 2017 08:46:45 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: HOMENET , Andrew Sullivan Content-Type: multipart/alternative; boundary="001a11467cc6ae4bad055679b4f5" Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 12:46:48 -0000 --001a11467cc6ae4bad055679b4f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable How does the client know in which moved a response is intended to exist. Also, what problem are you trying to solve here? What you described sounds like it's just an attempt at implementing mpvd on a homenet without requiring that all routers behave the same. On Aug 11, 2017 6:15 AM, "Toke H=C3=B8iland-J=C3=B8rgensen" = wrote: > Ted Lemon writes: > > > On Aug 10, 2017, at 6:07 PM, Toke H=C3=B8iland-J=C3=B8rgensen > wrote: > >> Now, assuming that I am wrong and this is actually a serious issue tha= t > >> we need to solve (of which I am not opposed to being convinced), I thi= nk > >> it would be feasible to come up with a solution where we could at leas= t > >> allow less capable routers that do not implement the full MPvD support= . > >> I can think of at least two ways off the top of my head: > >> > >> 1. Allow the router in question to offload queries to a more capable > >> router elsewhere in the homenet. > >> > >> 2. Allow the router in question to just query all upstreams and combin= e > >> the results (and so offload the problem to the client). > > > > Great. Can you explain, step by step, how to do either of these > > things? > > Given that router A supports MPvD and router B doesn't: > > 1a. Router A exports over HNCP that it supports MPvD. Router B forwards > all queries to router A, using a source address in the same prefix > as the original request was received from. > > 1b. Router A exports over HNCP that it supports MPvD. Router B uses > router A's address (which would need to be routable inside the > homenet, obviously) as the DNS server in RAs. > > 2. Router B simultaneously forwards the query to all upstream DNS > servers known to the homenet, waits for replies from N of them, > creates the union set of all those replies and sends that back to the > client. > > If N=3D1 in 2, that corresponds to just ignoring MPvD. Router B could als= o > fall back to 2 if no router A is available on the network. > > Now, please feel free to explain why you think these would break > things... ;) > > -Toke > --001a11467cc6ae4bad055679b4f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How does the client know in which moved a response is int= ended to exist. Also, what problem are you trying to solve here?=C2=A0 What= you described sounds like it's just an attempt at implementing mpvd on= a homenet without requiring that all routers behave the same.=C2=A0
<= div class=3D"gmail_extra">
On Aug 11, 2017 6:= 15 AM, "Toke H=C3=B8iland-J=C3=B8rgensen" <toke@toke.dk> wrote:
Ted Lemon <mell= on@fugue.com> writes:

> On Aug 10, 2017, at 6:07 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
>> Now, assuming that I am wrong and this is actually a serious issue= that
>> we need to solve (of which I am not opposed to being convinced), I= think
>> it would be feasible to come up with a solution where we could at = least
>> allow less capable routers that do not implement the full MPvD sup= port.
>> I can think of at least two ways off the top of my head:
>>
>> 1. Allow the router in question to offload queries to a more capab= le
>>=C2=A0 =C2=A0router elsewhere in the homenet.
>>
>> 2. Allow the router in question to just query all upstreams and co= mbine
>>=C2=A0 =C2=A0the results (and so offload the problem to the client)= .
>
> Great.=C2=A0 =C2=A0Can you explain, step by step, how to do either of = these
> things?

Given that router A supports MPvD and router B doesn't:

1a. Router A exports over HNCP that it supports MPvD. Router B forwards
=C2=A0 =C2=A0 all queries to router A, using a source address in the same p= refix
=C2=A0 =C2=A0 as the original request was received from.

1b. Router A exports over HNCP that it supports MPvD. Router B uses
=C2=A0 =C2=A0 router A's address (which would need to be routable insid= e the
=C2=A0 =C2=A0 homenet, obviously) as the DNS server in RAs.

2. Router B simultaneously forwards the query to all upstream DNS
=C2=A0 =C2=A0servers known to the homenet, waits for replies from N of them= ,
=C2=A0 =C2=A0creates the union set of all those replies and sends that back= to the
=C2=A0 =C2=A0client.

If N=3D1 in 2, that corresponds to just ignoring MPvD. Router B could also<= br> fall back to 2 if no router A is available on the network.

Now, please feel free to explain why you think these would break
things... ;)

-Toke
--001a11467cc6ae4bad055679b4f5-- From nobody Fri Aug 11 05:48:28 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008961324FB for ; Fri, 11 Aug 2017 05:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 4gUMgH7Yrsj7 for ; Fri, 11 Aug 2017 05:48:25 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391A9132397 for ; Fri, 11 Aug 2017 05:48:21 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502455697; bh=ooAxhYhmfyUbQCzxi7PH7f11IbFjc6dR4cWtZVnQRu4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=fK/fPcDRznOiRcTTh3LmD9T4qybwJsJZsJMAs8LlM6XymnI3LuVR79Q+LtbrkfLNV W7Rpv5bdtRrr+SgrtcoJkL3kpOkLPv1tfd3mTpQyNZNloC4DNymGGv7RJzk6LqzJ/6 7LmB0rHEOel66SuBBLONanPbZAzKrSU9tP82352CRGbpiut1mSuDKzK5/UqonpmY+Z 79CaGIY4stfWOUkx1dARZudWgNZwoEHsWN8rQw/c3PgRZm+AvsS1rRBWo2Nd/ZzeEX TA1n4hiW3LKRwVDbqF7g4srMDb96M1eTENBkVpAlCMmOExE6bNX9iTVdp0n0/las6O QczrKDgKE5bLQ== To: Juliusz Chroboczek Cc: Ted Lemon , homenet@ietf.org In-Reply-To: <87d182gv57.wl-jch@irif.fr> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <87d182gv57.wl-jch@irif.fr> Date: Fri, 11 Aug 2017 14:48:17 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87bmnmz2we.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 12:48:27 -0000 Juliusz Chroboczek writes: >> 1a. Router A exports over HNCP that it supports MPvD. Router B forwards >> all queries to router A, using a source address in the same prefix >> as the original request was received from. > >> 1b. Router A exports over HNCP that it supports MPvD. Router B uses >> router A's address (which would need to be routable inside the >> homenet, obviously) as the DNS server in RAs. > > This has the significant advantage of not requiring a DNS proxy on each > Homenet router. It has the disadvantage of not requiring a DNS proxy on > each Homenet router. > > I like it. > > (Aside: what's the fallback mode if there's no A in the network? One > could either advertise all of the ISPs' DNS servers in RAs, or advertise > oneself notwithstanding no support for MPvD. I guess both should be > allowed.) Yeah, or fallback to 2 (send queries to all upstreams and reply with the union to the client). If you don't want to bother being MPvD-aware, you just set N (the number of upstreams to wait for) to 1, and it turns into a sort of happy eyeballs for DNS... > (Second aside: what happens when there are multiple As in the network? > One could either elect the "master" DNS server, so that all links use the > same DNS proxy, or let each router pick one at random, so you get load > balancing. I guess only one should be allowed.) I'd say don't bother with an election. All routers with the capability are eligible as upstreams. Picking one at random is probably fine, but not sure if we need to specify that? "Pick the first one you see" would probably also work, as long as you update your choice if that router goes away... -Toke From nobody Fri Aug 11 05:50:51 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D583132656 for ; Fri, 11 Aug 2017 05:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 zpmEIoTEq6Pm for ; Fri, 11 Aug 2017 05:50:40 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 C1164132654 for ; Fri, 11 Aug 2017 05:50:40 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id v77so15226099pgb.3 for ; Fri, 11 Aug 2017 05:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AH4ckS67OxKUbUxaxUFMm6gKd7CKH4MGKiAJvafawL0=; b=nq9+cNviGWye/yK2YkQCTflAMN3S3MY4WQOljg59VnLPEOFPGMej8Kuz6km6yHq7Bk yzK2d7AVuMBM252ctfKlVJspXGo/QYX+zuDcMQ7vb7xiSdSgLepp22rae20d81bGXIle /M57H+i4oEWx5q1dnyDbmACCuUTRJl19R2iWtI0oeHj5Qen1ZxUxcmyiroAAC10sfj5N 3JjgbNK9wSS5nVYY4BUMUYoR1hfpQpmnhTrQ1BDzzfBSR9SVzYVHOCgSWYLuD1RgBJXL DElk7FIDuf/tDvIsG/D0xfEPKGA0XtQq8BUXjsESA+EGlQzucu8TAiMUS4GfNrSMVFyR l/mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AH4ckS67OxKUbUxaxUFMm6gKd7CKH4MGKiAJvafawL0=; b=pOm09eKYECibWFg2xptdMyRxuQTf5O/+7xl8pkoljFSOW8TC4qbl3+MRFSODGGTnvX OO5sfI0eCq/VfBbY0TLjNQ1vJxGdezz5/K/fGWt32RPBy6RJiOUPulgSf+lyHZ5ns8Hy N9OylyisdLuqVYJtbqdjBEM3WI0zC/JDvjs6sL/X+TDyhguLKeoLLjrvv+WvCUmpdOPK rq5W3bkrEn/Y6VBPREe5nIVUvzeSmvMFX+F/YIhY1ol5VyPCMQLGQvoMFXqDf4Tm9ZP7 08zKnCvzOOK+FKgrXxMg4ffNWWXTaUTV4qzIE3rjYhPZJdNC+egXLTyDdbp98SGXyMyz CbNg== X-Gm-Message-State: AHYfb5hj5csM/B2EwxPPcjlbrXN8QjL8pN8vbe3u5EwV3R9E4w9mobB+ SzYy++/pig1ItJw1WFxmgZvccVUfBOl6 X-Received: by 10.99.97.204 with SMTP id v195mr14966065pgb.422.1502455840264; Fri, 11 Aug 2017 05:50:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.131 with HTTP; Fri, 11 Aug 2017 05:50:39 -0700 (PDT) Received: by 10.100.180.131 with HTTP; Fri, 11 Aug 2017 05:50:39 -0700 (PDT) In-Reply-To: <87bmnmgtux.wl-jch@irif.fr> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <296D97E1-29AA-4D25-A559-BF9D4F7D2023@iki.fi> <0F31651E-77F1-433F-831D-424B21D6CDA4@fugue.com> <87bmnmgtux.wl-jch@irif.fr> From: Ted Lemon Date: Fri, 11 Aug 2017 08:50:39 -0400 Message-ID: To: Juliusz Chroboczek Cc: "STARK, BARBARA H" , HOMENET , Markus Stenberg Content-Type: multipart/alternative; boundary="94eb2c08b438a673eb055679c2d1" Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 12:50:50 -0000 --94eb2c08b438a673eb055679c2d1 Content-Type: text/plain; charset="UTF-8" What dnsmasq seems to be doing is trying all servers at once. That would work too, if the pattern described in the document is followed. On Aug 11, 2017 8:41 AM, "Juliusz Chroboczek" wrote: > > - round-robin = bad (think why happy eyeballs came up for example of > why) > > > DNS resolvers use round-robining. That's how the protocol works. > > Does that mean that dnsmasq breaks the protocol? > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h= > f22556a595673c7478706f17a22af2095e1068f8;hb=HEAD#l366 > > -- Juliusz > --94eb2c08b438a673eb055679c2d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What dnsmasq seems to be doing is trying all servers at o= nce. That would work too, if the pattern described in the document is follo= wed.

On Aug = 11, 2017 8:41 AM, "Juliusz Chroboczek" <jch@irif.fr> wrote:
>=C2=A0 =C2=A0 =C2=A0- round-robin =3D bad (think why ha= ppy eyeballs came up for example of why)

> DNS resolvers use round-robining. That's how the protocol works.
Does that mean that dnsmasq breaks the protocol?

=C2=A0 http://thekelleys.org.uk/git= web/?p=3Ddnsmasq.git;a=3Dblob;f=3Dsrc/forward.c;h=3Df22556a595673= c7478706f17a22af2095e1068f8;hb=3DHEAD#l366

-- Juliusz
--94eb2c08b438a673eb055679c2d1-- From nobody Fri Aug 11 05:56:03 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD4D1325DD for ; Fri, 11 Aug 2017 05:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 XSiflRgmRfXe for ; Fri, 11 Aug 2017 05:55:59 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81127132547 for ; Fri, 11 Aug 2017 05:55:59 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502456157; bh=68DtMipIDyYt64Xo+7kt7pU9rAjDPj2qlh+Wvm7abAI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ibh1qZTeTZYFGrzRCvtiBt6JuE45HqTUxdfMTAQhYL3LH6598JNYzOU2atXf4udqT Pc4xI1pKLTcoyQ2QD2Pm34z1NxlVRuZ2KywRVqNFus3hbt9RUasr5anG7TVomBWTsj FEcX9zSPqng1rTVTjVEWATpzfBZfGVdpj6L508S6Hy8kx41JOVyFg4My6zC86WE/1h ZULM9fSejNOHlYBQi4GcmQNC1jave4AUIFNRqRYDgt3YoSLqRX8QjouPt81FmRUUIp 3IMFE2qXxZmzN+NVNsHc1sTU3voZz6NID2avLugV2/cJMPcJ43Qzs4Qd67JGKn3Yzd DIVF99E8KBSRA== To: Ted Lemon Cc: HOMENET , Andrew Sullivan In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> Date: Fri, 11 Aug 2017 14:55:57 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877eyaz2jm.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 12:56:01 -0000 Ted Lemon writes: > How does the client know in which PvD a response is intended to exist. Well, in some cases normal source address selection rules are going to do the trick (i.e., the client picks the source address closest to the destination). In others it won't, and the client will get degraded behaviour. > Also, what problem are you trying to solve here? What you described > sounds like it's just an attempt at implementing mpvd on a homenet > without requiring that all routers behave the same. Well, as I said I would be perfectly happy to just ignore the MPvD issue entirely. What I'm trying to do is at least make it optional for a homenet router to implement it... :) -Toke From nobody Fri Aug 11 06:03:13 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD07131D2C for ; Fri, 11 Aug 2017 06:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 OKStI2f-mNbX for ; Fri, 11 Aug 2017 06:03:09 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 A2A051252BA for ; Fri, 11 Aug 2017 06:03:09 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id u185so15419758pgb.1 for ; Fri, 11 Aug 2017 06:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QqOqedArx/cebo+FURmkwB+dln+uSpoEKXRbzjht3gE=; b=eYDa0C57tM9FGNPNn0SPB+japvjvzeiCNz9mi5SKbcKMAmepSPlTJRXriooh2dij8U YmsaMzoNW6WssPKMWwzLs2wQDPLmMkIzwV5vM55OUJOcxBzSIwX9OAo9ddo6gvnkKvCC fGkdLGvwJGRVZS1xjjtQxEc4eH8KFeh592PqQpEWRCPI2s8jfCphSkfSc+UYn4DaCWV3 nFFpWYdrSU0OGCHsRRUsROERxWA+X6Un2FZ2CyfBTs2bcnZVaThItqR0tqYw5rouZW+9 IyepeXzRqtpiMu1708qHk9YoPjaQWZt2EbtQfouemM4CIGbSjcgIpJ2/H4RxROsTLZmX svMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QqOqedArx/cebo+FURmkwB+dln+uSpoEKXRbzjht3gE=; b=TiAsjCtirbF5zcjBoRK9aYgCVG4wZKNMn3z0FGTgq03L3dB60GWkpLDrHWcWRmijeU 0dLqxbAjNPDoDc1CKCAVDNzrNKWc+PxDi6xEIuXuxD6mCoTZ8dXnqB5MjuS2APzy8GkT rLQiPRm6eHXpRrBMmUEtxftLtW3Gfsop3ChWHnnpw+CxEP0Q2VGoSr263IWTL2jjlmqn qqAJ9kZuWIyJ+esZmozR7rQXMBi20rQQ350of35+qbfx/RR8OymqfxlcfdEtr2fsHoTR ow962fmAoSbdF+DLUy12XjICr+VbBc2cn3RPeZMohiOwCHFqwFd7k6uecHd625GjiqRL Zwhg== X-Gm-Message-State: AHYfb5iYNps7blTIrWT0xzYKFIEOfIw6slP25tUen9z2eESNC8HYyX7j BUnAra9WMXfK1h08tgRwyMHZQFE/BOJ7 X-Received: by 10.98.200.152 with SMTP id i24mr16429348pfk.33.1502456589132; Fri, 11 Aug 2017 06:03:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.131 with HTTP; Fri, 11 Aug 2017 06:03:08 -0700 (PDT) Received: by 10.100.180.131 with HTTP; Fri, 11 Aug 2017 06:03:08 -0700 (PDT) In-Reply-To: <877eyaz2jm.fsf@toke.dk> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> From: Ted Lemon Date: Fri, 11 Aug 2017 09:03:08 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Andrew Sullivan , HOMENET Content-Type: multipart/alternative; boundary="94eb2c1113be493b57055679ef33" Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 13:03:12 -0000 --94eb2c1113be493b57055679ef33 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Why do you want it to be optional? What problem are you trying to solve? Do you not know how to do it? Do you think it's resource intensive? Do you think it reduces reliability more than not doing it? On Aug 11, 2017 8:55 AM, "Toke H=C3=B8iland-J=C3=B8rgensen" = wrote: > Ted Lemon writes: > > > How does the client know in which PvD a response is intended to exist. > > Well, in some cases normal source address selection rules are going to > do the trick (i.e., the client picks the source address closest to the > destination). In others it won't, and the client will get degraded > behaviour. > > > Also, what problem are you trying to solve here? What you described > > sounds like it's just an attempt at implementing mpvd on a homenet > > without requiring that all routers behave the same. > > Well, as I said I would be perfectly happy to just ignore the MPvD issue > entirely. What I'm trying to do is at least make it optional for a > homenet router to implement it... :) > > -Toke > --94eb2c1113be493b57055679ef33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why do you want it to be optional?=C2=A0 What problem are= you trying to solve?=C2=A0 Do you not know how to do it?=C2=A0 Do you thin= k it's resource intensive? Do you think it reduces reliability more tha= n not doing it?

On Aug 11, 2017 8:55 AM, "Toke H=C3=B8iland-J=C3=B8rgensen" &= lt;toke@toke.dk> wrote:
Ted Lemon <mellon@fugue.com> writes:

> How does the client know in which PvD a response is intended to exist.=

Well, in some cases normal source address selection rules are going to
do the trick (i.e., the client picks the source address closest to the
destination). In others it won't, and the client will get degraded
behaviour.

> Also, what problem are you trying to solve here? What you described > sounds like it's just an attempt at implementing mpvd on a homenet=
> without requiring that all routers behave the same.

Well, as I said I would be perfectly happy to just ignore the MPvD issue entirely. What I'm trying to do is at least make it optional for a
homenet router to implement it... :)

-Toke
--94eb2c1113be493b57055679ef33-- From nobody Fri Aug 11 06:09:58 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341CE1324FB for ; Fri, 11 Aug 2017 06:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 SeN_HIcqVKYo for ; Fri, 11 Aug 2017 06:09:55 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5541324EE for ; Fri, 11 Aug 2017 06:09:55 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502456991; bh=JkphxgsU3usN0mzhuQStV1te1GaTQyF1Px8wcl/ig2U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=xUrnVC2ddXCq+6YIWQYXms9ejqqXKBeNMD4R7M/nXunJVk2IZ8JvUIFMp1QopV/LX UiJi+xQdJHtExNDcCI5hS7sDpES+XPfEp89ti3ncfuAxhLV/KIAG4gBVz0dtho+lDw AoetcbIkkjD4HcHpHSYRwdPp0qFYjmCkXBJaZZLXwBUCRmH2DT8mbD16XCyDQv4I+9 kGFJ/Mr0La2/VwnmMHF/ghVO09ZAYOvJYEfXAvP4n/ksdTsmKKHVLppOv8t7+ZBY/D pxQFOEclajXYJvrknrYu3zQs1tW+n5nNQ20dHbq5T2agZD1lZ67owran2f6XRcy2Yj FZEA/tD/C+kiA== To: Ted Lemon Cc: Andrew Sullivan , HOMENET In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> Date: Fri, 11 Aug 2017 15:09:51 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <874ltez1wg.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 13:09:57 -0000 Ted Lemon writes: > Why do you want it to be optional? What problem are you trying to solve? > Do you not know how to do it? Do you think it's resource intensive? Do you > think it reduces reliability more than not doing it? Because I'm not convinced the added implementation complexity is worth it; so yeah, the last one I guess... -Toke From nobody Fri Aug 11 06:27:12 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C881324A3 for ; Fri, 11 Aug 2017 06:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 2I6-KXQ_3UbH for ; Fri, 11 Aug 2017 06:27:09 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F9F12711B for ; Fri, 11 Aug 2017 06:27:09 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id v7BDR6Vf019655; Fri, 11 Aug 2017 15:27:07 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id DD19DEB2F0; Fri, 11 Aug 2017 15:27:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id J4XJAMMXjTQi; Fri, 11 Aug 2017 15:27:05 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 33447EB274; Fri, 11 Aug 2017 15:27:02 +0200 (CEST) Date: Fri, 11 Aug 2017 15:27:02 +0200 Message-ID: <877eyagrq1.wl-jch@irif.fr> From: Juliusz Chroboczek To: Ted Lemon Cc: HOMENET , Markus Stenberg In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <296D97E1-29AA-4D25-A559-BF9D4F7D2023@iki.fi> <0F31651E-77F1-433F-831D-424B21D6CDA4@fugue.com> <87bmnmgtux.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 11 Aug 2017 15:27:07 +0200 (CEST) X-Miltered: at korolev with ID 598DB0AA.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 598DB0AA.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 598DB0AA.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 13:27:11 -0000 >>> DNS resolvers use round-robining. That's how the protocol works. >> Does that mean that dnsmasq breaks the protocol? >> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h=f22556a595673c7478706f17a22af2095e1068f8;hb=HEAD#l366 > What dnsmasq seems to be doing is trying all servers at once. That would work > too, if the pattern described in the document is followed. Ted, Can we please agree that this document has no business mandating round-robining? -- Juliusz From nobody Fri Aug 11 06:32:45 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA78A1324A7 for ; Fri, 11 Aug 2017 06:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 jTx4ehxur-FX for ; Fri, 11 Aug 2017 06:32:42 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06A24132488 for ; Fri, 11 Aug 2017 06:32:42 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v7BDPOBW030876; Fri, 11 Aug 2017 09:32:26 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2c9cdqtdk7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Aug 2017 09:32:26 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7BDWOgs013429; Fri, 11 Aug 2017 09:32:24 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7BDWIZk013314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Aug 2017 09:32:18 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi134.aldc.att.com (RSA Interceptor); Fri, 11 Aug 2017 13:32:03 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.30]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0319.002; Fri, 11 Aug 2017 09:32:02 -0400 From: "STARK, BARBARA H" To: Ted Lemon , Andrew Sullivan CC: HOMENET Thread-Topic: [homenet] Status of draft-tldm-simple-homenet-naming CFA Thread-Index: AdMSExv6TskYwTm0TxW2ixuYvce/UAAJxMKAAABdugAAGQAhYA== Date: Fri, 11 Aug 2017 13:32:02 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBF7F5C@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.233.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-11_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708110215 Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 13:32:44 -0000 PiBGcm9tOiBUZWQgTGVtb24NCj4gQmFyYmFyYSwgSSBzZWVtIHRvIHJlY2FsbCB0aGF0IHlvdSB3 ZXJlIGVudGh1c2lhc3RpYyBhYm91dCB0aGUgd29yayB3aGVuIGl0IHdhcyBkaXNjdXNzZWQgaW4g dGhlIG1lZXRpbmcuIMKgIFlvdSdyZSBhbGxvd2VkIHRvIGJlIG9uZSBvZiB0aGUgcGVvcGxlIHdo bydzIGluIGZhdm9yIG9mIGl0LCBkZXNwaXRlIGJlaW5nIGNoYWlyLiDCoCBJbmRlZWQsIGFzID4g Y2hhaXIsIHlvdSBjYW4ganVzdCBhZG9wdCBpdCBieSBmaWF0IGlmIHlvdSB3YW50LiDCoCBJIGFj dHVhbGx5IGFncmVlIHdpdGggUmF5IGFuZCBNaWNoYWVsIHRoYXQgSnVsaXVzeiByZWFzb25pbmcg d2FzIGZsYXdlZCwgYW5kIGFtIGRlZmluaXRlbHkgaW4gZmF2b3Igb2YgYWRvcHRpbmcgaXQgYW5k IHdvcmtpbmcgb24gaXQuIMKgIEkgYWxzbyBhZ3JlZSB3aXRoIA0KPiBBbmRyZXcgdGhhdCBpdCBz aG91bGRuJ3QgYmUgdGhlIGZpbmFsIHdvcmQgb24gbmFtaW5nIGluIHRoZSBob21lbmV0Lg0KDQpI ZXJlIGFyZSBteSBub24tY2hhaXIgdGhvdWdodHMuDQpJIGRvIHRoaW5rIHRoZXJlIGlzIHZhbHVl IGluIGRlZmluaW5nIGEgaG9tZSBuZXR3b3JrIG5hbWluZyAvIEROUyBhcmNoaXRlY3R1cmUuIEkg KGVudGh1c2lhc3RpY2FsbHkpIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhlIGNvbmNlcHQuDQpUaGUg bm9uLWJvaWxlcnBsYXRlIHBhcnQgb2YgdGhlIHRhYmxlIG9mIGNvbnRlbnRzIGlzIGFib3V0ICJO YW1lIFJlc29sdXRpb24iLCB3aXRoIGhlYWRlcnMgZm9yICJDb25maWd1cmluZyBSZXNvbHZlcnMi LCAiQ29uZmlndXJpbmcgU2VydmljZSBEaXNjb3ZlcnkiLCAiUmVzb2x1dGlvbiBvZiBsb2NhbCBu YW1lcyIsICJETlNTRUMgVmFsaWRhdGlvbiIsICJTdXBwb3J0IGZvciBNdWx0aXBsZSBQcm92aXNp b25pbmcgRG9tYWlucyIsICJVc2luZyB0aGUgTG9jYWwgTmFtZXNwYWNlIFdoaWxlIEF3YXkgRnJv bSBIb21lIi4gSSBzdXBwb3J0IHRoZXNlIGFzIGEgZ29vZCBpbml0aWFsIHNldCBvZiBoZWFkZXJz IGZvciBhIHRhYmxlIG9mIGNvbnRlbnRzLg0KSSBkb24ndCBsaWtlIHJlcXVpcmluZyBETlMgcHJv eHkgaW4gYWxsIGhvbWVuZXQgcm91dGVycyBhbmQgd291bGQgbGlrZSB0byBleHBsb3JlIG90aGVy IG9wdGlvbnMuIEJ1dCB0aGUgRE5TIHJlc29sdmVyIGRvZXMgaGF2ZSB0byBiZSBzb21ld2hlcmUg aW4gdGhlIHByZW1pc2VzLg0KSSdkIGxpa2UgdG8gYWN0dWFsbHkgZXhwbG9yZSB3aGF0IHdlIGNv dWxkIGZvciBETlNTRUMgaW4gdGhlIGNvbnRleHQgb2Ygc29tZSBob2xpc3RpYyBob21lIG5ldHdv cmsgImtleSIgYXJjaGl0ZWN0dXJlLCBhbmQgbWF5YmUgd2UgY291bGQgZGlzY3VzcyBzb21lIG1v cmUgZXZlbiB3aGlsZSBhZ3JlZWluZyBpdCdzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2MuIA0K SSBhZ3JlZSB3aXRoIHNjb3BpbmcgdG8gaW50ZXJuYWwgcmVzb2x1dGlvbiBhbmQgbm90IGRlYWxp bmcgd2l0aCBleHRlcm5hbCByZXNvbHV0aW9uLiBCdXQgSSByZWNvZ25pemUgb3RoZXJzIG1pZ2h0 IHdhbnQgdG8gZGlzY3VzcyBtb3JlLg0KSSBmdWxseSBhZ3JlZSB3aXRoIHRoaXMgYmVpbmcgYSBz ZXBhcmF0ZSAicHJvdmlzaW9uaW5nIGRvbWFpbiIsIGJ1dCBJJ20gbm90IGZ1bGx5IGNvbnZpbmNl ZCB0aGUgcHJvcG9zZWQgc29sdXRpb24gaXMgdGhlIHJpZ2h0IG9uZS4gDQoNCkNvbmNsdXNpb246 IEFzIGxvbmcgYXMgd2UgY2FuIGtlZXAgZGlzY3Vzc2lvbiBhbGl2ZSBhbmQgaGVhbHRoeSwgYW5k IG5vdCBnbyB0byBXR0xDIHByZW1hdHVyZWx5LCBJJ20gaW4gZmF2b3Igb2YgYWRvcHRpb24uDQpU aGUgbWFpbiByZWFzb24gSSBoZXNpdGF0ZWQgdG8gbGVuZCBzdXBwb3J0IGlzIGZyb20gYmFkIGV4 cGVyaWVuY2UgaW4gb3RoZXIgZ3JvdXBzIHdoZXJlIGF1dGhvcnMgaGF2ZSB0cmllZCB0byBvYmpl Y3QgdG8gY29tbWVudHMgb24gdGhlIGJhc2lzIG9mICJ5b3Ugc3VwcG9ydGVkIGFkb3B0aW9uLCB0 aGlzIHRleHQgd2FzIGluIHRoZSBkcmFmdCB3aGVuIGl0IHdhcyBhZG9wdGVkLCBhbmQgeW91IGRp ZG4ndCBvYmplY3QgdG8gdGhpcyB0ZXh0IHByaW9yIHRvIGFkb3B0aW9uIi4gQnV0IHNvIGxvbmcg YXMgdGhlIGNoYWlycyBkb24ndCB0b2xlcmF0ZSB0aGlzIHNvcnQgb2YgYXR0aXR1ZGUsIEkgdGhp bmsgd2UnbGwgYmUgZmluZS4gQlRXLCBJJ3ZlIG5ldmVyIHNlZW4gdGhhdCBhdHRpdHVkZSBmcm9t IFRlZCBvciBEYW5pZWwuIEFuZCBJIGhhdmUgY29uZmlkZW5jZSBpbiB0aGUgY2hhaXJzJyBhYmls aXR5IHRvIGJlIGludG9sZXJhbnQuDQoNCkJhcmJhcmENCg== From nobody Fri Aug 11 06:34:57 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E9D13218C for ; Fri, 11 Aug 2017 06:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 CHOodEQRmehV for ; Fri, 11 Aug 2017 06:34:49 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 33887132642 for ; Fri, 11 Aug 2017 06:34:48 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id d136so20376103qkg.3 for ; Fri, 11 Aug 2017 06:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vnp/VYecB1MD9P9KVdK75cJNMoXIEa96aZtjr92nnYQ=; b=HDhlWhdO68KEhE5QiDTukFzUaSw8LKO3PcrgSIjNVfQqcFRQ6kcErJDxxSQUnTAftH Yiv9TtNhEtx+syZ+yPYaB0Ijkjt9095ILoRvvvjFXwTx1ANOomtb8LUunAfGupVb3C36 hcGpv+VjExQxNmDIC/pnIHAMsrRktHjaWUWpWrErGybgHCTYiIgMD7wHt83CqkbRUPMb AlM/pV8MTXQUFdvUrLT3YSFO/fkx5s6dKdg9Jn8LvdTUHUoRY22cl69ThUv0MB2C9a2W pDw7qlph1b2pokCuWspAPJ6z2WRkN/qp3OMqBg1F/xm7LQTzvUYLY8IXogyuECgC+pMi diWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vnp/VYecB1MD9P9KVdK75cJNMoXIEa96aZtjr92nnYQ=; b=cOlnTNVzIPIXSSQtOMsDKXL9T7FBGgv7h7T7o8LzmW1XeJGed7Ue3DbSHW0N8XYsNm VUwB/X6QoVjjy2qZmFwAG63vD6URStbC5MIH46iH1FfnFgSzTo5wJbLyNYBq4yr2Ggii XJoFDR2e9C7fBnRbbEihOiO7CEbYpFWbqp32kGtNPK1QHUorEpvYIkSJH8IokCJSPjX7 6Lrv01cl1wS7VoXcYxJvX2ghuNA4NDMlfdzzY+opmwzJyd188JplhtYnTew+dW1eeHkJ 5kTFBkltltSrmfvMRDKvQjEFipSOOmfhyoB+eL1+ydA+otbDdp9+iRcqwvw0YQaA3vYR bvxA== X-Gm-Message-State: AHYfb5hrDOb+ZfeDg0A7cdJo+hT2O/fvEqtg0kex9CMY0WbgvD7m+cLo 9ZKBnI6OjgaJlbH+aUkJ4Q== X-Received: by 10.55.95.196 with SMTP id t187mr18035855qkb.255.1502458487264; Fri, 11 Aug 2017 06:34:47 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id d125sm515163qkg.43.2017.08.11.06.34.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 06:34:45 -0700 (PDT) From: Ted Lemon Message-Id: <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7E74F83C-F62F-442E-9D62-F0728B992FC3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 11 Aug 2017 09:34:43 -0400 In-Reply-To: <874ltez1wg.fsf@toke.dk> Cc: Andrew Sullivan , HOMENET To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 13:34:56 -0000 --Apple-Mail=_7E74F83C-F62F-442E-9D62-F0728B992FC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 11, 2017, at 9:09 AM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: > Because I'm not convinced the added implementation complexity is worth > it; so yeah, the last one I guess... This is a refrain I've heard from you, Juliusz and Markus, which I = actually find a bit disturbing: the desire not to really solve the = problem because it's not trivially easy. That's not the charter of = this working group. The reason we chartered this working group was = _explicitly_ to study the problem carefully, to see what we needed to do = to solve it well, to describe what that was, and to do it. My experience both in doing math when I was a math student, and in doing = computer science now that I'm a computer geek, is that often times a = shortcut solution to a real problem winds up being harder than a good = solution in the long run. Sure, you saved a little time with that = shortcut, but the long term result was that you didn't actually solve = the problem, and now you have a brick that you have to fix in-place, = instead of a green field where you can do what needs to be done without = continuing to support the old solution. Think about the routing problem. We need source-specific routes. = We're extending babel to add them. Why is that? Couldn't we have just = relied on happy eyeballs to eliminate the bad routes? As for the MPvD problem, you say that you'd like to avoid the = complexity, but have you actually explored what the complexity looks = like? Have you asked the Android folks and the Apple folks why they = are interested in (and in some cases, already have) put support for this = into their devices? I've attached a picture of the router I'm using for my development work = on this (the second, really tiny board is the serial console interface = I'm using to debug). It's got 8G of flash, 2G of RAM, a 1.2G 4-core = arm64 CPU, gigabit ethernet and a fast I/O bus for both wired and = wireless network interfaces. It cost me US$24.99. This is more than = capable of supporting the complexity we are talking about, which I don't = think is really that much complexity anyway. Are you targeting a cheaper, less capable device than this? If so, can = you talk about why you think that's important for Homenet? --Apple-Mail=_7E74F83C-F62F-442E-9D62-F0728B992FC3 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_B1592D56-807D-431A-8A72-EF1C33BA008C" --Apple-Mail=_B1592D56-807D-431A-8A72-EF1C33BA008C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 11, 2017, at 9:09 AM, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> = wrote:
Because I'm not = convinced the added implementation complexity is worth
it; so yeah, the last one I guess...

This = is a refrain I've heard from you, Juliusz and Markus, which I actually = find a bit disturbing: the desire not to really solve the problem = because it's not trivially easy.   That's not the charter of this = working group.   The reason we chartered this working group was = _explicitly_ to study the problem carefully, to see what we needed to do = to solve it well, to describe what that was, and to do it.

My experience both in = doing math when I was a math student, and in doing computer science now = that I'm a computer geek, is that often times a shortcut solution to a = real problem winds up being harder than a good solution in the long run. =   Sure, you saved a little time with that shortcut, but the long = term result was that you didn't actually solve the problem, and now you = have a brick that you have to fix in-place, instead of a green field = where you can do what needs to be done without continuing to support the = old solution.

Think about the routing problem.   We need = source-specific routes.  We're extending babel to add them. Why is = that? Couldn't we have just relied on happy eyeballs to eliminate the = bad routes?

As = for the MPvD problem, you say that you'd like to avoid the complexity, = but have you actually explored what the complexity looks like?   = Have you asked the Android folks and the Apple folks why they are = interested in (and in some cases, already have) put support for this = into their devices?

I've attached a picture of the router I'm using for my = development work on this (the second, really tiny board is the serial = console interface I'm using to debug).   It's got 8G of flash, 2G = of RAM, a 1.2G 4-core arm64 CPU, gigabit ethernet and a fast I/O bus for = both wired and wireless network interfaces.   It cost me US$24.99. =   This is more than capable of supporting the complexity we are = talking about, which I don't think is really that much complexity = anyway.

Are = you targeting a cheaper, less capable device than this?   If so, = can you talk about why you think that's important for Homenet?
= --Apple-Mail=_B1592D56-807D-431A-8A72-EF1C33BA008C Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=IMG_20170811_092742.jpeg Content-Type: image/jpeg; name="IMG_20170811_092742.jpeg" Content-Id: <15D48838-96D4-45AC-B801-2147E01C3E22> /9j/4AAQSkZJRgABAQAASABIAAD/4QQARXhpZgAATU0AKgAAAAgACgEPAAIAAAAHAAAAhgEQAAIA AAAJAAAAjgESAAMAAAABAAEAAAEaAAUAAAABAAAAmAEbAAUAAAABAAAAoAEoAAMAAAABAAIAAAEx AAIAAAAUAAAAqAEyAAIAAAAUAAAAvIdpAAQAAAABAAAA0IglAAQAAAABAAAC9gAAAABHb29nbGUA AFBpeGVsIFhMAAAAAABIAAAAAQAAAEgAAAABSERSKyAxLjAuMTQ3NTQ4NzY2egAyMDE3OjA4OjEx IDA5OjI3OjQyAAAigpoABQAAAAEAAAJugp0ABQAAAAEAAAJ2iCIAAwAAAAEAAgAAiCcAAwAAAAEA 3QAAkAAABwAAAAQwMjIwkAMAAgAAABQAAAJ+kAQAAgAAABQAAAKSkQEABwAAAAQBAgMAkgEACgAA AAEAAAKmkgIABQAAAAEAAAKukgMACgAAAAEAAAK2kgQACgAAAAEAAAK+kgUABQAAAAEAAALGkgYA BQAAAAEAAALOkgcAAwAAAAEAAgAAkgkAAwAAAAEAEAAAkgoABQAAAAEAAALWkpAAAgAAAAcAAALe kpEAAgAAAAcAAALmkpIAAgAAAAcAAALuoAAABwAAAAQwMTAwoAEAAwAAAAEAAQAAoAIABAAAAAEA AAKAoAMABAAAAAEAAAHgohcAAwAAAAEAAgAAowEABwAAAAEBAAAApAEAAwAAAAEAAQAApAIAAwAA AAEAAAAApAMAAwAAAAEAAAAApAYAAwAAAAEAAAAApAgAAwAAAAEAAAAApAkAAwAAAAEAAAAApAoA AwAAAAEAAAAApAwAAwAAAAEAAQAAAAAAAAAAA0EAAMM7AAAAAgAAAAEyMDE3OjA4OjExIDA5OjI3 OjQyADIwMTc6MDg6MTEgMDk6Mjc6NDIAAAACTwAAAGQAAAACAAAAAQAAACwAAAAZAAAAAAAAAAEA AAACAAAAAQAAAG8AAAH0AAAB0wAAAGQ5MDk3OTkAADkwOTc5OQAAOTA5Nzk5AAAADAAAAAEAAAAE AgIAAAABAAIAAAACTgAAAAACAAUAAAADAAADjAADAAIAAAACVwAAAAAEAAUAAAADAAADpAAFAAEA AAABAQAAAAAGAAUAAAABAAADvAAHAAUAAAADAAADxAALAAUAAAABAAAD3AAQAAIAAAACTQAAAAAR AAUAAAABAAAD5AAdAAIAAAALAAAD7AAAAAAAAAAqAAAAAQAAADIAAAABAAAGYAAAAGQAAABIAAAA AQAAACMAAAABAAAL5wAAAGQAAAAAAAAAAQAAAA0AAAABAAAAGwAAAAEAAAAqAAAAAQAAABQAAAAB AAAAfwAAAAEyMDE3OjA4OjExAAD/4QobaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hw YWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBt ZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQuMCI+IDxy ZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4 LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHhtbG5zOnhtcD0iaHR0cDovL25z LmFkb2JlLmNvbS94YXAvMS4wLyIgeG1sbnM6cGhvdG9zaG9wPSJodHRwOi8vbnMuYWRvYmUuY29t L3Bob3Rvc2hvcC8xLjAvIiB4bXA6Q3JlYXRvclRvb2w9IkhEUisgMS4wLjE0NzU0ODc2NnoiIHht cDpNb2RpZnlEYXRlPSIyMDE3LTA4LTExVDA5OjI3OjQyIiB4bXA6Q3JlYXRlRGF0ZT0iMjAxNy0w OC0xMVQwOToyNzo0MiIgcGhvdG9zaG9wOkRhdGVDcmVhdGVkPSIyMDE3LTA4LTExVDA5OjI3OjQy Ii8+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/PgD/7QB4UGhvdG9zaG9w IDMuMAA4QklNBAQAAAAAAD8cAVoAAxslRxwCAAACAAIcAj8ABjA5Mjc0MhwCPgAIMjAxNzA4MTEc AjcACDIwMTcwODExHAI8AAYwOTI3NDIAOEJJTQQlAAAAAAAQAvfF3o7C2RG+xkm1yqp1j//AABEI AeACgAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMD AgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUm JygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaX mJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4 +fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncA AQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6 Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeo qaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2wBDAAICAgIC AgMCAgMFAwMDBQYFBQUFBggGBgYGBggKCAgICAgICgoKCgoKCgoMDAwMDAwODg4ODg8PDw8PDw8P Dw//2wBDAQIDAwQEBAcEBAcQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBD/3QAEACj/2gAMAwEAAhEDEQA/AP03v/DNtfyyTG4nh85kaREcbHKDb8wx nBX5WGcEe/NdGFAAUcAdPavGD8bNLxiLRNQf/tiR/MCoj8Z424Tw/fc/3go/mwr1YuHc8DlltYvf GOb/AIlui2I/5b36ufpCjPn8wK7LwBbmDwlZ8YMxkk/76Y/4V4Z4m8UXXjG8sbmaxaxh08S7FZlZ 3aUBckAkAAZ785q5oPxM8T6BbyaPf6VFfW0DH7JNDKEcwkZ2So2MOrZG5SQwweDmuiK/dOVuoW15 T6TdFYFHGVIIIPcGs6DSNMtvspgtkT7FGYocD/VxtjKr7HArxhvjHq2Pl0DHpunT/Goh8YdfbpoU an3uF/xrHmj2KUWtT37bivmzx+ftXxGvYwc+RaWUIHoXaRz/AErU/wCFs+KXb5dItwP+u+f6GuHu L+81+8vdcug1td3rLkoMBPLXYmzPXb1yR17YqqSTqxSQ5K0Xc+vxGERYh0QBfyGKrXFpbXcTQ3US zRN1RxuU9+Qa+crP4n/EOGyggvoLC7ukULJOpeMSkcb/AC8HaW6lQSAehxVv/hZfj+Qfu7OyB+sh /klZNWduV/cXa+p9A21na2cfk2kKQR5ztRQoyfYYqcsIwznjaGb8hmvnX/hP/ibJxHDaL9IpT/7L TZvFHxOvoXtpWSJZRtLRWzlgp4OM8fiaVm1pFk27szvg1F5mq6bcE5LpdT8/9NGds/8Aj1fUjAE+ 1fJH9ja3o0NreaSbnTJNNKNFKIyVCqNpWQMMMjKSGBx68EVtx+NPiHdSpBb6grSOQAqW4JJ9ua9C tTfu2V9DmutT6WIwaUDNeCFfjDNg+ZMufSFR/NqT+zvi7L965uBn/ZjH9axs7fD+RLj5m/8AGvL+ FbC3HHn6rYqfcLJuP8q2vhYY/wCwboIwL/aTuAPI+UYz6ZFeeSeCvHmotGdY8698li6CV02q2Mbs A9QDx6VzuueE9d8NzR6pLPPpRuysBeCYKsjDJRWAyC3XbxnGRW8IN0pLS7e1x6cyPq/8OtAr5Y0L w54v8QSsLDVLyXyPvM9xhRu7dO9dOPhh42cgyapJ/wCBLf0FcUqc1pJJfM3XL3PfzsH8QH418t/E ANP8TNXeP5/K06yhGOcsTK+PryK61PhV4oOPM1Q597iQ/wBKuQ/CjVogf9Kh3McsxLMzH1JPJrow 0VGqpTaSRFT4bI7zwHrmkal4I0G7sLqOSF7KHDbgOVXawOehDAgj1rpXv7FeXuYx/wADFfJ+u+FY PDeuPochVJ5YvtYWJmVXR3KlwBgZ3ghvc+9dhoXwrbXtLh1JrpYopslASznAOM9fUVpKhJLmVrdy G4s95fWdJj5e8hH1df8AGoR4j0GNtzahCAvJ+cdBzXk3/Ckrb+O9Q/8AAD/jVuD4M6fE28XgyO4i H+NLkbW6/Eh8tzxjQtStvDuoeHtb1MNHa2+oK8zgZ8pJjIodh2UF1yewOa+o/wDhOfCQXc2qwAf7 4rl2+Fdm6Mj3zHIxygI/nXh02nWFte3NlIiKbW6a0c7APnWTZ6dCSCPrXpVKSqteyktF+RimlfmR 9It8QvBi9dVhP0bNV3+JnglBzqkZx6c1kR/CHQ0ULLM5YdcKoGfyqynwq8OKcl5D/wB8j+lcHI/5 l9zNPdXQ5Px54v0DxNoMWmaLcfaZjeW0p2g4VIX3sSfwxXM+A/Ftn4P1rV7fW43jtNRS2lhmVdy7 4g8bo2OhHykeoPtXr8Xwz8ORdDLz/tAf0rn/ABn4L0XRvC+p61aLK0unQPcbS2dwjG5hz7ZxXTBQ VJwctW77Ete8nY0T8XPBYOFnlOP+mTVC3xd8Jrkr57Y9IjXnPgvS9N1nxPFo98pZHtpbgAHGRGUX BP8AwMV7cPAHhQc/Y/8Ax41jUoOnLllPX0KUovZHISfF3wyfuwXLZ9IzXlfiS+XxP4ivdZhjeG2n tYLZA/DnyvMLMR2GZOPpX0MPA/hdcYsVP1J/xqdfCHhqPpYJj8f8a1o8sJqcm3YU9VZI8W8I/Et9 A8NaXoOsabNLdadbx2zSRYZH8lQgYfUAGuhb4v2mMppFw35VQ+Jum6dol3ov2C2EQ1BriN9vTMUY kU49+RWr8KbHS9b0fUbu9s0eS21Ce1BYZ+WJUwfxLGs5YdcntFJ2vtYrm1tYpt8Xg33NGm/FlFQn 4s30yOlvozI5RgrPIMBiMDPtXsn/AAj+hr92xhH/AAAU9NG0hellCP8AgArkdKL3b/Au/ZHxzbaZ f6Qmg3lhIsl7oEsUyF+FkKxtG4PoGDH6V6h/wtrxEVAOix5HX96K97GmaYBgWsX/AHwP8K+S/iVe zaPceMX05FjfS/MaAY+Uf6Mkq8fVjXoShDET6ppfkZRbitdTu/8AhanimQfu9Hi9OZM/ypP+FmeM GHGkQg/7xP8ASvdtJsbKLS7PyoY8eREfujnKA5/GrkqRRozJEpKgkAADOO3SvN9nDu/vOlS8j5i1 zWvEvi5bKDU7ZbaCyn+0BYgzF3CMi5OOAoYn3OKytHfxJ4NvtR1LQ0XytUMbzpMjbfMiTywwI9VA B+lfWMJDxI7RhGYAleDgntkdaz9djWbQtRjCgn7NMVyP4ghI/UV1qUFT9ly6XvvqTq5c1z59T4ie P53WKCO2Z3OAArMavHxJ8V36W0S/9sXrE+H13KfiH4eRm/c3dnesV7GQRRsp/AFsfWvqp+D16VlW w9OnPlV/vKjJtanzZ/a/xcm+6iL/ANsGrDuPBXiHV11GTWLWa7m1Zma5YptB3RiIKo/hUIoA/Pqa +np575bmKO3iDQtje5bBXnsO/FWzISf6U6TjTlzJahJNo+U2l+IvhuCLT31F4Y41Cx+bDltqjA5y Aas6fN8UNaDvYam0qxkBikIwD1wSWr1L4qAnT9NkHQTuh/4FGSP/AEGsD4FSBtD8QQMS0kOt3m4s cn5wjL+AUgD2FOWHpez9pbVvuCk78pgjQvi84O/UJgfaNB/Wql74F+IOtWcum65d3F3ZXAAlhJRF kUEHaxHO0kDIB56V9MZ700vWMadNNe6U27HzZcfDbxNLPHe28b2t1FkLLHIoYBuSOcgg46Va/wCE I+JJ4Oq3I/7aRf4V9DE0oNdFVRqS5pLUiPuqyPnf/hX/AMRTwdWuc/8AXaP/AOJpf+Fb+P2OTq84 /wC26D/2WveL6G8uGj+y3BgC7t2B1yOPyqk2nakXzHfuozz3PTA/KsfZU/5fzK5n3Pnu/wDAmreH pZNX1UtcTXWyJ7h5PMbbHnYnYKoySAB1JJ5r5e+IjpYeK7lNuPNWOTOP7wx/Sv0V8awNL4VulzuM Plvnv8rDJr4h+IlhbPqltczR7jJFtzx/C3/168LiKjGrlbsvhkv8v1PfyKpyY3Xqn/n+h4vHqrDg Hr7f/Xq6mpuwyW69jit7+ztLI5t1P5Uv2DSl4Fqn86/EfYrqz9W9pHsYDXobqR+IFRi4tz97afyr ojY6VjLQR4+lRmy0cH/UR/8AfGaHRT6lc67GELqEcptGPpTTqUSjqG/H/wCtW+sGnrjy7VD9I6na 20vb81qu4/7Ap+wj3IdVdjlDqaE8Y/P/AOtTTqYx2/OuwjtdMKc2yj/eRRQ0Wmf884fbhf8ACq9i l1J9ov5TiH1RCP4T+JqFtVRepUZ9zXbNZwrubyI9p5GxMms0rpsAIk2qx7OoH8s0vYxJ512OVbVl IzuX681F/aq9mQ4+p/rW9c215ciT7AYQoGcdGx+WeaNNhtozsuEbze5xj9azVO7sa80Ur2OZfVCe AQc+x/xqo+pcHOP++en616UzxA7YwePVaeVbadw6/gap0UT7ZW+E8lm1DKMdm4kf3T/jXBazqMiq x8th/wBszXuWpanbQRkSuo29fm7181/GH4oWPg7QJtRQia6kPl28QON8rDgHHOAOW9q66ODjUmox 1bJni1CLk1ZI+aPi/wDEWbSIzpVgcX9wOPl/1aHjeR6/3fz7V4l8NfAGp+MdXWdo3eBG3SSYLfU4 5yT296zdN0vxJ8SPFwVma7vtRky8jZxz1P8Asqo4HYAV+n3w68D6T4J0S20qyAO1QZJMYLv3Jz+g 9K+xrzhl2H9lT+N/1/wx8pTU8wr+0n8C/q3+ZkeGPDjaJZQWdhZvHFCoCjyz/Pb3713cL6ioH7qT 6iM//E16TaPCUwXRFHdmFW0u7Q/KJQW9eCP518FKmp6t6n3Ea3KrKOx//9D9N18EeEV/5hkZPuWP 9anXwn4XT7ulwfiuf51tu6qpZjhR1J4AHvXK+HfEqa9c3caeWI4wkkJVss0L7lBcdmypOPQivajc 8BXNdfDvh5Puabbj/tmK8K+JulW2leJ9IbTAkMN/BcefAFAUNDtKSJjoTuKsOh4PUc/ROQa+e/ib N5/jqC2AP+h6bu/GaXH8lNaxbUkg6M9Z8IaDpkHh2yle0ieadBI7sgYksfUg9q6gafpy9LWH/v2v +FGnw/ZtNtLcceXDGuPooqtq011HYStYuiXJwI/MIC7iQMc8ZPbPGcVlJtu47l9LezXhYIx/wBf8 KlMcHaNAP90VzuhXM0z3kU880jwOqlJlQPGSu7G6P5WBByO46V0a81Nh3PlTX7NLb4heIbGzZvsp ntmSMnKxyTx5kVPRScNt6Ak44OK+r4LaGzgS3gRY0iUKFUYHAr5gtE/tP4i6tJ1E2sCP8IVjX+hr 6lk6nHOa2k24QTDZuwzzT2JpwmY9z+dcXrl3Amr6faXl21rbNHcSOVkMW4rsCjIOerE4rR8OvePp aNeM7kvJ5bSDEjRbz5ZbgfMVxnjP41nyktm/cCKaCWG5USQujCRW5VlIIYEdwRxXzH8GrcLqOlRo S8cMErJuJZggBCZJ5OFwMmvobXbj7HoWpXW7Hk2s7/TCE14t8GrXZdQEj/U2CfmwWuii2uf0M5LR H0KxAFQGaNDtdwpPQEgVI/NcgdJubrxFc30qx+QqQInmRB923czbWJ+Xk4NZIk7DdxXlXxlSKXwM 8MqBzJfWG3PVWE6sCPcY4NeojIryb4xOToWkQD/lvqtsD9EDv/Sp6r1X5lI0vhSmLHU36AzIPyXP 9a9RLYzXnXwvQjQbqQD79yf0Va9AkBKsucZGM+lbV9akhR0SKcWqWE1x9liuEaYZ+UHn5euPXHfF Xyc1xulabqsDadDOojjsEKPyrLIdpAZONyk5yefauvHrWKRbfY+d/iiVfx5pyjkxaXIf++7gf/E1 678PkCeCNH94S3/fTsa8d+JAz8Qs/wDPPSYR/wB9XEh/pXt3g2PyvCGjIOCLWM/mM12v+BD1Zj9p mve3cNjA1zcttjXGT/vEAfqaYt5C149iD++jRZCP9liVBz9Qaq61pw1fT5LEsFEhQnPcK4Yj8cYq Kz0a3stTuL+2ARbiKOPbycFGY5yfXdUJ6BY2QeK+Q9e/ea7q7Do+uY/8moxX14oya+RL/wCfWb0j +PxAR/5OqK6aDtKX+F/oRJafNH2HNw7Y9T/OqpPpVqU5kb6n+dZl5byzqohnaB1bOVAOR0wQa5kA 3Tb5dQs4b6MFUnXcAeorm/iN83w+8Sr66bdf+izXT2FlFYWcNlBnZCoUZ68etc38QQP+EC8R55/4 l11/6LapezKjueP/AA3wPiHZ+v8AZd2P/H4K+lHJFfNvw6GPiDZN1/4ll3/6HBX0m3tXdineq/l+ REPhRyP/AAkJfXJdCSMCZZFAZshdnlq5Oe7c4AH1rqOe9Z8uk2MryyPH88siSk553xgKpB7EAYrR xXLcs8V+MQPneFm/6e7ofnauf6Vd+CZxo2vpx8ms3H/j0ULf1qD4wfd8MH/qIzD87Ob/AAp3wWYL ZeJ4/wC7q5P/AH1awGulv/Z/+3v0F9r5fqeynlsVh6Hfy6hpsVzOQZWaQMB/sOyjj6Ctw8+1UIdP sreUywQrG7ZyVGOpyfzNcfQsuCvkr4q24k1jxvb/APPW0jf/AL6ssf8AstfW3SvmL4iwiXxr4ig6 +fp1mcf70Uyf0rpw38VfP8iZfCfQfhSf7X4U0W6znzrG1fP+9CprXkUMpD8qRg/SuM+FlyLn4Z+E 5yeX0qz/AEhUf0rt5M4JXrg4+tcaNXuU7Rrd7WJrTBh2gJjgbRwMZqaSLz4nhYcSKyH/AIEMf1qG zS5itoUu3EsqoA7AYy/fA9KvR/6xBjqw/nQxnyP4Mf7P428ESnjMlxAc/wC3aOMfmlfXT4NfHtrK lj4i8NXK/dttcWHPoGkmhP8AOvsEEtXVifjT7pCjtYpzzLCY9wLGRwgwM8n+nHNSj+dSke1Jj2rk LueefEqHf4bjl6+VdQn/AL63L/WvP/gfK0es+NtOPQXlpcqP+u1soP6pXp/xDaJPB9/LMwQRmFgT /e81QB9STgV458KZxY/ErxBaSNj7fp1nKoPdoJJIzj8CK61rQfkyLe8fSpHp3pmKmzxzTDj1rkTL IsE0Yp2UHVhSCSIdXX8SKu4miJpYkUs7hQM5JI49afuj6swA+tc3LoOlSMGaYY2OhG4YIcsc/wDj 38qmGm6cJlmlug+07gpZcAkkk/mfwp3Qi9q0SXui30CEOHhkHHPIGf6V8N/E1EisrC8ckBZGQn/e XP8ASvtpJtC0OwuZp7uKG0hiLys7qFSOOPDMf+AjJr43+JUMd/4Pa7hUlY5IplyMHa3Tjtwa4Mxg qmX4iC7X+7X9D0MunyYyk33t9+n6ni8eoREcA/pUn9o8YRcfXFc5Czp8oQH6irYuJgMCMHH+zX4C 5H7Gomr9ulOMso/EU8X8uc7059//AK9Y/nSsSPJH/fP/ANal3MfvQjB9v/rUk33L5V2Nf7XLyAwx 7Mf6GmG6Ykbh0/2m/wAay2MqA4jz6YHFRedOP4D+VEpNEqKNoT2+MPuH5n+dPF3ZqOHNYOZmP3CQ ajMUhOfK/X/69QqrH7NG1Jc2jdT+eaiN3arx8vHfn/CsVrdzjMZ/P/69N+xN1ER5/wA+tWpsXJE2 Yp7JS3lhAW+9tB5+vFLusegVfb5D/hWObTaMeVjP+fWons/WPn/PvQ6lhci7mxJPbIPlYD2C/wD1 qxry/WNSTKc/h/UVl3MBjydmPz/xrgNevTArdvz/AMauDcnoNxSIfFviS0sbSe4upNkUKlmZmUAA dSfavzV8Z+JdR+KHjACyRmtYiUto+hCdWc/7TfoOK7j4uePbvxdqx8IeHWM0CPtmZDxI4P3Ac8qv f1PFewfBX4QnToU1a/QSyMcnjgkfw5PUDufXjsa+4wtOGCoPE19+i/rqfI4urLFVVhaO3V/10R3v wh+HOm+GdIivJ4TFe3KgtnBKKRnbn1Pf06V75CbaHHIJ9yP8ahttIKAZjB/KrEmlyAfKoOP9kf4V 8TiMVOtUc57s+yw+Hp0YKnHZGil3aLwWjX/gVTC+sx1ljGPesJbFx95R+Q5q9FagLgKB9AP8K5VN 9Dt5In//0f1RurSG8gktrkbopRtZckZB6jj1pPsVsLpbxUAmWMxBhx8hIJGOmMgV5CfjARynhy9P 1aMfzaon+MF3lSnhq5KnqTLEDn6bq9iNSJ4Siz24DtXzh4hY6h8S9VQc7DZ2o+gBc/8AoddEPi3q DMCvh6Vcnq08X9GNcNPPfS397rkUiwX15MbgHG9Y3CgRjHG4LtGemea0g7zVhtWWp9XvgfKOg4qv NBDcRtDOiyI3VWGQfwNfPtr8WfGywRrqGhWb3IUCQw3REbOOpQOAwU9QDyOnvUjfFjxof9XodoB2 zck/yWsHO3QOVnvtta21onlW0SxJnOFAAyep4qyuA1fPB+Knjlh8uk2K/Wdz/JDT1+Ivjy6Uxm1s rfeMbkMjkZ9tq5/MUc91omLld9TN+HGdQ8TJeEf6/UL65P08x8foBX02xBzXyINK1iys7dfDt1Np 95ZskkM6x+Z8ytlg6HhlkBKsPQ8EEA11f/CWfFNsbTbKB1xbSmuud4qKt0JSu3qfRZUemcU7FfMz eM/iM+f+JlbRj2tyf5tV6LUfixeR+ZFeuyNyGjtOMfUtzWXNLpFhZdz1z4hTm28B6/MvX7HKoPu4 2j+dcf8ACmOOO4vlyN6QxKB32gkZx+FcvPpvxD1aBrPWnubu1fBaPyRGrYOQG5JxntVC78CeKJru 31PT47zT722Dqk0DBCUkxvR1PyspIBwehGRitqafLN97GbsmkfTu0ntSBD3r5rm8N/E2GFpptT1D y4wWbHl5wOTwOa5u0HiPU5Yhaa7ezm4xsCSLht3TGBWKVR7R/EfurqfW23FeNfF+TK+GrUEEm/kk IHXEcD8n8TWAvw88dyDMt/cnP965A/kKt2/w08RqwkuW86QAgPLNvIB6gZ6Z9quCbmr2WvcHZJ2O 3+GV/ZP4fnt4plM0F1IsqZG5CVVlyPdSCK9BM0I6yL+YrwOX4RapPcveKY4JpFVXeOVkZwv3Q23G cds9KxvEPw8ufDejXOt6jcFrOzXfMVnkJRM4LnnoOp9BzV1bubcbNepMbWVz6Ra8tF6zxjH+0Krt qumIPmu4h/wNf8a+ZtE8Gprt8LG3HzbSxZ3YgKO/Wu4T4KqPvzQ/98sf51LhUjpKyGnE5zxvNHqH jq/uLORZoksbWAOpyu8NIxGfbcK9L8F+PvCt/wCEtLlF/HbtFAkMkUrbJI5YvkdGU8ghgaz4PhW0 MYiS8REHQKlQSfB7TZ5WmuJ0Z26nyQSfqTXQ7eyjFSV1f8SV8TbR3EnjjwhED5mr24x1+cVWb4h+ ClO06xBn2avI/F/gHSvCtra3uEniurhLb/VAFXkBKZx2JGPqRUvg/wAD6V4jkugxWIWewMFjGcuC R+grJU6jjz3Virw21PUP+Fk+CNy41WJsntzXzfqst9Da3Ws2Ns11KupHUEh6PJGLsTbRn+Ixg4Hr xX0FH8KtDiORPJx6BRV8fDnRcYaaU/iK2otRbc5dLaGcntyozh8W/Bci+cLmQBucGNgR9Rjg1C3x e8IIfleZj7RNWoPhr4dGSTKT/vf/AFq8y8aaHZeH9asrC03NFe28koLHJDROqsPxDgj8aiNNzlyq W/kNyitbHYt8YfDH8ENy/wBImrD8RfEbTvEXh/U9DsLO4E2oW0turSJtRfNUruJPoDmtnwD4a0LX vD0er3MLSPJNPHyxAHkyGPt7rXcDwV4ZQ5FmPxY1LhZ8rl+AuZdEfOmnajeeGfEun+IbeE3cEENx bTxLw5SYIVZc91ZOR6GvTj8YLY8rpF0fwA/rXoQ8IeGh1skP1yakHhbw8BgWEX5V0V5xqT5k2iYK ys0eZP8AGD+5os5+pUf1qP8A4W7csMposn4utef+NJo9E1XxRHawgR6QPNiUd1a2WcD8CSPpX0R4 d0TSH0DTLhrOIvPawSsSoJLSRhj19zUTpKMVLnepamm9jw7xH4jvPGTab9psxZR6bO9wPm3M7tE0 QHHYByazvD+ta74MvtSl0uFLu21WSOd43JUpKkaxEqcchlUfjX0zLY6NaRNNLbwxxoMliqgAUy0T TruPzorRVTOFLRhdw9QCOlWpw9n7Oz3uLXmueKH4oeLCMrpUA+sh/wAKgPxO8YsflsbVc+rMf6V9 ACys5cRPAhVyARtHIPFfJVhe3A1Lw9uC4udXt7aUEcFDMyEfjtAqIUYzTd3orlOdraI7sePPHkn3 bKAA/wCy5/pXP3Flq+q6td67qULNdXiQxMEQhFjgDBFHf+JiT719RbEHYD8Kz7+++wRC4MW+Jc+Y QQCo9cHGaVKSpy50rv1Jl7ysfOHh9/HfhfS7fQdHO6ws18uBZImZkjByFz3x0FaVz4l+JUKGSeSO FPUwMB+pFfQ1tcw3cEdzAcxyqGU4IyD04Nc347Zk8Ga1Kg+eK1eRfqnzf0rFqEnqn95om9jxCDxL 8RL2Zbe3v0kkboqQ5PH41ro3xYLg/aJFxzxAM/qazfAFw6fFSG1Zz5cmj3TovbetxCCfrtOPpX0w eB6061KFObil+IRm2rny63w91V9PSwFlMBGQ6t/GJA3mb8/3t/zZ9a14tE+KapsXULkAdMqma9m1 aTVEnh+wSfNK6IibRtABzI0jHtt6Y710GQeB0qqs/aW5lsOPu7HzLqMHxB0zYNS1e6h3/dOEwfxx UWnWfjfWfNFhq93P5JAfayjaWGQDx1xzXq3xNVv7MsHB4F1tP/Ao2/qK5T4IkCDxZb/xx61KzH1E lvCy/kuAPYUexp+z57a3sPnlexjv4F8XXixpq8txfRRyJKI5ZQU8xDlGKjGdp5GeM80t38NdbuZo 7yOJoLmIFVkjlCOFPUZHY+lfRJGR0po+lVGdoOCWjJabd2z53Hw88aOSHv7oD1N11/SpP+FaeKm+ /f3B+t0f6V9CGkNZcsP5TTml3PnwfCvX2Pz3spz/ANPT0p+E2rH7905/7eZP8a+gDRVcsf5SeZ9z wD/hUN6fvXHX1uJT/WlHwbduXlU/WaU/1r308mlBNHLHsS5PueCj4MR/x+RJ3w5d1PfkMSD+Irhv HGlTpoer6XOMTRRtnHPK819aivCfH9mH1m/hI4uYgf8AvpMVuoqdOdK2kkyY1HGpGp2aZ8NR2uBu 3nP4VcjgiP3nYfl/hUy2TxsUeXG0kHj0q0saPwHJIr+cXB31R+3qppoyi1tAeFlb8eP6VH9iDDly f+BCtL7NGc7mIx71G9juHynj65rN02+hftF3KYsVUdZMexFILWFTyX/76q5/Z/YSEfgKY2nMD/r2 H0RafI97B7RdyA2sH8DOP+BVH9iHA3tj61YaxbIP2g/98rQLLHSUn8B/hUqL7D513IPsBzkM3/fR pv2Jc8lz/wADNWvschOdxIP0/wAKU2bqMl8VXIxOa7lI2qLkbX/77NVJ0Eanh/8Avo/41pyosQyx P51yuq3sMKMSxX6mqjBvoS5JHPa3fCFH5IH1Jr4R+OHxZle5k8F+FJC95IdlzLGTmPP/ACzQ/wB8 /wAR/hHvXSfHb41vYXMnhHwlMZtTf5ZpVO7yM/wr6yH/AMd+tcF8FPhLc6tqq6hqgPnr+8fed3lh jnLE9WPYHk9+K+uwOChRh9ZxOiW39f1c+cxuNlJ/V8PrJ/1/XY3/AII/Bt/MXVNUUtJgbjjhAf4E /wBo9z2+tfc+laFbWdukUMO2OMAKBwAB0HWrOi6Hp+nWiWlnEqxx8Y3ZOe5Pue5rpYrSIDDYH0LE 183jsZUxdVyfwrZHrYPCxw0LdXuzN+zRoNu0j8KhkiTHKk4rcFnAzbdob6qf6mh9OiPSAN34Fcyi 7WPSU9TmWRQThCPxFKpAP3T+YrUudMzyLNhj0YKKxlFnbNiePy8nGGmDD8qwlGzOpSuf/9L7Z+Iu ix6HrGiXOjFIbW/M0NxbEZBKoXSWNs5UgjDLyrA54IyfSPBnhrSJNCgvbyzjnnuMsWkG7C5wAAfp XC/FCbzfFuh2I6W1rczsPdtsa/zNe1aJbm10Swt8Y2QJ+oz/AFr2YtuJ4ewz+wdCHI06Af8AbMVK ujaMo+WwgH/bNf8ACrcm/YwjIDYOCeQD79KwtEu9VvXmnunhlsuFheONkMhB+Zhlm+TsD369MZYz YXTNMxlLOAf9s1/wr59+IVimm+PoE09ykF7pzTTW+B5ayRSqiSIOqlgxDDocA4znP0atfOfjeQXf xKvlXn7Fp9rB9DM7uf8A0EVEW1NIelme6+GdNtbTQ7FUhQM8Su52gkswySSR71vbY1+6qj8BTYI/ JtYYu0caL+SgVk65cTW2mXFxbTrbyxjcjONylgeFI6kN93jnninuyXpobO4dqNzHnNc54fv7jVLN tQuf3RlYj7P/ABW5T5TG56lwfvdvTiuiXqAOc1RB8w6rZRRfEDxDb2g2wy3cDFM5USyRL5hUdtxw SBxnJ7mvqPaIlCrwE4A7YFfNlgPt/j7U5SMibVyv4RhE/wDZa+k5Tk5+tat3hG5n1Ywuc0byOK5X X5o0u9PivXMdhI0nmsCVUsF+RWYdATn6kYrT0lbdLIC0Mhh3MU80kkLnoC3O3+7ntUpD1sa6n51P oc/lXzL8M4IjrVgLddkRu7p1UcAL5sjAD0HpX0nNIIbeWY/8s43b/vlSa+ePhHGz3mjue8Mkv/fa lv8A2ataWjl6EPY+k2OKi81CxTd8w5I74qRxXJ67Z6gLy3v9KTdK6PayEfwxy4KufXYw/WsrDOpj lWRd6EMp7g5Fcj8RJBH4E8QuQGH2C4BB6HKEV01naxWdrFaQDEcKhR+H+NcZ8UX8v4da+f79sUH/ AANgv9aia0Y47nFfC6LZrxA4EVkR+bIK93Y8V418M4wNd1B/7lso/OT/AOtXsb98Cu2vrUZnHYyJ dc06G6NpLOFkDKhBBwGf7oJxgE545rVzXCXmgajcX95Ig2LPcRTI/m/IBGqj5o8c9D+ldz3J9awS KPMPi2xPh7Touz6nafoWP9Kr/CZdp16T1mtl/KIn+tL8W2/4luiR/wB/U4v/AB2KQ/0qz8KVxZ6y /rdIPyiX/GumP8KS8/0JfxL0PUWPOB1rnbbxNpt5As0DM265FqVIwyyElRkehxkHuK6I5zmuOTwl FG2nSpOUkspd7kDiZQ7OqsP9ktwe3I6GsgOu69a8Q+KGG8UaEnf7FeH/AMiwivb8V4d8TefGGiKO o0+7P5zQ1tS/iRt3IezOu+EHHgO3/wCvu/8A/SqSuy1zUH0nSrnUUiM7W67hGDguc4wPc1x/whH/ ABQVof8Ap5vv/SqSu7vrOG/tpLS4yUkwDg4PBBH8qyfxMZhHxJBLqOmWVonmpqCO5fOPLAUsoI9S QRjtg10wrJi0LTbe5F3DFskEzz8E43yKVb8ME8dK2MdqRR8mfEuPOteOU/vW0Z/OxA/pX0z4UbzP Cehv13WFof8AyClfOvxFj3eJfGMePv2lv+ObMivf/AknmeBfDjZznTbI5/7YJXRU/hw+f5iW7N6e GO4ieCdBJG4wysMgj3BqC0s47NDFCWKE5AZi232GecVfZQap2D3M9qkt3F5MrZJTOdoycZ98YzXO UXI+JFb0INfHMyi3u9NY8fZvEcI/LUiv9a+xiAuD6V8deJj9kW/kXj7N4g3/AE26orf1rpo/a9GR Lp6n2S/p6Vn3Frb3O37QgkCHcA3Iz646VqSAGR1HOCR+tUbpLgwSC1ZUmKnYXGVB7ZAOcVyIsco7 CsLxXAbnwrrVv18yxuV/8hNXQKpAG7riquoxCfT7uAjiSCZf++kYUNaD2Z8z+DJAvxT8MTf8/ena lF/47BKP/Qa+p3zzXyD4WnEXjb4e3ufllaeEn/rtZMf5pX2ATnmt8Qr1GyI6JGPfywWsaXM6lijq qAdd0h2DH51fGelU7yza6nszkCO3l81h6lVIT8ic/hV8CsLGiOC+IsYbw6JOvlXUDfmSn/s1ee/B qQx+JfG1j03TWFwB/v2/ln9Y69N+IBRfB+oSOQoi8lsn1EyY/POK8l+GTm0+J2uW7nAvNKtJR7tD PKh/IMK6FrRa8w+1c+i+elNxUoGRTcYrlNCE9fTNGKlIpMc0xkRHekxUvFBK+1O4rEWPamF41YIz AM3QZ5OKnyvqOPeuck0K1kuJJ5J872ZwOPlZgQTnPXmi6JNhbm2aTyxKpfjjPPPTj3wa8z8f2+NT tZ8f6yLB/wCAsf8AGu5j0qxjkE3nKXVkcMSpOULH+TEVx3j+/wBOe70/To50e8KSy+WpBYRAqu84 6AtwPU59K1pSSmjKUdD4N1yOW21u+tRGcRzOB9M5qGGVlGDFwPYVvfEN4dO8X3qSIxMoSQYOPvD/ ABrl4tWtlHMDN3+8OK/AcdF08VVh2k/zP2fCv2mHpz7pfkagufRMA+wqUXBPt+ArM/tqEHi0Y/iK X+2hnizf65FcHP1udbj5Gj5jDvn8KBM4H3c1mnWpP+fNyPr/APWqA6uzZ3WTdfWnzruLkfY1zeSr 0hqJr+47QjI/z61lNqjYOLE/iarPq8yniw5+v/1qnmXcpQfY13vrvGdqr/n61nTajdovIBH+6Ky5 PENygJNkFA61yWqeMbiFWxaE8HjpVw952uNxa6Grq3iK4gjbtn0C18NfGj47X5u5vCHhCUy6ix8u WZMEQ5/hXHBk/RfrWV8Y/j3quqTyeD/BuY7qQmK4uEO4p2KRkfxerdu3Nc38LfhJcz3ZN2Cbo4M0 mN3kq/JGT/y0Ydu2cmvr8JgqdGH1nE6JdP6/LqfM4vFznP6vh9ZP+v6Y/wCFfwdv7+6+03jb7l8N LLy/k7+ep6uevJ9zxX3v4W8J2nh7To9P09CkacklQWdj1Zm6kn/PFV/DsVh4esYNM0yyMUMfA68n uWOMlj3Jr0SC+X7P5wXBHY/4183j8ylip9orZfqevg8AsPHa8nuytHGVGdp5/wBmpAzr9zK/RB/h UVxq2pwRmV7FlX1wGGPXIrIbxDqTNtWNMH1Uj+teXFo9Tkk9bG4ZrkfdZxj/AGV/wqu8122VLSY9 uP6VlPrGrHkCLI9qhfVdW7bfyH+Nb80RqMl0JpoLhznfN/32f6UyKzKgsUdz7kmq7ahq5z93PbgY /nULXurbP9agP0/+vUOcV0NVzM//0/tTxe5v/iZeqvK2tnbW4/3pXZz+gWvpIIIkWMdEAX8hivlW C5uJ9e1TxQsJ3X9yksEUvyHZAgVA/XbuIJ9gfWvQrT416PNbJLfaJqtlcEfvIHtWkKP3AeMMjDPR lOCOa9OEkoJs8ezvY9avbKHULWWzucmKZSrbWKkg9sjkU2x0+KxVkiaVg2P9ZI0mAOmNx4H0ry5v jPooG5NF1Vx2xaPn+VQv8abEf6vw7qr/APbvj+dX7SPcOSR7Qo+bHvXzVJ/xMviJ4hkHIfULa2H0 hiQEfmxrrF+MbSY8nwzfg9t+xf5sMV53bx6zaR3uq2jRRaveXM18vmZeFJnbciNjBZAAqsRz1I7V MJKVS66DcWlqfWr4yR6Gq0sMUpQyoH2MGXIzhh0I9xXiNv8AFvxE1vGbvwt5dwQPMVLuN4w/fYxI JXPQkA46gGh/it4kP+r8OJ/wK6T/ABoU0S4s9uSCKMu8SBTIdzYGCxxjJ9TipY+HXPY14C/xR8aH /V6Dapn+9d5/ktRH4iePLjMf2KxtQwILiR5Cue+Noz+dDqaaJkcupB8P/wDTvEUN0efPvrqf8PMf n9K+j2IPSvkw2Wo2Nlbp4ev2sL6zKyQT7BIN6tkh0OAyPkh1yODwQcV0q+NfiYwGG05T7Rykfyrq leMYq3QzSu3qfQ5xilGK+eD4n+KDni6tFB9LeQ/1po1r4qSHI1CID/ZtG/q1JSf8rFy+Z7n4iuDa eHdWuT/yytJ2/JDXjnwnjWDULCJjhorAcfREB/nWa4+IGqQS2WtXss9pOCskcdv5e5T1BbJOD3qC 88JavdS2t1ZJdWV5YuZIJoAVZCylGUgghlZThlYEH6gGt6SdpNqxD0srn00eeaYVr53GlfEyTrql +f8AgCD+lH/CM/EWX7+p6hj/AHkX+lY3l/KXZdz6KHSvOviwwPgS+gH3p5baMAdTumWvPh4J8cyH MuoX5HvOo/kKtQ/D/wARbla6aW52Hcomn3gMO+OmalqTa6D0RsfDa/so/EGqafJMq3T28cqRk4Zo xIVZgO4BIB9MivZGmiHVwPqRXgl98ML/AFKaG4uLdBNb7vLkWTZIgbG4BlIODgZHQ4HpSD4T6g4x JIxH+1cyH+tdFW7neJnG1tT3U3Vqv3pox/wIVE+o6cnD3US/V1/xrxH/AIU6z5MrIc+ssh/rUi/B i24L+Rx6lz/M1nafl94/dLvxP1Cyv20C0sZ0uJI7x5nCMG2osDrk4/2mAqv8OPFmhaZPrWh6ndLZ 3Szx3CCY7BJDJEqhkJ4bDKynHQj3FaVl8LVsAy20sUQfrtQ5P1NTz/C+G82/a545NnTdHuxn0zXV FfunFvW9zJtc3kdk/jXwlH97Vrf/AL+CqjfEDwYpIOrwcejVy6fCbS1GDLH+EK1aT4WaSpz53PtG tYJT7r8SvdNhviP4LA/5CkZ+mTXmXi7VbHxH4nsdT0pzNbWllJCz4IBkllV8DPXAXn6136/DTSU/ 5bv+CqKtp8P9LTjz5SPwral7s1KUtjOTVnyo81+H3j/T/CmgyeG/EUU0FxZ3d20bpGXSaGaZpY3U j/ZbBB5BFdu3xe8KD7q3L/SBv8K2P+EA0XOWklP4gVKvgPQh/wA9D/wKpmk5NqWnoNPujnW+L/h0 cpa3j/SFqYfi9pHGzTbxv+2eK6oeBtAHWNz9XNSjwR4d/wCfYn/gRrNx/vfgaXXY8L1WRvEWr6vq 8sbW8WqLFEkbcskcUXl5OOASSTirvg34g674W8MaX4Z1XRnvJ9Kt47X7RC67JVhUIrgEgjKgEg9D UGsSx6d4l1/RY4/3elGF4znO6O4gEoB91OV/I16VoFl4efwbpXiK/s/MN7bQzv1Ygypv9egBrsqq HsoJMyi3zO6OfPxc1U/c8PSfjKn+NQN8V/EZ4TQAPrMtekafY+Fb65lt7SyVxEAS+07eQDjPryK2 v+Ef0RT8tlF/3zXDypbyZtfyPGj8T/FrsAuiwKD3M/8AgDXB6nokusaTf2l5KVuNRmluXkQcJNLL 5wK57K2MZ7CvqZdG0lelnEP+ACpxpumjpaxf98CuilOFNt6voRK720PAoviL8QI4xHLa2Ujjq+5x uPc428ZqVfH/AMRJPu21j+ch/wDZal8amO18ejS4Y1jgm02K6AUY+f7Q8L/mAtdb8LLz7V8O7TWr mIS3Ej3RfC8kx3EkYA+gUCspUoqKmm9S1N3tZHHnxr8SG+7HZr9FkP8ASorjxD8RdQgms5p4oEnR 4y8MLb1DgqSueN2Dwe1e46ffNeSlWtfIQoGUsMHtwRjrWvhewFZcset/vHzPofK0/hW4+y2EWnJL bS6U8clpIqktG0SlFPPX5SQfXNaJ8S/EVf3batGpHH/HuM/zr6aBHQV81/ECa6i1/wAURW52NDbR SwkfwtJalsj/AIGpNdnu15LmVjJNwWhJb3nxQu4/Ni1R3Q9GS2GPzzVnyvim4O7Urj8LdR/WvWPh 26y+APDUkZJV9NtGyTkktCpJJ7knJJ9a6/PFcXLDt+JvzM+cLjw9411eJbfXri6vrZZI5fJKBEZ4 mDpu28kKwDAdMgUl54J1uS5i1S1iuLS8t1ZVmi4bYxyVPXIyM49a+j8+tPU963VRRg4KOjJs273P lWe58TQpJLdeIbuJIgSxYooUDqSccYrXh8OeO7xEnj1PUWSQBlO9VBB5HauP+LCBdL8RJcDfFBfA yKejRLcRuVPttPI9OK+u4mEiLJ/eGfzolSpxs0tylKWp8+jwX43f72oX5/7bgf0pR4C8Wty1/ff+ BNe83ouWtJ1siq3BRhGW+6HI4J+hqrpKajDptvFqsiS3aKBI6Z2sw7jPrUcsOxfMzwyf4feJYoWm lvL1lQZOLok4HXgVyy6Osl7a2H9o3bXF7J5UKG5fMj4LEAZ7KCT6AEmvq/aGG3ruBH518uxgWPxE 8JzSD5lu7q25HQywsP124rWNOm03bYnmldanTL8LNUYfNczH63Un+NH/AAqa7P3pHP1uZf8AGve+ lITXO4x7FXfc8IHwjkPUg/WeU/1p0ngN/DVvJexxRhZCokdCSxx93cTyQMnHOBmvds9M9axfEsfn eH70f3UDf98kGiDUZXSIldo+E/izpwGu213sLebAASCAPkYivL/IiOC0Tkj/AGhXu3xcgVbbTbw9 A7xk/UAj+VeLCeM/xDj2r8a4ghyZhU87P70fq2Tz5sHT8tPxIkwF4tm5GAS44puxuoiYH/fq35yd 2z+FNN0gBx1/Cvm91Y9zXsVTGf8AniT/AMDNIyOP+Xf/AMeNTNcnpz7ciqzzN3J/76q+ULkbqcZa 3H4sf8KoXTiNc+RGPq5/wqSW7UZ3EDH+1XGeI/FGn6PYXGp6ldR2trbIZJJHYhVUdSf88ngc1pCn fRIhzS1IdV1GNUYmKLPpvb/Cvhj44/GCe3uZfCHhYhL8/LcTxMWMWf8Almn+2e5/hHvXPeO/2qNV 1truw8Jab9mt3zHHdSSbp8HjcqD5VJHTJJH1rivgr4JXxnrX2kyedMsh3bwSYz1Z3759+5r7TBZc qSdbE6Jf1qfLYzMXNeyw+rf9aHpPwQ+DN3qLR6rcApLuDSSMM+Wh52qD1Y+p+tfe+jeEYNMtVtbB BFGvbAySepJ7k9zVnw3pGlaNYQ2FmAscfc5yT3J9zXaRzWka8N+QNfL5ljpYup2itl+p6+Awaw0L 7ye7/Q5+DQbpZN7sGHpkj9BW6y30cRit1jVPcf8A1qmN9BnAZj/wGmHUIR3k/Ba8dRR67lJ6mDd6 RdXG15jG4j55L55689fwzUa2RvEEsTxHBwcr6dsZrZe9Rz92Q1ELiLn92w/A1aUSXOZkvpl1nAmT B7BcD9KhGk3K9JR+AP8AjW958Q+baRz701r+3Ucn9T/hWiUSOeRhNp90B/rQB9D/AI1Xk0+cjmb8 wf8A4qtWbVLUDlv1P+FVm1K2fARsk47sP8KylY1jKR//1P0sTwBogX5pJj/wIf4VOngLQF6+cf8A tp/gK68dKeD3r0ozujykjhpvDHg60YxzltynkGViVyMjIHrXC/E3Qk8N6VZ65oe1Eiu4IbmCTLia KdxGdjZykiFgwPKnBUjkEez/ANkac80lwYQZJTlmyck/nx+Fec/GBt2k6LZZ/wCPrVbYn3WImU/+ g1bdtgGeDfDOnanFPeaghkEbhFXJAzjJJx1rvF8KeHkHFin4lj/WqPgeLZoe/wD56yu35YFdaTTk 9dBdDFXwz4eByLCPj1B/xqdfD+gr92wh/wC+a08ntTs0XZmcdeXWgabdTWkulDMaB1YQgh8lRgcH uwGfrXM/E3SLK4+HOqarDG+kXtjAbqCWEBJYpYjkA44ZWxtZWBDKSOvTuLrwzp99PPcXLO7zgAZb 7mCGwvtkDg1yPxb22fw01GyUkiYQWwLHJPmSKnJPXrTlJqOhNjK+HltHeag891ErGOFWAIyAzY6A 17F5ca9EUfgK83+HsWJNQlA6bF/ma9IzXTN6mKQDaOgpcnHWm5ptJCY/OB1oz3ppNHNUSPBFOz2H So/507mkO4uecGnZpuKOetSxoX3peaSl7UJAwyaMmg9KACashjTn1xSZ75pxFGKskKTJpwHpSY5p k2Fo6e9LilxQMKOtKBTttSxoT2NPHYUmPWngY560DPl7xUgPxG8YR9zb6afztXH9K9c8C2jap8Lv DVv5rRCTTLPJXqR5IBH415X4njJ+KPikdntNKP8A5ClH9K9U+Gl5Ha/C3wpPKC27TrRAFGSWKAAA VvP+FD5gvifyOusdHj064lmglcpKBlGORkADP1wK1jWJN4jsI38oJKz7tihU5ZsgFRz1BYZzVUeK bNlRo7edi+042gEK2zaTk9DvWuazLOlHFSAVyn/CWWHmrCkUrSOm4LgZzuC7TzwQT34q1a+IUur6 3s44GXzGKuWIBVgjNgAHJ+7jPSpsFjyP4ips+I+lyf8APXRZx/37vIz/AOzV03wSP/FAxwf8++oa lF/3zdy/41h/FBCnjjw7Lj/WadqUf/fMtu/9a0fg1O0PhPXFVC5s9a1UBR1P7wOAPrurqf8ABXqy ftHsLU3nsa5n/hILp5lt0tgXYZHLYb5guV46DOTnHQ0R6vqISJ5LbcZFQnAONxVSVXjOckjn0rls M6hR3NeA+PLXd421KMji7060P5GeM17bptze3Bf7XAIsKrLjPcsMHPcYB/GvKPHqbfHFk/abTP8A 0Xckf+z100NKiImtGdD8HJ2uPhX4VZjymnwxn/tmCn/stej+1eT/AANJ/wCFZaXBjm1kvIP+/V1K v9K9b2sa52jbqYGmza9LfXiapbRQWqbfs7RvvL9d27IGD0rdA6+9O2mjB+lSUfK3xfsnntPGlpH9 6SF5F+rQI4/UV9EaVd3z6TYutsGLW8RJ3jklBz0rx/4k2nna3rVsP+Xmwhb/AL6jkT/2WvU/AF19 u8DaBeE5aWxtyfrsGa6aiTjC5MXZs1zcamfu2qfi/wD9aozPrH8NtEPrIf8A4mtnaT2xmsTQ49cS 0l/t+SOS486QIY12jygcJ68kcmsOWPY0uxVm11mX9xAOR/G3+FfMniCW8h1PSdSvlWO5tNbhMoU5 Vd0zRHBPbDV9Z8ivlr4owiKHxE8Z5s7tLnjttaKf+VdFO2qS6Es+pGHFYmtWF7qVibWxvX0+UujC aMAsApyRg8cjita0mS5toZ0ORIisD9RmrITnpXOy9ijbxvDEkUkjSsoALtgFvc4wKS9iE9jdQH/l rE6/mpq+Y+2KRYyWCnucfnWYj40+KdqZ/B4nABaCaNue2cqf5183qJCMALxX1n49tIr7wRrCwMsi ojMpByD5T9iPpXxW9xLCOF/WvzHiilbFRqd4/qz9G4enfDSh2ZvsJQD8ufpVOR7gDIQgfhWN/akg U7k/M1j3WqFgVMX6mvi1FH1tpHRSXNwucggfUCsm61CRFJOfzrkLrUIipDqfzrxL4r/EvTfAmhPd LiXUbjK20BPVv7zf7C9T69K76GHdSShHVs5qtSNOLlPRI634j/Gjwr4Bt2XVbkyXrKWjtIjulf0J A+6p/vNivzw8c/GTxh8RrM6XrV4tvZ+aZfJhTYpx9wMeSwXtnvya4PVb681jUJtT1SQ3F7ePvkLd cn/PA7Cs6azaIKDwWOBjpx15r9CwmW0qCu1eXf8AyPgsVmFSs+VaR/rct6dAIJFlvH/0UkI7qQJI w/G8euM195fsu+G54rnV/EWofKpQWDtwqzzW8hPmj1ITAJ9a+QvhV4RuvF3i210SBN0ch/eMRkRp n5mI6cDJFfrp4f03StD0230yxjEdtbIEjUKeFHrxyT1J7nmvLzvFqEPYLd/kdmVYZzn7Z7I34Z9P QD51/EgVaF/p4Hyuv/fQ/wDiabFc2+BhCf8AgJq0t5GOit+Ar88PuEvIrG8tG6EH6Mf6LUbT2+P4 vzb/AOJrSF3uHAcZ9qidriT7ufxpq3cNexmtNb553Z/4H/hUbyWbDndn6PV8x3ufmYceoNV3+0g4 3L/3yaZJVMVo2AFc/wDAXprwxJ922dvfYf61c5P33b8Awqjcz2sS5eUj6saHtqgV7mfM7I/yW7c+ oFcH8Rfipo3wx8Ovq+pRtLdTZS0tVYB7ibso4yFHVm7D3Iq5408eeF/BGgXPiHW7g+TCMIik+ZNI fuxoPU/kBya/MTxl4v8AEPxD8RS+INZP+kTfu7W3BJS1gzkIo9fU9SeTXtZVlbxdTnnpBbvv5HmZ jj1hocq+J7f5n//V/VhtR06FpEmuYkaLG8Fxld3AyM9z0qMaxpTMwW4RghG5gflXKbwSehG3njNU Z9G0d5luP7QMTLL5oIlT5STuIXPTLYPOemBStp/hWKPyWu41QYwPPHykKFyOeDhR+PNdMJRtucPL 3NSHVdMlmjgiuUd5fuqM89fbg/KeDg8GvLPisfO1rwtZg8I93cEf7kRQfq9d8uoeDLFvM/tG2Vg4 kLPOCS43fMeeT87fnXlfijVbHxJ4whuNJnW6tdOs2jMiHcollcEqCOM7VyfTj1rRyTaVzNxdrnrf hxUs/Dlq8h2qsZkYnsCSSakk8Q6ZEqtKZE3f3onXaD90tkcBv4T3rldO+IXgQacunX+qQWstuvkT 29wfLdSowQVPUEcgjIIOQapt43+EcRjD6tZEopQZctwexyTnrxnp2rZyj1Zm0+iOqTxXpcmcR3AO QFBhZSxJUADPU/Op+h9jSL4v0jZG5EsfmuigMm1sSAFWwTnadwrl3+J3wojbcdWtCVO4YGSDxzx9 B+VVJPip8JN6MbuGRosbCsDMRjAGOPYflRzw7i5H2Oxk8XWiW7yR20pkVd6o+1cqQCGzu6cjjr7V yvxmkJ8OaXZ4z9r1SyQj2Vw5/wDQaib4t/DWUKBvnC4K4s3boMDHy+nSua8UeJrXx/daPHpEFxHa aZctdSyzxGJXIRlRVDYJOTk+mKbnGTSXcXI1qz0jwHHjT7uXu8oH5D/69dzgYrwfTfH0/hK5l0y/ 0S7vbCUCWK6s1E21/uvFLHwyngMrAFSCQcEc7R+Mtgf9V4d1d/rb7f5mtpzipWZlyNo9f29/SgrX jTfGNjxF4W1M/wC8sa/zaoD8X9TI/d+E7z/gUsK/+zVPtIi5JHte2jbXhzfFrxKf9X4TcD/buoh/ U03/AIWp4wb7nhmJf9+8X+gqvaxM+RnuoWl2mvBW+Jvj1v8AV6DZJ/vXRP8AJaiPxE+I7k7NN02P PrNI38lo9ouzHyM+gQh6UuzvXz3/AMJ38TGJITTI/wAJW/pTf+Ew+J7/APL3p8f0gc/zYU/adosf J5n0Pt4xRt7187HxJ8Tn/wCYvaL/ALtqT/N6jbWPiW/3teRP920X+rGq5n0iw5V3Po3ZRszmvm03 fxCk/wBZ4kmGf7tvGP8AGom/4TRuZfE17j2WNf8A2Wjmn/KTyrqz6YEeemad5ftXzA0fiEj994lv /wDv6i/+y1SkgnP/AB8eI738btR/QUc0/wCX8Q5V3PqzywOtGxB3A/GvkeSDSx/r/EMx/wB6/wD/ ALIVQlXwcvFxrwb/AHtQJ/8AZ6n2kutvvKVO/f7j7GLQjrIo/EVG1xZr96eMf8DFfGDXHw3i/wBd rVsf969Y/wDs9QNrHwnT7+rWZ+s7N/7NUOt3lH70X7CXSL+4+z21LS4+Gu4R9ZF/xqBtd0JOH1C3 H/bVf8a+MG8S/B6MfNqVk34s3+NQnxr8HIufttofpEx/9lqXiYLepH7y1hqj2hL7j7LfxZ4Wi+/q 1qv/AG1X/GqreOfBycHWrUf9tVr47PxF+D8fIuYT9LZj/wCy0z/hbHwmiOUmBx/dtD/8TWbxdL/n 7H7zVYOq/wDl3L7j1/UZbbWvHmua7p8glsZobC3SVfuu8CSGTb6gbwM+ua0fh94+8KaN4G0nwt4r l+x3+lQLazwyofvQkqGU9CrABlI9a8XPx6+HMKBEnnKjoFgI4/MVnz/tAfDncGP2lyP+mS/1at54 7C+zjFVo3XmKOBxHM37J2Pqn/hafwxjcyJcoW45WFifl6du2KjHxd+HSkCN5HIwPlt2PAxjt7Cvk 5v2ivh7HwIro/wDAUH/s1VX/AGmPAaH5bW5P1aIf+zV57zDD/wDP5HSsBiP+fTPrj/hbvgUPvitr ln6ZW0fOOvXbSn4veFi4eLTr5mHQi0fPPvivjyX9qPwUn3bKY/WaIf1qo/7VvhFPuacx+twn9BWb zHDf8/19zNFluJ/59P70fT2v6u3jXxFpOr2tpNZ2elW15GTOuxpZLposBV64URkknuQBVfwt4l1H wDcaxZTaVNqNnqV699FJb4LIZkRXRlPPDJkH0NfMD/taeHF/1elhvrcD+iVTk/a20ojEejxk+87H +SVs82wPsuT2uvez/wAgWVYzmv7PT1R9rN8XrjO6PwxfMenOwcfiaiPxc1c/6vwtc/8AApYx/Wvi GT9rSA8Q6LF7fNK38lqo/wC1ldn/AFWiwj/gM5/oK4XmuEX/AC9f3HSsoxf/AD7/ABPuj/haviJ+ E8MOP964jH9aw7q71nxLrqeINVgSxSC0+yQ26OJD88vmvI7DjJIVQB2BJ618Uv8AtXa6c+To0PH/ AExmP8yKrt+1V4wYYi0qMZ9LaQ/zeqp53gqclJzb+QPJMZJWUEvmfaHh/UvF/gaK40rRbS21DT5b ia5i82QxvGbhzI6nggjcTgjtXRH4ifEM/d0ayX6zk/yFfAr/ALUPxAk/1enKPpa/4vVY/tK/EyT7 llt/7dV/q1Y1M7wTk2pS/r5msckxmzij9Af+E++JDnjTtPTPrI5/9loHjX4lP1h01PxkP9K/Phv2 ifiy/wBy2YfS3iH8zULfH74xNwI5F+kUI/pXM88wa6y/D/M3/sPF9l/XyPvuO11S91K91vXbhbi9 vlhjKxgrDFFAGCIgPPJdmYnqT6AVS0seOPDVqmleHtTgGnQjEMdxEWaNM/dBB5A7V8FP8dPjUwyp mUe3kj/2WoH+M3xvl5WS45/6aRj/ANlrSfEWDcVBJ6en+YRyDFJt3R+hba18T24/ta0X6WzH+tMO pfE1xzrsC/7tr/i1fncfiv8AG+Xg3E6/9vCj+SVG3xH+NsvW7nA/6+j/AEWuN8QYTtL71/mbf2Di u6P0SS4+JDH954j6nkLar+X3qLTw3FHY3drevLfPqEks11LPy80k/wB8nAwBjCqoGFUADpX5yP41 +NMxw19Muf8Ap5k/oKibxD8Ypcn+0pif+viY/wBauHEmGg7xg/vFLIMRJK80fopbaN4s06L7Jpni S8gtk4RCiPtA7biMmnnTfHLcv4tvvwiiH9K/N06h8YJid2oSZ/67zf8AxVReV8Wp/v35x7yyn/2a uWXEOGbvyP7/APgGyyGt1mj9I/7I8WHmTxZqR/CIf+y0jaBrEqNHe+KdUaOQFWAmSM7SMEBlXI47 jkdq/Nh9K+JspxJqJ5/2pT/7PV2x8KeL7jI1LUGx65cYH4sRWL4hodKb+/8A4BX9g1etRfcfcvj7 xL4X0DwrJ4J0WWJ7iSBbVLeFt4t4AAuXIJx8owATuJ596+YW0qwjQEwbse3/ANes/SfD0GlxFd5L HkncRk+tWrqSKJceYFPYlj/jXzmOzCWNqe0mrJaJH0eBwSwlPkhK99ytLBp0Q/49jz7D/Gufv5tP VTtgYVT1TV1gQ7rhCfYsf615hq3ikwBnLbgPc/41y04X2R3TuldsZ458V+H/AApo1zrmqq8cMI4U EBnc/dRfdj+XXpX5k+LfE+o+MtZude1JwzucRxAkrFH/AAoM9lHX1PNe1fGq98Z+MdSt5dMsrhdD 0wmP7QUbyGunALqXPy7lUgY7ZNfPtxFJAxS+tzE6dXUH9R0/KvvMvw8aUOaW7/I+HzDEOpLki9F+ YyC1QJ9qnkyfmYgHDEDrgkEZz/8AW5pLOzvtUu4bSBTLcXACoBxtX19vXPpz1qQWkkiJLCUuAThV U5YY6Er7k8etfSPwt+HN/NPGrDN/dqDLI3P2eEds9Ae3146A16letCjTc5PQ8mlSnVmoRWrPon9n D4Z6fo+k3Gs3iGVpSIkfBG9l/wBY30z8o+hr60ttL0gDH2fH4muJ8O3TadaWujaaWtbe2QRIojVh gep9T1Nek27XyoN1w2foo/oa/JcTXeIrOpLqfpNCh7Cmqa6Atjpafdtxn/gRqYwaeFx5HH0NP33h yDdSA+23/wCJqMtdYx9pkbHbK/8AxNc/L5G3M+4hi0//AJ9zn2VqC8UfEVuxHspqBvtjc+fJ+a/4 VD5d3/z8Sn/gYFDC/dllrtQCWtJDjttxWcfKuW+0ppzyY6ZJ6j8cVbit51+Zp2P+82f61HcwRysH mcEj0OB+Waz5X0DmQ9bwqPLfTX49AG/oa43xt468J+BfD9x4j8UIbS1t+AuxfMlkP3Y4x/Ezenbq eKx/H/jbwz8OtBn8Q67OUjj+WOONh5k0mMhEAPJPc9AOTX5dePfH3if4t+Il1PWcrboStnYqxMcM ZPXnqT/Ex5J9BgV7mXZdUxUry0gt3/kebjcZTw8dPieyJ/iJ8RfEHxW8RHXNWQQ28ZYWFgn+rt4y ep6bnP8AExHJ9sCus8AeCLma9tc2rX+pXrBYLdRyx9T/AHVHcmrPgnwDcPdWsENt9t1S9OIYsdT3 Zj2RepNfon8Mvh5pXw+sXuZZFu9bu1AuLkcADr5UXHyxj8z1PpX2WNx1LB0lSpL0R8hh8NVxlR1J 7dX+iP/W+lftHwcX/WahpzfWdm/9mNR/2h8Do8lrnS29eGf+hr4yi+GOrs373WZgv++o/kK0F+Fd wT8+sXBX/rqRX59HiBW0gj7B5ElvNn10fEPwIg6SaYT7Wxb/ANkNbEPxZ+FdjCLe11VI4l6LFbyK o+gCACvjH/hVsedzajO3/bV6d/wq3Tycz3Ny5P8A00fn9a3XEcltBf18yXkNNrWb/r5H13d/GD4U zMGnvDcFRwTaO+PoWWs4/Gf4UxcI8v8AwGz2j+lfK/8AwqvRT0M7H3kb/Goz8KtFOMLkqO7k4/Q1 T4jqP7C+7/gkLIqPWT/r5H1NJ8evhtb/ACgXftiBV/m9VJP2jfh7H92O7P4RD/2pXzda/CzS4zkK hTOdpwV/LFXj8LtCPP2aPPfAxn9Kz/1irdEvuK/sOh3Z7tJ+074EjOEtbk/WSIf+zmqr/tVeC4sh dOlY+9xEP8a8X/4VZphI8uKJcHPK5x+WKkn+HWlwQqreWHdguQuD74zS/wBYsStrfgarI8N5/ieq S/tYeFv4NK+m65X+i1Qf9q/RD/q9IjP1nY/ySuPg+GumbFeFFZcZy2M1ci8DaXEceWtS+IMW9b/l /kV/YuDXT8/8zVl/avtRzHo8OP8Afmb+SVnyftX3HSHSIP8Avmc/0FSjwbpoOAigfQGrC+EdOHRF /IVm8+xj+1+Qf2Pg/wCX8zEk/am19/8AUaXB+EEp/mwqq/7S/jd/9TpsY+lqx/m1dUPCll3CED/Z FOHhiwB+ZEP/AAAVk87xr+2xrKsGvsHB3H7R/wASP4bPb7i1T+rVnn9on4pzHEcTj6QRD/GvUP8A hHdOA/1K/wDfAqVdC0xcfuE/74FQ84xb+2/vZvHLMIv+Xa+5HkMvx6+Lzcjzx9EiH9Koy/Gv4yyD /XXKZ/241/kte5jSNPOB5K+3yLT/AOytPXrGvHsv+FZvNcW/tv72bLAYRf8ALtfcjwIfFT4zXf3b u4A/6+MfyWoZPG/xkufvXs4+tzJ/SvoNbGxT7uB9MVJ9lssjLfrWTzDEveb+9mqweGW1NHzPJr/x buSVa9mP/baZv6ioC3xNuGxLeSAH1Mzfzavp821gOCxP40CHT+wz+Jrnli673kbKhQX2D5eOkePZ f9Zev/37c/zalTwp4umH727f/vz/AImvp8x2HQx5/OmGOwH/ACyHFZOvWfU0UKf8p83r4G8QuMtd S59o1H86sL4A1g/eupwf91B/SvocPYD/AJZDiniaxAOI1/IVn7Sp3K5Ydj58X4c6icH7bcZ+qj+l Wk+GN2cbr64P1cCvdzd2I4CKPyp322y77KPaVO4ckex4aPheSPmv5/8Av4f8aePhXAcb72Y/8DP+ Ne3/AG6x7MlH2+wHBdaOep/MUoLseMr8KtL4DzSv9ZG/xqYfCjQyNzBm9i7H+tewf2hYk/eX9acb 7TyOHGR6A0uafcaiux5B/wAKo8Pd4Qfqxp6/Cjw8OfJXP4mvWzeWJAwcn2UmgXloTjaf++TRzT/m K5Uuh5WPhXoY/wCWSflVpfhlog58iP8AKvUBeW2flRv++DTxdQ/88m/74pPm7lJnmkfw30UcCCPP 0/8ArVZX4d6QvIiT8j/hXowuUzxC3P8As1Kt0F6wtg/7IpfMNTztfAWlr92JP1qwngfTFBOxOfY1 3n2kf882/IUpuFA/1bc+1Ty+Y9TiP+EL03GFRf8Avn/69OHhGwVcbf8Ax3/69doLsY+43NJ9rHUq 1Oy7j17HHDwnZDjZn/gNSp4VtMcRfoK6pr5Rzsbn3ppv8YAjY9utFl3Fr2OeXwtaLyIsZ9hT/wDh Frct9wj8BW2dRcHiNse5pp1R/wDnmfzosgtLsZY8LwDjYf0pv/CLxsPun9P8K2BqbMTlTTlvWOFE bH8aVkGqMuPwwijH+f5VOPDkCfeP6/8A1q0vOumPyQHH+9R5l3nJTH1b/wCtT5SWyquhWfSrI0Sz C8n9f/rVMrXffYPq5/wq2sjqPmdCfY1aj3MmY0mk2OMEH86hTR7RjtUt9NwrYecnj5D+NV/MuM5j C1lyq5S2KD6OVHyqfrkVUeyeL+ID8a3BJe8DanFIzX7EgKg/GtOQV+5zMqSg/LIoA9mrKumCZEl3 GPwfNdjLb6m/C+WD9TVVrHU2BDug/E1UaeuwnJHn+6wbd52oAA+quo/U0x5fCtrE5u76CYqMn5m3 fkSa6+5tLmNSzyp+OT/Ovmj4n+KJ9PvI9F0GI3et3q8mCLzDbwfxTsowOB90EjcRXt4DA1cTVjRp K7Z5WLxlOhTdWpKyRleLPiD4Z/thtK062FxY2A8/VJFby2S2A5jjYkYlfovIx1rU0jwTpnjSIeJt Ae60fwrPFB9mhvYzJcTqvEs0bFtyoSCiFyxkcFgAgyfIrH4b6j8Q9XtPB0Xm+HvDdrDJfPdXe03u oSyHHmmMtksSOh/1ackZKitjwz8RLQaInhTSPEUWoHRpvJDyzSq8kcI8v923Oxdw+QlWXHynjmv1 /G4TD5dljpUKaq1GtL9X39F0V1+bPy+njcTi8X7WU3CK6eX+fc+gItGtbuW38PW8cVpFBbyFIi+6 FIQedyn5WJJ5YjLMWc4AArwLxR8A/D/jA502zeGW7mEUH2dd6Su/CEJ95d5+7jt8xABFem6Vrcev XttpusWcd7cn5oSVCzADqeP3ci+pRvqtfS0vhbxH4V8G3+o+F7UT+NbyErbJ1ayilGSUB6XDpls9 UQA9wB/PeXUs1qY51HJx6yvt/XRKySsfX1p0I0lFq5+Juo/CjUtF+Odx8L9MuE1C70m7WCeS1ffH 5sYDSqrjsjZQn1Br9TfBHw/0rw5pqW5Be5kCtPIOA7Adv9kdAK8G+DGjfCvwp4l1O0sriS38WXb7 Lk386yvvY7mSKT7pJY5bncT19K+x4NJu8AFiPcAf0NfV5xXqyqKnKLil3W56GWUqcYe0jJN+RFb+ HtIHODn1wM/yrVi0myj+4zL7ZAqaPTJwPmmx9RSS2ZjGXZWz7kf0r51LyPccvMT7DZKQWZiR75FN aOzU5XZx64qHbDggD8nx/MVVa3R+FZl/4Gv/AMTWqSsQ77EsjQL0aL8lqpLOFXKvET2GV/wpx0pW w3muf+2g/wDialj0kL1c/Xd/9jUSYJIarSyxAxJE2f73H8hXnPxG8e6F8NNAk8QeLDbxx8rDCvzT TyY4SMFeT6noBye1O+KXxF8MfCXw8db1+4eSeYlLSzjcedcyj+FQRwo/ic8KPfAr8nfGfjHxT8Vv FEmu+IJjLOfkihUnybWLPCRj+Z6k8nmvdy7LZ4p809ILr39DysZjo4dWjrIu+PvHniP4teJm1fUY 1ijGUtLOMfubaM9M9NzHqxPJP4CvRvA3w8vJ9Rh07RrJ9Q1a6wY4WI+QHq8rdFUHn6VN8PPAGoXu p2mhaJam71e85VABtiUDPmSHooHv061+nHw2+EWlfD/S2jicXGp3eGu7ogEyN/dUtyEHYd+p9B9Z jMbTwlJUaK9F/n/Wp81h8PUxdR1Kr06sofC34XaT8O9PM9xt1DW7xV+1XTKO3PlxA/djH5nqa9XM kA/5Yg/RVqT+zZF4EpGf92lNi+MGVv0/wr87qTlUk5zd2z7SnCEIqEFoj//X7gNAACIj/wB8ml82 JTkRPz7V0qWGR82D/n6VN9ghC/NGvFfhsKfkfrLmjkjPBjmNx9eKZ5tv1MZ/P/61dh9ltB/An5A0 hhtQcbUH4LXR7Ni50cQ0tvJIUMXyrjPJ5JqyZAwwsOAPQ11vlWo6+WPwWjbZZwzR/iQKfs7mfMrn IrIF48k+vUUvnOefKx9SK7DbYH+KP8xSkWgPDRn8aapsXOjlFumHDRj061XuXeXYQuPLORnntiu1 IgHIZBTd8AYKXUE0+TuNTVzk0urlk2YYADHHH8qcs1wowEcgfWuvD2w5Mi003FmODMuark8w50+h yZkujyY2/Kl33eMGEn8Oa6Y31jGMGUfqf6VGdS07r5v6Gjlt1Jv5HNn7Uf8Ali360givDyIm/Wuh Op6Zj5nJ+gNA1TTCOGb/AL5NHIK/kYPk3p4EbfrSraXxGPLNdAL+w/h3H/gNAv7bPyxvg/7NPlfc fMuxhixvu6Y/z9acLG+7qP0/xrbN7Aekb8/7NIblOmzH1P8A9ajlZSl5GN/Z12eMqPxFJ/ZtyRln APsa2ftS5+6o/wCBf/Wp/wBqXplB/wACNHKx83kYo0u4PWQfnTv7Ml7uPzNbH2hOzofxNMMzE5Uo fxNFgvcyTpDnneP8/hQNHyeXH5GtBpp8nAjP4t/hUfnXfZY/1/wqS0Vf7HUcFh+RpP7JT++PyNWj JekcIn6/4Um7UeypSsPXuVf7Kjz98f8AfP8A9epBpMJH38Y/2RUxOo9mjH4UwnVCOHT8qVvIevcc mjRDnzOP90VMNJhHV+PoKpsdVPSRR+FA/tYn/WKR9B/jRZdg17mgNKgAyHP6f4VINOiH8f8AL/Cs 0R6merA/l/jS+TqY52qfxX/GrUVvYnXuaf2KBTkyc/UU5ba2H/LXn/eFZJj1EH5lUD/eX/GpEW4G N5H5rV6dRa9zT8qDP+u/8eqTbaDrID/wL/69Z2XHJP8A4/8A/Wp4bP1/3z/hS90dnYvhLQ8B8/ia d5doR1z+JqqiA+o/7aGpvIi4+9/32f8AGqsibsk8iyPO3P509YbL+4D+FVnt4sfdfHsx/wAaqtbI edrjHuf8ah6bItK/U1NlioP7oflTWFoekYH4CshrRO4f8z/jUJsQe8n5n/4qpu+xXKu5tkW56Iv5 ClAiA4C/p/hWENJDdPNz+P8A8XSjRN38Mp+v/wC3VWYWj3N75TxlR+X+FGyM4LOufw/wrnv+EdRu QrA++P8AE04eGUJ+YjJ9QKVu6Fp3N9RCGYtIu3oORVjNrj/WoCPcVgroFvGAGZOP9kVOdJswBgxj HfAyf0qlYzfqajSWp4EoP0Iqs32Z8jf+VRJZpGMxyRqP93/Cla33H/Xp/wB8/wD16GkCv3GGO2OS CePenqsHbGKhayDA/vV/L/69QnTucmRfwA/xqErPYrdasvYtgAQV/KmGWJeAwH5VQOnRgZZx+lJ9 gtRyxB/L/CtDKyNDz7bq7j9KYbyzXo4H5VRa1tAONv5D/Cq0lvB1UL+X/wBjQhOxbm1S1QkCQY/3 gKwL3xDaQZzMP++v/rVHdhEUn5fy/wDrV5N448Qx6DplzqEitMYUZhHEpaR9ozgAL+Z6Acmu7D0K lWahBXb0SOWtVpwi5Sdkij49+JyadALPR1+3anckpbwKxwzf3nIHyov8RP06mvMrXw1BpPh65+JP ieb7XpNk0ZvbwSN5WsTyEOIjErAm2hOI0zjeRgEDOfN21rw3fXN1repQy61Hphjl1ma0vls91lKd otrXccyLuxkbN3DFsMQBaHi74Z63rt74u8RX62vhLQZRJYadcpGL27uBGCGmSLIMaEYUcB2xu71+ 8ZZlkcBS9mpe+/jl/L1sv6137H49j8w+uVOZL3F8Me/myP4h2ltq2lXPxZ+JL3emXGqyKdD0azmM TqmONxYF1Mg+Y45ROc8gV8bm8vYLwyzZEqEDzFPzDAwBv7hRxz2z6k12fxB+J+rfEPxPceINUP7o gxWsQbctvCTnAI4LN1dh1PsBW58LPh1qXxW8Rpomn/urGLEt5dOuI4IVPzE+56ADkkgDrXNjK8aj 5YK0FsOjTcFeT95nUfB681/xp470rwpqN1EdMu9zXE0jOrLCqnO5IyhO7ATIPLH04r7A8W+KP2j/ AA9461v4ceHL1X0yygVbiOzX7U2ni6XarvK+CtzIvJBbgdQAK8v+MfhXR77VfDvwx+F+nTvrvhxC 7zW+T9it2ILSTiMEmUkh2IOV4VckgUz4jap4Y0y+svhl8FA99r17bta61rCzzO14ZwDKHLEZfOTI xX5B+7HeroYJRtUkrXXVaRtrd/I462Ku3Ba2fR7+R5V4H8Ma74j1u++GWnXtvd6Kt15t7qEcIc7U PLRysN5LHIXsT83Tmv0y0htE0bTbXS9NhcW9pGkSA5J2oMDJbkn1NeSfDT4daP4G8PwaVDH5k74e ebaN0kh6nrwB0A7CvU1s9OQfNGOPYV+U5/mscbX5aCtTi9NN31k/Xp5H6Rk2XfVaPNVfvy38l0X+ ZvpqyMMLGwHuQP61Xl1GI/ez+eay9+nRj/j2Dfl/jVSS6tF+5ZqB9RXy8W+p9G4rdF6TVokzncce gNYlxrVruPyTZ/3c/wA6lN7CD/x7KPxFRC+gOSbdT7Vo2SlZ7FZ9dt0GXjn/AO+P/r15V8UPjt4b +GWhG9uEe51G4BW0tMgNM47k5O1B/E2PYc1D8Yvjj4W+FWjA3Fkl9rd4p+x2QbBY9PMkI5SJT1PU 9B6j8u77UPE/xK8USa1rczX1/eOBkDCqufliiToqL0AH4+te3l2VvEP2tXSC/E8vHY+NFckV735F /XfE/jL4n+JpvEXiC6a4vZ/kG3iOGLtFEvZR+vU5NexeBPh5czanBomnW32nVZivyZAWBW5Msp52 hQM4PP0rR8DeBbyXVbPQtAiE2rzKszyn/UWyE4JY45YDPXoemTX6N/Df4WeGvAOkfZ9Ocz3tzhrq 7IG+Zh9eijsPxPNfRZhmMMND2VJa9F2Pm8JhJ4qfPUfu9X3K/wAMvAnh74a6ObS123eo3PzXd4zf PK/XA44Qdh+J9vTk1OLrhcf7/wD9apE020H35GPfkipFttOQ8yf+P1+czqTnJym9Wfd06dOEeWK0 G/2pGOuP++z/AIU7+1Fzn/4r/CnhdMzjeP8Avs0uNP8A4WU49yawvI3tF6n/0O/Sxs8fck/77FTf ZLL/AJ5uf+BirccEzD5F/PI/pSi3umPCAn/gVfjMY6bH6nzorC1sx0gY/wDAhSi0tM8W/wCbf/Wq wbXUM5Ea/wDj2f50xre+zgoo/wCAsf61rZhzpjksrc9Iwv4g1aS0i6Kq5+grOWLUw5VVVAO/l/8A 2VOZNVHWXH0j/wDsqkhs11iCdFQUHf0yg/OskQ6ocjzif+2Y/wAaUW2qdTIx9ti1VmK6NPDHrcKP aoWtsncJ935VAsOo9Dub6oKXytSDHaxX8BT5e4c1iwbYn/lr/Kk+xA8+acfh/hTFg1Y8LJn8AMUj WOr5+eUgfhT5ewc5bFtCv3pGP5f4UjLGOF+b6mqBsrzO1pW574p62LY+d2f8MUasV0SlWPSJT9TS +VMCP3KgevWmNp+4ffcH2JqH+yLl+RNJj/eNLlYudFzbOBgKo+gpP3i/fwfwqsNCuWHEjn6k03+w Ljozvn6mizHzIuPNBgL5S5HXPeoTLFnPlx5/CgaHj70nP1NO/sWPqzDj3NKzHzJDVuEzz5YH0WrH 2q2x9+MfgKrNosBPUH/vqpV0iBeOv51SvsPmRIbm3PPmx0CW3PIkQ/n/AI05dMiHGP61YXTIsBeR S5bhzEP2u0Q/6xAfYmmnUrZf41/L/wCvVg6TFnJI/Km/2Rbknnj6U7SBSiUzq1qBkspH0/8Ar1Gd Wsj1K8e1aP8AZUCnj+VB0m2J5PP0AqeWTL54oyn1PTyedv4A/wCFPW/08/wj8Af8K1F0mzU5zj8a edPtB/Hx+FLkaG6iKC32njGEYn/cP+FTfbLJhxG2f9yrn9n2IPDDP1pwsrYjAP5Yq7Mz5kZz3dqC cIfyFNN8iqyiNsNwcDrWmLG3UffIH4Ups7Y4BZunrU8rHzdDnmvYumwmo2ukznymA9f8muj+w2iH O0tUnlWicbCfwqfZ9y/aHNx3KynCwk/5+tWCNo3MgUe5/wDr1vebbgYCdPUgf1qtPcjH3FIHvT5b Bzsx2vbVHVE2uT6Ef1q3FNO/zJDkD1KiohMs7bY1EZzjIw351pRxXAAzKhB56AUa7DugWS5Zc+T+ o/pQTKRzGM+nBq8sgAxuUe9IZhnnB/GrsyObyMsrdHlUX8x/hT47a5P+swp9gD/SrjSRg7jjP1FK 9xblclwP+BD/ABqeVbsOd7EKwOMDOT+IphS9U5QLjtyakjkSQ/LyP96nkxod2SPqaLCvYpOdQB42 D86ZjUnOTsx9P/r1Za9iXjzkX6n/AOvU32nO0pKppJeZXNboUPs9+fvBPy/+vSG2vemEz9KtLqls 8hhWdS47AZNTfaDnduP4Af4U7JC55GaYbsfeVPyqM21weyj8K0nndh8pb8h/hUBmkAP3z+FFkHMy mbe4A4IH4U0w3IH3qna4k7xyn8KrNdSg/wCol/KmkJtkTR3XQuarNBdk8uaSW8fp5Eox6g1QmvpB z5Eg/H/69aWRnzMtsl4Af3h9KzLg3mMec35VRn1Rk+8jfif/AK9c3fa4VUgoQPr/APXrWMEYylLs UfFGrf2Pp11qeoXbQ21pG0sjngKiDJJ/Cvzv1f8AaZ1ibXr+C1jI0K7ZIzIvy3y2+CGEcm4qhfcc 8E9O4GKn7Q/xon8W6jL4Q8PyldFtX/fSI2ftco9x1jQ9B/EeTxivlhs9R15r9JyfCyw379/G9vJf 8E+FzTEKv+5+z18z7m0298F/FC8vfGRi0/SfDHhCBBHp8jrHe3AXYqb41zI6k9SvHG3jczDH1Pwf p8kUPiPWdTtvBkfiQvttDbtLGliRkkxnLYfaGz9zLKAeu34/s7aSUpIHEWSQrHO7cOeAOT7npXvn hX40XJ8QaXd/E5ZvGdjocDw2lm7LbtEdgWNlO0q3l4BAYHOBwelfpNHM1OPJXW/U+DqYBwlz0X8j Q1z4Banb6QfGFgH0jQ7i+On280qmWCe5EYm27Iy8q4TDOwDqucZFfTfg34jeEfAPwn0zQvhhF/af ivWZPJFuil5nvASomlQDcETOYY++ST0JHEeHvE+m6j4c1n4m6vr51S91cnTNP0aC68y4iMxGFuUI BUEIoLKMuOp3MMW/iTotlongLwvfzaKvhHxZaiaeTyBKbq7Ly/6yVsqINgwFUA7ehfc2BFLLYOpG S96Plt93UmrjZKDT0Zu2vjzxB8E/DupWGl6dHF408XbYp7qV5WvVKEh5hG25GR3ZhH90bwSAwXNe l/BT4TW3hfTTrHiBGm1q/G6QkkmJDzs3ZySTyx7muI+EXgHxDrWpL8TfHBn1TUrna1u10xeQhV2r IxbJ+6AEHYc19bWz3yqAbd+Ow/8A1V+Z8T50m5YChK/88l1a6ei693+P3ORZVLTGVY/4U+i7+rL1 vptio+WN8emT/jWgLCxP3oCfqT/jUCTXQXDQuPrmo3upwcBCPrkV+ZxjG2p96+cdLYaaR81rn6// AK6y5rPTF/5dl4+n+NFzfzL2UfVjXOXF7OSdqwn6k11RhEzcpGuYrAdLZR+I/wAa8G+Nnxw8M/Cj TRY2VpDf+JLxCba0yCsYPSafHKoD0HBboOOa5H40fHi2+G9s2k6YkF54iuVzFCCSsCnpLN6D+6vV vpXwNpGka3471u41nWLh7q5vHZ5ppDmSZ8dFHGfYDgD8q+iwGVqs/a1V7n5/8A8PG4/2Xuwev5FC Rtf8da/ca3rVxJe398+ZJGH3ieioBwqDoAOAK+j/AIefD7UdQ1GPw34Yt0udVnI3ytkLaopG52Kn KjGcN6jABzirvg3wfda9Pa+DvBlt5upXMYNxICFjskQjdJIxByW69R2Ar9Efh38PbT4d6P8A2bpN sstxOQ91dOR5txL3ZiOgH8K9B9ea9XMcxhh4qnT36LseRg8FPEy557fmavw7+HOjfD/Rv7P0+MTX M58y5uWHzzSE5J/2VBJ2r+J5NekJEufmAUVlRnVR0hQfVv8A61WGOrNy0cf6/wCFfnc6vPJyk7s+ 5hQ5YqMVZGkYbfHVT9RTBZ2jHLbRn/ZB/pVDOpY+ZFz7DNSqdSI4TH0A/wAay5kzdQkkXDY2Y525 +gpVitRxsFVmOpnhlb8wP61F5d4TzEf++lpOUROMj//R92XyMDL/AMqFMHUP/KlSKPHO7n2P+FTe VH6t+tfkqeh+kqImYepf+VKTB/E5/wA/hSiJOfvfrTCkQHG79apyK5R4+zdNxP4//WprCDruIx6E /wCFREQ9wx/OmHyOm1vzrNzGqZKGizjJ9uTSrMo+8G/U1EFhbkI35/8A16fshxjYfzH+NJTYOCGv MM5Cv+tRrIwO4lj9VP8AjVkLF/c5/CnBIhyU/UVSk7j5URfacD/Vs30XH9aia5b+GF/0q7iPoE/U Um2MfwitHNmfKkZxuZx96CQj/eFMN7MmFW1lf8Rx+tae1c9FH+FLmMdwtLmDlRmNe3jDAtJfpkf4 1Ebq/OcWUhJ9WFapljzjzMUgkiPPmE/j/wDWqLhyrsZf23VV+7Ykf8DFK2o6ttybMj/gZNau+Hu5 x9arSSWwOTKy/Rqd3YaS7Gc2oak2P9Dxn3JqP7bqHObc8+matvPZKMmdh/wOoWudLUZa5H4yVGpo uXsQG61LdxAad9q1EE5gJHpx/jR/aOjr/wAvC/jIKb/bGjDJN0n/AH3/APXqdupdl2HC/vgeYcD6 D/GpPt95/wA88D6LUJ1rRv8An5T/AL6NMOuaSv8Ay8qfoTUOT7lqK/lLIvbk84b/AMdo8+4PZsem VqAa/pWcecD9N1PHiHTAflm/8denzd2HL/dGMbgnlnH/AHz/AIVGftAGPMmH4L/8TU3/AAkVhnAZ j7iN/wDCpRrts33fM/79N/hR8ytuhS3Tf89px9Av/wATUix3B4+0XAz7j/4mr39rFvueYB/1zx/O mnVZehdgP9ypbtuw0fQrfZZXH/Hzcfn/APWpVsJzwLyfHuCan/tdh96RuP8AZpDrsa8tK3/fBocl 3Ks+wi6XeH5Rey/iv/16edGuT969kYfQ/wCNVD4mtlbmR8f7hpR4ts1OCsjD/dNJOLHyz7FtdGl6 /aHP1X/69PXSp1OBMQPXaKoHxhZjIMMh/wCA1A3jC1zzbSfkKr3RctR9Da/syfH+vH4gCkOm3H/P dT+f+FY48W2vX7G5B6fdpR4xt+1kfzX/ABovHqPkn2/IuPpO47mMZb12nP8AKmf2XjnzI/8Avk1X PjOPtagfV1qrceN0hAzZZz0wQaV4PqUo1F0/I1V00d5U/wC+Kk+wqDjep/4AP8a5WL4g+fMYIbFQ wBOWO0YH4GtGTxhcRYT7IMkZ4I/Sk3Fbv8x8s72t+Rt/ZUHv9EWlEIA43f8Ajo/kK5STxpqfWG1j P1Lf0FXIfEurzrnbDGPfcf6imnF9QcZLdHQmKQ8BXP8AwI/0FN+yzNwIR+O4/wA6xzqutyD5ZYv+ /bn/ANmqu17rh/5aqfpGR/U0tCLs3lsLlmyLdZAOwUGoLwXGVWcJHjou5VI+oxk1jJqWv2z7kcHP /TOqU2pazJKzyIhYjGTHSlorDjdu50drFC7lnPA67B1/HitVLa3I3JGzf8CH+NcFJf62ZPMYR7un 3OPyqT+1Na6+aF+ij/CoVimpPZndfZoAMmIf99D/ABqJobTr5QH/AAKuJ/tPVupnH/fI/wAKryap qv8Az8foP8K0UkZuEu53jRxH7gx+X+NVXhA5Dj24rz6TU9VI/wCPg/h/+qs6bU9Vx8tyRj/PpWim uxm6b7nokyuAcS4/CsyVmX7zhvwrzS41XWec3JP4/wD1qwp9U1gg7bg+n3j/AIV0Rl2MZUm+p6Ve XOAen5Zr5O+KWua38SLLxP4O+G+radap4cs5LrWrie5WGWSJAd1rZqAWlfg+aVwFHylstivI/jl8 ddR0yWfwd4Xv2F5gpeXUbf6nI5ijb/np/eYfd6D5unxckrzPHHHkKw2MM4ySeAD2Hqc5Nfc5Rl6u sRXjp0X6s+MzPGWvRoy16v8AQRYbg263JhcW8hKqxQqpI6hT046HB46GqcpSMfL2yc5HXsBXpfjX 4r+MfHfhXw14I1+9juNI8HJJHY+XAkTKr4UpuQLuVQuAWGSc5JzmvLhHJLOS/EadD6n/AOtX2MuW /u7Hy8b2940oNlxH80oSWEll3E/Pk5IB7Nn1wKmkmVXkDc5ZW3MfmUj0I5PpVKDE4aRAAg+UY757 mgx3MR8tIfM8whcgZYHOBx7+1LnDluXtMn1CPVYNQ0l3guoH8yORPvRlSGDDH908/Wv1i+H9nL4p 0q2vtS1y58Rz6hbr/aWozvlpc9LdemAMcrjCA/32bHg/wZ+CNvp+jJqOvQob67Ac5b5oh/CBxwf/ ANdfWmk+HLSytorW3kEcSDACtgfoK+QxfEvsoVKOF+J6c3l1t59j6GhkXtJwq4j4Vrbz6X8j0i2j hhjWKPhUAAA6ADoK2bcIOSwH1/8A11wcWlWoGfNDeuXNXRZ2sQwuw/VjX5qnqfccvY7t57dQTuBN Yl3fQjoU/HH+NcnPLHEpIEXHua4rVdYhtlZ2MWPx6V2w1Zk4s7W/1a1jDbzFn8DXx58bP2jLDwsJ vDfgwxXmukFZJgA0NpnuccPJ6L0H8XpXlPxi+P0t68/hXwLMsYGUub+PGR2McB9excdO3rXzpoPh ua4KySoTk5A68n19Sa+1wOW3Sq11p0Xf1PlsbjuV8lJ69xmmaTfa9qT6jqjvczXMnmyySHLysTkl j719L+EfD1/r2pW3hrwkgN65Dee5ISxjB5diMKoAHAGST71h+DvAmreJtWj8OeHkBuAA087f6q2T uXPr6Acmv0S+H/w60TwJoqaXpQV5Hw1xcOf3k8nq3sOw6D65Na5nmioR9nT+L8jhwOAeIlz1Ph/M 3/h34N8LfDjQ/wCytKuEkuZj5l1cvjzbiXuzY6DrtXoPrk16Imp6djm5T8zXPJZY53IB9T/hVkWb Dps49Cf8K/NJ1Zzk5S3Z+g06NOEVGJ0I1bSdozOp/E006zpIP+tXH0Y1hizcd1/X/CgWch6tGPzr NyNlGPc3117R1/jTP+4anHiPSFHDj8EP+Fc39h9ZI/1/xpVslBO54yPx/wAapSdgcY3Oi/4STSjg 8n/tnS/8JJpXTBBH/TP/AOtWCLKAfeK5+p/xpfsVoeoQ/n/jScmJxiz/0vQP7Z1vBzGi/wDAf/sq cmsaq33mjX6Y/wAareZYx8zSJkerD+tKLyzPELqc/wB0g/yr8aTdtz9VVuxoLq1+eGdfwFKdUvcZ EmPouf6VTMgHA3fk3+FRluwD59kc/wBKb5h6F46penje31Cf/WpDf3jfxy8eiiqi7mICrIT7I1Pu ZPsi77lZEU9ymKzbktyrJ7Fs396FGGn/AAX/AOtUD3motyrzD8P/AK1RwX0Uqgwk/McDJA/rVuQ6 hGMm3Yg+nP8AI1SkzPlV7GY0mssf+Picfl/8TSFNcb/l7m59x/hV6N9QlOPIdfqpA/nUjJeL8zbQ PUnFO73GUPJ1fveS/wDfQ/wqJ7DVnGftsmP94irMkt0pwGViewx/U00tfMMGJvyX/GjmvoVYqLp+ pZw16/4uaDYXGfmvH/NjV4RXh/5dmP1Kj+tWEtrs/ehC/wDAh/Sosx81jMXT2/iu3P4N/jU62wQZ a5bj1z/jV0282MMqg/WqrWD5JIH5UWRPMxu63Xhpic+xz/OoDdWytgbjj2pzWOOwz+FQNbTA8bce 4H+NZ3XY0S8x5vUHGMj0/wAij7XESB5Ct+H/ANamBJlIIEZP0/8Ar08i4PRUB/3TTTb2BxRKLlcY Fuv5GlWWRvuxJj/dNQhbw/3f++aeEvSM5GB6LV3kTZE5eT+4n/fJoEk47KP+A/8A16jEd73b/wAd FHkXZ/iP5Cl7wWRN59wDjK/98/8A16PtVx1OD+FQC2vOfnI/4CP8aBZ3vXzD+Qo94LInF9cjpj8h SG/uh94fkBTfsl6f+WrD8BSfYb1s/vnH5UWkV7oHUZc8xk/kKT7d03RD9aQaddn70sh/H/61NOkz MeZHP1I/wos+w7x7kwvojw0OfzP9KlDxP0gUfVTVUaPKOVZvz/8ArVMumXAGN7/99f8A1qqz6oTt 0ZJtt85aFOPRcf1pC1iBuaJF+uKT+x5WxuZz/wACpDomR82fxNLlfYq67jvN0vrhBj6U0z6T1Oyg aJGPf8aeNIgH8I/MUuV9h3XcctzpY5ylA1GxXIjZf0/wpV0uAHlV/P8A+vUyabCRxGhpa9EPTqyB dRts4Z0/Er/Wr4trPUEAYDHqMf04o/sxMYEMeP8AdqVLQR8BUXHotOz6oi66Myp/Dmm/MqA7zwCd pHP4Vnt4euotiwTbTGcrkgL15yBgGuuSBx021aETnG4D8/8A61HIX7RrzOMSG4sXEknlyMTzhBWm JnYbgqp+Cj/GuiFoX6Lj86U6cwGGTI9j/wDXq1Azc0cnJqDRnaZQT+f8hQt1I4B8yT8E/wARXUHT EUFlUg+7Y/rUCwSAYVcH/eBocGg54vYwd7k/O8v/AHyR/SncE8mU/n/hW81uBzK7KfUc/wBKTybZ eTPJ+ZFLlFzXMUWjyn92jn6g1DNaPCMyrt+oNbsqQbeJJCf941QazMin90HB7uHP65p8l+gc1t2Y bzQKQpdQW4AxySfSpWtbxwWW3fA7+XgfrWeIo4NQhNuscTB8/LI4P12EHNegWDT3EZaadnToB5ew fqAauFO7M6k+VXR57cxPGMyYT6jFYVzOqHaHBz9P8a9RvtOtHB/ch8++DXG3mmeW2IoVj9CSDWvJ ZmSqJrU4ibfJnH9P8a43xHBf3Ol3lnpc6297PDJHDIwJEcjKQrnHPyk5r0W7tpI8+Y+M/wB0/wD1 q5TUDFGskglLFFLY/T0rZWSujfC03WrwovaTS+9n5m+O/g9rGm+Mj4Z8J29zqUENsss93P8AKhlw S+HxtJJ52jnJrwt5CC6xn7hKsfQjggf1r9V742cWk3Gta8/k2So+8nuP48fUnaMdelfFd/8AAxdR 0u48QaQYfD9h50txI907uYLUKWAwB82OAQeRnjNffYPMXCChiHqra+b6epw8WZJhcJiI08Iv3ju5 LpFP4UvNLVu+7PndJCTuxkDr6cVoW9xFApkCCaRshFYZVQRguw7n+6PXk9hXYeHPhL8RPEuoaR4f 8NaXc6tqOsRNKkUcZAVFHmcu2FyIxvbJG0FR1IFc/d6JdaJe3Flq9u1vc2sjRSQSAq6yISGVh22n 735V9I5cyPy7VMihWKKyCltsu5SiBeiY5dm9TwFHuW9K+w/2efg0mrQx+OvE9ujQOQbC3m+62D/r 2XuOyA8d/SvMPgP8Ibv4qeJnvNSjkOh6cwkvJP8AntIeVhU/7XVsdF47iv1Qs9AhtIkht7URpGAq qqAAKBgAD0Ar4vOsydNPDUn7z3fZdv6/U+nyvBRm/bVNlt5+ZSs9NjjUY8kH2P8A9atmOyyBjyqs ppbjGI2H/ARVg2RUc71x7LX54ot6H2mncrNbFRj5P0rKulaMEhk4+n+NWLvyYRmSZh/3z/jXiXxJ +JHhjwLpcmp6zfsgOVjjTa0kr9lRQck/oO9d1Gg5u0Vqc86qirt6Gz4t8R6foGn3Gp6nexWttbru kkcgBQPx/IdTX51fE341a345ll0nQmex0dsrkApNcD1fk7FP90cnvXHeP/iN4i+JmrCW/LQWMb5t 7MNlU9HkPG5/foO1T+HvDElw6sRknqfSv0TA5ZChFVKyvLt2PjMbmUql4UnaPfuVfC/hZ7qWPKZx jt8or6G8F+DNT8W6qvhzwvGAUx9rvGH7q3Tvz3Y9lrR+HPw41Lxvff2Rozi00+EgXt+2AE/6ZxZx uc/kOpr9DPCHgjwn4P0qLRtGCW8EfX94C7t3dz3Y9z+VceZ5qqV6dPWX5f12M8Bl8qzU6i938zE8 D/D3Q/BOkx6Vo42rndLI2DJLJ3dzjkn8h0Feix2UWP8AWjHsB/hWhHb6Uox5o/77qYR6YDkSAn3k /wDrV+dTlKTcpO7Z9/CCikorQpi2hUY81vwUU3yl6CWXHsg/wrRX+zgceYuf9/8A+tUo+y9fPjUf 75/wqLGnKjL8hgMiWQ/VB/hTRBMfuyuPwH/xNbivZrwLlD9Cx/pU6zWw5WUH6Kx/pRZ9A0RgrYX7 D5JmP5f/ABFTRaZfk/PM3/fX/wBjXTLLZkBmf/x00jXVqnKShf8AgNPk7hzvojFTTpP4nJ/4EaG0 +M/edvwY1sNq1vCuZZFIHoP/ANVV31qB+Qp2nodp/wAaVoibbP/T9fOki6UlVOfWki8PTDJVmB9C 1ZA18o47n/dNS3Him9Vf9GG4jsEP9a/HIuNtT9Us1sbkej3qkbmU/XBqymlzg5difzrk7bxTrtwc +Qsajj51Ib8s1rwa7rMn3448eoyP8av3RNyudAtpKnCDHvgVUuNHe6ZWkk3AdVKgg1RfWL/++in6 VBJql/Ku0zgA9wuDXPKURWkbFlpVvYyfvBGxzn/VKuK1bqaxMeJTke3BrivMnf5mm3H1NSGS42YR lI9xQqgOJpNZWs7F7ffkf3i39KeulzN2THvk1j+dfIBtk247AkCo21DU/u+efzq7x3YPm6HS/wBk gDhYx+FNbT5F6D8sYrmTdao/AuW/BqjaXU9p3zSEDr+8P9BS5o9ASfc6ZrOcf3h9AKqtaOTyWP4i uWM11uJ86U/RmpdztwzzZ/3jUOaNVFnTf2dv6jn3NMOmqv8Ac/EmsUKSv3pce7Go2jkJPL492out 7E633Nw2MYPJT8jR9lgHUr+Rrm9qjhpCD+dOIRh/rSc/ShSQ2mdF5EC8ZH5D/GmEWy8mRR/3yP61 zLW6E4M5/wC+hURtLc9Xz+VXzEWOqD2g6TLx/tLSG4sR1mX/AL6WuR+yWq8Eg/gKcIbccYU/gtJy ZXKjqTe6apIM6f8AfYpv9oaZ/wA9lP0audEdvn7qE/8AAaeYYhyVUfiKnmYrI3/7R0scmVf++jTF 1PSe0qkf7xrEKRn+6tRmFD918fSjmY/d6nRrqWmEcMPzNKdS04c9fpk1zn2eQDKyUq28w6ykZ700 5MXunRf2lYN91Sfwak+32Y/5Zn/vk1gm3kz/AK1j+NMMcv8Az0HHqaPe6h7p0i3lsRkR/mD/AI04 XUHZMY/z61zeHB5kX86lEjKD84/Oq5n1Qmb/ANqh67M/h/8AXo+22y8GPn/drIWc+oP4mpGZTyV3 Z+tVcRonUbdekR/74/8ArUn9qIDlYP8Ax2sxpFx/qz+RqAytnGGH4CpZWhtHWdgyLdj24WkOukDi 1lP04rH8wjPJ/EipRMoABOTTuw0NQa42Mmzl/FqBrbhvltG/FqzlmiHVh9M01ryEZ+dQfwp6hddj XGvXAJItP1pDr93/AM+uPxrHN7Dj76/mKBej1Q/Uiqd+4vka/wDb93kfuAKVtcu8D5Av+fesYXYz nfGM+pFRvdA8iaIfiKi77l2XY2W127XqBj8KhbWbljx+n/6qxjeRZ+a8jGPRhTTeQgbjdpg9CW60 czsPlXYvyalflhgFs+2f8KjF7euTlM/8BH+NUf7Ts1yzXqsB6GmHW9NUgGcNn0qHd7lrTZF5rq+P 8Bz9VFRtc32M75I8d1cD+VRf2nbvgplgfamm5Ln5UP5CqWhDb6oLm/nnH74bz6n/APVSrrV5FH5c Z2gcADgD8hVR5WPBjb9Kqy/MCvlMD+Aq+Z9yOVdixLrV+ykNIfTv/hWBcX95IT+8P5tU8kec5jb/ AL6FVZEAUt5bfi9PmYcsexzt9NMQQZD+IP8AjXC6rqFvaQypcTiEMAZZGOBHEOSeTjce351L498a ab4WtGec4uGGEXduOT047n0H4nivkTWPGE2saullcwSapqDuPJ0yE5Cu3IM7DPznrswW/wBnsfYw GDqVZc9tOh7dHF4bK0sbidZLWEOrfST7RX49D0vxBr9v4of+0tQmGneFdICuhl+VZNv3ZGB6858t MZY/MRVTRtG8U/GrWbTQ9G0+ZNFikT7PZEEyXLjlZbhM4Cj7yxH/AHpMCvdPhn+x/wDEHxssfjn4 3XcXhDQLT96sd0ViMKnkskLnETEcebOd5/hVRivpqX4p/Df4NaKdC+BmkRSXMimM67qWYoCe7Qq4 824OeflUITz81fZQy903z1XZr8P+D5vRdEz8rxebTxlWdST5pTd35+XkvJavyN+y0/Qf2WfATCWa K58datFldxDrZxNyZXz2B5GRmR+cbRivx88R/AXxXqOq2epQ3Etzc+KNUmCB45JPKt3LStdXErcg nlju5diQo4r7NvNZm1/VpNb168k1rUJ38x7i5AVN5/iWI8nHQF8AdlxxXU2+uKgJdtxPUlgST715 GJzZUG40Xd7JLZebf2pPqdlDK51kpVI26tvRvyS6RXQk8E+DdE8EeHbPw5pK7be0XDNg7pHP3pG9 WY8n/wCtXbobPONhPvg1yH/CRwjH+IqGTxbCnA4/Gvh5KU5OTd2z6tQ5UopWSO5ZrMDlP/Haxr69 sIVOEH5V5h4k+JuleH7F7/VrhLW3QH55HxnHYdyfYV8PfEv9qDXfEHnaR4L3afanKtdMf3zj/YH8 A9+v0r1cLl9Ws7RWh5+JxUKKvNn0H8YPj94f8EiTSNJij1LXGBAhABSHP8UrDp/ujk98CvgHVtY1 /wAW6w+sa9Obu9m+6BwsY7KijhQPasfSdNv9VuytvG9xPMcljliSepJ71774f8G22hGEXkTXmpXB Ajt4xukZj0GB0r9CwuFoYOF1rLufD4rGVcRK3TsYHhnwa6xfbb/ESAZd24AH419Q/DT4Rar47aK5 KyaX4cU/NORtnuh3EQP3VPdz+Fd/8Pfgdqt9Lb6343tVKRkPDp3Ploexlx94+3Svrmys9VgjWOKC JFQYA+YAAdgB2r5XMc5bbhQfz/yPawOUt2qV/u/zE8O+FtK8P6db6VpNrHbWtsu1EUDAH9Se5PJ7 11i2qIOAv5CsyOLWf7sQ/FqnEerYwfK5/wB6vi93dn2KjZWRqCJBxgflT/KTqFH5VmBdS7mIfgxp 23Uf+ekQ/wCAn/Gp+ZVmafyjGI+v0p4YjpHisz/TQfmlT8EP+NG68HBlX/v3/wDXpq3cVn2NTrxj H40eUp6sRWXuuv8Anv8A+Qx/jUyyzjrKT/wAUvdFZl7yhjapJqB4mI2lAfwH+FIGlz/rWGf9kUpZ m4Z3P4CqsuhabIzZiQGOZAyMMEEdqjWztrPakVuQo4GDxj86sqFU5+c/hSvJuXaA+PwqJbC1P//U 7xIzJhobjgdcgf8A16ktppUv4o5HVkZHycDqMEc/nVzGONoH1YUHaOXKjH+0K/GIrQ/VLjrye287 bvBIAHWmpfWsa/K649+n6VGWt2/iX/vsU3dB93ev/fVVYEI+q2wPMij6Ix/XFRHVrfgCTn2jb/4m l3W3dl/76ph+xHqU/E5/pWXKXp2Jl1O2Axvz7bG/+Jpn9q2vJ+bj/Zb/AAqPFiRgFPwGf6VAIbIn Hy5/3f8A7Gno9hW8iVtag9H/AO+TTf7ZtyMFX/KoGtoiflwcf7J/+JqM2AY8Af8AfJ/wqblLlLf9 swgn5WGfXH+NNbWImAXaw/Ef41TGnIfvL+ho/suLk4I/A0tehVoFn+0oj/AT6cqP61C12G/hI/4E P8aZ/ZyH+Gl/s9BxkKPc0O4/cG/bAPlOB/wIUv8AaBGD5iD/AIFn+lH9nwgZ8wc9s037PagY3Dj3 b/Gi0g9wd9rDjDTD/P4UzdASCzKTn0J/pTttouSdpP1b/GpLcWUsqxSGOMMeWYMQPyyaLMXu7iFr XDM0ka7QM7mCnn/eINY0/iHw7bqWk1S0QAlTmdOCO33utYfh2DSNTiu7i8ijvboTOsgdd5QA8ADP AI9q+Bv2jdO8H2Xii6ia8lgWNWeGCCPzVnuQECxyHOECBm+c5OBtruy+lDEVFTmmr7W/XQ4cbUnQ pucNbd/0Pv8Al8b+DVPOt2SkcHM69jg96z2+IngRef8AhI7EdBxOvfBHHXnNfjZDLo8mj3s17PcH VY3iS0i2K0HlfMZWds5VlwoRQCDk5ximTXek/wBk28sLXDasbiT7QW2+SIMDyvLI+YuTu354Axjv X2H9h0f5n+B8x/bFX+VfifsYfin8OkyG8U2AZc5HnAkY65ABPHvVKX4x/DWIknxXY4HVhLvUZ4GS oIr8f9Uv9JaysIdHSeOZbf8A0t5mQhrkseY9nIi27cBvm3Z7Yq9dan4ZPiKCazhu00JXty8Typ9q ZAF84b1+QMx3bDjAG3I61ayTD9W/w/yIeb1uy/E/WmT43/DBIxLJ4vs0Q5wcyEHHUDCGs+X9oH4W wMqP4ut0yAwxHM2Qeh4TvX5TQat4Zj8Ry3d3aXM+lv8AadkCzIkoLh/s+58FSEOwycfNhgMcVk6d qekQ2Opw6lavc3dxbxrayJLsWCVZFLuykHerJuUKCMEg54INrJsP5/gR/a1fsj9Xpf2j/hYJjB/w las6kjC28xzjrjIAqif2mfhRseT/AISh2VMFttnIcAnHQkdO9flgup6Z/wAI89kbNmvxd+aLnzm2 iAxlTF5WMZ34YPnPUYp17f6bc6XptvHZfZZYIpFmnWRpTcMZCVYoeEKqQuBwcbutaf2Phuz+8j+1 a9un3H6hSftN/CnYJF8Q3cqElflse456M2R7cV2Hhj4u+EvF9yttol3qM+6NZBItrFs+fIC8OSH+ U5XGRjJ4Ir8obvXNJn16y1GLS4obaE24a1M7yJJ5aIJN0udw8xgxIz8m7A6Cvr/9n3x3oHh7zb/V rcadY6hLciBlPmJHlgdgY/Mdi4XJ+YrzzzXm47LqVGg50oNv128zuweYVatZQqTSWvRa+R9e3ni+ zttTXSANTkuXAIBWCEHJwf8AWSKSR1wATjkZwa121C8gjWWe3u4kIZizzxYVUjMhJCbj91TwATnj FeGeMfHmjeJvE/h+HwzC+omwuF3yo6QfNMCqKJJQVXucsD1OARmvQNS8eSeF/B9t4v1RlS3hiiE6 vBIJo55FMeRIsUiJscgOSu11JAKkgV15Xl+GrYdTxELO9lq1ft1PPzXMsVRxLp4eelrvRO3rp8/m drbajdXDxJBFLMZ9wTbdAHKAFtwMOQPmABxgnjOeuFdeMb62eMf2JfPBOQIZjdoqSHuB8mQcnABA yemRzXmmm/FOKPwvpGq+Nxe3Uc8423dhcm3MiXxQWgAQwuiDa2/Od/y5ChM1B4b8bDxhPrevXEsy Q6LO1rb28QC7RbRL5iKCctufODu6Y47V9HHI8Da7p/i/8z5mefY9O3tL/Jf5H0VpMtpq9mLyKS4h YM0csMzlZYZUOHjkUEgMp64J7EcGtA2KZGJWz/vn/GuC8HyGO5163O2dobxQ7AAkybAHJPHJI/8A 19a7U3Ei9IR9cAV+ZYzDqjiJ0o7Jn6fgsS6+HhVk9WiU2RzxKfzFQGwlY4Sdh9HH9BUi3Fx3jUfi P6VOLi5H/LJMe7Y/pXDbyO+7Mw6TM5P+lPn3y39KQaFKeftJ/Ed/yrT+23GcBEx9c/1qM6iB8soQ /Q/4ZpGqciomkXMfS5GB1zn/AOtVkWig4eVSPT5j/WtK1kiuT8m3J+v+FXJLDUB9xUIPoT/hTcHb Yn2rvuYxtox/d/74/wDr1QurSNgd8gUf7orZmSdBmYRq3oZMH8gM0kME1z/qjEAPV3H81qeRdCva Na3OTttH0mWcCe9CZ9Byf1rf/saO4kXzZpPLAIG0kD9KsSaRdtKGkltincHLn8zipG0dmx5LbAOy BcfzpOLfQr2nmZt34c0+3xKiNKw/56OSPxzmnQ6dalcvbw/z/pWqmloqgCIbh3+UZPr1qf7BMD1x +K1Sg7kOp5mS1jp+P9RH+AqM2dnj7qg1stZ3HOHH0O2q5s5u8/PsoNacrI5zFa0tMjpUTWtn0+X/ AD+Nb32CVhzOf+/YqncWbKu4XDfTyx/jRyO1w5zEe1tB1C15j8QvGmieDtOdxEst23EaAfxdvX8v zrrPFmujQbLzTP8AOwOAQq4HrkHj/wDWa+E7HSfE37Rfxat/h/4ena3tnLNe3eDttbOMgyyH3wen ckL7162XYF4mrbodWKnHA4P67W1crqC723k/Jdur8jofhr8O/id+014zns/CUn2PTrR8ahrcgJt7 RW58u3/vykZ6c98qPmr7+8JwfBD9mnTP7L+E+nRa54gQmK4128HmkzfxrEU+aRs9Uh2oP45M5rjt b8Y6B4Z0K3+C/wAH7f7F4W0lWhlMT7JNQkH+sMkwwRGTzK4OXOEX5cCuIS2e3UXV2AHChfMcrGio P4IxuCog7KPxyea+3xmOpZfD2VLWf9fcj8zo4avmVWVevLS+rf8AX/AR03irxr4w8b3YvNe1CRih zGJArGPP/POMfuYf+Aqz+r1xo06NpTNLiSZvvSSAu5+rMST+dYmqePfAOi7jq/iKwt2H8P2hZG+m 2NmP6V5Nrf7S/wAMdHLJp73eryD/AJ4QmND/AMDmZf5V8NVljcY9U2u2tj6+jDB4Re60n30ufR9p ZwRgEBM/7gq8YkXhCox6KK+DtX/as8S3atD4W8PQWufuvO73D4/3V2r/ADrzTUfF/wAc/HgaK71S 5htn6xQf6PHg9sR4J/GuqlkuIfx2XzOernFCPw6n3z4q+JfgzwbE7a5rkEEi/wDLFCskx9giZP54 r5P8aftWXtyXtfBVkYxyBcXPzMfcRr8o/EmvKbD4OXLZutfvVgU8ksefxJrobbQfhxojbFZtUuB/ DEN3P16Cvdo5Xh6Ws3zP8Dwq2b1qnu01b8zya6l8c/ETUvtuqTXGozMcBnJKr7AdAPoK9H0n4V2u mwi88T3CQr12Z5+gHevcfC/g/wCIXipBH4b0lNDsH48+ZcMR7EjJ/AGvpvwL+zloOmyJqXiMyazf DBLzt8in/ZT/ABq8RmtDDrkhv2X9aHPRwGIrvmlou7PmfwL8Odd8RkReErJdJ09iA17cDazD/YXq f8819jfD74OaD4LAuotl1qL8yXUx3SEnrg/wj2Fey6d4c0myjEccIUAYA3kY/WtxNMswMiIH/tof 8a+HxeYVsRo3Zdv8+59dhMBRoaxV33Zj21n5ePnjGPTNayKy4/eKfzqwthCPu26Y93P+NTrZRAf6 lB/wI15CTPZ0IVPIG5f1p48vHOPz/wDr1ZW0i7Rp/wB9Gni1j/uR/nVBYqDyu6injyem0VdW1Rv4 U/SpRZKf4V49xRZk6GZ8nZV/SjgclR+Y/wAK1RYL6DP+9S/ZQO2f+B0crC6Mr/gPX3/+tTlWU/dU /n/9atHyEHUY/wCBGlEMfv8Amadg0KPlz5xsP6/4UnlXA/5Zn/vo1f8Astuw5yfxNOFhadSg/HNO zLSRnkTg/Kh5/wBo0jfasYCEn8a1RZQryqp+INNaCIDhIvyP+FJphZH/1fQRPe/88Ux/vf8A2NPE l0eWii9uc/0rcR7b0P5GpQ1sf7wP0Nfi0XJo/VNOxgrJck4McQ+gqXMoXog/DH9a2CbXrtY5+tA+ zYzsP41d2O8TGBfj7oP4f40u+XuQT+H+Nbg8kfwcfWnh7fH3KXvCuuxz4MoPDfqKQiVu5/76rod8 JGNv603fAeNlCT7iuuxzRhkPdj/wI1CbVz2Y/wDA2/wrrN8WMbRTNyHkKKLPuO67HKGzbqUP/fT/ AOFRmycjb5ZIHqW/wrrSV/uioyy9lH5Ucocy7HMCzbaP3Z/8eoNm/wDc/wDQq6Qsc8Jn8KYWk/55 j8qOUfN5HN/ZCT9wfrR9ibH3B+R/xrohJJ/zz/SkLyf3KfKLm8jnzaMByox9P/r1JDaAyIqqMkjq Pf3NbG65wcRir2km4bVbNZIlMZmjDZGRtLDORWkIXkkROpaLdj4nufgv8Xhq88ujaHqVhYoJpJd0 zTG7eWRin2ciMmIZ+ZkbcAp+U54rzb4j/AbxBB4V/tnxnodxptpaQy+ZdziZPss0zt5csxQMJgny JhVUclj2r9aviB8P5vE+tWslr4l1Tw9DpcrZh0uVIEnCvkCUlSSuONowMV5H+0ld+LofDZt/DkT2 +mXNtdG/u4oYXMB/diABpQ+wsSw3eW4HU4xX6xFYeK5oU0m+v9I/LZSrSSjKo2lsj8jLT9n67n0W SLSv7M1G8ukjU3k17NCbNxM2dsHlYcOi43MWAHIweBy/ij4Tr4c/s7SIorbUp3jhvbm6s5nnUCWN y1qzAqimMxMSQhcZJ5GFrt/ifear4fOj22k3NzZWkCSRoEaVI2MMjLhWwIjwoH7sA/7I619B2k3i nUPCOjS+OdDt/Cs8ysLMrLczXMkIAdrrb57v5okARtwGMKdnWtacW5vmlp/Xmc86rjBWjr/XkfIN h8NV1drO3bS/sywQybvJC+bcFlMytI0lxjcqkKdgGVA2q8hKV2tv8E7fULYeIEt1jnit4rgafbWs 00f7kMD5oi+0ttmCbyUJwdwITIA+tLHxXpdtcXMTYtLSR5nuPPvGm2REAyhzglnSWRh5a9WIAPIA 5WG20f7Zb6bcQW0mj62t1cWlw0atEsLbVEYjuNgQKxOWYK0bY5zgV2+zhZu5x/WJuSVtz5W+E/w9 i8f69qerNY+QlolzP5ENk13aoDG7bdrIEQL/AABnLDAIBwTVKz+HtuNE1KXSoHv2eB7ZxHGk8iOs cc6PGxjxv3HaFUiR13KNuNzfVXww8BeBvA2teVcajb32oXqXDAtax6pHbQINoIaGCRkZtxJKqNmw EMcgVysn2HToNUm8O6ncBIBcFJLMtNLK0Ee1JVEsxMLZQsGALhcBkdQkY5afLLqdc5SifLnjbw2N MuLzR9OijgsVs7XUJFXy5XExZocCYKDs+bLBdqscNt6Y88nlv57Sy0+YRyQ2HmeUAioxErbmDuoD Pz03E7RwMCvp34kaDf2iXWtwwONMudFW3jkaKOIs8NwJCrRRvIF+Ug5Bx75yB8/SRjZ8yDcpAIBz gc4xVVLK1iqTbTuNs01XxPrtgb67FrLaRwRpPsDCOGAhYh5aj5ypwMnkjlia+x/hb8NPiJ4z8LWn iOLSLCaO8upLn7RP9mUefgq8giZgA+8nJ2Y4wAF4r41sIlvbue03bRPCULrjPzOvK8jJ9q/Vv9mm I2Pw4i0KSQyQ6a6rFuAGN4JY4HTcwzispS5YXN4RUp2epxdl8D/iFbX6SzDTEj3whnRLDcUjwMgs hI+XgAcDHAruL74TeLNQ8Lv4fh1K0tXkiaDzDcRuFRny2F343Ed+gz0zg19cfD23tbrV51niSULC SoZQwB3AZANe0xafZrwttEB7RqP6URipxjza211Im1Tm+RWutbf0z8s1/Z01eTTYLKXUbGOdGhaS 4SYtI3ksW3bd2z5uhA7dK6PR/wBnLW9Ng1MDUbfUf7SuJJ8bfmUyeu4hTjrya/TmK0iGNsKD6KP8 K1YYQD90D8BXfKrUatf+vvPO9jS35fxPz00P4M+LLK4v3TybcX8ombYQRnGCSAw612en/CrxZHeR A3kB8w7CrlhnPuCcV9g6hrN5YahFawxWzpNLDEA0wSb94RvcDphAenBPBBPSuSnkQa55WMM06jIH TLgZya+XxmDpybqS1bPpcJjakIqnDRI+TnudIhlaCa9gVkJBDSdNvB6tWDc+N/h9ZSmC71u2R1OD gFufTO0j9a/Nvxh+0OuoePNQ0y58FaOUtb24iDublnPlyMCxxKqknGelb9z48F94bl1aJIrJCJLU xWyPFGXyTjG4nlSOc59+1eXDJrvV2Pblm6jsrn343xC+GuD/AMTqFj7f/s1x/in41+APDcNs8D3G ptdb9qWqjKiPAJYyMg5zxjPr0r4d8I/E218htCljMd5cNGkBVpnV2yfvhpOMZznPtisr4m+I4p9H utKu7NX1J5LaSO5Rm/drH5glGCTjeNuecDFdMckhe7kYSzl2tFH1Ne/tU6fYFW0nw9PIc/emnRQP rsRz+tZq/tpeJ1Plv4JtGQEgEakVOM9cGNq/NwXlwxIaRiB7k1YjO4lZFDH3z/MGu6OV0ErNfn/m cE8yqyd/8v8AI/SKz/bEjuZv+J94SljjPU219C5H/AXVAa9h0n9o/wCDdxYx6hea0dKLNtNvdwOJ VOM5xGJFI9wSK/IiKGzkP7xXjJ4JVsj8q6KHw4l7Cwgl8wKCQM9DjrWc8ow8ttP687lRzaqt9f68 j9j5fjT8Lo/CsfjR9eh/sWW4NotyQ4UzryY9gXfkDn7uMc9K5y1/aL+Cuo39vpln4lge4vJEhjHl TAF5CFUFmjAGSQMk4r8dtU1nX7Xwza+EUm/4ly30l2IscieREic591RePr61Uvl063udJsrCWX7a wY3JIVVSXzCYvLYfMfkAJz0PSsY5JT15pPyNnm89OWJ+wPiH9pb4NeF9YvtA1PVJWvtNlaGdIbR5 AsiHDKGwAcHg4OM1if8ADWXwafQ9R12K7uSunPEht2gVLiYzZ2mJWYBgNp3Ekbe/UZ/IxINSvtfv ptRka4uHZ5mklJcyOW3EsT1JJ5qjZ2cmvWl80WDNBh1CjqD2H5Vayahy2bdyZZtWvolY/Ua+/bf+ HMKE6fomo3L9g5giH5hn/lX0d8OPiPovxQ8JWnizQInSG4LxyQvzJDNGcPG23gkcEEcEEGvwyuLa 60zQIbkp5cjOEkVgNwxkr9M4ru7HW/E+l6GLXw7rV5p1jO/myQwXEkUbO6AbmVGAJwMZPanVyei4 2pOz89RU81qKV6iuvI/b2+1SwsIy+pzw2aj+KaRYx/4+RXlHiH41/CXQQy33iuwEi/wRSee/0xFu r8fZ4bzUJfM1PUHuHPUuzSH9SatppOnQjLBpAPUhRWEckgvjqX9EbTzh/Yh+J9TfFT4/+F9eWe30 S5luC/yhjGyrt7/eweeB9M+teT/DH496n8KPDniPRvC+kx3WqeJtiXGpSNIJkhXJMUSJgAMzFixb PQY4rzqNNLgPEcSj1b5q1U1vTbcYRVH+6oFe9hqFLDR5aZy5nm2IzFw9ulaKsklZJG5H8WPircRy W+jyNp0cpyTDGFY+g3nLADtg1z9zovjvxNJ5ut6jPcbjk+bK8n6EkV1OlXOt6mANG0e5us9CkTEf mBiu6s/h98U9WAzaJp8Td55Fj/Qbm/SsauJw9OTnJpP5XOGnQxVVKME2vnY81sfhfYxqH1K4AJ6g sFrWbQPh9owzPKkrDsBuJNe16Z+z/c3OH8ReImx3jtIWf/x5yB/47Xpmh/Az4aabIJLi0utRcc5n chT9VQKP1ryKueYaOzb9EejDJcVL4lY+S4vEOlQuItB0U3Eh4BYYH5da7bSvDfxh8SqDp+m/2fA3 8ZTylx9ZMfyr7p0XQvDGkRrFpWlxWir08uJEP54yfzrubWKzYbvLb6nFeFVz+T0pxt63PVp5HGOt RtnxNoX7NOrarKlx4y1SW4PXyojuH03MQv5LX0n4P+CXhvw6EOm6TGrjH7yRRI/5t0/ACvbLNrCI jMbce4/xrfiv7JRgKw/4Ev8AjXhVsbWrfxJ6dtj2qWDp0vggYth4e+zKCIhnjsK6KKxuEAG3H4VI uo2RGCrf9/B/SpUv7HtGT/20NedddzvUH2HLZ3AP3c/8Bq2tlMeoH5VAL+14xD/4+3+FTLqEAwVh H/fTf4UtO5pyvsW1sX44UfU1YWwJHOwfj/8AWqn/AGkOggH5t/hUo1IjkwKB9TWilHr/AF+BPLIs iwfgb4xR9ifvMgpi6si/eAX8RTv7VtT96RV/75rVSjYnlkH2Ju06/nTxYSnnz1NVTqFhnJukH1K0 06lZDhbtPzWlZDszQGm3J/5bZ+gpjabeDkSZH0rP/tK2Jwt4PwIpf7ThU8XJY+m+lddfzGoy3/Qs m0uFJDOw9whNSLaSHpNj6rVEarJj5FZ/+2gp6aleH/lgw+rg1PMi+VmmLGbPDlvyFSfZp1PzbvzH +FUl1K7OAFVfqQaeby6b/WGPH61d0HKy4IZD1cj8P/rU8aejr87n8wKyZrlFQsXCfRcms5tQtQcJ 5rH/AK5mk3ZFqF9j/9b3f7LGBkxj8gP50ghgB5EYHuw/pXKfbdUb/lmAfZf8TUqyai3Bcr7BRX4t GTsfqfKjp9lqeGMf/fJP9KXbZpzkf8BjH9a59UuMfvJJW+mB/KpRGmMuJT9XP+NbXYrI2/MgH8T/ APfKj+tNMtt33H/gQH9KxvJhPJgYn3P/ANekKpj5bVT9WH+BqW2Ghpvc2AHzDH1kFV2vbD0X/v4f 6VQPnHOy2iGfVj/8TURN4TzHAP8Avo1NylYvm/08D+A/ixpp1CyHQKfoGNVC15g4aBfopP8AWom+ 2d5oQf8Ac/8Ar0hl4alajPyfkhpDqcGOEP8A37/xrOZL8jAuIx9EFRmHUGzm7UfRB/hVa/1/w4tD TGqx9o2/BVpjauMkCJz+C1meRen719+SiomtrjHN835CjUWhqf2q/aF/bkVG2qXB6RN+YrHa0lzl r58e1QNaEnm9lP4mjUNDZOpXh58k/wDfVOttSvUvIHMJAWRCTu9GB9K586fGetzM3/AjTP7Ltif9 ZI3/AAKtYNppmcuW1r/1959D/FX4iaZ8PJJNSutI1XWhcTELDo9k97KAf4iiEcfj05rgPjNoWs+K fColsNUl0jS4rS7m1CMxly8LW5eLMK4dpElC4VXXnINfL3jCLxpqesXek6F4vn0ia4kSG1jOoizS NRCv+qTOzIZg5BXLKDjH3q+c/jHJ4l0Hw+z3PxHu7TVbDci2kOoSXK37FlDqtwu1TJEuGK7MfPjI 7/qlPlnCLvur/efl1R8spR7OxSg0i21jRbq+1lZbfVINSeIIH2TNFJEJdzKQWPz5AJ5VcLk9T6R4 u0yy019OXSfJk0yO2WKSH7UkLtONzCWSabfiTczRkYXcoC81y/wu17x/4k+D+vW934UjutHtYZBJ 4imlJu57ndvW2OWj3pKAUPXlcGQcAZsl/wCJLfwRqqYn0u9u41ubyeCB3kLB5dzSCbbCwaIMPkYg KDtywXOyV5XTepyv4bNLS3zPTGsZNUfU7MaQNNSOwN79qMUaJ84y5VmDFeQcEIBjbg5GK5eDw/ce JtR0q8e4M0NrJNJdrcSETgmVzHH5ixr8r+YwdkBwQFAJrzH4QaR4g8248PTiGC/1EAwTzXc8ky+X 5ZKJEsrQbWEin5lMhOAnRwPXfBCaj4Kt57bW7WHT/ts1sqRMqqpd2VVRkRSQ0QcLEBlWL4TJzXZy qVnL+vxOaTcLqPyLuo6DrHhfxlYR2fhs2mqPa3C+XHcG4hkttu+STfO8eCm3dwemeCa9A0v4UWes 6De2enXy6QkVzJBIVtVlld1GJGEkzSKyszFlaMKFblSCMjgPFX/CPWc6eJrvxHq1pFYwmNLZ5EMf zIq3KGZkLKk0rOrDcCoO3jAqIeN0vPE0994elvP+EV1D7XJbJb3N1FIjwdN+2XaykDllVQxBOTya 4YUZSlL2atbrZr87nfKtCKi6juu1+vyM74u+GNE0XTF8J65PdzxxyYivAkNukq3EJAiZgI4ztCHY eCXBzk5z8hnwRpYV3uLqJU8yNEYJI3meZGkgZP3vKfN97qVBYA8A/XfivxF4f/4SbSrCey1C/trp Hk8y4iMk7ySL8pDJcTMqGJXGwuoJOOuDXnOu29zrGkzx6VDLpcllql2rtJpyMsqTPGsTBm3b/LDA szFiACwJ2ivRpRvTUm0/M4qk+Wo1FNeR4PZWngm2mbyIb118xEWUqikEOpyNzEr8y9QM7c4OTX6M /s0zz6t4Tu7uaA27yeS7Rk7tpLzjGe/SvjLxP8PJbe7E1pdSXQuZoFMAtmieNpFVtjSPiMEdBzzx jsK+2v2T0uLf4fvo18rC6t55ZHLEN8ryMirkc5XYeOnP1rhrqXs3zLqd+HlBzXK9bH1x8OITHrcy N1MDfoRXI/HD46eLvhZr2naH4U8HzeKJbxYnYRJMEjQyYdpbgIYYFCKQpkbGW3sVRGDeieBLYprz Er1icA/lXlnxx0i1vviHpiyWdprUk1j9nOmX17NDaTLM0gD3UUMuRBvCxtO0WEZ1X94Hfyyg/cKq q9Sx0fh/4weKr7UtV03XJ9GspbfULjR7CC2czXt5qFrCJHj8qR0ij3rl4VabMgBUEkg13fhPxv4g 8Y+DdN8SWrm0e61e9tGUWbbvs8F3LDHvjlIaNgiDeWGQc5UdB8w2fiGR/CGnaX8I/Dtlc6hY/ZIN U0y+t7qKzvLZ45rRmu7+62CSC0lOI5SxbK7SPmWvYfgfqF9o3wX0qbX9OtvDt7b61rC3Nj++WCzk W7nZ4lERb5IycDeSuMEHdg10mLS6H0J4gjS31O3u7dkiuGaCMnhpGjMy5Xy9hLD6sAD838Ncxcbf 7XXevzfaF/RxXYaqdPtPEkepyXF3FLbJCJBG0YiCTO8aAq43tuYncE9AeoFcrq8ezxI8PZLlTz/v g15+K+FM2w/xH8uni8vbfFPxJEr7Quq3ykdiBPIPxretLq4jtbyMSHyw4bYTx91TnFZPxEhKfGTx VbqOV1zUEA/7eZBXcR+FdRg0e81aQIIY5MYz83yAA8Y6cdc11RCRgeHJrj/hK9MkiUFjOmAffp1r vvi2XW7R1G0uvb6tXC6CceKdKcnj7TEP/HgK9P8AijZT3Vvd3kUZMVoIfMYDhfMcquT7mtUZvc+c d7E4AxnqPX61dSTYuB1queTzUyqKkovJMGORW/pupzWMqyxNz0xXNImfbvV+3VZXEMYMrkcIvJNJ tJakpXdkaV7cLceZIFQGRi3yjgc5wvpXBX8xj1m3mLZceWT36V7F4c+G/ibxh4W8SeKXS4N1pjQC 3hEZY3RYnzgOMkxptIA69KxrT4G/FTVpYZ7bw/cYJGTJthwB7yMvWuT63RTac1p5nbHC1rJqL1KA 1ReRP97JI69M/lXK+Eb0W91es5wJFH86+nr39lrxnK2nDTr62USWsbXfnOR5V1/y0RQisWTphh71 0/gn9ktNN1j7Z401RLuxKSA29okiszMpCHzHxgKTu6ckAdM1wyzTCpN851RyzEt25T5B8Sal51j5 KMOZASMegNd/8PvA/i/4gWqaJ4Tt0nuYIUnk8yVI0jj3bQWZvUngDJ9q+t7H9kv4cpEU1bU9Vvyx z8vkwDH4I5/WvZfAvgTwl8KtPubTwpZXIa8ZWlmnkWSVwnCrn5QFXJwAOpya4qucUuR+y1Z3Ucoq uS9psfMOnfsmeOrlfP8AEHiCxsABkrEJbhlH1wi/rXk/jX4e6J4Mhlkk1OXUHibaD5YjViBzxljx 9a++/EnimWLTLgBHjJX+Ijn2GD3PFfnX8YNbNzfNY79wiJRiO7/ekP4dK5sFisRiKustEfdyyfBY LKauOxFO8n7sLt799+n6He/ATwJo/izw34x8e+L7BZdJ8P26Q2qKzIJL6flASpydi4yOhLCvqjwH 8KdI0vw5p1xLY24vp4/NkkaJWcb+VAJBwAMfnV3QvAL+C/hT8PPhA0fl6lrjf25q46MplO5Vb/dX C8/3K93jt55G/d2+xBwq7uijgDp2FdPEFeNKlCjHdnweS0pVKsqvRHEQ+F5iAqTsqj+FSQPyGBWr B4KL4Jkb8z/jXe2tjKAMw5/4HW7b2pAB8v8A8fr84vc+65prqedweA42wCx/X/GugtfAdmMFk3fU f/Xrt41I/gAP+/V2N2XoqjH+0aWnYTlU/mMC38I2EWCsQGK1k0K2TogA/D/Cr4mb/Y/76NPE7eqf mTRp2Fr1ZVXSIlPyxj9P8KtrpiKfuKP8/SlF2Acl0z+NTfbVzjzFz9DUfIpX7iiw2/3fpUq2R46f lUQvTnG78lP+NPOoe5/Bf/r0FK5YFk5//VT1smGOePpVT7dITwrf98j/ABo+2TkfKr/kP8aaYcpe +xp0bpSmxtsYZAcVTWe4YcK/6D+hqQST+jj8f/satNi5V3LAsbEDHlL+VNawsyf9Tn/gNMAmPVn/ AO+j/hSmJj94yH/gRp6j0XUU6ZZNx5H/AI6P60v9m2icrb9PZar/AGbBztc/Vv8AGpBCy/wHHu4r P5FejLAtoU6QH68VJ5UP/PEn8qzZElPRQfq9QYuwPlIH/Az/AEpXLt2ZrNB/cjK/iKTylH38fgM/ yrLjW7zlz/4+/wDjV9DJjLsAf+ujf41SE3YmMUR6Bh9F/wDrUz93HwGkGP8AZ/8ArUkk02MRlAfd j/hVYvqDfdlTH+8f8KG7PRFxs9y0ZIj/AMtSD7g1GzA8LcqP+BEf0qpIl8RzKp+nP8xTRDdY+Z1/ FBQ5N9CrLuf/1/XkltuvnqfxJ/rUnnW4480fk1RhcDKsT+VSIMn7zD8v8K/Eo3tY/VNBDLbnjzOn +yaYZIT0l/8AHTUjqMcMT/wL/Cm+WpGTIfzP+Faj0GiSEj77H/gBpvmRE4Bk/COmsE6ZJ/76/wAK qTSKgyNxPsp/qayZSt0LZaLr+84/2QKaTbnr5n5CsjzZi3I2D/aKgfqageO6nu/KSTYigMdpDZA6 9M1N/IfzNz/RgM7H/MU3fbDjafxYCslbpY+gMo9Qc/1qz5o252dfXOa0TJZaM9qv/wC2Kha5th6f 99H/AAqJXBPMY/WmlUP8Cj65qrXJuhzXdsOgGPq3+FQm9t++B+DH+lBhi/uL+VQtCpPCqP8AgNWk xXQG8t/T8kJ/pULXsOeA34Iad5ajjp9FFQtGnoT+AFOxFyKS+j7+Z/3ziqhvo88kgepOP6VYaNP7 jH8BUbxRZ6N+f/1qpLUTZ5Nrtn4T8T+Lh4d1PVZbS/u42ECK5kiYSQ7WaWHIyAEf5wCwIAyODWTr Pwz8PXNtfeDJdL1PxLHatEkV1HbwRNZXEio0nkRudxjkiVMfKTuLEgnDV2J+H/g7xb8QpNQ121km vLGwg8hhNIgVJJJlfhCucnA5B44r1zSfhl4KsZLq5htZBJe7POYTynzNg2rnLHoOK/SKFZfV6aT+ zb+up+d1sK/rM5NK3M2fJ8Xhnw14W8Ka94Xs7GWC6LNaXMt/OjvbMWkt7m1NqPk/1m1gxXAYHJwR nzbxD4o1GxvtPsNXm094dMitYS0E6pPsRVZVaKEqAu/yyQFB2jDfKGA++2+D3wrVp7tvDdtJNdSM 8juGZneRtzknd3PJ7Vw+t/s6fDq+vri+a61KzhuGVha2tyILeLaANqKEJwcZOSea7IYiMIqKu36n JLCylJyk1b0PApNK8eeJ/EiW0PieznNu9zvhMsenp5Urxj5Xhil80ZbGONo+YEE884LGyuC9rrN3 eeTpFkt7I0lxDPbbF/dugMZLnLjc0nB4HGQVr6n0P4V/D7wzc3H9m2MmqXl8qQBr+VbpxjcAI2kG Iy28gsMZ4z0r5BudKsPEniG4vvEbWbBTBE018tlcBTFCuYibFUtkMYTCw4EgOVc7iCfRo1vaTtse dXoKlDe5vWkWm6aWiutPj1m4urszfaCJHtUto5sq5nn2ncI3VgI0YuylvkGAOCv7TWFvJJdVvop9 Oto8PKoBCG42xqiCGE5kjK7iqDAMmWIZnJ6SbWfEVudREelsiMmx5BakN5cjbYmCMhjRH2uX+fCj Df73MR6rYwWf9l6fbtPNN5J8mTy2jZnfcW3lk3NtjUPjC5PGOAOirL7JhSi9+5jeOr2bWvD9hfQL KqQvCGdZD9zy5BHH8iodyg5ZiSCeFOBk81pNjrF3oga2s7q7Md4wQrOysihIXOVkSUMp2nkgYbBD HGxvX/B3w6n8fS6lHbarDZ2tmUEcUtoJYlM7l3aNSoUMXi5ZCU2naABkV6lYfs7RQZL+I4VeZSrN Fp8aswZZFIyT0Ilb8dp6qK8SpicPSqcrdrdLHr06VapC9t3ufNDW3iyDy2ttDQJB5aqrzhjtRidx G3IYoRhgAQRvX5yY1+1/2ZIzFp2o27eWGjQBlhYMquJDuGQT0ZiOvWsX/hQtscSnxRdbgwfdFaQq dwkSQHOSMh41I49fWut8HaX4U+BGl6hqGr6rdyWUixx+dPAGCgsqqo8hT3AC555x6VE8dSqrkg9T alhJ05c8kj7A8E4Gsp/uP/Kus8TeENA1yX+19Yn1CP7JC2RZ6hd2ibEy5Jjt5EDN15Iz0FfLngj9 ov4bahqsp0G7m1KWzU+ai28qbQTt5Lhcc/561Z8Q/tw/CfwzeXFhqVtfm4tiVkSO2ZyCE8w9CAfl Oa3ozsuV7mdanJyUo7HcxfBv4AjRRoX/AAhlzdadfy2922nyyXckcs17I22WS2kudpk3RlnZlz0O TxXtPg/QPCdrodtZeErR9H02wurh44reQojyszCRyQzlwzMW5PJ618Qwf8FHvg/eEPp2lapLvO3c 0EcYGOBuZphjn1rGj/4KafDI3Ytv+Ee1RAH2uxjhOPXgS84rp9qjB05bH3v4oNzJ4l02C0vCkzqj GLMaBI95VpA7xsQTngKdzEDA6mqPiFMeI5mH/PYHHbGRXyFo/wDwUO8Ha9eLpfh/QNWup5WVY41i gDSM/QKPNPNXtf8A2pby1tE8R33gS/hs5r2Ww+0T3VssYvbfmSBvKMrK646EAcEAk1wYmtGSt2Oz D0Zp3Pn7x5YfCXU/FWqJrml3WrTw31yG82308bW81twSQxebtz0y2fxrGbRvgxPDLZf2Hfw2TqEF uLlXBUj5gSeeTnv9MVx+oaoPEGsX+tJkNf3MtwVQFghlcvtz7ZxVhFcjkOf+A4/rXhLN61P3Uo/c j6v+zKM1eV7+rN618I/Aa0kWaz8IT74yChM/QjoRjofSub+JnhHw34r8K6lo/g3TBo99qD2zNNNN LIrC3kLgMPm7E4wOtaaRy8ZR/wABVlILk9IW59h/jWM86xMuqXokaRynDr7L+9nydF+zN4hlH77W bJCfSOZv/ZRW3afsvTs2bvxEAB/zxtT+hd/6V9TxQXQAxFwPUf8A1604ra7OMRoB71xyzXEv7X4I 2WV4Zbx/Fnzxpn7MPgqJlfVNQv7/AByVLrCh/BEJ/WvZfDfw88J+D4yPDmnQ2jMMGTbvlP1kYFv6 V2kdreZztjA+v/16vx2d2x5Ef4GvNq4ytU0nJs7qeFpU9YJIopBOQAJ2X2HH/stWVsWY/NO+fqRW nHY3Q+8q/lV+LTrtmAVAT/u1wOS7HVZ9zJSwJbHny/8Afbf41dj03I5kkP8AwJv8a34dG1PIPl8f 7la0Oh6gMfu+D/sVO/QL+Zy6aQhGWLfiW/xrmtdt4baJixJA/wB7/GvWn0q8hiLeX0/2f/rV4z4p uzbzzS3w/wBGsl82RQMFucIg46s2BXTCKSvY7cDhZ4vEwoQe/wCXU8M+IOrpo2myk/etlEpX+9NJ xCn/ALMa8C/Z5+HDfGX476XpN6vnaRpMhv8AUXP3PItWDyZP/TSXan0zVv4y+J7gTPYhg9xA/mS8 8Ne3A+VfpEnPtX1V8DPCbfBz9my58UyKYvE/xQkW2tMjEqacmQGHf5wWf6utfomUYb2cOaR5vHWZ RniIZdh37lJW/wC3uv3betz1rRr3/hPPiF4h8eOoaz8z7JZDHAhj+UED0IBP/Aq9VitUGPkX/vkV zvg3wvNoWhWmmxKUKIC2F/ibrXdx6fdqvJPH+zXweaYv2+JlJbLRHBluG9jQjF7vVkMcaBeVX/vk VaQxrxtA/ACl+zXIP3//AB3/AOvTxaz5+9+n/wBevEuexyCq2eABk+wp3znuP0pVtZ+m8ipPs0x6 yN+YobY+VDE3k8uB+VS4cjG+lW0kHJd/zFP+yTZ+8x/GpCwnlkjlz+VPWE93OP1pq2dxnqwPrk1O tg5+85/FiKB28xfKJ6OT+FKImP8AEamXTj/z0/8AHjUo0zuJP1q+Vhddyr5Ix1Y0giwcAsc+1Xxp p7yU5dKycO4P4GnyhzIoCLjBLcU7yo+5JrRGlKPut+O2n/2Uvdj+VHKHMjKMSH1/MUnlD1/UVr/2 VGR94/8AfNL/AGTF/ESfwo5X0DmXcyAkQ64/MVKGiVeCv51pjR7b/a/Sl/se2wev6UcrFeJl+anT eB+IpfNj7yAfiK1hpFt6H9Kf/ZVvjofzFKzGpIxN8BPzTA0/5cZQk/nWx/ZNuw5BI/3qQ6NaH/lm f++jTUWLmRmordty07yiTyA3u3NaQ0m3TpGf++jT/wCz0HGzp/tGrURcxmyRHb90D8KrM1ug+crn 8a2DYR5+6B+JqNrFMdEP1yaTiUprqf/Q9TOoQqMEr+Yp0V6HPyLu/WtlbS1PWNz/AMB/+tUi28S/ dhfH0xX4nBM/VXbojM3EjDNtqPzYo+suPfAra8kdoX/OmeT/ANMmH/Aq1afQRkefGR/riR9B/hUD mNhnzWx9B/hW4yAdEA+rU3JH8Kf99VDT2EcpIkSkMg3k/wB4H/CmxWIeZpdqxP8A3lB5/EV1RZvR PzqIv67B+NRydzTmaWhlGG6ACJMrr6Mmf1xVaSG7OANnHolbZmH96Mfj/wDXqIyr/wA9I8fSrUfM m7MUQ3A5Y/klIyygHCyN9EFbXmx95E/BaaZ4R/y1T8qtQXcm7MHE/wDzxlP1Cj+tB88f8sJP++lH 9a2zd26/8tl/KoXvrf8A57AY/wBk1SSXUV2YjNdNwtsT9ZKgY356W35ua2zfQZ/1/wD47UbahBjm f/x2qsiW2c4/9qH7tsg+rMag2611EUaj6tXQvqFv2lJ/AVVkvYj0eQ/QCrVjOTfY5zQxdx+N5zdA bpdLXGM9I7r/AOzr2yxUsmRyTXjFpJDJ43sy2/dLp10gzjB2SwueevFe36bkRgg19lhX+5h6fqfK 4j+JIfqExsbCe7fhI1LZx6V876v8RZLu4NvZsWY8V9GanB/aGnXFow4kUqeK8q0b4a2VvdiUpuI7 da9CDitzz536EGg6Xqlzq1jdyErGrQyHP1BNfHnjq5vjqV3Pb/Zb5Y5fsimS4s5vIlj8wqs3lRRQ xKmwYhlDT84eTLZr9MtO0uKyaM5yF2/hivzY8f8AijRH8YajoWrapHLcRTPDBbPKt44dbiZQEjjg CwkDAELs7/NuyxO0ejg5XqaHkY1Wp3Zw97rlil3af2jFYxSRLL9pkhKtBcfaY/3gcXE4VmQR5jdU OD0JY7KoTajZ22p2ttr9vJZQmO3C2QaOF40jR2t544y8W/zBydgBc8MeldbdWNrrWnNDp5Gprbp5 TQ+QIn8py+91ElusnVmX5V24zySvHLapLYaPfyWGoR22m3MapBcMky2jTCMrDskkuJnBPzMQpQDJ Lf6vk+lUi1O76nm0mpQSXToe7fs8mxgudfhbywdkbnaqoGUXFwqkAKp6ED5i5/227fQF9qdkijyk GAeCfxz+lfJvwzeOw8VawLRQkQs3STbIkqq4udyjerHO4MSDsXIGRkYx6PfauNyFnyD19sKT9a+J zCP+0yt5H12Cu6EUewx69AmFQjGOnavM/jZfRXnww1eM87TBLx2EcynPJHT6j61xkuulUdw2Nvv0 4GBXnHiP4k2OteCtZl06882KBmtndQwKyxyIGUdCSD3H5jrXFRpyVSMkuqOqr8DXkeXeF9Z1Lw7D faloX2t1SKSOS5jkilg2pIX2EeW/zKXLZ3ElWGc9K5nXNVtW8V299qDyTm6b7YJi9tHvVEEZUqHk VQU+XYeTnJqbRrf+3Yrm8gj+x6XAsizXyEJEJ0ZiCYQzPcO2MM251yDl2wayY9O1nxN4hTw9pehW lveaVp8lywadZRcIyqECFRglc7iccc5xX2zUea0bX6ny8ZTUbyvbofqL4X/ZB+GHi34V6Pr3xL1O 4miurOK8vD9ruI7dG5YFY42RVRQcADoKqah+y9+xH4W8A3XxHexk1rQrCVIXlsZby4ZpXcRhFX7Q M8sM9ABz0r33wf43+Gtz8ENH8O+I/E1lYNNpYtLgSOQYztMcgbpznI6j1Fcvpni/9nXwt8PLj4f2 PxGsrmOS4NwJZiLgqwYHaUXlgAMcnPeuL2kk9H/X3Hc47uzPB9O0H9kKwu7a20r4KeJ7ma7Aa283 T2iNwCdoKefcFiMjAO3rX2R8OvgX8G79WvpfhEPCwiVGibUYbUyOWPKhUDMCvXJ4r5ibx/8As0rL FfwfEcSXGjk7JbKylYwHcXPzO7BcsS3PU17XYftHfDz4Z63eaL4p1zxVrGp3SQBbPU7RIxCrjcjx J8mBID94kgjpSdRpXlI15HJJQi7nAftPeD/DWieKtDtdJ0+CyjexkYiOMLuPnYBO3HavnuPRdNI+ VAPwP+Ne3/F/4p6b8S9f0zUtB025his7Z4XF3GFYsz7sqFZuMeveuDhkv3AP2VR9Ub/EV8JjKvPW k07n22DhKFCMZKzOeh0Sz4AjU/8AAc/1rbh0S1UANbpj3Qf4VsRLqJxiFFA/2G/+Kq9HDqLDJA/7 4NcGux2SKEGlWOAPJjA91H+FasWm26/dii/ID+lKbS+xxCGPuAKallf7ubP8pcY/Si7JUPMviyi6 LFG34ircVimPmijUe3P8qqR2E2Rutyv/AG3A/oK1Ybfy1znyz/113f1pNv8Ar/hiuRLr/X3k0Vnb qOFAx6A1oQiNc+Up/wCApVNXvYzmOaIj0Oc1M2tXVuh3SRkgcAA5J9s8VHP3BU29tTYjFwFDeZ5f s4PT6cVsCe32De4JHtjNcO15fXR3OmQw4yrLj8cEU+6trlYSysqnGSdx/HpinGo3shukluy14m1i 00+wlnZwNoz15NfFXxK8SpptvcXV2N/2ELdTJ/z0u5eLW398ZDEe/tXsXi7WoI3mvJk8yDTQGK7i fNmY4ijA9Wbk+2a+FPi34pnguJLVJPPn06Uknr5+sXQ4HuIFP4HIr2sFRdWquy/M+9wUoZPldXNa nxyVofp/n6JHP/C74b6l8cvjNpfgUM00CztJqM6+uQ93Jn2XEa/7TCv0q1qez+IPxY8nS0UeGPBU YsLJE/1Z8n5WK9sFhgf7KivK/wBn3wi3wJ/Z/vPiDKuPFvj8/YNKLf6xLdss84zzzlpCf+ude6/D zwomgaDBa+WpdgHctknca+zzTELCYTkj8UtP6/rqfgOChLF4t1Kmut35/wDDs9KtfIVfmIH41b86 0HG+qi2hUYCKPpmg2crc7sfSvyj0P0dKJZzbMfvE09TbdBk1UFnOOfM4+lP+yXGP9cfyoVx6dy3m AHODTt0XZD+dUzYSHgzHNOGnuf8Als36U9Rady6GiH8H604SQ9NgFVBpp/56v+dSLpsZ6vIfx/8A rVWpOhbWWIf8sxUwnTsij8RVUabCq5LMf+Bf/WpwsISOC35mizHoWfteB91OPcU03xHRV/OmCxjH 978zTzbxKOuP+BUrPuUrdhhv5RyAn60n9oT9doP/AAE0vlwdN4/77/8Ar03bb/31/wC+/wD69S7r qVp2FN7ck4CYz6Kad9qu2HK/+OmojHaEcsp/4F/9em+Tp/Q+X+JzRqVp0RIbm56bR+VRm5uPYfh/ 9egwaZ6RH8M/0pPK0zsi/gn/ANakP5C/a5hyWX9P8aQ3jDrKn/fS/wCNJ5Onf3F/74/+tS+Vp/GE X/vmldhZDTf/APTaMf8AA1/xqM6iO9xH/wB9rUuyxB+4vP8AsingWp6KPwAodw0Kp1JB/wAvKfg4 /wAKYdSjPW4B/wCBH/Cr4MHA2k/hS5i/uH8qS5hadih9vh/565/Fj/Sk+3QYOHJ/Bv8ACtMPH2T9 KXeB0jP5VpZg2ZBvYie5/wCAt/hUbXy9lJ/4C1bJkHaM/kf8KaWOP9W3/fJpO4ro/9H1kS3bf89T 9Mf1NL/pZ6rKfqVrZW3kAB+X9acIm7soP0/+vX4vGL6n6pdGH5VwesUn4stNMFwf+WL/APfS/wCF b5VQMGRM/wCfeoy0Q6yp+n+NXYfMYTWc56xMP+2g/wDiartZyY5i/OX/AOxroDLb95U4+lJ9osh9 5lP/AHzUuK7ApM5v7O4HEa/9/j/hSeRJ/wA8k/7+NXQ/bLIHAI/MUw6jaA4CZ/L/ABrLl8yuZ9jA NtITzHH+LN/jThZyH+CL/wAeP9a3DqUJ+7F+o/xpn28HpD+bCq5V3ByfYx/sEnfyR9Vb/wCKp/2F l6yQqP8Arnn/ANmrRa+fr5I/76H+FQm6u2OFhA/Ff8K1tHuReT6Gf9iGcCaL8Ih/jTWswB/x8AfS JautcX39xQP95agaS6OchPzH+FPQTuZslsM8XDfhEn+FRfZdx/4+ZPwRB/SrkjyfxGID3wf6VA00 Q+9NED1+7n+lKwyL7CG4NxJ/45UcmnRgZMrt9Sv+FLJf2Y+9dKMf3Ub+gqhJfabjL3JP/AXFaxsu hm1Jl7SNAtX1mDV2di9nHLGoJGD5+0H8gtez2Fsvk/KM4GcCvnq++IXhfwXY/bdUeZormWOICCFp nLnO0BBzz+Q714xf/FXQZrppdT8OajdabI7MTqviTURYzKp3bZLWCF0KN/zy5GPlORX1mCnD2UYy kl813PmcXTnzycYt/LyPafFX7U3wm8M3MulW97Nrd3A5ikWwQGNCpw376QqjY/2CwPrV/wAMftH/ AAg1+bDas+kEY+S/iMOSfR13oR68ivzX8ZaVefE/xtr3izwoummDUbuSbybSV4LeNyqlkiN1HCWA zuyFAGT0AryAR6rb2kOoQ7xa3JYRyIwZHZDhgNpPIxzXtunC/I90eMqjtzW0P3t03xz4C1FhHpXi HTrl2w21LuIkg+gLCvzT8X6To8/xX8Q6nqGkLJJYXl2YnaUxxtdSTedGfPiCnJVkw2SRu9Bg/Gd9 4u1PS7VVWZMvNEjSPEJDGrEhjt7nHrX1d4d8E2I8OXUFpq8kl5qXkMbueOKbEQyWRk8vJXa3yArl eoYHkenhaMotyi9TysXOMkkz0fSvCmq6bZ3E3iC6EVvp/wBouoIrSWS8ST96d8MjOqII0MoZV5Ll c5G0moNTsvBEmvy2sMWo3N3Day6nI0kVjE4S5JDlXklnbYSdwRcEMWII4NeMalpt34VjtZZLeaSG KVkKWdnJINnlBdwxuQZPJJcYJIGH3ObGueLbzT9ZnZjKheBrLzzJEHNsmSI2RY2UZC8srZyeowaq pDEcqi2m+t19xhB0FJtJpdLHMa18V9J+GWrT6HbQu0dxD5kSrI58lXfcse2TjGBwVGT1OfvHAtfj prXia/h0rQNMnuLiXPlx7yMkDLYO3HTPcVw/xH8e+J9Ru4IfDMn2UZbe0AQSOoRFTcwzwuCAM8fX JPmcUvxNu4wDq18AxOVa7kXnvxurCtQoublNanVQqVVTUUfRzeKfibeTXFvH4bkia2IEpldgoJTe DnAB4/u59K5+28T+M/EMF/os+nHT7eQNFJeSRt5SZJBIBZd5OBgDrnJGK+YLy61uVWe7uLiUI2CW kZuV47sa7W08O39izQJqHmwM4LRhjt3kY3EZ+8B+OKydOhT1aNoyrz91Pc/TP9mO+a10zX9GsfIk FpcmS1SdkmnWKVmdnCbn2IzuTg/NuPPavkr4zeIdFvvj9q0FlZGEQKmnP5TLHEJX2/PhV5AZjuBP J57YOV8P/iO/wY1nUIoNEW+u/EGmy2kb+e0RgOciQ4U7uewx04qSb4WLplmNZNyo3qjvIkCAo4GW +Yu2SGPJIJHUZ5rgwuHc8VUr9GtPn/wx14qtGlQhQ631/r5mzr/w08U/2Zb6npkM/ilFcA2FpaXk 8M6EkD940aglSCMhSMYxXJ+Hvgn8bish0/4cawkUsjlEltmQgMeFzJsyB0ziv1y/Z3+NJt/AMHhC XT4r7UdLsJHtAyAiUQRed5bAcknJ575r2O7+KPjvX/hrq15oC2XhzW4J7ZIbyGD9wUfa0yhJ1b5o yfLY4I3dMV6EZKKty7/12OKpFtu/Q/JHwN+zX8d0ln+3+BtTjtbmRGeNbm3QHaSc4eYKCDgjivpF /wBlz4u6/o1m6eF7uDxAtzI09zd6stxCbQ58qIIRI4eP++GAPPFes6z47+NdnrGlQReOtcudNvAv 2+6j/s2yNsTKUby4ooWdwIwJByTk7TyK+1/hXrnhy+W+tNF8W634puIVi8+bVlkCpndgxZiijycH dtz26Vz1IRfvOO51RqSgkov7j4iPgPxl4IhsdL8dvHFqTw7/ANzJvDIGKhiSo+Y45/OtKK1HAadf +BPj/CvWv2i5oX8aaWWSOXFh1YkdJXrxqGVAMJFAPxavz3E2jXlGOiPuMK3OjGct2bcdrEOtxH/3 3/8AXq2lrbj/AJeIz/wM1iLcTniMQjH+y5/rU6zaj/BJEAPSFz/7NXLdHdbzNxYLYf8ALWM/iati C3PPmRfk1YKyaljJlUfSBv8AGrCSajgYmJ+kGP61lcu3n/X3G2Le36+bH+AaniKEcCaP/vlv8ax1 k1DOWkf8IlH9alEt0OWLf98KKkfz/r7jXEcBUZnTn/YY/wBaZd6Wyxh7MKz5HDrgc++DWX59z0O7 n2UGsqeBiCSJOP8AaT+tCBPzOpjhvlt3dysTr90KQQf5AV554j8V6haQ/ZhboJH+UZbJJPsCaqar OYIyS0nA/wCeq15RPePYrJrEW6S7mf7PYxu2/MzdZPog5Pvj1rphHblWvQ93KsveOxUaXTd+hyvx H8UHRLOVoMTy6dII4k6/aNWnGFHusC5J9wfWvnr4G/C+7+Onxn0zwhC7T6TpUjm7uAeHbcGvJy3T LEiJD7g9jWB8TvFr3E4h0SXzVt2ksNOfP+suH/4+70n0UcK30PrX3z8KPBb/ALPP7P8AbW9qnk+O fiUohhyMS2un4+eQ9wdrFv8AffH8FfpmU4NU4cz6fmfI8c53HFYpYPDP93T91eb6v9Ed54l1ez8e /EX7RpaL/wAIv4UT+zdKiQYjZYuJZQPR2AA/2VFeoWl8qRL+5P4Af415V4Y0OLS7KCztTtjhQKoD sucdzjvXYCz4+ZiR7yyf418Hm+NeJxDcX7q0X+fzMMqwkaFBKS1erOwOpjtCR9cf40v9rIOBGR+V ccNOjb+6fq8n+NH9mwnqqH8XNeBdnu2gdj/awHRSfwoOrDqQR/n6Vyq6ZbAZKpx/ssf61Yj0+2zn 5f8Avg0XYrROiOrRAfebPtTRq6Zx85H+feslbGIH5cfXyzUv2ROv/tM1QtDR/taPPSX/AD+NJ/aq dNkn4nH9aoi2A52sf+2ZpRbHOQjHP+waNg0Ln9poTnyW/Fh/jT/7QXGPJP8A30KoiB88I5/4B/8A XqTyJCMFG/74padgLP8AaCHnyB+LjH8qadQT/nin4v8A/Y1D9mYDhG/74FAtX7ow/wCAD/Gn8h3H nUx/cj/76P8AQUg1EMeBGMf71J9lkzwjn8F/xp4s5f7r/kv+NHyHdANQz0Mf5PTxfvnhkP8AwBqZ 9mcHPzf+O0/yHB43f+O1K9Auhft0xPDKB/1zP+NH2yYc7x/36FKLeQ/3vzWn/ZSOpYZ/2lqtX0C6 Ift8v9/H/bJaX+0Jem9s/wDXNB/SpvsgxyWP/Alpv2NcZyf++hS94PdG/b7gj77/APfKj+lL9vuM fek/8d/wqwLfA4Y5/wB4f4Un2c9N3/jwo1JvErfbbnu0v/fQFL9tu24zJ/33/wDWqwYsnIk/8eH+ FAiYEYkx/wACFF5dxu3Yqm8uec+Z+Mh/wqP7ZOezH/to1aPlBs5k/wDHqaLeMctJ0/2jV2fcV12K Hn3B52E/8Df/ABphlnI/1ec+7/41qiOHGDJ/481RFIQMBuP95jUu/cNOiP/S7VYxwTKTn2/+tUgi jxy7Z/3R/hTvMTP3Gz7uB/WjfGDyoH/bQf41+JLzP1u7G+XFnl2P4Ck2x9i3FODp2CY/3/8A69G7 J+QR/wDfWaTsV7woKDpkj6U/zCMBR+gqMeYf+eQ/z9KXEn96PH0/+xqLq4rMebm4H3SR+ApftN0w +83+fwqPDjIM0Y/Af4VGxQcm8Rf+BAVSfYiyZIZ748b3xTDJe4OXc/jUPmW+Tm+U/ST/AANB+xkf Ndg/8Dc/1qk5DtEkAum5Mrfi1IbadjzJIc+jUwNZDpLu+nmH/GlzasOhY+ySH+lO8u5NkH9nM33n kP8AwM/403+x4jw2efVz/jRst8HFux/4A/8AhTGRD0s2/wC+Hp2bC406Ja/xbfxeoW0bTu4j/Fv/ AK9SMkgHyWJ/79t/8VUTR3n8Nj/5D/8AsqqwfMZ/ZOnAADyvzFMbTNNTlvK/MU9otRYYW0x9Yx/V 6gMGrE8Ww/74X/4qrSRm/Uw/FVhYS6BJFaW6XFys0cmAw5jT7ygdyf5Vw3izxBoEnhm7RLd5XmiM YhMbKEYjAyTwNp6Yr1E2er8D7OPrtT/Gqr2OrnOYR/3zHT5Xzc3QNFHl/U/KzVPib4o8DeIdU0TR YtOigsZvnVbSKRJnjyjPJIwYuWyRuDDI4Fc5/wALc+JVwS8OtSRiKQbQFRSvHBjwBgjoOtfpHe/B vwrJ4hm8Vt4fim1S4fzZHkKPH5o4DrETsBI+9kHJ561n2nwq8M6PcSTab4UgiinP75GMbFwxBdd5 +ZVYjIVcBeg6CvuVnNOMbKL6HxbyeUneUl1PzMuvFXj3VZFluby6vbgAkApmdXznAcDeMD5tuR61 Pa+KPH1tcpqNvqN86I27zMsVEfAySchhuwuTk9Bmv0xtvBtpavKIdAt1gkaR/LbyyA7ggPkHcXTP DE545pr+DVS18v7FGAgXYTgGLac/JggDPfjms/7cX8n4/wDANP7GS+3+H/BPkDwt8ZPGkM0emeJd Fa9kOELxARzMxGcNGTgjbzngVsXHg/4Q+PvNmhsW0a9cZka3BtzknpJHgxNzz90fWvfLzRInQQwx RNIGb5kKec+ccFs5ZRjhT05I602XwLqV/wCVJKEUxqqqBgfdzjOAMnnqck+vStFxDLbkui5ZDBau dv60Pk+b4Ca54ZZ7/wAOyx61b7M7Y18u4bByMR5Kvx/dYn2rhPtFxFBqUq2V2V0ohrxvskpW2DEA ecdo2ZPTdivrTxpp3xI8LS3/AIutrtL+0/dvNBKCzFjuMjs2OASR06fSvRPDXiC68c/DPURpVyb7 Q9ftmtdVhtubmzYrtKzBlZkKjlHwyEenIr6rC+wxsPaQ0fbc+ZxMauFlyS1XfY/MWTxXcbWuF04G 0EmzzScZyeuMV6FptkkUmh3F/pd1Z2HiO4b7PcFPLWcoVDlS2em5e3TpX0/4b/Z38IXF1JP4m1GC Tw5pmLktI3kbIYuSZ1BAYdjgkMfTOBx3xm+JngTxXrekS6Db3FxZeFMppsURSO1Y5G93PLMcgA4U D+7kc14NerNVnQVN6Xu+nkfUUMDSWCWMq1ld/DFPXR637em/4X4nRfCdl4s+LOqxRofsfhu1igBj crmcnOdxPGDuJ7cV9Bp8KbO7h3SSuUmiEeTOTmPO4DIPIzgj35r4Yto/EGr6hfW2l/apX1iczTW8 Bkk8x2JxuC8kZJ68V+kXwm0LxDY+BtL0vxHGtreWkZiCZDsIlJ8sMRwGC8EZOMV4+NlUw8Y8tS2y sn5b/eXhI0q8pc1O+7u157HMx+Em0q5iuYNaurG5hIKtZvHAq4UIAMhm+6ADk8/Sukh1TWoDkeI9 SdiCpLXQYkHntH6gH613l14cklHE4B+grNHhScnBuiPoBn+VePLNcRtzfgj2o5fhnq4/mZ9lrWvI wdfEF+WHQmWQkY+gWvStN8eeOUiWNPFGphAMDEh4+hIJrlYPCLcBrqQ/l/hXQWvhGEH/AFsh/GuW WPry+2/vNVg8NH7K+43hquoapOk+rX9zfzICqvcEOyrnOAT0Gea2Y3jx1fP/AAEVkW3hm1iO7dIf +BHitmPQ7QY4c/8AAj/jXI5OTu9X6mvLBaJ6ehOs0K8kt+LqKkF5bL3zz/z1H9Keuj2Y/g/8eqYa XaD/AJZj/vqi77Fe73K/2636FR+Mp/oKk+3W+Pup+Mjn/wBlqZdPsxx5a/mTUgsrQD7qj/P0pNvs P3Smb+17pF+bH+lJ9vtQPuxfkxq41vZoOVXH0P8AhUR+wxjkL/3yaNR3i0VG1GADIEfH+way7vWY 0Uncn4Rn/GtK4msl5GD/AMBrnb28s9pYp2/uCtI7it5HF6rqTXbrZQON0hOSUwAOpJJPQCvnH4me LvJtxDpcogkvI5LazcnHkWac3F03oW5AP+FeqeNddtbW2mDSC3SaNnmkxgx2iffbju5+Ueo+tfDO uXeufErxfb+FNFgeXUfEMkUIgj+9FabgILcHsZD8z+3J4Jr6PK8K60/aW9P8z7bMMUshyd2dq9b7 0ur+X5s+gP2RvhLafF/4jTePvEkf2XwV4RiEpMwwgt4Msit23SlS7+qgj+IV9l3fiO5+IfjC8+IN 7G8VvP8A6NpUGM+RYRHCnHZpDlj7k+1P1Lw3YfDbwTov7NvhSRTMUjvfEt1EMbicMsA9mIGB2RUH rXbaVapbQxxRRhFjAUDHQAYA/AV9TnOMWFw6w9N+9L+n/kfgWV4d4iu6017q/r/gi2V3sXnzT/wE f4Vpi9weFlP4D/CtSIMAMACreZewFflrP0WLXYwlvXY8RynH0qX7VJ/zzm/MVt5lHUfrTi7YwxqG XddjE+2TYx5Ev5igX8o/5d5cn3/+tWw2D/H+maYqR93/APHaWpV11RRF7c9rWQ/jS/bLvtZyf99V qFogOSSB7VC01qPvEj/gJp69xadiiLq+Y/8AHmfxc0jT34H/AB6/+P1aD2ueGf8AKpd0B6F+PpS+ ZpZdvzKCz6jn/j2UH3c/4VJu1M/8u6f99H/Crw8rqA2e3NSjzOigD6mp17j07FBRqhPEEY/4Ef8A CpfL1M4/dRL65Y/4VeUznpt/OpQk3dQf8/WgT9DMMWo9xEPxam+XqP8A0x/8erV8qYn7oFKLa49c fgKTQXMzy9RPeAfg9OWDUDyHgA/3W/xrV+zT4/1mPwFJ9ln7TkevSqsxcyKK2+od5Yf++G/xp4tr 0/8ALWL8I2/xq6LSUj/j5OPoP8aabV+9y36f41Vh3IRaXJ5MqD6Rn/GniykH3pAfohH9al+xnvcv +BWg2ig83Dn8R/hUtIL+Ygsuxcn/AIDS/YlHc/lThZwcbpmP/AqX7JZj/lox/wCBH/CjQn0ZH9jQ 87mGPYUq2ScEsx/75p4t7DODI3/fR/wpDHpaj5n6e5pe75Ds/MX7FF0G781pDZxYxk/99Cm50leM 5/AmmmXSV4H/AKAT/Sr0KsxwtYQM8/8AfVJ9mjI+5n/gX/16hN9pi8Z5H+xj+lVZdS07GQent/8A WqW4lcjfQ//T9Og06zPVB+AzVn7BbDoi/iBWSurWoOYUUn1wD/7PUo1WZ/uxgD/cT+rV+Lxs1oj9 Val1ZoraA/cRPzpRaSL0WP8AXiqcV7fMeGVB/uIf5GtATXBGTcD/AL9iteXqZtj1tFwAVQ0G1i7w q34D/CmbgR88pf6IRULywAYELuT/ALJrOTsCSLAtrfr5Cj/gIpfJiU5WNfyArIeX+7ZN/wB8f/Xq sXnP3LFh/wAAx/7NUKVzTlN0jj5YQfpTSZMcwn8zXPFtQydtkf8Avn/7OoiNWP3bLA9wP6vVJ6hy rudMDIeBEfzpw39TG34kViwrq/Xyo4z/ALin/wBmrRU6p32f98D/AOKrXl8zPYsHPZP1pp8w/wAP 6/8A1qjJvzyxUfRR/jTC10D82SPy/rSsJMkKsRhhj/P0phiBHc1DvmLEYOPXdS7ZOw/8eNSVcUxL 1Ib/AD+FMaFc5wf1pXilAzgf99GoHjm/hx+bUyW0L5Rydqn9ab5cmOYxn6mmMtyo+Vwp98mq0h1I fcnVfquaq9iHqSS28zYAiQ/VqzJIbxT/AKuEA+4P9amK64x4uIsf9cv/AK9U5tPv5uZZIWb1MI/o wq+ZWEl3K0iTA/MYVP1H+NZN5HPIdn2uFF7gMP6Bj/Kt0aYy/wCsERPsrD/2ao202P8AuoD9Cf5m oux2ijhZdJmOF8+3mBJxuXHJ92FaK2mpxRhUiRwvHUEf0/lU994cM8vnR3bwkDoqrj6jvn8auWUN 1YQ+Qbp5+Ty4BNRs7msndK2pgXFjcXMUkd/bxmNwVZezA8EEHqK+DPFI8R/AH4pN4k+GU7WkbBJn tXOYpo35eM/3lByOeV7V+hdxBJcAgybT6hB/UGvnr41+Az4ksrQQndcwsVWQ4UjcMqCQBxkY+pFe 3lONnh8Re9kceJyyWNpShSV5JXt6dD07wndeFvj/AOE5PHHw0ijs9atBt1fRmA+SRh82IzwA/ODj Y/QjOa+PPiZ8H2N6Na8C6dHbSytDbXOmxRiFIiGKtcIo5IGf3i/eHXlennPgzxX42+DXjm08ZeGp Ps2pW5KyBs+Tdw5+eGdR2IGM9jzwcV+p2ny+Cf2mfCp8f/DYrp/iizAGo6a7BZBKB0Pv/ckHDdD7 fsMVHE07Nn5Q5Tw8mlt1X9fmfN3hfwvofha2XT9CtFQDAklC5eVh1Z2PJ9h0HavXdLYRIDsVfwrl tJ0iwuNVm07WImtb9WKsjEoGcdRt/hf26HqK9KtfDGmQgAITj1ya/E8ywdfC1nGtrfZ9z9awWKw1 eipUenTsR/aou5A+mB/Nqb9ot15MmP8AgQ/pmt1ND09OkCn6j/GrC6ZZjG2PGPQCvH1O/mh2OeS7 g7OT9Gz/AErQhuIj6n8/8K1xZWo4KGrCWtqP4Ka8yHJdjPjuUH8J/Jv8KtJeIP4D+Rq8LW0PBjFS i1tu0Q/L/wCtWqRHMuxSF7H1CkfUf/Xp39ox9OP0/wAa0FtIR0iWn/ZYeoiUfhV8vmLmXYyzqkAP JH/fS/8AxVM/teDHysP++l/+vW2kMQ48tfypcKD9wflRbzHzrsc82sWxHJz9Mn+S1WfWbUD7rH6K /wD8RXUFyONv+fzqNySMnAH4VSjfqLnXY4ubXIBnbDI2PSN//ia4rxB4jgFrNvVoI41LSMylSE9F zjJY8D616bqNzFZ20lxM2EjGTz/nrXyB8T/Gy2cdxcykOYnAWPORLckfu4/92Mct75rejRlVqKnH 5n2GQ4OnUnLF4jSlT1b9Nf6+Xc8R+MPjYIs9nMdxYpNdop6n/l2tR7dC3tzX0P8AsheALf4aeC9T /aZ8eQfaNTvS8Gh27j5p7iXKmVR6ZyiY6KHI6ivmD4G/CvU/2iPixFpE8rDw/pTte6te5wNuf3jb um5/9XH6DLdAa/SPVtXsvHXiW1bSIBbeEvCy/Y9It0GI2MYCNOF9AAAntj3r9bwlKng8M69TRI/G +Is3q5zmMpR2ekV2XRfqyp4ct9WsXuNV1iGW/wBW1aRrq8n4GZZDnaM9lHHtXoMGoXm0FbBxn1Yf 4VVhUcBVYe+Ca6KwsQxDzbmA6BsCvybF4qeJryrS6/gj6XDUIYekqaW34srx6tPvCm32MRxucD+l aMV7dyrnyDj13/8A1qWdPMJjRCNpBAxx+JNLCgiTZJb4I7ggZ/I15nPK+56PKrbE3+lN1hbn0kNO 8qYjmNv++2/xqJpEP/LHP1P/ANelFxGOPKA/4EKq/cVn0HfZiT/qST/vH/GmGzc8LCR/wOnNdL2T p/tZp4uQB0AockNJ30If7OuM8D8z/wDWpp0+4zkvjPuv/wATVn7SAeSB+FO+0R/3hmi6KvIpHTbr HEuPxH/xNOGn3WBi4Iz9P8Kufa0H8Y/MU/7ZFj765+opaFc0iqmn3KgZuD+dWBYSng3Dfmf8acL2 IH/WA/j/APWp4v4u7j9f8KVkLmkxg098A/aGGPc/41ILByeZ2P4t/jSjUYgMbwfwNH2+E9z/AN8m q07BeQ4af/02b9akTTF6mdvyqM30eOAf++TQL4HojH/gB/xpWj2FeXcmFjEv3pmP4D/CnizgXkTS H6Y/wqv9rLcCNv8Avj/69IbiXtGw/wCA4ov0sGvct/ZoMf62TP1FNNrb/wDPRz9WH+NVfOkxjy2/ If40edL/AHD+gov5D+ZYFvAOAzkn/b/+vQLeInADnH+2f8ariZ/7v6inGZgMkAfiKL3GWBawjqCf q5pTa23Zf/HjVU3HAJIx/vCmm4QdXAz/ALQpMVi39lt8528/71SC2teuwfnWf9pgHUg/jSC7gHf9 T/hRcdjUEFqOiKM0ogtR0VB+A/wrLN5Cen9f8Kb9rgHUH9armHY1DFbjoEH4CmlYsdVrLa9hIB2k /gaga/h6BDmlJhY//9T1lDB/sn/P0qwjxg5yP8/hWCb63U4WB2/OoW1I5wtqSff/AOua/GIpn6kd OZ0PV1H40w3MI/5ag/Q1yzarcqPltgPqV/8AiqrNqmoscLbrj2Yf41Tfcaizs/tcQ6scexoW/jz3 IrivtepseYgB/vCkE171MYB/3v8A61YOWuhXJ3O4+1oAcLmmC5Yj7h59v/r1yCTzgfMuP+Bj/CrC TOx+Y/8Aj4/wo5mLkR1Qn9UpHnizkp/49XMeeVyR/wChD/Co3u3A4iB+rD/CtOcnlR1AmiPQce5N O8+IcnH61yq6jOvSGMfVv/rUHUr0n5YoVz7k/wCFO4+U6YzRY7frTNy9iPyNcub7Uz3hGPRD/wDF VGNQ1TJYSRj/AIAP/iqGyuRnVF1xgn+dMaVF4Gf1rlzqWqno4/BR/wDFVH9v1FvvMT9FH+NLmiHs 2dQbk+hP0FQtc8Y2t+VYH2i9bqHOfcD+tITcvgMp/wC+h/SjnQnA1mnQ/wALY+lVmuYwcbGz9Kz/ AC5yc7efdv8A61MaKfPHHtn/AOtU3uCRp/aox2I+tIb5M+31rIEVwOVb9R/hTTBPydw/z+FO5Liu prNexHr+hqs93Cc4A/76rNMEvTfj/P0qJrWbP3ic0ObsHKi4bqPHLD86rNPFkdKrGyk5LE5+tV3s mIwS2fqRWfMy1GPctyXMYJOzdj0rndatoNTgMRiIOD9MHt/9etGSxHvn/eb/ABrKu7RI1JLYPux/ xpKUr3R34Ws8PVjWg9UfK3xC+H/n/aZYovPIBMsXdgeN6/7Xr6189+GPFfjH4NeK7bxX4WvntZ4G 2rMQfLkTPMFyn8Snpz06+hr7g1HxN4ZvfFMHgC4uPK117ZrqBwMqUBxsc84JxkA9RXkvjj4e/b3u DDbrHeY/ewN/q5l/vL7+9fo2W5i0lGej/PzR62ecPUM6ovMcst7X7Ue7/wDkvz/P7C8K+Kvh/wDt YeHzqGiGPw/8QdOiBurFz/rAP4lPWSIn7rj5l7+/O2evat4Y1N/DHjOFra6gON8gycdiT/Ep7MPx r8wl/wCEk+H2tQeIPC91cWlxp0m6OSIlbm1Ydv8AaT1ByCPUV+i3wu/ab+HHx/0u38D/ABsWHR/E igR2uqxkRRTOeAdx/wBU57q3yMemOlfY1VQxtJ06yv8A1+DP58isRgq14XTW6/Ro9piuElRZFIKs Mg8cg/jStcIo6/y/xrzzxL4R8a/CO48y9jOseHnP7u7iGQgPTeOdh/8AHTWppet6NrEH2i0l3jHK 8lh9QP59K/LcxySvhm50/eh+K9V+q/A/QMBmtDEpRl7su3R+n+R1wu4yM9vw/wAakW7TucD6j/Gs EzWq9C3/AHy3+FMa7ss4O4n6Gvl7s+j9n5HTC9Tuf1FP+2w4GWA/4EK5cX9kp6N+Q/8Aiqb/AGpZ j7qN+AH+Nac3S4vZPsdV9uhH8Y/76P8AhTft9vz+9XPblj/SuZ/teDosb/8Ajo/rTxqynlYW/wC+ h/TNXzMPZvsdAdQtu8n5K5qJr+1x98n/ALZsf6VinVR3iYfmf/ZajbWIQeY2OPY//E07k+zfY121 G25wX/CI/wCFU5dShHQyc+q4/wAKzm1u1x/qX49v/rVwvi7xpaWFk6QgrI2RycH6D+p7D3qlzSaj FXZ6OCwFTFVVSprf8PNmN4/8YLBAYIZQu0FgzYAXb96Q+y9vU/SvgLxNqGv/ABM8XWHgrwXbyXl/ qL/ZrOBPvYkPzyN/dZwCSx+6gJPSun8deMdY8Za3D4P8IW8urajqUohigt1LyXEh+6iqP4F6nt3J A5r7M+E/wwtP2cdMkSNoda+Levxbbq4UiSDSIH5aNW6Fv7zfxEAD5AA36hkuU8seeei6v9DyeLeI KNKisny53ivif8z/AMk/veiOu0fwZpPwZ8BQfAfwZOsmq3arc+JtTi9WHMKHrjHyKvZeTyxrbspo bGGO1tIFSCEBUUkcKOneoNJsIbCF4d8s08zmSe4YZaaVvvMSevtW8sUe3AkYZ9TXz3EGbrET+r0P gj+P/APmsly32Mfb1/jf4f8ABf4Fmz1jawPkRgD/AGsf1rp49fRo9oQRkdxIBXLxWiHpcfqKtJYI elzz7H/69fF8ztZn1LhC9zdOpXDnHn4Q9cy5p0bzMPklA+jA/wA6yU0tj927J/CrsVpJENxm3Y/2 cVN49R+jNZJbsDAKt2y3/wBbFSlrlsfMo/z9azBIV/5afyphnA5aQED6f40uZdGTyyN+C2llOGkA /D/69STWlxFkJH5hHTJA/rXPw+IbOwbJUH6Mo/xNSyeO7ZiFFvjHGd5/otVutGXySv8ACXGmnhP+ kwBB6/If13/0q6FyN6BXB9FFY8firTJImBQHd1Vjkc+zKKqC88OFRI1uImP/ADzIAz/wEj+VF3vc LeRtuZhzt/IJTQZj3cf8BX/CsyO80yT/AI9/tDAdl3kf+hVYFxZsOYpj/vI1TdhYu7Jj/wAtJR/3 yP6UeTJ3ll/76xVcTQN/q4nP1U/1pwk7CPH4U7k7FnyZMY82T8ZDSeR/ekb/AL+N/jVYyspx8o/C m/aWAPzqPy/xqblWLn2dRxvP/fbf404W6f3sj3Jqh9tRfvTKPxFJ9viHWYEfUU7hys0RBD1IBP4m niK37qD/AMBNZYvI+0hP0BP8hSi+j7s5+iOf5LS5gsa4SH0/8doIiHO0nH+wKyje56CY/SJ/8BSf bWB4Sf8A79n+pqr2FY1cqfuo+PotId7cbW591rJ+2zAFgk4H+4o/maILy4um2wRzse/yoKltjS6m t5bDjDn8RSCNz/C5/wCBVXjF/MflSY4JBBdRyOtR/wCl7iPKm4OOWI/pQVqXPJccrGx/4F/9ekKT dTFj6tVIxTMCXhIH+1Lj+dPGnK/JiX/v5mkrB6/1+JbCy9dqj/gX/wBakO8d0H/AqgGjBhnyEIPu ajOilMk2qD0JNaW7CbXcmabaDmeNf+BCqzTJn/j6T8GFQ/Y2XgW0Q/4GB/Kg23HMaA+xJ/oKTfcR /9XvgV4wn5ml8xlPCL+dZ6Wurkc+Wn1B/wAamOn6uRkTRD8D/jX4rG9r2P1i0e5ZMsvZF/M1A8t3 0EWfpmo207W2G77RH+Cn+tJ/Z+tYwbr8kH+FPUVo9wIvmOBCR+IFJ5N4x+ZMfjn+opTpurkZ+2v9 FiH/ANakXStWY83kw/4CF/rU2dxXQptLn+6vH+f71KLW5HZP8/jQdE1Yj/j7mb8cf1p/9g3pB33U oPuW/wDiqOUfOu43ypQfm2U8hP4mX8qZ/wAI/Ket43Pru/8Ai6ePD+3rdn9P6mk4hzJ9fwF3xL94 n8FP+FRefbn5SGP0VqsroSfxXJP/AHzUo0RM/LcMD/wH/Cmr9EK8e5lloD/yzc/8ANV5J0TpbO3/ AAFf6tW8NEI6XDn/AL5p66O//PdqLP8AlHzeZzH27YQBaSH8B/jTjqMo6WZH1rqP7KPQyk04aXF0 difxNWo+Qc5yR1O7wCtuqgfX/CoG1S76+UPwDf4V3A0uy6OpP/AjT/7H08jGwnPqTVWI57dDz46v c9PLx/wBv/iarHWro/eVkwe6EfzAr0KfSdJiUvKiD/eP+JrgJdMSa/Zo0SROdvy4RR7nkE/TNTKy RcXzdCA63J/eb8h/iKhfW8DJlbd9QB/6HWtbabp1vcMLmFH2nBwvHHpuwDXSpZaFPjbZJ/3yP6Ul JbDdl0PN5NeT/nqc/wC9/wDZ1TfXosEeYzD2J/xr1j+ytJx/x6x/98ikOnaWv/LCIfgKYvaRXQ8Z l1qNsnMmP94iqranGeoYn3Yn+hr2prHTu1tGfwFQS2tljiGMfgtZSS3No1kvsniz6hEwwIie3c/+ yVzusazDZ20s8qmNIlZmYpwFUZJzgdBXvE0CqGMcKnHuP8a+R/2lPEN1aeH7bwjpigan4nuFs4gu NwjJHmHqeDkLn3NdGGourUUO5FbFRp03Ox5L8KvtnijxbrnxFuVLHUJfItSBwtvEcDbkg9h+Rr6y VU1i2W01SNkkXmOcYBU/XJq/8N/Adn4X8OWGlWZQC0iVNx6sQPmbj1OTXp/2WCKPDnf68k/zqsTi Oeq5w0S29FsduV46rgFF0vi6+berPkPxx4FivMtfJ5U3RLuMcN7OP6H8K+RfGPw7vtMuDOyi2kcn bMnMEv1A6H9frX6t6hp2l3sbR5WMkY+YjafZgTzXjWveB4ZElhsxHJG4w0LkPG2f7p7fQ17eDzhx ajUfzPtcXl+V8RQ5n+7r9+/r3X4nz18FP2v/AIh/B0Q+EvG0B8ReGSPL+y3Lbnjj6HyJmzxj+Bsj 6V9uaFovwj+N8X/CS/AvxAmja3jfLpU58sgnkjy85Ue6blr4e8T/AAoifzIrFBAx62lyMxt/uN2/ WvEp/Cmu+Er+O70iWfSL6Bt0e9mUDHTypl5H519/h8whNK7PwfOuFMflsm6sPd/mWsX/AF52P0o1 o+KfB10uneN9Mk05wSq3KLmCQ+oYcfkQfanQal54DxyAqeAysxX8SMY/HFfPvgP9tT4peErRNE+J +mJ4s0Y/IxvFBk2+06Ahv+BqT7173ofj/wDZa+JGLrRNXuvAGqSclX+e13H6bkx/3zXDisqweJ99 K0u6/wAtjysJm+NwyUW+aPZ6/wDB/M3Es9TlAKLx1yTx+Zenix1gnCyKPYMM/wDoZroLb4ZeM/KN 74L1bS/Fdr1V7C6EE5HuuSpP1NULi48c+HG269omo2wXqZrYzJ/38hJFfL1eHq0f4U0156P9V+J9 RS4kpS0qQs/v/wCD+BmtpGuEgBnOfc//ABVOHhzXZDzg/wC8/wDia0YPiPprfu5Dbqw/haZoW/75 kT+tXv8AhNYJV/dQo4/6Z3ED/wA5FNec8pxsf+Xd/S3+Z6Mc5w8vtJetzHTwxrIxujhb6sv/AMSa tr4f1FBlorbHU5cDH/jlXx4skYEfYrhsD+EwY/PzDXm3ii98e+IAbS1EWmWDfeLzQ7yPf5wCfY8e 1aU8rxk5JOm162N6eYYSTvUrRSXq38ktW/6uZPjHx9p3hi1nBeBSnBkRsr74JA/P8q+crXRPiR8b DJceG4k0fwwrbbjXNRY29iq9wjH5pW9EiDEnqV617tpfw48OQXiXuoJbavfIdwlvM6gEb1SEhLVS O24OR616obGC9ljn1W5bUJ4Rtja5kEgjUdBHCu2ONR2CjAr6ahQy/ALnxNRSl2Wv9f1qY4zO8XiK TweUUnCm95P4per6LyVzivht4P8ADXwssZrD4VQyXOsXqeVfeKL+ILcyKfvR2cJz5MXp3PVieMdj baJcWCtHaZzKS00z/PLK56s7HmultyIuOXx6hBVo3ajhoyR/vD+leLmnEFTFR9jRXJT7dzycvyeG Hl7Wr70/wRzw0iVhmS52n08vP9KaujuTg3D59ol/qK6UXduDl4G/Ak08X9kOfsrk/h/U18YrH1fP P+rGLH4clkBIuX/79R/1q1H4ZXo9zKPrHD/hXRwapbHjySg9yv8AjV4XtjjLAc+pX/GtVHsZSqzO aTwta4Ba7c/WOIfyFXovDVrH0dm/If8AoJrcW5tTgqFP/fJqX7VIPuFcD2FD80QpyfUxl8PqD8ss i/Rm/wAaupo0iDm4kPsfm/nVk3t1jmRB+H/16gN7Jkhrj8lJ/rU3SKvJ9SU6KnSSRmz7Y/lUMnhr T5RiVM/mP1zTRdbujM3/AAA/1NKt6qdY2P8AwHFVzIfv9yeHw9pcLblRvxkOPyyavRafYQg+UgX/ AIGRWQ+rKvPkZ+q1A2tNnCRAf8BH+NS5oOST3Zvm0t3yMA/8DY/1pv8AZUPaNT+LH+tczJrV4D8u B9E/+yqB9fvgOWfPtH/9lU8y7D5JdGdgNJh/54pn3Un+tPXSYMcwoP8AgH/165NdbuCuSsv02f8A 16sDVbhh/qpD/wABH+NUrEWkup0w02LoEUf8AFP/ALMjzwq/98CuaW/kAyYJCfoKkOpSAf8AHrIf T5RTsg946P8As+McYX/vgVMLJcfKFP8AwEVyx1GfGPsr5+gpn2297W8nP+5VaCtLudgLPHQL/wB8 ikMCD5XKj6rXI/a9SZhtR0H/AAD/AApRc6sDwGI/7Z//AFqnTsFn3Opzajq8f/fNBay/idB/wAf4 Vzaz6qD0OP8AgH+NTC51HHzMq/UD+jUa9g5fM2Gl09M5kQ/RP/rVPb3ltH/qOUHfG0frisIzXXUm N/baf6GmI4DmaWASy4wpLttX3AIOKTbBJdTpf7UcyqNyhQewzzW3M/7g/IXJHTIH9a8vtrW8gkZp p/P6lC/VWPfHTjtWhEbpRmaUSN6lR/jVQbWrKlFPRHRmKRzueIoV6Yfdj61CJZImwqO3rlOD+IzW Sktwi7ATg9cHH8qaJbgZ8qXZn3yfzNCaCzOmXUJFGXjCKPc0wa1aFtrjLDsD/jiuZAuf+Ws5f8WF WUlaL7hCn3yf5ir9AcTba8t5c7Lcn/vk1X86DqdyfXGP0rGnmuJBgXBTH93I/pWZJZmU7nuXz9WN JvzM1E//1vRUaZh9+M+/H9FqXbMeP3X5N/8AWqqkZKgYH4ZH8jSm1Ruo/Vv8a/Fo7bH6qi7tl24Z xn23f41WkiJPzMW9v8mqpsIz94AH6H+pqBtKtieQM/7tJlJpdS4sUA5aHP1/+sasrOYwPLgP4ZrE bRbJuowT6Cpo9LtI/lAJHuT/AI0Jsl8v9f8ADmm2pTL1tX/An/Ckj1ORm2m3kX3OaqraJGf3ZYfi f6mrADjjzG/Sn11M7LoiZr1QMvCx/DNQ/wBo2wbAjYfVOKjdN33mJ+uKg+ywk88/XH+FTqVpsXv7 QQ8qin6j/wCtSfbUPWJT+A/wrMeysWB3gfmKr/Y9LUYbb/33/wDXpe8UuU3BdQn5fKA/D/61Kbi3 /ugfgawfI0hTk7c/9dD/AI1IJNKj4BXH++T/AFqx+hsfaLT+7n6H/wCuKlWe3bgZX8T/AImsM3em gYCqfxY037Xp3aND+DGnp3FaXY6RfJck/aMf8CqYeShz54P/AAIc1x5ksSSfIQn/AHG/wpmLMncL Vc+0R/wpNxDlkdJqQ86DbEkDSA5Bm+ZR74FciZZbe/lkaSKUuiABeM8kHuTjj8PSrhkjIwID/wB+ j/hUDLGx3eQcjgfuyKiTTKinE0NM8S202mwvdSASHcpXYT8ynBzgHiqj3lxOdxuwg7BYyB+tQBML xA2P9zH9aCpPAgJ/4CP/AIqpb7DSV9icuFU7rzH4D+tVJL20jHz3p491H8hTtj44tz+S/wCNMKSf 88Cf++f8akdtTOfVNMY83Bf6u5H6CplvbB03RMpPrtP9anMM3e3/AFFROkwX/ULx6sP8KVyrL+mY up6jLHEzRzKo/Af0NfFvhySb4qfGi+8SPP8A8S7wxm0tZD8ytIc7mA4GQdxz7ivavj143n8F+CLy 5gCpfXhFraAHLGabjIGP4RlvyqX4FfD+48HeC7O2mjT7XOPOnZj8xlk+Zs/L26fhXsU/3OGlV6y0 Xp1f6HnT/eV40+kdX+i/X5Hs1lItpEifb920dAg5/Srb3rSqRuDj/aDf0FT/AGa7xldg/wCBGm/Z 7nnLJ/49XhN3PUVkZj3F0BiKKMD/AHG/+tVU/wBqynmCNlbsyt/LdW19muj91kH4N/jThZ3bHPmp +Tf40tOxoqltUzmbnQmv08u6t0aP+4VJA+hJyK5LU/h6kkTIissTZ/dyoLiL/wCKFerDT7onmZB/ wA/4006fdHOJ1/79/wD163p1qtPWm7H02F4gxdFck5KcezX6/wCdz5e1D4QWjMz2du1u5/isZhj8 YZK841f4JCRtzwRu39+W2ltpP++4OP0r7ibSZZP9ZOhz6xj+tN/sePo10F+igV69PNsRHdX/AAOX EPJcW+bEYaz7x0/yX4H5/wAPw68U6FMJtDvrqykQ8Nb3vP8A4+ob9a77SPHP7TPh7EejeMNTKDok 7RTr+O5jX2H/AGJYE/vbzOfXbUiaNpcTZWcf+Of1rtWe11tH8T56rlGRP4FU++P+R8623xV/aq1E CK6fTNSB/wCfrSraX8+K6yxf49asN+q6d4UtVbq0mjwlv++VOa9uWG3iHy3Jx9VH8hT90IH+sLfU 5rKeeYl7O3yPKllWXJ/uqb+bv+SR5va+GvEzAPq9xpjn+7Z6TaWy/m6St/Krr+HbpsDZEcdysYP/ AI6grtCRu4GR+JpDJJ2jH5H/ABrx62Nr1fjm2dtHD0qX8OCRyUWiasowksaj6A/0q9FpWpryblF+ iL/hW8ZbgdIxj6D/ABqMzXIH3FH/AAID/GuTmOttvexUjtb9eWux9Nq/4Vb+z3DDDTg/8BqEzXg6 bB9XH+FRedf9TJGP+B//AGNHP0sZez8y0unhmy8gP4VaGl2zfeCE/wC6P8KzBNqGeJk/76P+FSLN fjnz1/M1HMuxfLL+Y1V0m1OQNv8A3yv+FPGiWpHDc+wH+FZomvyAfPH5t/jU6S355My5+rf41XOl okS4v+YujQ7XHzMfwJFOGg2Z6sx/Fj/WoUmvc/65PzP+NSrNdk482MEf7R/xq+byJs/5iQaBp4A4 H5Z/matR6Raryj7cf3VUVT8y5x/r0H/Am/xpAbs9JUx/vN/jT57dBcrf2jattLtPMDOHlI9Tx+Qr e8uxhXDLEp/2io/nXATxXsmcOhH4n9C1QRWU75Bm2D8E/pT9r3H7JWvzHUanIkcyGGIyq3Vo13qC PUAE05w1xCHWOLp0YtE4P1x/hXMSw3OnKLmCRrgg/dSRifrjiqEutatdA+dbNjP8UZ/ntFEdLsTi nblZ1eJMgcqR/wBNFkH5gg1fQOy8157DdXYfi3kB98gfqtbMN/eBQBbO2PU1lKdi3TZ02x+o6fgP 6VIDgcgfif8ACsdbu8YD/RMfU5/oaC+pSfdt1A9z/wDWo5uxHJ0Zps/b5P1P9arEoD95fy/+uaot HrBO1YVHv/kiomsNZc7tkeT9f/iqpXfQtJLqaPmRg5bH4D/6xo86DOcA/g3/AMTWSdG1liPlj/T+ pp6+H9WJO4xgH6Vok+o/d7msLiPHyx/kr/4ig3SjqgH1U/1eqK+HLw/eZP8Ax3/4k07/AIRu5b70 q/8Ajo/9kq+VmblHuXDfRKPm2gf8A/q1M+3wjoyf+Qv8TTF8N3AHEq/99H+gFOHhyUdZ1H4t/jRy ico9R39qRjo6n8U/oppDqQx94/gf8Ep48ODB3zj82/8Aiqd/wjMB+/MD+B/q1HL5i5o9iI6l1+8f ++v8BTDqmD1YH3Lf4irB8L2ZGC6j/tmD/OlXwvZD/lofwRR/Sp5fMrmiVTqSZyxA+rD+r0z+1rcH JZR/wJf/AIqrp8M2B6yS/gVH9KcPDWnLyHl/76H+FKw+aJQ/ti37MmfqD/jSf2urDgj8if5LWl/w jenHnfM3/bQgfpUZ8NaQeGEpI9ZWP9adh88OxUGpqBnOMf7Df/E006pGBkkn/gLf4VcPhvRR/wAs CfqxNDaBoyjAtv1P+NJpCco9j//X9DUDp5h/Sghcf6xv8/hVVdKc9b2c/p/SmnQ1zzc3B/4Gf8a/ GFc/VVYtssfaRjUWI1/jfn3qA+H7Y/fmuD/wM00+HLBupmP1c0te47onCwf3n/76NPCWndj+LGqp 8NaaBxHIT7vSL4b03vbk/VqGvMNC2Rp4HJ/Nz/jTfM0pfvMmfd//AK9RDw1ph5+yj86cfDunD/l2 xj3P+NKyJ0Ee60XjJj/76H+NQm90LP8Ayzz9R/jU58O6djBgH4kn+tNHhzTR/wAu6n/P1p/INO5W Op6GmRsQ/wDARUf9taIpwsS5+i1pJoOnL/y7rn6f/XqT+ybEcrAox7UvkO8e5inxDpY+5CD9AtRn xFaH7lsT6cD/AArf/s2152wJ+VOOnwYGIEz/ALv/ANanr2KvE5w+IlHS0Ofx/wDiaj/4SSQnAtP/ AB4//EV0hs4xx5Kf98//AFqT7PtGBEo/D/61Td9h3h2/E5k+Ibo9LVf++j/hTf7e1E/dtV/Mmun8 mboFA/A0xrScjnI/4D/+uld9AvDscs+tasRgWyjP1/xqE6zq5OwQKG9MH/4qut/s6eU4G7H4j+WP 51orp1pZrsk81nPJEacficEn86G5W1DmhfY4D+0dek4WFPwGef8Avqgz+Ij/AMsgP+A//ZV6vYwW 4VpI45EB6iQcn6AgVHfXEcRwFOT6Cjlk9WR7WN7KJ5SZfEZ4AX/vj/69RFfErcAgZ/2B2+oNekCc NyATTWlUj7jZ+hqbPuWqv91HmZg8TEZD8/7q/wDxFUL2HxGkbF5yCPQD+iV6q0gwT5bfrXiHxt+I MXw+8Dalr4H+kqnl2ykn5riTiMfgfmPsK0pUpVJqMd2TPEKEXJxVl5HyVqsOr/Fz40x6IkrT6Z4Q bdK2N0bXLEccDsRj/gJr7LstE1y3t0jW4kAUY4zXmX7NHw+n8KeCYtQ1RC2q6wxvLl3+9vl5AJz2 B59ya+ndhA2hRke9deOmpTVOD92Oi/V/NnNhZSjFzktZav8ARfJHmzaVrzdLuUj6mm/2NrB+9czf 99t/8UK9JMTk8BaZ5Tegz9K8mz7ne68ux5wdB1ZjzdSY/wB9v/i6D4cvyQDcyf8AfR/qxr0kQn2/ KnG3J6kYHt/9aizF7eR5ofDE5HMrE+5pP+EUYjDMT+I/wr0z7Pnv+lBhA6n9KOUPbyPND4RyOSPx wf6Uq+Dj13KB24H+FeliD0J/IU/7Meu4/pT5A+sS7nmg8Iv2lA+g/wDrVMvhKXHNwfzb+hFejGE5 BJNIYG/vUcgvrE+553/wis3T7U34Fv8A4qm/8IjI3JvHA+h/xr0AwnnLGmtEc43HH+fahRD28+5w X/CHA/eu5D68Un/CG2vRrh8/h/hXcPD13OfzqLbCo5cfmKEmHtpdziv+EOsAOZn/APHf8KQ+ErEd J5B9CP8ACuxaS1TrIo+rD/GoHu7FB/rkP/Ah/jT1D2k31OZXwnZDn7TP+EmP6VMvhexzzcXDf9tW rc/tGyz99T+NP/tC04I5+gJ/pRclzmZaeGtNX+Of8Zn/AMasDQdKQgs8h/3pn/8Aiqvi+tG6xsf+ At/hR9sTPywN/wB8n/CndCvN73Il0vSU/gP/AH25/rU8dnpikbYwT7kn+dKLonGLc5/3TR9omIys O3/gP/2VFws+pN5NkOViAJpPIt924R/z/oKZ9ouR1Kr/AN8j+ppDdSkYaZB+KD+lU2Tyk4hifnyg Pz/wqRYIsZEa/kazzdnp9pT/AL7X+gqP7WMkG5Qn0DZ/kKyuVys2hCuB+6Ufh/8AXp6QJ3RVH0FY wuPWYHPs5/kKf5q5ALk59I5D/SquLlZtiOJeoTj/AHakAiHOUH5VjI6k4/eZ/wCuT/4VIGORiOTr /wA8zTu+xFl3NlWiBILgflT/AD4x91/8/lWSrMP+Wch/AD+tSrIR/wAs3/HH+NUnLsZvl7moJE/v H9acZUxgEn6kiswSY58hic+o/wAad9oYf8sOPciq1tqCS6F8S8Z/XNIZMjkZ78VWF1L2gUfiD/Wn rcXTceUg/L/Gj5l/Im8wdVUn6VIsjH+A5+tRK98eiov0WpMakeVKj/gIqlHzHzEwdj0ib86cHlzx EfzqrjWOzL/46P6GjOrd5lX8V/wo5AuXd02OIv1p3789Y/zNUR/aBxm6XP1WnbdQbI+1D8x/hTsO 5fVZT1UU7bLnhcH86pKlwP8AWXpH0P8A9ambkz82oMT/ALxo5e5FzR2z5+6P1oKXB6IM1ngRNz9s kP4tSNDCf+XmT82/xocUO5oeVOBgoPyNHlT9MD8qzhbWzHmVm/4E3+NWEs7Ijncf+BH/ABqUh3sW xHKOuBTfIkPVv5VELKw/55bvqSaVrWxUcWoPrWqiiE2BhI+9IB9SKryIo63CD/gQp3l2g6Wi8+3/ ANal8i3IwlqgP0qLINbH/9D1gSMf4GP4U/LHgRn8v/r1nBE/5+pW/P8Awp/kBxxPKfz/AMRX42kr H6imy8N5P+rP5D/GlDODjyz+lZpsd2czS/mf8aYdPhAw0kjf5+tJpDNUyS9k/UD+lMEsg4IUfV// AK1Zg06zJyyu31JqUaZYAf6r8z/9ep0HYvfaWH9z/vv/AOtUbXpyQTHx/t1TOlaYesY/OlGj6Z2j Xj3Jo5hWQ9tQOcAR8f7VRHUT6oPx/wDr1KNH0z/nkP1p39jadn/VD8qWtxXiVf7SA/iX/P41G2qB e4/T/GtBdI04D/Vg/hUg03Tx/wAs1/SqtILxMj+2B3ZfzH+NN/tdTyWX8x/jW4LCwH8Kj8qT7NYq M4Ax9KSUu4+aPYxG1dO+PzH/AMVTTqvH3f1H/wAVW0Rp6j5mUfiKhMmmdN6E/Whp9wunrYyG1oLw UOP8+9ImvQSEDbz6c1pmXTx91l/U/wBKTfa/w4P4N/hSs+4/d/lIxrG04jiyfen/ANvagQVCoo+o /wDr00tH/Dgf99f4VEWU85x+LUn6i07Ex1692jcQWPouf54qlLq1/IdoDbf9wD+tDsCeG6+7/wCN RHr1z/31/wDFUm/Maj5ERvL8ZIDH8BUb3+oqCfJY/wCfpU5HYAfk3/xVRmOQ9NuP90/41nfszSy6 ozLnVdSRGP2VlAHU9K+GfiDqN/8AGP4y6b4Bt4w+leGWF1fdSjT8YVvoML+LV9PfFzxzB8PvBuo+ I7h0326YiQqfnmfiNRz3br7A15X+zV4Fu9J8Pv4s1kg6v4hk+1zs65fD8oCc+h3H3Nexh37GlKu9 9l6vd/JfmedXtUqRpJabv06L5v8AI+k9JW+tLWOJUQAAAYVu31NabXt2h5ZAfqB/M1ZwijmaP8h/ 8VVVjaAkPImfXj/4qvFk3c9JWfQT7fcnvH/32BTGvLnPWIf8Dz/JTRnTwfmugP8AgX+FPDaUetwT +L1KuFo9iL7Xe9AYvzb/AOIpwuNQJxmID6v/APE04PpIPDsSP9+nmfTk+6HP0BP9adpdwsuiG+bq R+60X5PTx/apHMkY/wCAt/jTPtNueEjl59v/ALKlWQ4+VJMfT/FqWvcLLsOP9o55mQf9s2/xp4TU W63Cj6If8aTzZeyv/wCO/wDxVRtcXXXzGUD2X/Gnr1CyLK2t+3/LwP8Avj/69OOn3ZHNz/46P8ap C8lH3rpv0H9aeL1f4rxv1P8AKi68w5X5Fs6VcN1uj+QqM6M+f+Phj+A/wqBruHGWu5Dn0VzTftdt n/j4mP8A2zkqd/8Ahw1XX8Cz/YanrKxz7D/Cj+wou7n8h/hVM3lnkZlmz/uPUf2ywb+Oc/8AAGos uwa9zU/sWDoWb/P4Ux9MjiTgMx9yRWSbuwP8U3/fo/4VVYwSyAQmQn3VlH6LSaXYWvcnuHMTbYEL +pALfrkCqiXapk3UuzPQKGdvyQHFaf229tgqi1SVf95j/MVVu/EM5XyTaGH6Sxxj8N5H8qNttSkr 9PxM+xe7u7pvKuFaEPjEgljfB9AV6iuoGlOx3RT7iP7xP9CP5Vxf2+3llS1cbJrhwFDXKSDnuVU4 H4A1tWVrqmlTiS3tongb/WbF+bHrkKM/jV26MJL+Vm39kmQ4co2O2Cf6UgtixyVQ/wDAP/rVA+u2 AOJvOB+n/wBlSjWLL+GOY/Xj+dK7Is+xeS0z1VQP9wf4VdjtI1AxtJH+yKwn1iIgiK33f7zqKi/t K6xkCGIf727+RrVNdzNqR0kkRUfIMfRT/wDWqq0ksWSW2j/cA/m1c3PqSfenmVv92NmrNfWLEtg2 8030hwP503LyBQfc6t76Td80xx7Bf/iqaZpWOUkY5/2sf1rn49ZhPEenP+I/wqwNU1Bz+5tfLHuu f8KjmKcLdDbCTH7xP/fWanWAZ+Y/zNYv23VnGCSv0jqPOqyHc1xIPogFPQk6VI4e7AfhU2Ldf+Wi D8q5XydQb+KZvyFOFnqQHCOT7vj+tV6IhpdzqS9qgy0y/lTBdaevWRePRf8A61cybXWT0hQD/ak/ +vVZoPEH8KwAfif61TfkOMV3OxXUbJeFPJ9ENPGoQ4+UHn1Q/wCIrhPs/iZvutEPouP5mpFtfEx+ 9Mgz6ED9AhqVN9jb2ce52/2+Q8KOP+uf/wBlTlupyOB/44P8a48prSACS6JI9On8hU1pHqMzbXu2 BzjAOePypqTb0E4JK51ytdv1IA90H+NPME7gksv4Kv8AjWRJpN1FF5z3j4HrVANZmVYpLwgEdWGO fTOf6UOWtmK2l0dGIWX78h/JR/WpQYE4kuAv1Yf41krosUvzxSlsdQVXP60iaMoba3H1jUf0oQrm yJ7AcPdLj3cf40C40oHPnI34j/Gs7+xlbg49/kFPGixt1YjPoFFXYhyRda80/PBGPYr/AI1F/aFs PuEH8V/xpg0GMgFpJMfUf4VMuiQoud7fi5/+tRysXNEhbUCB8gH5p/jUJ1WcDhP/AB5Kuf2daAnL 9P8Aa/8Ar0htrBRgyAY/2qXK+rK5ltYrrq1302H81/wqX+07w4IXr7j/AApfs+lngkH8SaPs+lL0 AB/4FVWa6j0/lGtd6g/3W2/Qio/NvT96Zv8AvoVJ5Wlqc7Af+AmkZdPX7kX/AI5SfmxXfRH/0fQS kUfMkoz9aDcWKdXyf8+4rPTwyne4Y/gP8KvJ4ejX/lu/4Af4V+LKLtsfqace5IL+0QAIucf7o/ma kGqRg/Jblv8AgSj+WafHoyL/AMtnNS/2WnQySHFVZ9hXRWOq5OPsoH1b/wCtSi/z923jH4//AFqn /sqD+IyfnTP7ItB1DH8f/r0veC8ewovH6mKIfV6Rr0A/M1uPrJ/9enrpVjj7mfqf/r07+yNOznyh n8KevcXMuxUOo2w5aa3/AO+v/r1EdUsOd1xb/qav/wBlab1ESn8qDp2njA8lP0oFddjOOsaWOTPD +CsaT+3NJ6CZSfaNv8K0xY2KnAiQfl/hT1tbUHhF/Sh3KvHsZI17Shkh8/8AbNqT+39MPZj/ANs6 2/ItsfcXJ+lOEMI5CrijULrsYf8Ab+mjgRk/9sxQNcsO1u3/AHwK3dkQHUD8aX931z+tIfuroYR1 u3P3bVsf7tJ/bII+W0b/AL4roAw65/nTt3cHj8ad/Mi67HMnV5SDizb/AL9n/Gq7atfMP3dmfxjP +NdWZV7sP1qFnU9+n1pO/cV12OWGoaux+W1x/wBsz/jUb3mvH7lsBn/pn/8AXrqvl6k/oabuQnGR +RqbPuUpdeU5A3XiPPMIH/bMf/FVWubrxHGjFsY9kT/4quxldEzk/pXiXxo+I1j8PvBd/rUkoS42 GK1UrnfcMp8sYHJAIyfYVpTpSqTUIvVkzrKEXJpWR8qfEO81f4zfF6x+H1uxm0vwvILq/wBoQK03 QIecHH3cE92r7Y0rT9YsrOKGLICgDAEQx7V4R+zL8PpvDXhX+3tbDSa1rjm7u5HGXzJyqkn0Byf9 omvrEMij0P4V14yaclSg/djp69382c+Guk6k1rLX/JfJHMta6wRnc2fZkH8hURsNWc5aRwfTzAP5 CupM0XY/yqNrmPoMn8q8vlO/nfY5hdN1DB3uxPqZj/Sl/sy8PLH/AMitXQm4QdTj8qj+1R85PI+l LlDnkYY0q874z/10c0f2TfjkSKP+BvW39rj67jzS/a4sck0OK7Bzy7mN/ZWqdrpR+JP86Bper541 DaPZR/hWv9vhAPDU06hFx8rfrS5V0FeTMz+x9WbrqTAeygU06DqLZ3arKB+Nan2+LPKtj8af/aEP ZGP4Grug94xx4cuf49UnP4mnf8I4+Ob+ZvqT/jWt/aMP/PFj/n60z+0If+eDH8v8am6LvMym8NIR 813N+BNMHhu0HDXEp+r1rG/i/wCeB/Nf8aia8jPItT+a0nyhzVO5m/8ACO2K8GaQj/eo/sHTR953 P1f/AOvV77UCCfsn/jy0v2xj0tPzdf8ACptEOafcyx4f0nHLNz/00I/rThoOkp3fH/XZ/wCjVom8 l6/ZF4/2x/hTWu7jgpaLj3kH+FMhyn3/ABIzY2GApJkXphnLD9SaiTR9Hiy0dugY9Tjn86m+13pz tt4x/wBtP/rUn2u+6GKIf9tKdlv+hF5W3/EaNK0kMH+zpleh28jHpVpYLQZAQYPWq32u9PO2H8ZG oF1e8H/R/wDvpquwvn+JcSO2QYSMKPZaeI4T0jH5Vnm7ux1lt1H/AAI1C17OvW5gH/ASabQ7GwIo s/6sflRhEJAUc+wrAOp8/wDH7CP+2Zpv9qIT/wAfqH6RH/CqvYXI3/TOhyucf4VIrAAr1z7iuX/t SMHH2xjn+7B/9annUhg/6TPgekWKLhyHSkr3GfxFGewTj6//AFq5Q6p2M10Qf9nH9aQ38R+9JcnP vU8wcnmdePMx8qZ+pNG2fps/Q1yazwO33Lhs+slXkghccwSf8CfP9apXIaR0arN1faPw/wATS70U fOyj8v8AGuVleGDJNp8q4ySfU49aSW4itwzTWaxqP4mxt/Pn9aHOwlC+x1PmwkfeB9hg0/7SoHyg n6Yri4tVgdd0caL9HUA/iAR+tPbUST0Xn0lY/wAlrNzNFTOw+1OePIZv+BAf41D9puM8WxA+uf6C uVMqyD5lHP8Atyf4UGG1OS0YP4uf5gU7s0SS/r/gnV+U1wMmNkHuf8KQCC1O7z5OOyqSPz5rkI0W A/uJPLP+7k/qamFxe5+W9br0KJTuugcvc6uXXHQbR0P+yTUP297pSizQxn1ZSD+ig/rVBb+4dQp2 v7lf8KiaAzcmNQ3qAahye17jSj2sWnktQE8590i8bumfxOTj6mti2ktQobzx+Mn+Fc2unEncSePU Z/nVtbRsYDbT7Ko/pWfvdCpSg+p04vrYfdnz/ugmp1u944ml9u39K5eK0lQ/65yfqKn+yF8755Of R8fyraMpnO+U6E7GyXeQ/VjULGxHUEn3J/qa5/8Asy1/jdmx/edj/WnLYWaA+/8AtGteZk2Xdm0J rMcKi8e4pTdQKDtVRisM6fYEEYz/AMCY/wBaaunadu/1IP1yaOZ9bBZPe5sNfpj7yCo/7Tg6GZBj 3H+NZ7aXpxOfJH5Cgafado1H5CjmdyrR8y2dXth/y8p/30P8agfV7c8fak/MU37Dadwv5imta2q8 jYO3UVLlJFWgf//S9N+2jaP3ch/H/wCvTvtpzjyW/Fq4wW+o4wZnHf7q/wDxNP8AsV9/z2k/NR/Q V+NxSsfqOh15vGAyYh/31iozen/nmg/4GK5f7DdH70sh/wCBgf1o/s6YnmZ/+/h/xqmB0TXpH8EQ /wCB5phv2AziEZrnn0pj1lf/AL+N/jUR0YHhnJ/4G9YOxV0dL/aL+sX5GnDUJBj5ox+BrmxosPGW 6/7TU86NbjjOfzpqwaG+dSYfxoP+At/hTDqbf89EH/AG/wAKwDo1r/dH5c/zpg0ay7RqP+A//Xp3 QtDdOrhTzMv/AH7ak/tuMdZ1/BDWKdJsgPuLz/sipF0uwQfcX/vlf8KGyvdNNtdh/wCe/PoE/wDr 0x9eiJ/1rdMcJ6fjWabGx3cAD8F/wpv2OwU5+X/x2p5uw7RNA6/Dn78h/wCAD/Go28QxdBJLn/dX /GqnkacOeOB6im+Vp6ngjH1qOYuy7Fk6/D/ek/JP/iqQ6/GFzmX8k/8AiqgJ09enf/aNR+ZYZ4BP 4tS5mGnYkbX4sf8ALX8l/wAaiOvx9ds2foKVntDyqEn1+Y1Bvtz/AMsy3r8pP9KLi07Df7fQsRsu D+A/wpj68OcQ3B/If0qRpIhykGf+AVDJcJGMiI/98Cle5WnYzr7xL5MRJt7jGP7wH9K+IvEWpz/G f4t21lHFJc+HvCzlnXcCslxnnnockY6fdU4617B8dviOPC2hDTdOBbVdYY29siBS+W4ZgB6ZwPc1 q/BbwHD4M8OQwzIBdz/vrhtwbMrjnknOF4A9hXsUf9noOu/ilpH9X+h51S1WqqSWkdX+i/U9Z069 ltLdI1spgFH/AD2UVonWbzj/AEOT8bgVcMyBeo477lFM+0p/E4Gf+mg/xrwW+x66a7FBtW1A9LM4 PrPTDqOqdfsaZ95j/hVs3EC53TKD05kH+NNFzb4yZV/7+f8A16V+4+byKh1LVQv/AB5xg/8AXVj/ AEqL7fqxzm1hH1kkP9KvfabY5+dT/wACzT/NtDn5h+Zot5BzeRQ+2aztyLe3H18w08XutYwEt14/ uSGr2+0b72PzNS5tQOo/Wj5C5zOW51gnn7OAf+mT/wBamFxqvBMsIx/0wOf51czaZ5C/kafutOOB /wB8n/CmLm8ir5t+3S5j/wDAcf41Ksl50N0PwgWpt9tjhRk/7J/wqRWgPY/98H/Cncm/9aFbzbvj /S3/AAiUf0ppmuu93N/3wg/pVzdEDyP/AB2lLxj7qf8AjtArmf5lweftdwfoIxTDJdHnzrg/8CSt MsOwx+FNzzkcfl/jQwuZW66K58y4P1df6Gm5uvWXj/pqP8a1jKB06fhQrrjOf5VIc3kZG26PB8w/ WQ/40bLoZ2hv+/hrWMoHVjUbSDuT+FS35iu+xkiO9PJU/wDfZ/wpwtrsjoD7bj/hWoJwBwCfxpyz IMkocfU0cy7i17GcLS7PUoPxb/ChrO4ONxX82NaH2hB/AcfjUX2pSfuD9afMgXMtbFQWcgOGI/M0 q2R3AsV/X/GrRvE7KOPY/wCFQm+T72APfBo5irSENicfK68ex/xp62Ldd4H4f/XpP7RRe64/Gpf7 SjIyMEf7tCaJtIatgRkeaP8Avn/69O/s7PWb/wAdFO+3lR93j/dNKuogLu2k/wDADRdC94iOmcZ8 wE9furUgswg/1n5KP6Cj+1QQSUYf8ANL/aJboP8Ax2n6CfN1EETF+CzEepwKtLc3EH3RHz6ktVc3 kpGFJ/75/wDr1A8l8AcDIPpGP8ab5lsCSb1NMm7vQ6zcI4HKLgjBz6n0rQ81khZky7ehA59sf/Xr mYp7tZUeaCR9p/hABA/Gtlrt2QJBC4yeS2Mge3J5oSk9SZWTsYd5HZFhK9iRIx5ZAyNn3wKfEkL/ ADLaO3+8z/4VLMLog/LtPqXx/KqS22pSN/rEx/vEn+VVqytLbmooHRbMDH+9/XFO2nqYo0/Af1NZ 62U6/wCtlXirS2wGJA44+nWq12B27lpYz/eXHt/+ursUII5BY57Cs1J5R9xifoM/yqYS35Py7wPd GNFu5Lbsa42p8oQ59zTjNxjaBj3rG82+5yXX/tmB/Mil2XjLu+1LGvGd20n8AKZlqza8yTAxt/Wm BpTzvUY9M1lRxyOJAbtmGRsIXt3zn39KmESj/WydPTI/maq/mS0zQHmH78g/L/69ChTybjHtgf1q OKG1kGQu/wDI1ZWzt85EWP0pqKYnKxGJrZT80+T9VFH2myUZaQn/AIF/hU5to+SsYGfU0CEFedvH uapIVyr9q08jOWbPuxpn2ixPPlM31Df4VZe3YjAC4HuajFmG4ZQfwNPysURNc2wGFtyceob+tVvt kAOFtx+K/wCNXxaovWIEey08WsG7JtwSP9kCk2y9DJOoKDxCo/Af403+0v7saj8v8a3WtoByIBn2 AqqwjB5gx/wEVErmisf/0+t+22/Yfkhphv4wOh/74NUfsMoHNwv4Lj+ZqP7Ax+/cf+OrX46rH6jZ F86gg4w34IP6mmnURjOWH4KP61ANNhI/1zH6Bf8ACnGwhI4eVsejKP6U3Yl2Q5tRUcZP/fSioG1E Hox/77H+FV30wMxI844/6aGqiac/niOaF8bsFjISuPruH8qzaRSki8NQPGc/99n+i0w35PJHH+83 +FLNpECsWVUdQeMM2fxDHn86fDptiwy0MfT3/wATU8qK5la5XbUAMAqPzY1WfUVBxtTH0b/GtxdM 0/I/0eLj/Zp50+wXpDEP+ACiyRXMjnW1KI9RGPw/xak/tKPGP3Yz7D/4qt37HaAkKkef9wVItohG FVcf7g/wqC7rc5k6pGCMsoHsq/8A16DquD8r9fZf8K6tbM4/1a8/7NBtGAwcAf7v/wBek0XzI5U6 k7H7zH8F/wDiaiOozEjaW/DP9FrqxAg6uT64A/pUoRCerHH1qdCr+Rx/226/hEp/77/wqI3V2ePL lwf9/wDxrtiqgDCk1EZFU4KHH1H+NVoTzeRxnm3h6RSZ+jf/ABVRn7eR/qJPyb/GuyN2qk4TP4j/ ABqI38Y+9GFz0JNOyDml2OQMF2R81u3/AHzn+tYWuT/2ZYTX13H5MMCM7uyqAqqMknPYCvQbi/hC nkfgR/jXxf8AtA+LNU8VapZfB/wqSbzVCr3rhh+7tgc7Tg98bmHoAP4q7MNh/a1FHp1fZdTmrYh0 4OXXp5s434f2mq/F3x5c+PLq2Y6TYu0OnoVHQcFufzPufavtSy0W6ihWMQBQB/sisf4e+CIfC+hW emWMHlxQIFUFznjufc9TXpi2UwX/AFaH/eJNZYyt7Wfuq0VovQeHh7KFm9Xq/U5M6dc8DaP/AByn iyuT1Ax/wD/Cum+yXGceXEPw/wDrVJHayj+GMe+K823U63UOU+y3APCEk+jIP6U8W96SMBjj1euu NtIBjIH0OKhaJwSC5/Amh3RPOcz9mvQPu5Hu5/wo8i8//WzY/lXQPEvQ5bP+9URjtx1jJ/4D/jU3 Y7rsY/k3vfYP+BN/hTgLoA73j/Nq08Qg8QMf+AD/ABpMwg/8e7H/AIAv+NO4Mo75cY82IH6Mf60e ZcjpNGfopP8A7NWkskY5W3bP+6v+NS+a45WB/wAMZ/nVW8yb26GUv29sbZUOfSP/ABaphFf95AR/ ugf1q/8AapACPs0v6U77W6g5t5fxK09CG32M4wX/AGk5PsP8KabXUiOJ8D2C/wCFaJvHHIjI+rrV SS/lHXaPrJSuilfoVWs9S/5+SPwX/wCJpPsd8fvXbj8R/wDE0p1Bz96RB+JP9KZ9rh7zj8EJ/wDZ aCrS/pDDp9zja19Jn/eA/lUH9lTE830p/wCB1ZN7a9PObn0jP/xNMF/ZKMedJ/3wf/iar1C8un5D P7HcDBupWz/tH/GnDSEzlppD9Wb/ABobVbNTj7RL/wB8E/0pDqtmeBNOf+2R/wAKCLzFbSrcDLSN j3Zv8aQadY4y2SR9T/Wmm9tJBt86dQf9jFTLLYkc3Uwx3O0VVmK763GG1se+SR7U/wCz2owQgP4U 4T6cACbxj/wMCnjU9Pj4F5H/AMDkzTsS2+iGBIR8u1QPzqZIkI+WM49lP+FNGr2Xa9gH0JNOF+so xFewn8Cf607Mhsk8hRysbZ+lPWJzjbHIc/SqxuZxz9thGfQf4mo3u7tc/wClR59tg/nQHzRppb3D Y4YfXFTC0mPLE49+n8655r7UY2y06kdMYX+majOrahHwxyB9P/iaV0huEvI6NoXU4LKMf7P/ANeo 1RugkLfRawR4juEOGg3475x/7LVqPxIzD54MZ9yePwSml1uJxklsaj7V+80n4CoftMS8ZkP1qsdd sHUtMjZ9Njn/ANlqu2r6e3+rs5n9/Lb+uKeo0vJl43aqe4HuM/1qdLsMufvevBFc5JctLg29jOPT 5QP5mqksWqM2Y7N/xZB/SkacifU64TyO21E2j1IqfZeMMJIv4iuJSPWgx8yEoo7b4yf1Fa0M95CO Ukz6eZH/AEWq06sykmtjpYbaYZMrByfYCnusijOcfRQa5+TWdQQAQ2qsf9qTp+S1Tk1jxDyY7eJc 9M5P+FS7bIIwk9WdT9raPr5hPsoH9KY920v3kl/lXHPqnix1OUt1B6YUmq41bxGhBnkgAPpGc/rg UnzdzT2a3O2a1iuSrO7KRyAW/wD11eihtFXy5HEhHYtxXI21zrN2NwYH6Q5H6mi5tdevV2288kTJ gnYqxDnsTnOPoKF5shro2dKJXt2bdaiRCfl6Yx6dKoz38ZbCRiHHY7SP51m2+ma+WxcXiup4KO7O P1Gasr4cti3mMEJ6kpinZ2BuKepqQXgYANcog9iM/oa0o5LVgB9p3/h/+us2PS4IvlRyh7ZxVhbC Zht8849mI/lRqifdexqiKELu5YnuxA/nUDXccZKsIVHvKDWT/wAI5ZynNxH5hPUs7H+dWIfDukxN xaqD/vE1fMn0Cy6sn+3xg4DQAeoera3uf9XLEPoSaSPSNOUcQAfSrsel6ZjBjx+JoV+g24kaSzvz 5iEewP8AjT2cqMvG0gPpgf1qUWWmxLhU/nUElvp7fKYm/AH+lXykN9kRPdRIMCyJx/edR/jWVcax bxsVa0UH3fP8hWi9nphH+od298/1NUzp1k5wtmV98D+uaUmrFx81/X3n/9Tshps5xuufyWmf2VIf +XpvwFZapfAEi8hHvhz/ADeqVx9ubhtSgX22sD/6MFfkdkj9NuzdbTH6/aJDj3xWHqDyWAySNo6s 8hBrBnsXmbD6vn/ZjXn/ANCasS50+9Erp5z+WAMFsHP15FZuxa0e52MWrxzrsEiD3DHP861ortYI wzFHX1Y5/wAa4u10OcRhQQf9pQMfoKv2umyx7lS7wW6gbay0voN22TOn/tHSrhdsmxc/3Vb+YFSR Poyj5ZM/QPXLS6bKDkXMn/ATiiKwuTjZcyfi5/oKlMFax2AudNXlUd/ohP8AOp1u4MYjtpD+CiuV FrdR4/eA59ZH/nmp1sp2wS3HtNJ/jRzDSXU6VriU8pasPq3/ANaoWnvscW4X6tWMunt1JOP+ujmp f7MXGGyf+Bt/hWTZa5Sy11fg5YKo9N3+C1E19MOGx+G//wCtSf2YmACq/mT/AEpP7LgY52Ln8aNT RSiMOoJgb1J/T+bUz7dE2VERP1dR/U1KNLtuhRPyJ/maX+zrYD7oH0B/xqbvoXzR2IWu41GPs6n6 yLULalGo5tYgPeUVbbToQOAPxXP9aiexix0X/v2v9aZPNEotq0Pa2txn/bJ/kKqvrkcfKxW649Fa tRrRR0baPZU/wrNvEEMZPnMOP9gf0rRXYnKCPNPiF8TrTwl4fvNYujHtgXCqARvkPCJnPc9fQZNf PvwL8PalcXd78R/E0U0+sa6/mkgHMcTfMqj0B4OOwCjtWR4oluPjZ8UYvDdrM83hrwy++4cMNk1x 0wCBg+g9g3rX2LougQ2dpHErvhRjHm4/QCvWry+r0fYr4pav06L9X8jz6bjVq+1t7sdF69X+i+Zf hvpggCWlw3/AmpjahcZx/Z1w31f/ABq++mQAHkn6yn/CqjafZ87ufT52r56TPXTj/X/Dlc3N1Ied Ll/GbFOVm5Laa49zOad9gs+uR/305p4sLEDsfxf/ABrPmRbt0/r8QUIw+ayC/WTP8zTSkYHyWy/T K/1NSC3sAcbfyD/407ZZdBH/AOOtQ2iblBpZVOFtQB67of8A69PiuLvr5Oz38yEfyU1dVLY5wn/j hpDBC2AAR9ABQmu47rqhRcTbeZmB9A4/otQtNdk5+0MB/wBdv/rVILWMHGW/SnfZE7Ow/IUcyJ90 ypJtU34jnOzPU3DA/kENOVtULc3BVf8Ars5/klaot1+6ZG/76p628K5BJJPq2aOZickZccV+3Ml2 5+kkh/oKl8iY8faGz7mQ/wBRV8QQA5yv6U/y4uB8o/Kq5jNzM77Ld4yLrj/dc/zapBBerz9tI/7Z /wCJNXfKjU8babtX2/z+NWpMjmTKjRXnU6g4+kaf1phgm2/NqMv5IP6VeCKehQH6f/XqFlYdGX8q LsV0U/szE86hPj2ZBQLcL1v7ph/10A/lVoLKOBIAPoP8Kd+9HIk/Qf4UczHdFdYYw3F3csP9qTP9 Kc0Nu5z5krD/AHj/AIVIfOPWQfkP8KNrkcy8e2P8KV2w0IBaWIA+SRvq7f4U1rLTun2Yt9WY1aLR jgzYP1Ap6zxIP9av4sP8apE83Yz/ALDp6jC2iD6gmnJZ2oyFtI/rs/xFXjdx7cmRP++hUMl0D0bH 0J/wo5mLmbJUgwOEiA9l/wDrUG3duyf98j/CoROOSWYfQt/hQswPcke+4/4U+Ykd9lmySoVSe4Ra QwXe7Amb8Ag/rTGuwBjH55/xppvQPmGMfSk35lLm6InFvclgTcyk/wC+o/oatJAF4aZ2+rdvwArO XUzu+7U66lEPvDb+VPmBqXY0vIi67m/Esf61KojUgc4+lZDamuPl3N9FzSC/mJykcuB/sf8A1qOY XIzeDrnjP+FOZ0B5JA/D+tYZ1S6A+WJlx6jGaDqVxJgYVc/3iBTUr6IXI+xuiWPs/P1FNYZ565/H +RrLjurg4zLF+BJrTjkBX7xY98A/4Voo3M27dCDywPmaMn8AP51GY1JOEb88fyrRCyMflH5qxqdb Wdx8zhfov+JqeQXtUjIa2kOMIf1/wqs9lMBnyCw/P+YroV0+bPzzN+QA/nVpbR0GPObH0FUool1j i3syxO63I47oD/7LVR7C64MVuR7hQv8A7Ktei+QOjSEfXH+FNMUBGHm4+oqrCVfyPP4IrhE2zwt8 vfIBGfcr/wCzVt6fdyROkLIWVlIyWUng+oNdF5NsDkXBGPQ1E9tYOcyOTyDwDnPbkVnbUt1brYrt BAAWI2D3NNS2hcZBB/KtQJaNgl3P54qcx2RG1s/rWqitzH2j8zLFrHjJOPxI/kRR5CqQRLjHoT/W rd1Z2skLrbnaxHXqf/HjXFvpEm8/aIieOCZGU4/4CCKmSSNab5t2db5cgw3mfqKcVlHWQD8a56z0 yFCPNt9x46u2D+Oa9AtNPtjEu6BEB7DmueE1J2N6lo2sznzzw0oH4ilBAAzJ0+n+Fbdx4f0uZtxj wf8AZx/hVceH7SM/u2IHphf8KtpiVRFIZ4xLj8qmWQj/AJase3BFXP7PEZ+VyPbj/Co2jnX7r+3+ eKW2o+dPQi3Pxhm/Q0x7h1HIY/lUwkuVPJJH+6xpxupMDCAn3Q/4UNrsXr0P/9k= --Apple-Mail=_B1592D56-807D-431A-8A72-EF1C33BA008C-- --Apple-Mail=_7E74F83C-F62F-442E-9D62-F0728B992FC3-- From nobody Fri Aug 11 07:16:26 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B36D13265C; Fri, 11 Aug 2017 07:16:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk CC: homenet-chairs@ietf.org, ray@bellis.me.uk, draft-ietf-homenet-dot@ietf.org, homenet@ietf.org, terry.manderson@icann.org, Ray Bellis Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150246097710.24498.9883419791827623506.idtracker@ietfa.amsl.com> Date: Fri, 11 Aug 2017 07:16:17 -0700 Archived-At: Subject: [homenet] Last Call: (Special Use Domain 'home.arpa.') to Proposed Standard X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 14:16:17 -0000 The IESG has received a request from the Home Networking WG (homenet) to consider the following document: - 'Special Use Domain 'home.arpa.'' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-08-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.', and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Aug 11 07:22:23 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F569132394 for ; Fri, 11 Aug 2017 07:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 yK2nVqOT8g9O for ; Fri, 11 Aug 2017 07:22:17 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9634D13239A for ; Fri, 11 Aug 2017 07:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1502461335; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=DnynBTQ+s6Kd5iSp6HerKIZy/gbIQg/5EWuEXEdh2Go=; b=SxcREL/ojJNRef2gRm3ZPy45kWBTSjQVKIXVc/KuRuZRcEKbirPRg6lmevEYKx3DMYEnG5K4YqSyZA5WkC0qjRBXte9dsaUa0x0Q8swP2fMvXbgSvIHHz8VtNYiC01TZyKpZxj2ZB5cT0OXXcOoGT0D+nOKNn4L+d9NkSl4yG/I= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0184.outbound.protection.outlook.com [213.199.154.184]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-99--ofOm1UGNHGcL03V-3zwmQ-1; Fri, 11 Aug 2017 15:22:11 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1121.eurprd07.prod.outlook.com (10.163.187.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Fri, 11 Aug 2017 14:22:10 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9447:453:3e6d:c99a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9447:453:3e6d:c99a%13]) with mapi id 15.01.1341.013; Fri, 11 Aug 2017 14:22:10 +0000 From: Tim Chown To: "STARK, BARBARA H" CC: Daniel Migault , Michael Richardson , "homenet@ietf.org" Thread-Topic: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued" Thread-Index: AQHTB7SPPiu9XY2yCUuLmtA4ygPxM6JsoKWAgAApz4CAD6M9zIAAMcmAgAKri4A= Date: Fri, 11 Aug 2017 14:22:10 +0000 Message-ID: <74D41199-2318-4499-AE62-EE17DE60460E@jisc.ac.uk> References: <150124709279.25258.15094387920433065465.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DBE0147@GAALPA1MSGUSRBF.ITServices.sbc.com> <12743.1501435181@obiwan.sandelman.ca> <6265.1501464056@obiwan.sandelman.ca> <19178.1501510069@obiwan.sandelman.ca> <2D09D61DDFA73D4C884805CC7865E6114DBED1F8@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBED1F8@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [212.188.254.49] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1121; 20:+l0/4b/Hcwmq/7jdgvb3WKHU2a7uxc7NciDYnhMqGuFOizYszvTDogV40pF5h2DoRZYexgUU53jegHXteC005xJS9kKdGTkbiCOYFza7d1ApUbgq2nb+TBk5PJ+75DvzfGVmZelWRqRe2rHNeV5XkngjpnPIWcrWIEPUl/2Ojkc= x-ms-office365-filtering-correlation-id: 6711d7ff-ffcd-4897-fc78-08d4e0c45abc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB1121; x-ms-traffictypediagnostic: AM3PR07MB1121: x-exchange-antispam-report-test: UriScan:(20558992708506)(97927398514766); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1121; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1121; x-forefront-prvs: 03965EFC76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(15374003)(51444003)(199003)(24454002)(377454003)(8936002)(74482002)(6306002)(82746002)(57306001)(6506006)(99286003)(66066001)(7736002)(25786009)(6436002)(105586002)(106356001)(4326008)(14454004)(33656002)(110136004)(101416001)(6246003)(54906002)(53936002)(6512007)(97736004)(72206003)(5660300001)(50986999)(76176999)(966005)(53546010)(50226002)(2950100002)(42882006)(68736007)(229853002)(2900100001)(6116002)(36756003)(6916009)(3660700001)(83716003)(5250100002)(3280700002)(230783001)(2906002)(86362001)(3846002)(81156014)(478600001)(189998001)(81166006)(8676002)(102836003)(305945005)(93886004)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1121; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <7A29D0BA5A7CA546A261E62E50808FCB@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2017 14:22:10.6004 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1121 X-MC-Unique: -ofOm1UGNHGcL03V-3zwmQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued" X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 14:22:21 -0000 SGksDQoNCk9uIHRoZSBwcmluY2lwbGUgb2YgdGhlIFdHIGFncmVlaW5nIHRvIHdvcmsgb24gdGhl IHByb2JsZW1zIGFzIGl0ZW1pc2VkIGluIHRoZSBjdXJyZW50IGhlYWRpbmdzIGluIHRoZSB0YWJs ZSBvZiBjb250ZW50cywgSSBzdXBwb3J0IGFkb3B0aW9uLCBpLmUuLCBpdOKAmXMgc29tZXRoaW5n IGhvbWVuZXQgc2hvdWxkIHdvcmsgb24sIGJ1dCBpdOKAmXMgcXVpdGUgcG9zc2libGUgdGhhdCB0 aGUgZHJhZnQgd2hlbiBpdCBtb3ZlcyB0byBXR0xDIG1heSBsb29rIHNvbWV3aGF0IGRpZmZlcmVu dC4NCg0KU29tZW9uZSBtZW50aW9uZWQgdGhhdCBSRkM3MzY4IGlzIG5vdCBjaXRlZDsgaXQgd291 bGQgYmUgdXNlZnVsIGZvciB0aGlzIGRyYWZ0IHRvIGNsYXJpZnkgd2hlcmUgaXQgaXMgY29tcGxp YW50LCB3aGVyZSBpdCBpcyBub3QsIGFuZCB3aHkuDQoNClRpbSANCg0KPiBPbiA5IEF1ZyAyMDE3 LCBhdCAyMjozNSwgU1RBUkssIEJBUkJBUkEgSCA8YnM3NjUyQGF0dC5jb20+IHdyb3RlOg0KPiAN Cj4gVGhhbmtzIERhbmllbC4gQW5kIHlvdeKAmXJlIG5vdCB0b28gbGF0ZS4gVGhlIGNhbGwgZW5k cyB0aGlzIGNvbWluZyBGcmlkYXkuIFNvIGlmIGFueW9uZSBlbHNlIHdhbnRzIHRvIGNoaW1lIGlu LCBwbGVhc2UgZG8uIEnigJlsbCB0cnkgdG8gY3JlYXRlIGEgc3VtbWFyeSBUaHVyc2RheSBkZXNj cmliaW5nIHdoYXQgSSB0aGluayBJ4oCZdmUgaGVhcmQgc28gZmFyLiBUaGF0IHNob3VsZCBnaXZl IGV2ZXJ5b25lIGEgYnJpZWYgY2hhbmNlIHRvIHRlbGwgbWUgaG93IGJhZGx5IEnigJl2ZSBtaXNp bnRlcnByZXRlZCB0aGVpciBzdGF0ZW1lbnRzIGJlZm9yZSB0aGUgY2FsbCBlbmRzLg0KPiBCYXJi YXJhDQo+ICANCj4gRnJvbTogaG9tZW5ldCBbbWFpbHRvOmhvbWVuZXQtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIERhbmllbCBNaWdhdWx0DQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0 IDA5LCAyMDE3IDI6MzcgUE0NCj4gVG86IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyQHNhbmRlbG1h bi5jYT4NCj4gQ2M6IGhvbWVuZXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtob21lbmV0XSBU aGUgSE9NRU5FVCBXRyBoYXMgcGxhY2VkIGRyYWZ0LXRsZG0tc2ltcGxlLWhvbWVuZXQtbmFtaW5n IGluIHN0YXRlICJDYWxsIEZvciBBZG9wdGlvbiBCeSBXRyBJc3N1ZWQiDQo+ICANCj4gSGksIA0K PiANCj4gSSBhcG9sb2d5IGZvciB0aGUgbGF0ZSByZXNwb25zZSAoSSB3YXMgb2ZmIGZvciB0d28g d2Vla3MpLiBJIHdpbGwgdXBkYXRlIHRoZSBkcmFmdCBieSB0aGUgZW5kIG9mIHRoZSBtb250aCBp bnRlZ3JhdGluZyBudW1lcm91cyBmZWVkIGJhY2tzIHdlIHJlY2VpdmVkLg0KPiANCj4gQXMgYSBj by1hdXRob3IgSSBhbSBzdXBwb3J0aW5nIHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGFy Y2hpdGVjdHVyZS4gSSBiZWxpZXZlIHRoYXQgZ2l2ZW4gdGhlIGN1cnJlbnQgc2l0dWF0aW9uIHJl Z2FyZGluZyBob21lbmV0IGFuZCBuYW1pbmcsIHRoZSBzaW1wbGUgYnV0IHVzZWZ1bCBzY29wZSBv ZiB0aGUgZHJhZnQgd2lsbCBoZWxwIHRoZSBXRyB0byBtb3ZlIGZvcndhcmQgcmVnYXJkaW5nIG5h bWluZyBhbmQgaG9tZSBuZXR3b3JrLiBJIGFncmVlIHRoZSBkb2N1bWVudCBpcyBub3QgeWV0IGlu IGEgZmluYWwgdmVyc2lvbiBhbmQgZmVlZCBiYWNrIGZyb20gdGhlIFdHIHdpbGwgYmUgdmVyeSBo ZWxwZnVsLiBUaGF0IHNhaWQgSSB0aGluaywgc2luY2UgbGFzdCBJRVRGLCB3ZSBoYXZlIGEgcHJl dHR5IGdvb2QgdmlldyBvbiB3aGVyZSB3ZSBhcmUgZ29pbmcuDQo+IA0KPiBZb3VycywgDQo+IERh bmllbA0KPiAgDQo+IA0KPiAgDQo+IA0KPiAgDQo+IE9uIE1vbiwgSnVsIDMxLCAyMDE3IGF0IDEw OjA3IEFNLCBNaWNoYWVsIFJpY2hhcmRzb24gPG1jckBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiBU ZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+IHdyb3RlOg0KPiAgICAgPiB0byBwdXQgdGhlIENG QSBvbiBob2xkIHBlbmRpbmcgdGhhdCB1cGRhdGUuIFRoZXJlIGhhdmUgYmVlbiBzb21lIGdvb2QN Cj4gICAgID4gY29tbWVudHMgYWxyZWFkeSwgdGhvdWdoOyBpbiBwYXJ0aWN1bGFyLCBJIHRoaW5r IEp1bGl1c3onIHBvaW50IHRoYXQgaXQNCj4gICAgID4gd291bGQNCj4gICAgID4gYmUgbmljZSB0 byBhY3R1YWxseSB0cnkgc29tZSBvZiB0aGlzIGluIHByYWN0aWNlIGlzIGdvb2QsIGFuZCBpcyB3 aGF0DQo+ICAgICA+IEknbQ0KPiANCj4gV2UgcmVxdWlyZSBpbnRlcm9wZXJhYmxlIGltcGxlbWVu dGF0aW9ucyBmb3IgSW50ZXJuZXQgU3RhbmRhcmQsIG5vdCB0byBhZG9wdA0KPiBhIGRvY3VtZW50 LiAgSW1wbGVtZW50YXRpb24gcmVwb3J0cyB3b3VsZCBiZSBnb29kIGZvciBXR0xDLCBub3QgaGVy ZSENCj4gV2UgbmVlZCB0byBsb3dlciB0aGUgYmFyIGhlcmUsIG5vdCByYWlzZSBpdC4gIFdHcyBj YW4gYWJhbmRvbiBkb2N1bWVudHMgdG9vLg0KPiANCj4gICAgID4gVGhhdCBzYWlkLCB3aGF0IEkg c2FpZCBpbiB0aGUgd29ya2luZyBncm91cCBpcyB0aGF0IHdlJ3ZlIGJlZW4gc3Bpbm5pbmcNCj4g ICAgID4gb3VyIHdoZWVscyBvbiB0aGlzIGZvciBzZXZlcmFsIHllYXJzLCBhbmQgSSB3YW50ZWQg dG8ga25vdyBpZiB0aGUgc2NvcGUNCj4gICAgID4gb2YgdGhpcyBpcyByZWFzb25hYmxlIGFuZCBp cyB3aGF0IHRoZSB3b3JraW5nIGdyb3VwIHdhbnRzIHRvIHRha2UNCj4gICAgID4gb24uIElmIGl0 J3Mgbm90LA0KPiAgICAgPiB0aGVuIEkgZG9uJ3QgYWN0dWFsbHkga25vdyBob3cgdG8gcHJvY2Vl ZC4NCj4gDQo+IEkgdGhpbmsgdGhhdCBpdCdzIHRoZSByaWdodCBhcHByb2FjaCwgYW5kIGdpdmVu IHRoZSBzb3J0IG91dCBvZiB0aGUgTVZEUCwNCj4gSSBzdXBwb3J0IGFkb3B0aW9uLg0KPiANCj4g LS0NCj4gXSAgICAgICAgICAgICAgIE5ldmVyIHRlbGwgbWUgdGhlIG9kZHMhICAgICAgICAgICAg ICAgICB8IGlwdjYgbWVzaCBuZXR3b3JrcyBbDQo+IF0gICBNaWNoYWVsIFJpY2hhcmRzb24sIFNh bmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyAgICAgICAgfCBuZXR3b3JrIGFyY2hpdGVjdCAgWw0KPiBd ICAgICBtY3JAc2FuZGVsbWFuLmNhICBodHRwOi8vd3d3LnNhbmRlbG1hbi5jYS8gICAgICAgIHwg ICBydWJ5IG9uIHJhaWxzICAgIFsNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IGhvbWVuZXQgbWFpbGluZyBsaXN0DQo+IGhvbWVuZXRAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ob21lbmV0DQo+ ICANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g aG9tZW5ldCBtYWlsaW5nIGxpc3QNCj4gaG9tZW5ldEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hvbWVuZXQNCg0K From nobody Fri Aug 11 07:34:22 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DE41321C1 for ; Fri, 11 Aug 2017 07:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NQv9gp4oWuBH for ; Fri, 11 Aug 2017 07:34:17 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 BBA4F1323D7 for ; Fri, 11 Aug 2017 07:34:16 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id t128so16966395lff.2 for ; Fri, 11 Aug 2017 07:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3zCKr7k1vTkI1VR2Ic1Xsl9GwClMctE7g0KcCgQH0BQ=; b=HdfO7zPhFr2V+cN5MCCP2XP9INGeJk9rBbUaRz9G3jF1BgT1LZLA3C0j0uhMokQS44 Bk9g+F37DEm0rqvTywYDzZDi8sltRwM76MYOAQhSMEgoYWd1L3Pe0/nxsUUkWwaIXdNx 0lRC0RPsS0BGMZnUEXNAbZrYAkvRs81UiG45l7EGrosAtuV4oYEU1H0QwNqOwYDsdQ/o BiXm1eddsHP91VpBY4Yvqji/UuxDv4HyYrM4vj7We0DvSHu6vXwzSNoTGeG6wQ8iGFHG F28VfG4pksGuk2UGSxv8q0ZX51dMLEZEnfQlSlgPNBo5yISPsgXA17yhbviKC2avqCJU dmiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3zCKr7k1vTkI1VR2Ic1Xsl9GwClMctE7g0KcCgQH0BQ=; b=TlgkHhnm58/FXmCgvfE21bs8KWNcKkwo2Z/tp0UgRRheDxEf1DAUyJ7aXx7FP2OB80 yBncKaBPctiC7PQ1HHOu3k5K/A//lSJG9GsZuOwjSQLCfj9CqSZ+0NBXO81AV/NtMgZw SlDPwtcGN8GqxTaaDc2jh6N7JQXRStUaJw3MZ7U0l4M157JzLRgKXi1Uxxw59wogj95F XR/mH0sYwn45VwgF59JBikyTDAiGTDY4T2SL4WQeOsqyOpqT+HTqOu6xz8xVwrYgnbN+ eiIn7+LfjbpPf+cnTv8QvA8sAVFqSz4geVH2VRIuena9R75euIsoH7IJv0HHazeRgYxp CTsw== X-Gm-Message-State: AHYfb5jCQ3cra5u7dXyNdE7cmO4vvMOqW8yAIupThCXLOgLvRvL+IurK bmQ2JqqCEwi2mkrpkYId2Bp8Jq9PFQ== X-Received: by 10.46.21.20 with SMTP id s20mr4784014ljd.147.1502462054198; Fri, 11 Aug 2017 07:34:14 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.97.18 with HTTP; Fri, 11 Aug 2017 07:34:13 -0700 (PDT) In-Reply-To: <74D41199-2318-4499-AE62-EE17DE60460E@jisc.ac.uk> References: <150124709279.25258.15094387920433065465.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DBE0147@GAALPA1MSGUSRBF.ITServices.sbc.com> <12743.1501435181@obiwan.sandelman.ca> <6265.1501464056@obiwan.sandelman.ca> <19178.1501510069@obiwan.sandelman.ca> <2D09D61DDFA73D4C884805CC7865E6114DBED1F8@GAALPA1MSGUSRBF.ITServices.sbc.com> <74D41199-2318-4499-AE62-EE17DE60460E@jisc.ac.uk> From: Daniel Migault Date: Fri, 11 Aug 2017 10:34:13 -0400 X-Google-Sender-Auth: GDh2hvzE9erVrQG08OXEYCQhiZA Message-ID: To: Tim Chown Cc: "STARK, BARBARA H" , "homenet@ietf.org" , Michael Richardson Content-Type: multipart/alternative; boundary="94eb2c1cc94607765205567b3519" Archived-At: Subject: Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued" X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 14:34:20 -0000 --94eb2c1cc94607765205567b3519 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 11, 2017 at 10:22 AM, Tim Chown wrote: > Hi, > > On the principle of the WG agreeing to work on the problems as itemised i= n > the current headings in the table of contents, I support adoption, i.e., > it=E2=80=99s something homenet should work on, but it=E2=80=99s quite pos= sible that the > draft when it moves to WGLC may look somewhat different. > > Someone mentioned that RFC7368 is not cited; it would be useful for this > draft to clarify where it is compliant, where it is not, and why. > I agree. We had multiple discussions for making choices and these should be clearly stated in the draft. If RFC7368 is not cited in the current version that is probably we referred to it so many time we forgot to put it. That will be addressed in the next version for sure. > Tim > > > On 9 Aug 2017, at 22:35, STARK, BARBARA H wrote: > > > > Thanks Daniel. And you=E2=80=99re not too late. The call ends this comi= ng > Friday. So if anyone else wants to chime in, please do. I=E2=80=99ll try = to create > a summary Thursday describing what I think I=E2=80=99ve heard so far. Tha= t should > give everyone a brief chance to tell me how badly I=E2=80=99ve misinterpr= eted their > statements before the call ends. > > Barbara > > > > From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Daniel > Migault > > Sent: Wednesday, August 09, 2017 2:37 PM > > To: Michael Richardson > > Cc: homenet@ietf.org > > Subject: Re: [homenet] The HOMENET WG has placed > draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued= " > > > > Hi, > > > > I apology for the late response (I was off for two weeks). I will updat= e > the draft by the end of the month integrating numerous feed backs we > received. > > > > As a co-author I am supporting the adoption of this document > architecture. I believe that given the current situation regarding homene= t > and naming, the simple but useful scope of the draft will help the WG to > move forward regarding naming and home network. I agree the document is n= ot > yet in a final version and feed back from the WG will be very helpful. Th= at > said I think, since last IETF, we have a pretty good view on where we are > going. > > > > Yours, > > Daniel > > > > > > > > > > > > On Mon, Jul 31, 2017 at 10:07 AM, Michael Richardson > wrote: > > Ted Lemon wrote: > > > to put the CFA on hold pending that update. There have been some > good > > > comments already, though; in particular, I think Juliusz' point > that it > > > would > > > be nice to actually try some of this in practice is good, and is > what > > > I'm > > > > We require interoperable implementations for Internet Standard, not to > adopt > > a document. Implementation reports would be good for WGLC, not here! > > We need to lower the bar here, not raise it. WGs can abandon documents > too. > > > > > That said, what I said in the working group is that we've been > spinning > > > our wheels on this for several years, and I wanted to know if the > scope > > > of this is reasonable and is what the working group wants to take > > > on. If it's not, > > > then I don't actually know how to proceed. > > > > I think that it's the right approach, and given the sort out of the MVD= P, > > I support adoption. > > > > -- > > ] Never tell me the odds! | ipv6 mesh > networks [ > > ] Michael Richardson, Sandelman Software Works | network > architect [ > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --94eb2c1cc94607765205567b3519 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 11, 2017 at 10:22 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
Hi,

On the principle of the WG agreeing to work on the problems as itemised in = the current headings in the table of contents, I support adoption, i.e., it= =E2=80=99s something homenet should work on, but it=E2=80=99s quite possibl= e that the draft when it moves to WGLC may look somewhat different.

Someone mentioned that RFC7368 is not cited; it would be useful for this dr= aft to clarify where it is compliant, where it is not, and why.
I agree. We had multiple discussions for making choices and the= se should be clearly stated in the draft. If RFC7368 is not cited in the cu= rrent version that is probably we referred to it so many time we forgot to = put it. That will be addressed in the next version for sure.=C2=A0=C2=A0
=C2=A0
Tim

> On 9 Aug 2017, at 22:35, STARK, BARBARA H <bs7652@att.com> wrote:
>
> Thanks Daniel. And you=E2=80=99re not too late. The call ends this com= ing Friday. So if anyone else wants to chime in, please do. I=E2=80=99ll tr= y to create a summary Thursday describing what I think I=E2=80=99ve heard s= o far. That should give everyone a brief chance to tell me how badly I=E2= =80=99ve misinterpreted their statements before the call ends.
> Barbara
>
> From: homenet [mailto:home= net-bounces@ietf.org] On Behalf Of Daniel Migault
> Sent: Wednesday, August 09, 2017 2:37 PM
> To: Michael Richardson <mcr@san= delman.ca>
> Cc: homenet@ietf.org
> Subject: Re: [homenet] The HOMENET WG has placed draft-tldm-simple-hom= enet-naming in state "Call For Adoption By WG Issued"
>
> Hi,
>
> I apology for the late response (I was off for two weeks). I will upda= te the draft by the end of the month integrating numerous feed backs we rec= eived.
>
> As a co-author I am supporting the adoption of this document architect= ure. I believe that given the current situation regarding homenet and namin= g, the simple but useful scope of the draft will help the WG to move forwar= d regarding naming and home network. I agree the document is not yet in a f= inal version and feed back from the WG will be very helpful. That said I th= ink, since last IETF, we have a pretty good view on where we are going.
>
> Yours,
> Daniel
>
>
>
>
>
> On Mon, Jul 31, 2017 at 10:07 AM, Michael Richardson <mcr@sandelman.ca> wrote:
> Ted Lemon <mellon@fugue.com= > wrote:
>=C2=A0 =C2=A0 =C2=A0> to put the CFA on hold pending that update. Th= ere have been some good
>=C2=A0 =C2=A0 =C2=A0> comments already, though; in particular, I thi= nk Juliusz' point that it
>=C2=A0 =C2=A0 =C2=A0> would
>=C2=A0 =C2=A0 =C2=A0> be nice to actually try some of this in practi= ce is good, and is what
>=C2=A0 =C2=A0 =C2=A0> I'm
>
> We require interoperable implementations for Internet Standard, not to= adopt
> a document.=C2=A0 Implementation reports would be good for WGLC, not h= ere!
> We need to lower the bar here, not raise it.=C2=A0 WGs can abandon doc= uments too.
>
>=C2=A0 =C2=A0 =C2=A0> That said, what I said in the working group is= that we've been spinning
>=C2=A0 =C2=A0 =C2=A0> our wheels on this for several years, and I wa= nted to know if the scope
>=C2=A0 =C2=A0 =C2=A0> of this is reasonable and is what the working = group wants to take
>=C2=A0 =C2=A0 =C2=A0> on. If it's not,
>=C2=A0 =C2=A0 =C2=A0> then I don't actually know how to proceed.=
>
> I think that it's the right approach, and given the sort out of th= e MVDP,
> I support adoption.
>
> --
> ]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me = the odds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ip= v6 mesh networks [
> ]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2= =A0 =C2=A0 =C2=A0 | network architect=C2=A0 [
> ]=C2=A0 =C2=A0 =C2=A0mcr@sandelman= .ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet=
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet=

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet<= br>

--94eb2c1cc94607765205567b3519-- From nobody Fri Aug 11 07:44:22 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092BF132197 for ; Fri, 11 Aug 2017 07:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 x4BXVRbX_2z0 for ; Fri, 11 Aug 2017 07:44:19 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 07F4913219C for ; Fri, 11 Aug 2017 07:44:19 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id v29so22156330qtv.3 for ; Fri, 11 Aug 2017 07:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FMnITUpWm+nPXjMSZy6zQgYVicOk0Oiq8XU4/FN6p84=; b=knBnox0JP57szm1C4p0GEaYIR/1t3W3kNhLT4WoKvIuy3seABDFsNCJiX9uWtZizeM SEUfKi39arVNw8m+JgL86jSTtrT503iFwGumBFdnIV1T5aBiY2jqay7xRo1Zxa1OtOXS 7ebFTumB/4QHNC3ADer0k8/zEjdPWTgdzjJfZITvXS5YvfdYpUziV0CjdO9EP50d5msW PZm5Uq+9TXqHrCb6WL+0h3mOjlqdfsPaYX0wQ6yggKrG4WIKNrOaKPZKYoQRCocWYul5 lYKfn6ZiTOhwpN3jPVJuFG//dSDVr5mW5yhTWzAfQ3rfeRqKkBo75NY+URyFZ84LDcGU 8a1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FMnITUpWm+nPXjMSZy6zQgYVicOk0Oiq8XU4/FN6p84=; b=FCL6YvRNAFv9oXBFoz0uR+WUVOWv2PxphaEcWwtDbEmn5Yx4+iEor+ByMaLP92N6q/ xEfGldkV9gSYxaho5k2Td91lEtB1OLqV9lySy2UD30j4t0TNpm2p5ku1HaaU6SMk7WmL kij024ihJrPBeFB2hDb7V0W5PE3/Zu2kU1ffVOHXxXouTbwwUp5FtCQnblrBa0NCOOHb y1g8ypjCNkMy1ww0H7z4R3M1+cH49d8yRWR5SfwqUmQ5JBWfLOJuhzYuZkrYGaBKwaFr oD987H6gmv4dI17eymAV7kTVJj80Sr87yVNVejMpZm4epttP+Jg3XeXx8enJ5mpKVudP Tzlw== X-Gm-Message-State: AHYfb5hWegETAjPbBs3v08iZrwoRHNRWbi8rigDUJNvMClOP4/MC31yB 12kUxL9yWgb8C9tX X-Received: by 10.237.33.68 with SMTP id 62mr21955806qtc.65.1502462658161; Fri, 11 Aug 2017 07:44:18 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id a48sm666478qtb.59.2017.08.11.07.44.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 07:44:17 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_60939BE9-441B-4A2E-88FC-9B460396A5A1" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 11 Aug 2017 10:44:15 -0400 In-Reply-To: <877eyagrq1.wl-jch@irif.fr> Cc: HOMENET , Markus Stenberg To: Juliusz Chroboczek References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <296D97E1-29AA-4D25-A559-BF9D4F7D2023@iki.fi> <0F31651E-77F1-433F-831D-424B21D6CDA4@fugue.com> <87bmnmgtux.wl-jch@irif.fr> <877eyagrq1.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 14:44:21 -0000 --Apple-Mail=_60939BE9-441B-4A2E-88FC-9B460396A5A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 11, 2017, at 9:27 AM, Juliusz Chroboczek wrote: > Can we please agree that this document has no business mandating = round-robining? The point of the text on round-robining is to avoid a situation where = one provider's answers wind up being preferred over another provider's = because of a difference in the number of recursive resolvers they offer. = I wrote it the way I did because the mental model for how to do it = that sprang into my mind when I was writing it was the round robin = model. I don't have a strong preference for that model, although I think in = practice it works, particularly if you take a happy eyeballs approach to = it rather than timing out before switching. That is, you don't ask all = resolvers at _exactly_ the same time: you ask one first, and give it = enough time that if it's operating in spec, you will get an answer = before you ask the next one, but you ask the next one long before the = query to the first one has timed out. The bottom line is that this is an implementation detail, and I think = you are right that it should not be specified the way it currently is. --Apple-Mail=_60939BE9-441B-4A2E-88FC-9B460396A5A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 11, 2017, at 9:27 AM, Juliusz Chroboczek <jch@irif.fr> = wrote:
Can we please agree = that this document has no business mandating round-robining?

The = point of the text on round-robining is to avoid a situation where one = provider's answers wind up being preferred over another provider's = because of a difference in the number of recursive resolvers they offer. =   I wrote it the way I did because the mental model for how to do = it that sprang into my mind when I was writing it was the round robin = model.

I don't = have a strong preference for that model, although I think in practice it = works, particularly if you take a happy eyeballs approach to it rather = than timing out before switching.   That is, you don't ask all = resolvers at _exactly_ the same time: you ask one first, and give it = enough time that if it's operating in spec, you will get an answer = before you ask the next one, but you ask the next one long before the = query to the first one has timed out.

The bottom line is that this is an = implementation detail, and I think you are right that it should not be = specified the way it currently is.

= --Apple-Mail=_60939BE9-441B-4A2E-88FC-9B460396A5A1-- From nobody Fri Aug 11 09:07:33 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16495132192 for ; Fri, 11 Aug 2017 09:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 9WLKVyyGGo11 for ; Fri, 11 Aug 2017 09:07:29 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE2213201A for ; Fri, 11 Aug 2017 09:07:28 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id v7BG7QpQ030813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Aug 2017 18:07:26 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id v7BG7LVp028850; Fri, 11 Aug 2017 18:07:26 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A6FA1EB343; Fri, 11 Aug 2017 18:07:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id PHuWPyMKKeae; Fri, 11 Aug 2017 18:07:20 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id CD2D5EB345; Fri, 11 Aug 2017 18:07:18 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1dgCSz-0007Tm-Nd; Fri, 11 Aug 2017 18:07:17 +0200 Date: Fri, 11 Aug 2017 18:07:17 +0200 Message-ID: <7ivalujdfu.wl-jch@irif.fr> From: Juliusz Chroboczek To: Ted Lemon Cc: HOMENET In-Reply-To: <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 11 Aug 2017 18:07:26 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 11 Aug 2017 18:07:26 +0200 (CEST) X-Miltered: at korolev with ID 598DD63E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 598DD639.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 598DD63E.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 598DD639.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 598DD63E.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 598DD639.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 16:07:32 -0000 > This is a refrain I've heard from you, Juliusz and Markus, which I actually > find a bit disturbing: the desire not to really solve the problem because it's > not trivially easy. If I were in a bad mood, I'd say that the three of us prefer simple, robust solutions that solve actual problems to complex, brittle hacks that are not going to be implemented anyway. > Think about the routing problem. We need source-specific routes. We're > extending babel to add them. Why is that? Couldn't we have just relied > on happy eyeballs to eliminate the bad routes? No, we couldn't. Happy eyeballs (or MP-TCP, or MP-QUIC, or MP-Mosh) uses the services provided by source-specific routing. They work in combination. (Come on, Ted. You already knew that.) > Are you targeting a cheaper, less capable device than this? If so, can > you talk about why you think that's important for Homenet? This has nothing to do with the amount of flash or RAM. It has everything to do with having protocols that can be implemented in finite time and with a only a finite number of bugs, and with building networks that can survive whatever bugs remain. -- Juliusz From nobody Fri Aug 11 09:35:16 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45715132676 for ; Fri, 11 Aug 2017 09:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 hAkWRKEeBvMc for ; Fri, 11 Aug 2017 09:35:12 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 0317213266D for ; Fri, 11 Aug 2017 09:35:11 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id x191so23086948qka.5 for ; Fri, 11 Aug 2017 09:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jdMMgmLUxac8dbRCyrqhct+oWUK/0ChM6GXu5OCIDr0=; b=hQEVIM8qgggDKuBjgeMgwcFZOSCGYYQHwqfeRV1t4/GZSdlYNhHOQteGTocg+bTeOr gpMeK9BiMz/RA5A8vKzhGf4m8SqZFrl7/XJGuhjQCy76hixMj4M15gyJTnfTvFM0za8H zGwpZ9OMe3w1ROsMp10UDyMfAXS9tCZTZ8xWnNg7V2gEUwSasXSiV1F1CpHyFlkJwiWp V//zfu02u2xofUgRzo5/yf7DotS1WX/QD1x0aBpBF7N07gGQD4BDIS9QRsrldrVRoTKe 7HSOXXm3jtd21Ca8WCGJ3KhISMFKu5GjzHSjpaCukbJsiFCI2Rd3bFBRZgjB2lobWFal EJnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jdMMgmLUxac8dbRCyrqhct+oWUK/0ChM6GXu5OCIDr0=; b=AeEuU8X6gii3l5+OcoF3c/GSNrOA9EcxN3x8WKWmbgCVT34o5r7j3VBdpmURkVu7ud EdR3RDwhkvmIFQ+RA1myb2QHkjVY1apKAIi2ERR9pQAvDM+ncEqlvJYREcUXfd5PvWfx aCVM6LKCQyuWpaeYpPKxaYyuLlZYJ60s33XdyKz0Y1Ur2h1S0JLMdq8tArNb7rbR/xnl R5a0ydUPRsgAdA/zwzuBNfLNLWg74ASqymH8LXAVcHHrEiL1UsPoqDSDEIHVur60H0hv bNDLi/UPxESl5O+Q8QRUj3fAPrq/X1PNgHcDWzB/EMr5jkqok2Q1HYPv1nYxmxNITqTB /fQA== X-Gm-Message-State: AHYfb5h1LA61LorwIkpvOGF+oAY65j0Jv4I0WnjB2988L8EofWYHdsXN ZxwouX8W1S9bMx8n X-Received: by 10.55.103.146 with SMTP id b140mr19627735qkc.329.1502469311024; Fri, 11 Aug 2017 09:35:11 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id v55sm780768qtc.90.2017.08.11.09.35.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 09:35:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <7ivalujdfu.wl-jch@irif.fr> Date: Fri, 11 Aug 2017 12:35:09 -0400 Cc: HOMENET Content-Transfer-Encoding: quoted-printable Message-Id: <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 16:35:14 -0000 On Aug 11, 2017, at 12:07 PM, Juliusz Chroboczek wrote: >> This is a refrain I've heard from you, Juliusz and Markus, which I = actually >> find a bit disturbing: the desire not to really solve the problem = because it's >> not trivially easy. >=20 > If I were in a bad mood, I'd say that the three of us prefer simple, = robust > solutions that solve actual problems to complex, brittle hacks that = are > not going to be implemented anyway. Forgive me, Juliusz, but I don't lecture you on routing protocols, do I? = You are objecting to something that you don't see the need for, but = the reason you don't see the need for it is not that there isn't a need = for it. It's that you haven't clearly understood the problem. Now, = you could certainly point the finger of blame at me for failing to = explain it adequately, but I would appreciate it if you could do me the = courtesy of not assuming that I am just trying to come up with a = "complex, brittle hack that's not going to be implemented anyway" for my = own amusement. >> Think about the routing problem. We need source-specific routes. = We're >> extending babel to add them. Why is that? Couldn't we have just = relied >> on happy eyeballs to eliminate the bad routes? >=20 > No, we couldn't. Happy eyeballs (or MP-TCP, or MP-QUIC, or MP-Mosh) = uses > the services provided by source-specific routing. They work in = combination. >=20 > (Come on, Ted. You already knew that.) Yes, I did, and that was precisely my point. We need source-specific = routing because happy eyeballs doesn't solve the problem: we want to = support multi-homing, and that requires a more complex solution than = would be needed if we could mandate that homenets have only a single = connection to the internet. Mandating that homenets only have one = Internet link would make the solution substantially less complex. Source-specific routing, however, is an incomplete solution. Having = chosen the correct route based on the source address, we still have the = problem that one provider connection may be better than another for = connecting to a particular destination, and there may be no way to = figure that out using the default source address selection algorithm, or = even by using a more detailed source address selection algorithm = configured by DHCP. Indeed, this is likely, not unlikely. > This has nothing to do with the amount of flash or RAM. It has = everything > to do with having protocols that can be implemented in finite time and > with a only a finite number of bugs, and with building networks that = can > survive whatever bugs remain. I agree that we should not propose solutions that can only be = implemented in an infinite amount of time. But we already have = implementations of MPvD support from several vendors. So it's not even = the case that the amount of time required to do this is long. It's = already mostly done for several important hosts, and one of those hosts = is a Linux host, so the solution that works there will also work on = regular Linux. Implementing this on the router is straightforward. I believe that it = could actually be done with no changes to dnsmasq, although a better = solution would make some changes, because doing so would make = configuring it easier. What I find completely perplexing about this conversation is that you, = Markus and Toke, all of whom I know to be smart people, think this is = hard. What is hard about it? I think the reason you think it's hard = is simply that you don't know how to do it. The unknown always seems = hard. That's something that we can fix by describing in the document = how to do it. If, after that, you still think it's hard, (a) I will be = very surprised, and (b) we can think about whether it's worth the = trouble. From nobody Fri Aug 11 09:42:38 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59491323AE for ; Fri, 11 Aug 2017 09:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham 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 5xKAupCOMTDt for ; Fri, 11 Aug 2017 09:42:35 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42CA9132125 for ; Fri, 11 Aug 2017 09:42:28 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v7BGZGn3021543 for ; Fri, 11 Aug 2017 12:42:25 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2c9d37qwb0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 11 Aug 2017 12:42:25 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7BGgOVt025176 for ; Fri, 11 Aug 2017 12:42:24 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7BGgJP8025140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Aug 2017 12:42:20 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi132.aldc.att.com (RSA Interceptor) for ; Fri, 11 Aug 2017 16:42:04 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.30]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0319.002; Fri, 11 Aug 2017 12:42:03 -0400 From: "STARK, BARBARA H" To: HOMENET Thread-Topic: homenet has adopted draft-tldm-simple-homenet-naming Thread-Index: AdMSv+YTjaxfBI5dS2Kjvl4e3PYq0w== Date: Fri, 11 Aug 2017 16:42:03 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBF952A@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.233.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-11_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708110263 Archived-At: Subject: [homenet] homenet has adopted draft-tldm-simple-homenet-naming X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 16:42:37 -0000 I have moved the doc to the adopted state. Ted/Daniel, you should be able t= o upload a WG revision as your next rev. Barbara From nobody Fri Aug 11 09:44:04 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9051321C9 for ; Fri, 11 Aug 2017 09:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 mUyQhvvU1nhI for ; Fri, 11 Aug 2017 09:44:01 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 9B539132334 for ; Fri, 11 Aug 2017 09:43:56 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id x191so23212289qka.5 for ; Fri, 11 Aug 2017 09:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ksSQTZIGbx9nOECHrXXv+V7SzOXGTkhYLjbh8iTHz10=; b=AqkBOf62gkH3O+dwsIqV4L8mqs1w9a9retC38hUWwaDMORzhTRQ8rb5z/EfhrMQHz0 WIWQj9HDpLsRClG+OYZQKZlQwOrRNvbX2r0pn+5tz/uPKWQOMrXGyC5raTCUXBrBueOb ydKwSRUPYeEy/8l6pwiM+hAaBgDo6R+ZymbeJPl20/Cuwh/PGZlBErdUHgclzYAlJcZE sXhc2Fnq41Av74ZKeAPTmdNHuWSNpBNwwO67T+eu0ywd592c7D3RfxdZ/2zOzBKF427W 68mZrS1dSZvHNf7y1Ln1VvbS5AGGEq+vNLTsveCgHCgIJ1/OswJ02IhJvikjk1nIpwR8 UfyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ksSQTZIGbx9nOECHrXXv+V7SzOXGTkhYLjbh8iTHz10=; b=Cy1C1YVhLf3x5mx7AmzrHHKiAYKPkK/Wwr2iXCkEnz1SjxlqSF3l1bohTQgNbNGVl1 0vvkhy87Ec0iHNfHKRltlnbz88Pj04dQ7KIwInofiLDK2D9UP/gL9PK91SQGuiAINC0A QJuh7grTo3igxVT+g1t5ryUkMLPZEH7F8mksx5Vn8OtzvMmd/BibUnA0ybN/bKo3RvN2 xNRSpCZhzhd8hPncczrcF4FLboYfYcl4eUu4ZzLtOzKS1F7jfO2gM1kJP9SCoqCaidcO SpAVilExgw8YHuJ4fLDuzeETlbbJJc3j6ij34iwplbWuGim654RspYguqG/6xtPrV+rk w1FA== X-Gm-Message-State: AHYfb5i/9Thoyz0n3C2/SmzDU2wh5PxiryJBjVxwptLvS87tXZBYKx5T IK5qOGTtuzEt1XFu1Mx2jA== X-Received: by 10.55.139.4 with SMTP id n4mr21523102qkd.100.1502469835818; Fri, 11 Aug 2017 09:43:55 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id x6sm834489qkg.32.2017.08.11.09.43.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 09:43:55 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5D1EA4DD-5DBD-44EA-ADE8-D53350C97EFC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 11 Aug 2017 12:43:54 -0400 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBF952A@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: HOMENET To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E6114DBF952A@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] homenet has adopted draft-tldm-simple-homenet-naming X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 16:44:03 -0000 --Apple-Mail=_5D1EA4DD-5DBD-44EA-ADE8-D53350C97EFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 11, 2017, at 12:42 PM, STARK, BARBARA H wrote: > I have moved the doc to the adopted state. Ted/Daniel, you should be = able to upload a WG revision as your next rev. Great, thanks! --Apple-Mail=_5D1EA4DD-5DBD-44EA-ADE8-D53350C97EFC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 11, 2017, at 12:42 PM, STARK, BARBARA H <bs7652@att.com> = wrote:
I have moved the = doc to the adopted state. Ted/Daniel, you should be able to upload a WG = revision as your next rev.

Great, = thanks!

= --Apple-Mail=_5D1EA4DD-5DBD-44EA-ADE8-D53350C97EFC-- From nobody Fri Aug 11 09:53:42 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6384A1321A4 for ; Fri, 11 Aug 2017 09:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 Lhk0m1AsOQxl for ; Fri, 11 Aug 2017 09:53:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46551321D9 for ; Fri, 11 Aug 2017 09:53:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 01272203B1 for ; Fri, 11 Aug 2017 12:56:00 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A8324806BA for ; Fri, 11 Aug 2017 12:53:37 -0400 (EDT) From: Michael Richardson To: HOMENET In-Reply-To: <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 16:53:40 -0000 --=-=-= Content-Type: text/plain Ted Lemon wrote: > Source-specific routing, however, is an incomplete solution. Having > chosen the correct route based on the source address, we still have the > problem that one provider connection may be better than another for > connecting to a particular destination, and there may be no way to > figure that out using the default source address selection algorithm, > or even by using a more detailed source address selection algorithm > configured by DHCP. Indeed, this is likely, not unlikely. My problem with the MPVD solution is that it seems incomplete too. The example that, in contrast to all other content, is when content is zero-rated via 3G but not via WIFI. (generalized to any two uplinks) I don't know the source address selection or source routing can deal with that problem period. It seems to me that we are re-inventing SHIM6, trying in vain to pretend we never heard of that. And I still don't understand why it was killed. But, again, I want to adopt the document so that we can argue about this as part of our charter work. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmN4REACgkQgItw+93Q 3WUmIQf/Rs/gE2osD49M/fr7xV6m3fpeRbhaDJsTOiO4xkrROSuHPpcwp7hVCEkI iReorz9gnnAdvkZcSwieH3om7znQQzScjzQE8rka/ljj4kFnERW73BPf6D23MQ/g MT/w162e2Andg8FyHQNxLvIc5hZa0dGB6vIjURozPqqvUQRDAvNLPY0QKBcqFf3B rNIfPrjh02co5DP71SIfg1rZA28m2fvHDO6rJESdR5Is1lLryHVbq+dqk9kpEffR +AbbEL7NZTjTsKcjAyi/oKvAELJ/Xaeh1C4Uqy7T0TB3zsVlEjkWuxt7JXIrS2tX vgQJ7FMgjyGSXf3pZEtzonghWf+aDA== =jQE6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 11 10:10:29 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D029C13252D for ; Fri, 11 Aug 2017 10:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 EBux7SDn_tln for ; Fri, 11 Aug 2017 10:10:25 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 954571324EE for ; Fri, 11 Aug 2017 10:10:25 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id u139so23682132qka.1 for ; Fri, 11 Aug 2017 10:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=G//IcoR9c/jUy0J+HCs1GNUY8h+OYxl1/ijEBfVNSOA=; b=gv4TtW5TfBeV8Ld+iFKLtSUcEe3uMRKv1H5a+c+8kbdCVOrRyGnFNEltsSUnb2/SUI 6J3dJOyQFDZV3nd7QlBt+17hF1huodlJlYYuuWf6YsPVGae3K3WS+wxRWuTxclwO+XlS t+qWO+lJxseWF6aHjNqZrTnTXP++MxPWGBxC+m7M/zEqaT8BPRo14YDGTSbQ3SMbNKvi HyN8p+GFB1ngg1m0K5xQyUgM1hil4b3e0N//ZmehEwN5N/39NWAkp7/O8wpbX2871qkj zF4K/XDGKhNTNa80rdl++PI5pQhrewyMF1vWussAwo1TrTQeaDsUIZtejJXLlOAMQmOy DHdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=G//IcoR9c/jUy0J+HCs1GNUY8h+OYxl1/ijEBfVNSOA=; b=FLLlVIOdnfohr8PLgGFl66Z9Vak/PxYMYkKWYTgHPUyeeDG2QKFzlAjjPT583HHAJa FX3sS+bF3a1eBIZtlEMAy2PseRfz2STz3TZ3pbBSl2ss4312Lt2c5g09OazyLkT6hKVs TzqzXUn+D9Z2X92epIgmC79PVBu9g/9ZXeoOaWnwp0jn9kYYixGJVz9NERT/31rensnl GM5suUywyLE07guj49Mma573pIdI2KRz65W4WloIwOpcXAd3vrS3f1RjrV78AaHoTHR2 fR1PGLeeTuWf3ZLk813u3Nj8NIQnXT89aIfojcHmAiVj0dtvWU+P/VjuV9a8cTHxEIBd NsUA== X-Gm-Message-State: AHYfb5hjcLRS2JVf0Ewac7tcZ1W+lQx1fyOIFLFtvtaCKoaAnMX4tlni /87FSm6swaJvLB+edceesA== X-Received: by 10.55.43.78 with SMTP id r75mr19662100qkh.358.1502471424428; Fri, 11 Aug 2017 10:10:24 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id s11sm881299qtj.54.2017.08.11.10.10.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 10:10:23 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C8DDF18E-DD24-4A4C-AD3B-2FC0C8C7E929" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 11 Aug 2017 13:10:22 -0400 In-Reply-To: <22112.1502470417@obiwan.sandelman.ca> Cc: HOMENET To: Michael Richardson References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <22112.1502470417@obiwan.sandelman.ca> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 17:10:28 -0000 --Apple-Mail=_C8DDF18E-DD24-4A4C-AD3B-2FC0C8C7E929 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 11, 2017, at 12:53 PM, Michael Richardson = wrote: > The example that, in contrast to all other content, is when content is > zero-rated via 3G but not via WIFI. (generalized to any two uplinks) > I don't know the source address selection or source routing can deal = with > that problem period. Two points here. First of all, does the IETF want to support = zero-rating on a technological level? I guess we're somewhat agnostic = about it, but I would be resistant to spending cycles on it unless = somebody is really energized about it. It seems to me that if you have = zero-rating, you have a problem. That said, I certainly agree with you that MPvD doesn't solve this = problem. The general attitude with MPvD is that when you have multiple = provisioning domains, it's not necessarily the case that you can believe = the claims that one provider or the other makes. If you want to = zero-rate, the person who's going to be paying for it when the = zero-rating doesn't happen is going to be responsible for making sure = that it's configured correctly. If the person who makes the money is = responsible for configuring it, they are going to configure it in a way = that serves their interests, not the user's interests. What MPvD _does_ do in addressing this problem is that it provides a = context in which special-casing for zero-rating can be effectively = configured. Without MPvD or something like it, it's actually = impossible to support zero-rating, even if you think that's a desirable = thing to do. If we were to support zero-rating, the way I would propose that we do it = is to specify a way that a provider can advertise the availability of = zero-rating for some set of products, and the user can choose to accept = or not accept that advertising in a convenient way, rather than having = to manually configure a whitelist. But don't get me started on the = opportunities for trouble that this idea presents. > It seems to me that we are re-inventing SHIM6, trying in vain to = pretend we > never heard of that. And I still don't understand why it was killed. Shim6 attempts to solve a much larger problem, and in a rather = heavyweight and top-down way. --Apple-Mail=_C8DDF18E-DD24-4A4C-AD3B-2FC0C8C7E929 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 11, 2017, at 12:53 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
The example that, in contrast to all other content, is when = content is
zero-rated via 3G but not via WIFI. (generalized to any two = uplinks)
I don't know the source = address selection or source routing can deal with
that problem = period.
Two = points here.   First of all, does the IETF want to support = zero-rating on a technological level?   I guess we're somewhat = agnostic about it, but I would be resistant to spending cycles on it = unless somebody is really energized about it.   It seems to me that = if you have zero-rating, you have a problem.

That said, I certainly agree with you = that MPvD doesn't solve this problem.   The general attitude with = MPvD is that when you have multiple provisioning domains, it's not = necessarily the case that you can believe the claims that one provider = or the other makes.   If you want to zero-rate, the person who's = going to be paying for it when the zero-rating doesn't happen is going = to be responsible for making sure that it's configured correctly.   = If the person who makes the money is responsible for configuring it, = they are going to configure it in a way that serves their interests, not = the user's interests.

What MPvD _does_ do in addressing this problem is that it = provides a context in which special-casing for zero-rating can be = effectively configured.   Without MPvD or something like it, it's = actually impossible to support zero-rating, even if you think that's a = desirable thing to do.

If we were to support zero-rating, the way I would propose = that we do it is to specify a way that a provider can advertise the = availability of zero-rating for some set of products, and the user can = choose to accept or not accept that advertising in a convenient way, = rather than having to manually configure a whitelist.   But don't = get me started on the opportunities for trouble that this idea = presents.

It seems to me that we are re-inventing = SHIM6, trying in vain to pretend we
never heard of = that.  And I still don't understand why it was killed.

Shim6 = attempts to solve a much larger problem, and in a rather heavyweight and = top-down way.


= --Apple-Mail=_C8DDF18E-DD24-4A4C-AD3B-2FC0C8C7E929-- From nobody Fri Aug 11 10:47:20 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234CE132197 for ; Fri, 11 Aug 2017 10:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.311 X-Spam-Level: X-Spam-Status: No, score=-5.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 8sIr007RPj8F for ; Fri, 11 Aug 2017 10:47:16 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0481E124217 for ; Fri, 11 Aug 2017 10:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1502473633; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=a+645ZRDZuaD3ax1EaYtd8FmYtW7/sSBW/w9o2fNOnA=; b=PAsI/fZRp6wObbwIJ70WMoGo5UTg+tAB2AWvq+TzboQ8u2tDpF9bg6G6f7a2i6rFFsEzKIv3pWEdj9W9XnwCMHV1U9Bq3CNgP8ruyo6WzuHbJYlzxrmXMLeEj+lBxyMinl9ob5z6kpR1cfgHSKIBQte1EM2FPUf7aRuAyxLXVSQ= Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0179.outbound.protection.outlook.com [213.199.180.179]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-124-O5YTC0t-ORefbzSGxkj5kw-1; Fri, 11 Aug 2017 18:47:05 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB260.eurprd07.prod.outlook.com (10.242.17.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Fri, 11 Aug 2017 17:47:04 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9447:453:3e6d:c99a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9447:453:3e6d:c99a%13]) with mapi id 15.01.1341.013; Fri, 11 Aug 2017 17:47:03 +0000 From: Tim Chown To: Michael Richardson CC: HOMENET Thread-Topic: [homenet] Status of draft-tldm-simple-homenet-naming CFA Thread-Index: AdMSExv6TskYwTm0TxW2ixuYvce/UAABYv2AAAEAJwAAAIq7gAABkeIAAAURmAAAFFmYgAAFRvGAAABSQYAAAEA5AAAAPA2AAADeVIAABVQNgAAA+SaAAAClG4AAAd2VAA== Date: Fri, 11 Aug 2017 17:47:03 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <22112.1502470417@obiwan.sandelman.ca> In-Reply-To: <22112.1502470417@obiwan.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [212.188.254.49] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB260; 20:M21ZyyE5bwB8K0cL9fBhOoSFF0AP+1ZbUArL3WJG1EfgFb+yzxFBS9jV//MVNnAyBSWNTV1Eue/HLHZdOr7NZpFfN2B6pSD1DtbRoThYSMuDRr2l/aj5+Q0z9HaXO2VBRb8OcB9jpWYQL7PWmsQOwM8uwJ3dm3yGj9uXHOfnMDM= x-ms-office365-filtering-correlation-id: 40bbd731-096c-4037-85fd-08d4e0e0fa16 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603124)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB260; x-ms-traffictypediagnostic: AM3PR07MB260: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB260; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB260; x-forefront-prvs: 03965EFC76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(24454002)(189002)(8936002)(50986999)(2900100001)(229853002)(53546010)(2950100002)(101416001)(82746002)(6506006)(230783001)(57306001)(81156014)(6436002)(305945005)(14454004)(81166006)(76176999)(74482002)(66066001)(8676002)(33656002)(6486002)(42882006)(93886004)(72206003)(7736002)(6512007)(3660700001)(102836003)(106356001)(105586002)(3846002)(99286003)(53936002)(36756003)(6246003)(4326008)(83716003)(86362001)(6116002)(189998001)(68736007)(97736004)(50226002)(110136004)(478600001)(3280700002)(5660300001)(5250100002)(2906002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB260; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <6AD526A21A5CDA4A9B27ED8E410616B8@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2017 17:47:03.8690 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB260 X-MC-Unique: O5YTC0t-ORefbzSGxkj5kw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 17:47:19 -0000 > On 11 Aug 2017, at 17:53, Michael Richardson wrot= e: >=20 > Ted Lemon wrote: >> Source-specific routing, however, is an incomplete solution. Having >> chosen the correct route based on the source address, we still have the >> problem that one provider connection may be better than another for >> connecting to a particular destination, and there may be no way to >> figure that out using the default source address selection algorithm, >> or even by using a more detailed source address selection algorithm >> configured by DHCP. Indeed, this is likely, not unlikely. >=20 > My problem with the MPVD solution is that it seems incomplete too. >=20 > The example that, in contrast to all other content, is when content is > zero-rated via 3G but not via WIFI. (generalized to any two uplinks) > I don't know the source address selection or source routing can deal with > that problem period. >=20 > It seems to me that we are re-inventing SHIM6, trying in vain to pretend = we > never heard of that. And I still don't understand why it was killed. Extension headers. > But, again, I want to adopt the document so that we can argue about this > as part of our charter work. Indeed!=20 Tim From nobody Sat Aug 12 10:45:17 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361C0132481 for ; Sat, 12 Aug 2017 10:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 UR3CVZXfaJFi for ; Sat, 12 Aug 2017 10:45:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F287D132496 for ; Sat, 12 Aug 2017 10:45:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 14F9CE21D; Sat, 12 Aug 2017 13:47:39 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 40C63806BA; Sat, 12 Aug 2017 13:45:13 -0400 (EDT) From: Michael Richardson To: Ted Lemon cc: HOMENET In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <22112.1502470417@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 17:45:16 -0000 --=-=-= Content-Type: text/plain Ted Lemon wrote: > On Aug 11, 2017, at 12:53 PM, Michael Richardson > wrote: mcr> The example that, in contrast to all other content, is when content mcr> is zero-rated via 3G but not via WIFI. (generalized to any two mcr> uplinks) I don't know the source address selection or source routing mcr> can deal with that problem period. > Two points here. First of all, does the IETF want to support zero-rating on a > technological level? I guess we're somewhat agnostic about it, but I would be > resistant to spending cycles on it unless somebody is really energized about > it. It seems to me that if you have zero-rating, you have a problem. In one of the original homenet architecture usage scenarios we have IPTV being provided over a seperate DSL connection over IPv6, but which did not provide general IPv6 connectivity. This was from Japan, I believe. That's actually an easier situation, since the connection won't work at all if an application uses the wrong source address. I suggested in: https://datatracker.ietf.org/doc/draft-richardson-homenet-secret-gardens/ which I wrote hurriedly when I understand what MIF was doing (but really it was too late). I feel that a lot of MIF's problem statement was tied up with existing operators apply IPv4 think to IPv6. > That said, I certainly agree with you that MPvD doesn't solve this problem. > The general attitude with MPvD is that when you have multiple provisioning > domains, it's not necessarily the case that you can believe the claims that > one provider or the other makes. If you want to zero-rate, the person who's > going to be paying for it when the zero-rating doesn't happen is going to be > responsible for making sure that it's configured correctly. If the person who > makes the money is responsible for configuring it, they are going to > configure it in a way that serves their interests, not the user's > interests. In the debate in Canada over this (where N=Bell Canada, who owns CTV), two things seem to occur: a) if one is a customer of ISP N, then you use XYZ app on your phone, you get access to content Q. It's free because your relationship with N. If you are N's network, then usage fees that would normally occur are waved. If you are not on N's 3G network, but on WIFI (or some other provider), your credentials get you access, but you might pay via that other path. The MPvD required to happen can happen in the XYZ app, and actually the entire ecosystem is a walled garden. b) as a bonus for having play PQRT, when on ISP's N's network, then your traffic to third party B is free. (Typical example is Spotify) You can use *ANY* app you like to access the content. > What MPvD _does_ do in addressing this problem is that it provides a context > in which special-casing for zero-rating can be effectively configured. > Without MPvD or something like it, it's actually impossible to support > zero-rating, even if you think that's a desirable thing to do. I agree that it may be required. I am suggesting that it's not sufficient on it's own. You can only get situation (a) above, not situation (b). > If we were to support zero-rating, the way I would propose that we do it is > to specify a way that a provider can advertise the availability of > zero-rating for some set of products, and the user can choose to accept or > not accept that advertising in a convenient way, rather than having to > manually configure a whitelist. But don't get me started on the opportunities > for trouble that this idea presents. I agree. It seems like it ought to be a routing protocol at the edge, that the destinations involved should be advertised with longer prefixes, and with some kind of metric that implies the cost. The edge routers that hear this should be skeptical, but should provide the information to the user. (The CAPPORT protocol and API would be useful here!) mcr> It seems to me that we are re-inventing SHIM6, trying in vain to mcr> pretend wenever heard of that. And I still don't understand why it mcr> was killed. > Shim6 attempts to solve a much larger problem, and in a rather heavyweight > and top-down way. I view MPvD as being as being heavier weight, involving changes to more parts of the host stack, with poorer results. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEyBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmPPqgACgkQgItw+93Q 3WVcjAf475HZyKK2vGMoGLBEyUnaQX60HyZm7PubSxeb36CL0YDHEHZJd4MQ3D42 Hm1knuSP8hZyVNQfntBR28Z800qjzN6Rql8qyCZrX2HDiXIa9fC5ZgVwvBGV3Ss7 zxAJ/3bN6M0UBzekI/FRYw/V4UAq6SIQHmHQ8LFx5kpEwrm2bwTGKcTU2W1G1VBY U8wbyuO1toZa9RQt2nsU4Myo04nwJeKEmUGnjueyWZvjknZuoE9/+aMvTaDbn0n1 R0g3gYpBfeswwHP3usAMd/pGkn0Iks2qM5SFlN72VkW54cxzp9bYtHvlUDwedJp+ YE3Nvy8kSQaXhx0fRt9WPCFCzeBl =ibn7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 12 12:21:49 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801C5129B30 for ; Sat, 12 Aug 2017 12:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 XZDyy5LWAp_2 for ; Sat, 12 Aug 2017 12:21:45 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 0E8561270AC for ; Sat, 12 Aug 2017 12:21:44 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id x191so34833000qka.5 for ; Sat, 12 Aug 2017 12:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GO6LEEfl9EpCJZePC7SD1SCCZnNZR5w9N70qtqPHKzs=; b=k0JENWLhYUMp0vJalzrganv6hsE7z0HwvaBvpvW6L8IPwu0CRb/3WOPsnXHxj1cq8M kChZ0IkD/5jRzRoVpOFqYQs0ShUfhXqW6eLkj3qx9mfXBTaB7lP3Iw8YZgBi67jgog7/ bQ9XLI63WlF4HbP+8r/1RMMIJlOutXnx4kmPfmI4c6WgsZ+xya4XMvosfER3cb9qD/o1 qzlgqeLFQ6zNK6iqnkDB1RNB9fC76dfhsqVWXmpO3f7AoYpE/I17ip1noOmljbYwL5n5 UjjQIT/IJdSOO4eEdBIQ+1aTXDLFZZYVT06Zgy2M2kwJPh6O18g3AkgH8NbMmjhXIJIm s2rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GO6LEEfl9EpCJZePC7SD1SCCZnNZR5w9N70qtqPHKzs=; b=NsAFk6AgBv3Uk/lWTNsXwCbEGFcOjinmLb/wMvgqYlGvSvZsLsz+6TNasHyWIdXnwp vrlJnTO8/joT9ls4tCHNCmyFezVTk5IhjU1FKsOi73JfphOfKRzQV3vB9I0U3biYoYOm QW5rwsPIOO1pPySMX5IH/yyknp3aFz8jX2HTXaITA+aCz37rSlaepmoP1Ie7FRUu3fon 4uvASqYCDNiIOzH9T9KGdJOcDOikbdP5riQgeAVi0KRmJ0Z3rPlMudFzACKICIRjmOFl uGTiFsMdxlmrp6j0kvRXwoTLQNltl0jZOJzKPN2vTNeG0m5A/h+WyjIHCa3JD9422hpA XXcg== X-Gm-Message-State: AHYfb5iQXWK5HB6/NUfQsUqYDPozl9bsB737raSLJImivz22w95SFnuu 99XELhpfZSXFfBhv X-Received: by 10.55.164.150 with SMTP id n144mr25674404qke.260.1502565703979; Sat, 12 Aug 2017 12:21:43 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id k29sm2702778qtb.13.2017.08.12.12.21.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Aug 2017 12:21:42 -0700 (PDT) From: Ted Lemon Message-Id: <8CA906A5-133D-483D-B583-0644C13A634E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A020377B-60A7-43B7-A278-2078BD53CD75" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 12 Aug 2017 15:21:41 -0400 In-Reply-To: <7759.1502559913@obiwan.sandelman.ca> Cc: HOMENET To: Michael Richardson References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <22112.1502470417@obiwan.sandelman.ca> <7759.1502559913@obiwan.sandelman.ca> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 19:21:47 -0000 --Apple-Mail=_A020377B-60A7-43B7-A278-2078BD53CD75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 El 12 ag 2017, a les 13:45, Michael Richardson = va escriure: > I agree. It seems like it ought to be a routing protocol at the edge, = that > the destinations involved should be advertised with longer prefixes, = and with > some kind of metric that implies the cost. The edge routers that hear = this > should be skeptical, but should provide the information to the user. > (The CAPPORT protocol and API would be useful here!) The problem with this is that it is quite brittle=E2=80=94it depends on = everything working right. The routing has to be set up right. The = operator has to set the routing up right. The other operator has to = not deliberately or accidentally set the routing up wrong. The home = network has to successfully get the right routing information and use it = correctly. >=20 > mcr> It seems to me that we are re-inventing SHIM6, trying in vain = to > mcr> pretend wenever heard of that. And I still don't understand = why it > mcr> was killed. >=20 >> Shim6 attempts to solve a much larger problem, and in a rather = heavyweight >> and top-down way. >=20 > I view MPvD as being as being heavier weight, involving changes to = more parts > of the host stack, with poorer results. It might be worth actually writing down why you think that's so. It's = far from obvious to me that it is, but I am not as familiar as you are = with Shim6. Unfortunately as far as I know nobody ever presented = anything about Shim6 in MIF; if in fact what you are saying is true, a = lot of time and effort could have been saved if that had happened. --Apple-Mail=_A020377B-60A7-43B7-A278-2078BD53CD75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 El 12 ag 2017, a les 13:45, Michael Richardson <mcr+ietf@sandelman.ca> va escriure:
I agree.  It seems like it ought to = be a routing protocol at the edge, that
the destinations = involved should be advertised with longer prefixes, and with
some kind of metric that implies the cost. =  The edge routers that hear this
should be = skeptical, but should provide the information to the user.
(The CAPPORT protocol and API would be useful = here!)

The problem with this is that it is quite brittle=E2=80=94= it depends on everything working right.   The routing has to be set = up right.   The operator has to set the routing up right.   = The other operator has to not deliberately or accidentally set the = routing up wrong.   The home network has to successfully get the = right routing information and use it correctly.


   mcr> It seems to me that we = are re-inventing SHIM6, trying in vain to
   mcr> pretend wenever heard of that. And = I still don't understand why it
   mcr> was killed.

Shim6 attempts to solve a much larger problem, and in a = rather heavyweight
and top-down way.

I view MPvD as = being as being heavier weight, involving changes to more parts
of the host stack, with poorer = results.

It = might be worth actually writing down why you think that's so.   = It's far from obvious to me that it is, but I am not as familiar as you = are with Shim6.   Unfortunately as far as I know nobody ever = presented anything about Shim6 in MIF; if in fact what you are saying is = true, a lot of time and effort could have been saved if that had = happened.

= --Apple-Mail=_A020377B-60A7-43B7-A278-2078BD53CD75-- From nobody Sat Aug 12 17:09:30 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A8B1323A5 for ; Sat, 12 Aug 2017 17:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 2i6Wg7ahTPmU for ; Sat, 12 Aug 2017 17:09:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F000132395 for ; Sat, 12 Aug 2017 17:09:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A74102009E for ; Sat, 12 Aug 2017 20:11:52 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F415C806BA for ; Sat, 12 Aug 2017 20:09:25 -0400 (EDT) From: Michael Richardson To: HOMENET In-Reply-To: <8CA906A5-133D-483D-B583-0644C13A634E@fugue.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [homenet] use of MPvD in homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 00:09:29 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {new subject line, nuked References} Ted Lemon wrote: > The problem with this is that it is quite brittle=E2=80=94it depends = on everything > working right. The routing has to be set up right. The operator has t= o set > the routing up right. The other operator has to not deliberately or > accidentally set the routing up wrong. The home network has to succes= sfully > get the right routing information and use it correctly. This seems a bit like FUD: the Internet depends upon all sorts of "brittle"= things like "not deliberately or accidentially" setting up the routing wrong. I do agree that a malicious operator could pretend to zero-rate things and then make it actually impossible to ever get that service. But: MPvD seems to depend upon the same kind of brittle things!!! > It might be worth actually writing down why you think that's so. It's= far > from obvious to me that it is, but I am not as familiar as you are wi= th > Shim6. Unfortunately as far as I know nobody ever presented anything = about > Shim6 in MIF; if in fact what you are saying is true, a lot of time a= nd > effort could have been saved if that had happened. MIF tried to solve all sorts of IPv4-induced problems that marketing people thought that they had. Many were not well defined in my opinion, or in my opinion were not even good ideas. Tim points out that SHIM6 was undeployable as described because of extension headers; but I was never convinced that was what killed it, but okay. (I believe that was the year I dealt with family illnesses) Maybe in the end, we have LISP as a response? SHIM6 tries to deal with multi-homing by proposing incrementally deployable changes to hosts. Host (pairs) that have it, benefit without infrastructure in between being upgraded. A host that had SHIM6, and had some HNCP and/or minimal babel listening, would be able to intelligently do SHIM6 better. I think that SHIM6 would also provide a channel by which a service provider who had differential rates for different access channels to say such a thing through the SHIM6 layer. (That would be an extension) MPvD tries to do the same thing: avoid making any changes to the infrastructure outside of the "device" (in the telco's case, a smartphone that they have an agreement with the manufacturer to modify, that they lock and "sell"). HOMENET is chartered to fix the infrastructure *in the home* such that unmodified hosts can reasonably get basic services without changes. MPvD only works when the end host has multiple interfaces that it can actually provision from, *or* if we have virtual provisioning domains on the same link! i.e. infrastructure! Which we do have in HOMENET. At which point MPvD requires that the infrastructure and the host cooperate to communicate the multiple domains to the end host via the infrastructure. That's where all the "brittle" things you describe show up!!! MPvD requires the walled-garden ISPs to do the same configuration. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmPmLUACgkQgItw+93Q 3WVEzwf/doixS8glJH+JMpHrDTno71EfIty9vT9CuW2cXI8EiUG6dzHxYfaCv4nE 5965L0juQ7NkSvqtqVPELT7B8VHsR2zChNFSd9vCFXooRAR0Xoeq7nNDq518HBI1 ifSqrWeIgOmFmiSWUo67YurFyyIaBtvtvLouBPwcXzj2LtXFO1HwLfIJKIwjar15 Phk6GjIJ8HA6Eaq/umEglXZRP/rWjPJUXJjuCf5+n1gNd/DAq1you81hcsanRuv3 k1OJ6bmagZrxzw8m0E/m8WfOeqkqlvDcFXuBffL2nehlxx+RNApvz8L/1GI1q5be PeV3jTuOFQP7A7+weYp7AfigYxJadA== =IVpc -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 12 19:36:10 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C04B13241A for ; Sat, 12 Aug 2017 19:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 pFSYQ8aZn_Oi for ; Sat, 12 Aug 2017 19:36:07 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 6151913240F for ; Sat, 12 Aug 2017 19:36:07 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id a77so36958598qkb.0 for ; Sat, 12 Aug 2017 19:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=r0lrJc6r7YmagOn1EMUhOOxJr6ISxqFNJTtdzIRs7es=; b=IHPIhORUT0xGP28pArokZzUapgS7SkapdzEmz3ZMAYnbJsc0iHBgLMgs2fCYCdDkco EOkpFVII/WbY+0fM/Qa8tlLj842XvajRNe0ZLs8WWgRicT7thrw6ABbfNYoyXogXeTkB oza3u3HXWP4iBc422vv764JWVHLMm+hWmPkMsyhPHZcwHVWNDWnKrSJsrtHv15VPPrm9 VL/WDpaIsn1dzAjdevjjRHaBOmZuowGstjs7YDfCc7eBAdKt9Ymrc0oTE/YC1P0rg+8+ B9GEUu0nJhILvrnYon2rTlXrim8vYGVDBSxKL+VTdsE1PrXtmIcOJtP7eU9hxdX7uvuy q9jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=r0lrJc6r7YmagOn1EMUhOOxJr6ISxqFNJTtdzIRs7es=; b=YRj2VkP+3+r96LF0GNKxXwiJCtoaWWZgQbr9ne0QBjbxsumTgGRVPQLCMTbHp/08bj j7nR/T39OtvtjcEJeG9KdMaYbfRMCnRcfIoIJcTvLbp8EiIkE0ulJNv2jyEbcskKf53C 0odq/BIowGOvMpVnIGXddqR8bY7HNZRzzCcowwHKEq/2B0O0fFg5s78e/qZ0y7DHU73V s07XFu6X+wy/WeKb+z6sWQMgTnPAAYHAObJV1hrEMvvkXasUYq+hCofAlCgODPXf3kV3 EkaeKGKNCfKtoWApg3fREGxwZ+iQE39PAwbhbgwLRFcp/cMhJc7b91lImGjilftEpJ90 rNvg== X-Gm-Message-State: AHYfb5jrfxcsb3bqv8Wc8YRC+q8oIvEy+dqs+86jFS2EXXl0ZeHCkL90 U1Dv/EB3pGwmfzxRyWa1UQ== X-Received: by 10.55.40.104 with SMTP id o101mr25830765qkh.311.1502591766375; Sat, 12 Aug 2017 19:36:06 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id f11sm3160126qtk.7.2017.08.12.19.36.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Aug 2017 19:36:05 -0700 (PDT) From: Ted Lemon Message-Id: <7161D4C4-7E15-480B-AF4F-73A2464F991B@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FD779F81-593A-4D4C-86FF-AA3AA0364449" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 12 Aug 2017 22:36:04 -0400 In-Reply-To: <29406.1502582965@obiwan.sandelman.ca> Cc: HOMENET To: Michael Richardson References: <29406.1502582965@obiwan.sandelman.ca> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] use of MPvD in homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 02:36:09 -0000 --Apple-Mail=_FD779F81-593A-4D4C-86FF-AA3AA0364449 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii El 12 ag 2017, a les 20:09, Michael Richardson = va escriure: > This seems a bit like FUD: the Internet depends upon all sorts of = "brittle" things > like "not deliberately or accidentially" setting up the routing wrong. I get that, and it's possible that MPvD is the wrong answer here. = However, I think we need to actually analyze the problem and not just = theorize about it at this level. The reason that the MPvD work = happened was that there was a need for it; it may not have been the = right way to solve the problem, but I'm having trouble figuring out how = LISP or Shim6 improves the situation. The problem is simply that it needs to be the case that if a host looks = up a name from one ISP's name servers, then it needs to use that ISP's = prefix to contact the address that it gets from the lookup; if it uses = the other ISP's name servers, then it needs to use that ISP's prefix. = Otherwise CDNs fail. The other problems that you are talking about are also worth thinking = about, but we haven't looked at them in this amount of detail. But one thing to remember is that there's a reason why it's beneficial = for hosts to implement MPvD; this is handset vendors implement it it. = It neatly wraps up real problems that real hosts have, pretty much = orthogonally to whether IPv4 or IPv6 (or both) are in use. Given that = this is the case, part of the benefit of using it in the homenet is that = we'd be using existing logic in hosts. But if you really think Shim6 or LISP solve the problem better, one = exercise that you might want to try is answering the question, "how does = Shim6 help me with the CDN problem? How does LISP help me with the CDN = problem. What do I have to put in a homenet router to make this work? = Which homenet router do I put it in?" When I consider those = questions, I don't know the answers to them. I do know the answer for = MPvD. So that's why I proposed that approach. --Apple-Mail=_FD779F81-593A-4D4C-86FF-AA3AA0364449 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 12 ag 2017, a les 20:09, Michael Richardson <mcr+ietf@sandelman.ca> va escriure:
This seems a bit like FUD: the Internet = depends upon all sorts of "brittle" things
like "not = deliberately or accidentially" setting up the routing = wrong.

I = get that, and it's possible that MPvD is the wrong answer here.   = However, I think we need to actually analyze the problem and not just = theorize about it at this level.   The reason that the MPvD work = happened was that there was a need for it; it may not have been the = right way to solve the problem, but I'm having trouble figuring out how = LISP or Shim6 improves the situation.

The problem is simply that it needs to = be the case that if a host looks up a name from one ISP's name servers, = then it needs to use that ISP's prefix to contact the address that it = gets from the lookup; if it uses the other ISP's name servers, then it = needs to use that ISP's prefix.   Otherwise CDNs fail.

The other problems that = you are talking about are also worth thinking about, but we haven't = looked at them in this amount of detail.

But one thing to remember is that = there's a reason why it's beneficial for hosts to implement MPvD; this = is handset vendors implement it it.   It neatly wraps up real = problems that real hosts have, pretty much orthogonally to whether IPv4 = or IPv6 (or both) are in use.   Given that this is the case, part = of the benefit of using it in the homenet is that we'd be using existing = logic in hosts.

But if you really think Shim6 or LISP solve the problem = better, one exercise that you might want to try is answering the = question, "how does Shim6 help me with the CDN problem?   How does = LISP help me with the CDN problem.   What do I have to put in a = homenet router to make this work?   Which homenet router do I put = it in?"   When I consider those questions, I don't know the answers = to them.   I do know the answer for MPvD.   So that's why I = proposed that approach.

= --Apple-Mail=_FD779F81-593A-4D4C-86FF-AA3AA0364449-- From nobody Sun Aug 13 03:52:49 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10D71328A2 for ; Sun, 13 Aug 2017 03:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 reN3I4_Tqc3v for ; Sun, 13 Aug 2017 03:52:45 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D996132113 for ; Sun, 13 Aug 2017 03:52:45 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502621562; bh=+DOETZp7SKc2qG2HDsuxFOiniDg6A8CIRZNB+sHQvww=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mGXU9f0zUhCGY/a3UFUQOaFjY3EnSSDA8pMEhLSepap31ipJTZlgva4SbXoFhdRAU JFkYxl41TcKl5P1fNzpbMYDmmVfQELcL57T4+yKZC4mHjhi6lHBN1Qgv0P0wDF9IXk SHNWOcAaH88ComHKXYFP4p2WjtRZjERuAXq8yf+lRrENmEEnp6dnwepbdrkyQ/IPme c7GRM051WdSwTMDFl11qag7IkrkFcy7ndn11Vs3GJZ4xhX6170L8m4hHYaRZIfFfAh G5783YvLY4mnhiAI55qH5MEJiL6M8M2gOf8cMQin6W6B4cF2tGIAFe3hn12Ycqo4/t CPtLtHCl4ov/w== To: Ted Lemon , Juliusz Chroboczek Cc: HOMENET In-Reply-To: <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> Date: Sun, 13 Aug 2017 12:52:45 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <871sofzqma.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 10:52:47 -0000 Ted Lemon writes: > What I find completely perplexing about this conversation is that you, > Markus and Toke, all of whom I know to be smart people, think this is > hard. What is hard about it? I think the reason you think it's > hard is simply that you don't know how to do it. Ah no, this was not was I was trying to express. As you say, technically implementing what's currently in your draft is doable, but adds a small to moderate amount of complexity. This can be acceptable, *if* it provides a corresponding benefit. However, I do not believe that it does, for two main reasons: 1. In every encounter I've had with an ISP-provided DNS server, that server is either (a) flaky, (b) censored or (c) both. So limiting ourselves to getting replies from just one upstream for a given query is going to give worse performance than using all available servers (or just doing our own full recursing from the root). 2. Even if DNS queries are paired with source prefixes, the client still has to pick which source prefix to send the DNS query from; how is it going to do that? (This may just be me that is ignorant of the details of the MPvD architecture; if so, please do enlighten me). Together, these points mean that as far as I'm concerned, what you're proposing is adding complexity to achieve a behaviour that is going to result in *worse* performance than doing the simple thing. Which is not a good proposition, as I'm sure you'll agree. Now, as I said a few mails back, I am perfectly happy to be convinced that there *is* a benefit worth paying the complexity cost for; but, well, someone is going to have to do the convincing... :) -Toke From nobody Sun Aug 13 05:28:12 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3D1132758 for ; Sun, 13 Aug 2017 05:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 rsneBP1dGi-Y for ; Sun, 13 Aug 2017 05:28:08 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 00149132514 for ; Sun, 13 Aug 2017 05:28:07 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id y129so31558606pgy.4 for ; Sun, 13 Aug 2017 05:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DhTX+NOajgc0Jjr4sl+ku2guCwSRzIIT9Ha9qFXE0sA=; b=GGRA2B7RM6Ii99vGZyCcjtqkady1phvftC7DjcfbXJaCaY3jDDqF5r/rrUPI3ne2Wv LYQ2S7t6m+RwLZPvz22GZUVBi8sDJh3OW6nvLlztov473jO3OMXiFPax+GL+8xze3z2R Va/6n8kia0XaH/j5GDcuE7/Qy2ouw/vGkPSvzV4qo5RdO1XWttilYSEWErWQMK+5b+hC 7z3T+1vSWNzcniZBRwnaxN/acBUnD4NSpJzOqYlX7Yjj7QN8lop5QZakSkvk8z6J8WCL b+QDnRMEo79rAzE/i+0/GHr4tdmqXQ1D7bf7M1+mAC4fbRLAYwG2Bv29M//HafZyU7mg hg9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DhTX+NOajgc0Jjr4sl+ku2guCwSRzIIT9Ha9qFXE0sA=; b=AGsxIR5FeFaVW07A9m8t5x0SGBxRn86tytlzjpXHd1eLe3HiXjriiKd9hZ2xuoz6fU tyAEY22Bm0CvNJPwbVUvcRaaaj/JvJNrt5GJtAnP4uJIjjE+NK5uqEOGe53IBoMbt9qN EGjm7a3Oi6U9D3wLrlQW9sofPTXHvFLJ5joq7jFjMB/OR1g68NOuBJiOkM68td3Vi77k P1E8/3VHguPR4V5X/i2izbUQjj2L2dFBv2MQ6Q5mWSNMaRODWU/urHgQNTtTdVI+eMZ5 e//553jybWJS+oefO9lONQux1dkVI2zLvXTCEbuFN55VR4JyfFz6WimS9XCAYH6qnuL1 zpvw== X-Gm-Message-State: AHYfb5hb9V6qoBsLqZeU9APh2OltTB2rss5djOO4+COfPgDE3qf7WjLA em/a8+jmjIoYBWWWXG0fLpwNo9rVC1/F X-Received: by 10.98.139.134 with SMTP id e6mr21698819pfl.111.1502627287476; Sun, 13 Aug 2017 05:28:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.131 with HTTP; Sun, 13 Aug 2017 05:27:26 -0700 (PDT) In-Reply-To: <871sofzqma.fsf@toke.dk> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> From: Ted Lemon Date: Sun, 13 Aug 2017 08:27:26 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Juliusz Chroboczek , HOMENET Content-Type: multipart/alternative; boundary="f403045c4322b345b80556a1ad0b" Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 12:28:11 -0000 --f403045c4322b345b80556a1ad0b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hm. What I think the ideal resolver to have on a homenet is as follows: (1) It can be configured to scatter queries randomly to a large number of resolvers all over the internet. (2) It can be configured to send certain queries to forwarders provided by one or more local ISPs (3) It can be configured to filter domain names based on a subscribed list (or a set of subscribed lists) of known-bad domains. (4) It can be configured to provide its own answers for some set of names, in order to break devices you own and have paid for out of provider-supplied walled gardens. (5) ... However, this feels to me like it's a laundry list of features that are not _required_ by a homenet. Many of these features require a fair amount of understanding to configure. Doing (3) in the local resolver is actually hard, because the list can be quite large, or else it's privacy-violating, because you have to send your query stream to the thing that manages the list. Ideally (3) would be done on the same mass of resolvers that you are using for (1), so as to keep the query stream private. The point is that what I have specified in the architecture document is what is minimally required to allow a homenet to function given ordinary ISPs and ordinary users. I think trying to do some of the things on the above laundry list would be very interesting work; trying to get it to where end-users can use it without being experts and without being made vulnerable to scams would be very cool, but is out of scope for this document. Does that make sense? On Sun, Aug 13, 2017 at 6:52 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Ted Lemon writes: > > > What I find completely perplexing about this conversation is that you, > > Markus and Toke, all of whom I know to be smart people, think this is > > hard. What is hard about it? I think the reason you think it's > > hard is simply that you don't know how to do it. > > Ah no, this was not was I was trying to express. As you say, technically > implementing what's currently in your draft is doable, but adds a small > to moderate amount of complexity. This can be acceptable, *if* it > provides a corresponding benefit. However, I do not believe that it > does, for two main reasons: > > 1. In every encounter I've had with an ISP-provided DNS server, that > server is either (a) flaky, (b) censored or (c) both. So limiting > ourselves to getting replies from just one upstream for a given query > is going to give worse performance than using all available servers > (or just doing our own full recursing from the root). > > 2. Even if DNS queries are paired with source prefixes, the client still > has to pick which source prefix to send the DNS query from; how is it > going to do that? (This may just be me that is ignorant of the > details of the MPvD architecture; if so, please do enlighten me). > > Together, these points mean that as far as I'm concerned, what you're > proposing is adding complexity to achieve a behaviour that is going to > result in *worse* performance than doing the simple thing. Which is not > a good proposition, as I'm sure you'll agree. > > Now, as I said a few mails back, I am perfectly happy to be convinced > that there *is* a benefit worth paying the complexity cost for; but, > well, someone is going to have to do the convincing... :) > > -Toke > --f403045c4322b345b80556a1ad0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hm. =C2=A0 What I think the ideal resolver to have on a ho= menet is as follows:

(1) It can be configured to scatter= queries randomly to a large number of resolvers all over the internet.
(2) It can be configured to send certain queries to forwarders provi= ded by one or more local ISPs
(3) It can be configured to filter = domain names based on a subscribed list (or a set of subscribed lists) of k= nown-bad domains.
(4) It can be configured to provide its own ans= wers for some set of names, in order to break devices you own and have paid= for out of provider-supplied walled gardens.
(5) ...
<= br>
However, this feels to me like it's a laundry list of fea= tures that are not _required_ by a homenet. =C2=A0 Many of these features r= equire a fair amount of understanding to configure. =C2=A0 Doing (3) in the= local resolver is actually hard, because the list can be quite large, or e= lse it's privacy-violating, because you have to send your query stream = to the thing that manages the list. =C2=A0 Ideally (3) would be done on the= same mass of resolvers that you are using for (1), so as to keep the query= stream private.

The point is that what I have spe= cified in the architecture document is what is minimally required to allow = a homenet to function given ordinary ISPs and ordinary users. =C2=A0 I thin= k trying to do some of the things on the above laundry list would be very i= nteresting work; trying to get it to where end-users can use it without bei= ng experts and without being made vulnerable to scams would be very cool, b= ut is out of scope for this document.

Does that ma= ke sense?

On Sun, Aug 13, 2017 at 6:52 AM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@tok= e.dk> wrote:
Ted Lemon <mellon@fugue.com&g= t; writes:

> What I find completely perplexing about this conversation is that you,=
> Markus and Toke, all of whom I know to be smart people, think this is<= br> > hard.=C2=A0 =C2=A0What is hard about it?=C2=A0 =C2=A0I think the reaso= n you think it's
> hard is simply that you don't know how to do it.

Ah no, this was not was I was trying to express. As you say, technic= ally
implementing what's currently in your draft is doable, but adds a small=
to moderate amount of complexity. This can be acceptable, *if* it
provides a corresponding benefit. However, I do not believe that it
does, for two main reasons:

1. In every encounter I've had with an ISP-provided DNS server, that =C2=A0 =C2=A0server is either (a) flaky, (b) censored or (c) both. So limit= ing
=C2=A0 =C2=A0ourselves to getting replies from just one upstream for a give= n query
=C2=A0 =C2=A0is going to give worse performance than using all available se= rvers
=C2=A0 =C2=A0(or just doing our own full recursing from the root).

2. Even if DNS queries are paired with source prefixes, the client still =C2=A0 =C2=A0has to pick which source prefix to send the DNS query from; ho= w is it
=C2=A0 =C2=A0going to do that? (This may just be me that is ignorant of the=
=C2=A0 =C2=A0details of the MPvD architecture; if so, please do enlighten m= e).

Together, these points mean that as far as I'm concerned, what you'= re
proposing is adding complexity to achieve a behaviour that is going to
result in *worse* performance than doing the simple thing. Which is not
a good proposition, as I'm sure you'll agree.

Now, as I said a few mails back, I am perfectly happy to be convinced
that there *is* a benefit worth paying the complexity cost for; but,
well, someone is going to have to do the convincing... :)

-Toke

--f403045c4322b345b80556a1ad0b-- From nobody Sun Aug 13 06:32:16 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946BB13262B for ; Sun, 13 Aug 2017 06:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 0sQqThrpfJEE for ; Sun, 13 Aug 2017 06:32:11 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03EC01324B9 for ; Sun, 13 Aug 2017 06:32:10 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502631127; bh=iPytzBgroCiZu5FNjP0zIm76QPObGTvPvGZB97yEv5U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nuo9LMaT9G45f75BW7kFcuYbNGeSIgICDVUDXDSp4VT/9nJJoSklZ+Rqg+PIgx4/r t5QUJtk3a6CULUTD0OY1OSGZ0c7q0299wSnYS+rDATunz/h3qgdzKOUUvvkBcUmlO4 I5jovJENZElmJdf1q2L8Fn/5fxY56/ONKX+p/3zz4bjviIMLOiFJxV/NBFQ2UCEJnc iAFVRxicD5hYgO1GsWBvDsH+sFs2GLfaYsYaYRSAuG2LsS7e5fXy0ZHeiIejZOyZcB wfv743yzn24kJA91ynzIbmRBUO2JW7H0RsA2i3IZOaY1BcSskPoZPNDYv8I4VvxyVB zGk3ShDgTLojw== To: Ted Lemon Cc: Juliusz Chroboczek , HOMENET In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> Date: Sun, 13 Aug 2017 15:32:08 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87valry4o7.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 13:32:14 -0000 > The point is that what I have specified in the architecture document is > what is minimally required to allow a homenet to function given ordinary > ISPs and ordinary users. I think trying to do some of the things on the > above laundry list would be very interesting work; trying to get it to > where end-users can use it without being experts and without being made > vulnerable to scams would be very cool, but is out of scope for this > document. > > Does that make sense? Sure. I'm just not sure I agree that MPvD shouldn't also be on the "nice to have" list, rather than the "absolutely required" list. Perhaps it would help if you could explain (a) the details of "the CDN problem" (what mechanism is used to determine answers for a given prefix, and what is the failure mode if the wrong address is used?), and (b) how the client is supposed to actually work with this mechanism (seems to me an unmodified client will probably make a mess of things?). As for an "ideal" resolver behaviour, to me that would be full recursive resolution from the root inside the home, replicating all queries across all upstreams and picking the best reply (best being something like "first reply that passes DNSSEC validation"). With an "advanced configuration" option somewhere that allows the user to override arbitrary names/zones as they see fit. -Toke From nobody Sun Aug 13 07:48:55 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8571321A6 for ; Sun, 13 Aug 2017 07:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 NdCATLOC561m for ; Sun, 13 Aug 2017 07:48:51 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 22862132655 for ; Sun, 13 Aug 2017 07:48:51 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id p3so41395407qtg.2 for ; Sun, 13 Aug 2017 07:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JhU7nlFtwmko+82aqNw3xJ8freWOCBq4iF0BocTUNAI=; b=k5ZxnxPKt8GYr7twenvQ7Dowa7KEiqIaCci/38bqxJzqnRruYbyBD1Ya/PPzl8xmGv G60QtKquIh/Q0A8pOXlkplpC9AgxV0GQv9FZp76NksFnJ12lilkb+SDdMe/wCkpXA4GY KUauucfkW4Ct6DR1RnNmSWV7ZijZLleMMDjdo853wXj0DpDg4M3S0yzRtMi7hlSpf44D FLwPmNxJYgMrILczxA4lT4ZkOGMJGOucnqBBII7LxnuBECbk7o4VEAmDPoFJqPnMSR73 muS73k4G543fuySvgBnP/a8wh0/bOZZtazhOP0yEq+jAVSTRymDjH3MvykfkElu8zN6y c3Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JhU7nlFtwmko+82aqNw3xJ8freWOCBq4iF0BocTUNAI=; b=V35NMiBw18kWwErMCFvESMXX2SkTveHuEdnB9/7gazeSpRfraGmfaN6/L6r2+brIKM DpW9WtWravpwJStBviTZLgoI2lAnz62Ex07dgQ3aejVH0SwuZBxSjuYKCZnHPbPIB4q+ dFh6rGRjZiC5hEk4T3SIJRlfxDH+L+/EXeH3S9vpHV2jwccPxvYiWKIKG4IhBqmrgaWC /gSHgI2rI1WzqbXtV1IR+dqQ0fRi3creHP3IM70edgKZXV5iw3pwGoX9qt7BIbBYI804 tuMPH5/D4tg6b8LImGqmj4paUmlH00OpgTP1C54djW+D4LjTRAwKQWhphHLvMGqjX4vg 8lYQ== X-Gm-Message-State: AHYfb5hNU0n0ER/KtugJhj9tNJOc/6p6HMmaaGIDJGp7y/buwx/VFyIK 5XUmEnBGrigvAmWnX74AhQ== X-Received: by 10.200.8.20 with SMTP id u20mr28968841qth.287.1502635730105; Sun, 13 Aug 2017 07:48:50 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id n69sm3500528qke.52.2017.08.13.07.48.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Aug 2017 07:48:49 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B452ED6C-4B25-463C-9624-2A26E42992E6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 13 Aug 2017 10:48:47 -0400 In-Reply-To: <87valry4o7.fsf@toke.dk> Cc: Juliusz Chroboczek , HOMENET To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 14:48:53 -0000 --Apple-Mail=_B452ED6C-4B25-463C-9624-2A26E42992E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 El 13 ag 2017, a les 9:32, Toke H=C3=B8iland-J=C3=B8rgensen = va escriure: > Sure. I'm just not sure I agree that MPvD shouldn't also be on the = "nice > to have" list, rather than the "absolutely required" list. Why do you think CDNs exist? What would happen if every home network = suddenly stopped using the technology that makes CDNs work? You = mentioned that you don't use it, and your Netflix works fine, and that's = my experience too (I have the same configuration). But if everybody = did that, I think it would not work fine, and that's why we should make = sure that out of the box, by default, it works correctly. We want = users of homenet to have a good experience, and to be able to tune their = experience if they want non-default behavior. > Perhaps it would help if you could explain (a) the details of "the CDN > problem" (what mechanism is used to determine answers for a given > prefix, and what is the failure mode if the wrong address is used?), = and > (b) how the client is supposed to actually work with this mechanism > (seems to me an unmodified client will probably make a mess of = things?). The idea with CDNs is that you put the content close to the edge and = give different answers using DNS or HTTP depending on where the client = is. By doing this, you can balance the load across the right number of = servers in the right data centers, and avoid transporting the same = traffic over the backbone many times. > As for an "ideal" resolver behaviour, to me that would be full = recursive > resolution from the root inside the home, replicating all queries = across > all upstreams and picking the best reply (best being something like > "first reply that passes DNSSEC validation"). With an "advanced > configuration" option somewhere that allows the user to override > arbitrary names/zones as they see fit. This is mostly what the MPvD solution does (minus the override option, = which I think is out of scope). Queries are sent to all upstreams, and = the good answer that arrives first is used. What MPvD does _in = addition_ is to make sure that if ISP A's answer is chosen, then ISP A's = connection is used to connect to the destination. MPvD also accounts for the fact that this connection might not work. = It isn't good enough to just select whichever DNS answer comes back = first, because that answer may not actually result in establishment of a = successful connection. So ideally you try both connections, either = simultaneously or else according to some algorithm that optimises for = which connection is preferred. For example, if you really, really want to use connection A, then you = only try connection B if you don't have a successful connection = established after 30 seconds, but if you don't care, then you try both = nearly simultaneously and take the first one to succeed to the point = where you have completed the https handshake (for example) and validated = the cert using PKI validation. You may also want to configure things so that you have a primary and a = backup connection, and your backup connection is never used for certain = things, or only used for certain things. E.g., if your backup is a = cell phone backup that costs more per megabyte, or has a lower data cap. = Or in some cases just the opposite. This is useful for situations = where you want to be able to have dual-homing for the sake of IoT = six-sigma reliability, but don't want to use the backup link for = anything else, because it's expensive. Now, as for the "mostly" above, the problem with what you've said is = that it doesn't scale: if every home does full recursion, that's a much = larger load on authoritative name servers than currently exists. = There's a reason why that's not how things are done now. If we were to = specify this behaviour, there would be substantial pushback from dnsop, = and I would be participating in that pushback. I don't think this = would get IETF consensus. This is not to say that you are wrong, but = the point is that this is the wrong working group in which to have that = argument.= --Apple-Mail=_B452ED6C-4B25-463C-9624-2A26E42992E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 El 13 ag 2017, a les 9:32, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> va = escriure:
Sure. I'm just not = sure I agree that MPvD shouldn't also be on the "nice
to have" list, rather than the "absolutely = required" list.

Why do you think = CDNs exist?   What would happen if every home network suddenly = stopped using the technology that makes CDNs work?   You mentioned = that you don't use it, and your Netflix works fine, and that's my = experience too (I have the same configuration).   But if everybody = did that, I think it would not work fine, and that's why we should make = sure that out of the box, by default, it works correctly.   We want = users of homenet to have a good experience, and to be able to tune their = experience if they want non-default behavior.

Perhaps it would = help if you could explain (a) the details of "the CDN
problem" (what mechanism is used to determine = answers for a given
prefix, and what is = the failure mode if the wrong address is used?), and
(b) how the client is supposed to actually work = with this mechanism
(seems to me an = unmodified client will probably make a mess of things?).

The idea with = CDNs is that you put the content close to the edge and give different = answers using DNS or HTTP depending on where the client is.   By = doing this, you can balance the load across the right number of servers = in the right data centers, and avoid transporting the same traffic over = the backbone many times.

As for an "ideal" resolver behaviour, to = me that would be full recursive
resolution from the = root inside the home, replicating all queries across
all upstreams and picking the best reply (best = being something like
"first reply that = passes DNSSEC validation"). With an "advanced
configuration" option somewhere that allows the = user to override
arbitrary = names/zones as they see fit.

This is mostly what the MPvD solution does = (minus the override option, which I think is out of scope).   = Queries are sent to all upstreams, and the good answer that arrives = first is used.   What MPvD does _in addition_ is to make sure that = if ISP A's answer is chosen, then ISP A's connection is used to connect = to the destination.

MPvD also accounts for the fact that this connection might = not work.   It isn't good enough to just select whichever DNS = answer comes back first, because that answer may not actually result in = establishment of a successful connection.   So ideally you try both = connections, either simultaneously or else according to some algorithm = that optimises for which connection is preferred.
For example, if you really, really = want to use connection A, then you only try connection B if you don't = have a successful connection established after 30 seconds, but if you = don't care, then you try both nearly simultaneously and take the first = one to succeed to the point where you have completed the https handshake = (for example) and validated the cert using PKI validation.

You may also want to = configure things so that you have a primary and a backup connection, and = your backup connection is never used for certain things, or only used = for certain things.   E.g., if your backup is a cell phone backup = that costs more per megabyte, or has a lower data cap.   Or in some = cases just the opposite.   This is useful for situations where you = want to be able to have dual-homing for the sake of IoT six-sigma = reliability, but don't want to use the backup link for anything else, = because it's expensive.

Now, as for the "mostly" above, the problem with what you've = said is that it doesn't scale: if every home does full recursion, that's = a much larger load on authoritative name servers than currently exists. =   There's a reason why that's not how things are done now.   = If we were to specify this behaviour, there would be substantial = pushback from dnsop, and I would be participating in that pushback. =   I don't think this would get IETF consensus.   This is not = to say that you are wrong, but the point is that this is the wrong = working group in which to have that argument.
= --Apple-Mail=_B452ED6C-4B25-463C-9624-2A26E42992E6-- From nobody Sun Aug 13 08:49:26 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A936C132682 for ; Sun, 13 Aug 2017 08:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 72xxxMsgHn5w for ; Sun, 13 Aug 2017 08:49:24 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757DE132395 for ; Sun, 13 Aug 2017 08:49:23 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502639356; bh=8l7Q5ZWfuspHNekpThcIInsb1sLyYEav6cYcHwQ8qFA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LHEZfz5z7ws7bXms2MeO32tHBUTeU4tyJWrYSkbaXaSy/QPl/ZSKFvWH/7W2xBf6y k7+kSot3Z3AY1mxzwa7tn90sF3DbjLg8vy2N3EdHfP9RY2aqLM/GAvGS552jZ+Zb+D ondJqziqUWJBvjZ4KZ21A9Afz2MbGI/jNajliOM97W4WGQJJXX3kLJ+PIgvv9+cQrQ nRbO3GQT/QVisatQ87OE+Man8LDc7Ou4kL4GmVM/8fIB2i22GVNobPOKHOoGLxtq30 2Q0MThI+4T7BxPePIhfIk2EKzH8/lyd3lcNU2m+gaIxACFDsCt+odmLckOJOpa2V/n Rb0iyTfcA2PGg== To: Ted Lemon Cc: Juliusz Chroboczek , HOMENET In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> Date: Sun, 13 Aug 2017 17:49:18 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87shgvxybl.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 15:49:26 -0000 Ted Lemon writes: >> Perhaps it would help if you could explain (a) the details of "the CDN >> problem" (what mechanism is used to determine answers for a given >> prefix, and what is the failure mode if the wrong address is used?), and >> (b) how the client is supposed to actually work with this mechanism >> (seems to me an unmodified client will probably make a mess of things?). > > The idea with CDNs is that you put the content close to the edge and > give different answers using DNS or HTTP depending on where the client > is. By doing this, you can balance the load across the right number of > servers in the right data centers, and avoid transporting the same > traffic over the backbone many times. Yeah, I am aware of the basic concept of a CDN. What I am (was?) confused about is what it has to do with different DNS answers. I have only ever used Cloudflare, and they use anycast to do their magic (which also seems to me like the obvious way to do it; why are people messing with DNS for this?). Anyhow, consider me educated... :) In any case, the failure mode of getting a it wrong is a sub-optimal path being chosen; but if ISP A's DNS server takes five seconds to respond, we'd get a better result from just using the timely answer from ISP B's and going over the suboptimal path to get to the content (in many cases, at least). >> As for an "ideal" resolver behaviour, to me that would be full recursive >> resolution from the root inside the home, replicating all queries across >> all upstreams and picking the best reply (best being something like >> "first reply that passes DNSSEC validation"). With an "advanced >> configuration" option somewhere that allows the user to override >> arbitrary names/zones as they see fit. > > This is mostly what the MPvD solution does (minus the override option, > which I think is out of scope). Queries are sent to all upstreams, and > the good answer that arrives first is used. What MPvD does _in > addition_ is to make sure that if ISP A's answer is chosen, then ISP > A's connection is used to connect to the destination. But only the client can make that coupling (from DNS reply to connection attempt). So if we're just filtering the result set based on the address the client uses (which is how I interpret what you put in the draft), we're degrading the experience for any client that doesn't know how to repeat the query from another source address. So we'd effectively be requiring hosts to support MPvD; and we're not supposed to require host changes, are we? > For example, if you really, really want to use connection A, then you > only try connection B if you don't have a successful connection > established after 30 seconds, but if you don't care, then you try both > nearly simultaneously and take the first one to succeed to the point > where you have completed the https handshake (for example) and > validated the cert using PKI validation. > > You may also want to configure things so that you have a primary and a > backup connection, and your backup connection is never used for > certain things, or only used for certain things. E.g., if your backup > is a cell phone backup that costs more per megabyte, or has a lower > data cap. Or in some cases just the opposite. This is useful for > situations where you want to be able to have dual-homing for the sake > of IoT six-sigma reliability, but don't want to use the backup link > for anything else, because it's expensive. I can see how these scenarios make sense for a device that know the types of connection (like a cell phone with cellular and WiFi links). Less so in the home, where all the client sees are different prefixes; in this case, either the network has to enforce policy (like the failover scenario), or we'll have to communicate more information to the hosts, which goes back to my point above about host changes... > Now, as for the "mostly" above, the problem with what you've said is > that it doesn't scale: if every home does full recursion, that's a > much larger load on authoritative name servers than currently exists. > There's a reason why that's not how things are done now. If we were to > specify this behaviour, there would be substantial pushback from > dnsop, and I would be participating in that pushback. I don't think > this would get IETF consensus. This is not to say that you are wrong, > but the point is that this is the wrong working group in which to have > that argument. Right, well, I'm not sure I have the energy to go argue with dnsop on this one... :) But I can probably live with a mechanism where we just specify that the user needs to have an option to override the default behaviour (i.e., add their own DNS servers which take precedence over whatever we end up specifying). -Toke From nobody Sun Aug 13 10:00:07 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917A51324CA for ; Sun, 13 Aug 2017 10:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 cIqBjey7rgOb for ; Sun, 13 Aug 2017 10:00:03 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 70AC3132449 for ; Sun, 13 Aug 2017 10:00:03 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id a77so40965115qkb.0 for ; Sun, 13 Aug 2017 10:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/QA2CrNn3HLdyB6Y908aAt7E+v7fyjWFIeK6tI5erow=; b=vdmdemL6RZXQfbjcICkNJOPwj/7uOZa/iGelaGCqnV4fM0PpQ7sT1UsPSuBz0PdHZL AqoQBYhGhgVkDs0caeF8ZgsqHKn38pmzkl80eU29HBrs57moXNkYlCBxmN4wXsfeWSgP o9p2VM61jMM36EWICvMBO3alRxCHqaoppH9jEyM+8CgcFfNZvz3mffPIGz+SM+I6TPC3 iUyFRzc9wuxTOMEfAyQ2p6gaaHfGe04uoOcyBFvwR7Flld3UA1TSHwZwjA67Lbv5VhJl CNlMtic5q5O2PyKIN8GkN8A7D8CKt1OJjUgRFSMQa5jIvLre4z1Og1lkn6VKAddeSDA0 z+0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/QA2CrNn3HLdyB6Y908aAt7E+v7fyjWFIeK6tI5erow=; b=taGHPLL3OheDbmqYRYYYzQPo+UkKhr2sTYR3Nr6FJr46Teio+BCWQAq6pWAPptiCqZ jKZZT/2p2isX3R6sg3THE7dktyQzzL7xFcazjdVCASHtdhMRFfKyvCyel3FTPh/LAKZs 5poj/5qCuDj7LNPF9/e/XYjs/AnLFW0PE1HCIfHRPUTMZmNSl7TnEpt1pY1B2Vu8O7hA g1AGIZS19pQb9uA0E4LQuoCnQdt6i33xyyxCoZNW/6d8vnjqFAoJ5t1tvuJIqMrmZwqJ eAqkPFUHzSfYK52a+LmGAnyy+kzYA8dp+IFIfkkb2RsWQL0Z+VBaQ5dTPTZ10b7VFc/f tJeQ== X-Gm-Message-State: AHYfb5joXIj9KuIwsK4+xurDyEK7PTG/nIImqRzcQ9WxCtdu/BAlgWyY awnI3+oGF9dO+xdEj2Uvwg== X-Received: by 10.55.214.89 with SMTP id t86mr7612016qki.42.1502643602489; Sun, 13 Aug 2017 10:00:02 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id f6sm3803797qtb.69.2017.08.13.10.00.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Aug 2017 10:00:01 -0700 (PDT) From: Ted Lemon Message-Id: <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DAF73656-553B-4651-8E94-BEFB92CB2F38" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 13 Aug 2017 12:59:58 -0400 In-Reply-To: <87shgvxybl.fsf@toke.dk> Cc: Juliusz Chroboczek , HOMENET To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 17:00:05 -0000 --Apple-Mail=_DAF73656-553B-4651-8E94-BEFB92CB2F38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 El 13 ag 2017, a les 11:49, Toke H=C3=B8iland-J=C3=B8rgensen = va escriure: > In any case, the failure mode of getting a it wrong is a sub-optimal > path being chosen; but if ISP A's DNS server takes five seconds to > respond, we'd get a better result from just using the timely answer = from > ISP B's and going over the suboptimal path to get to the content (in > many cases, at least). Not if the suboptimal path has substantially worse performance for the = duration of the session. > But only the client can make that coupling (from DNS reply to = connection > attempt). So if we're just filtering the result set based on the = address > the client uses (which is how I interpret what you put in the draft), > we're degrading the experience for any client that doesn't know how to > repeat the query from another source address. So we'd effectively be > requiring hosts to support MPvD; and we're not supposed to require = host > changes, are we? Many hosts we care about already support MPvD because the companies that = sell the software that runs on those hosts think it solves a useful = problem. Adding support for MPvD on the homenet is a relatively small = change now that their stacks already support it. As for a "degraded experience," do you mean that if we select one = upstream provider for a particular client, that's going to result in a = degraded experience for the user? Why would that be the case? > I can see how these scenarios make sense for a device that know the > types of connection (like a cell phone with cellular and WiFi links). > Less so in the home, where all the client sees are different prefixes; > in this case, either the network has to enforce policy (like the > failover scenario), or we'll have to communicate more information to = the > hosts, which goes back to my point above about host changes... Yes, in order to make this work we have to communicate additional = information to the host, and the host has to use it. That's why I = described a fallback solution for hosts that don't support this. It's = not clear that the solution I described is the right one, of course; the = point of saying something there was to have a place where we can write = whatever the advice is that we decide to give when we figure this out; = what I described would work, but it's possible that an entirely RA-based = solution would work just as well, in which case personally I'd prefer = it. > Right, well, I'm not sure I have the energy to go argue with dnsop on > this one... :) But I can probably live with a mechanism where we just > specify that the user needs to have an option to override the default > behaviour (i.e., add their own DNS servers which take precedence over > whatever we end up specifying). That's fine with me!= --Apple-Mail=_DAF73656-553B-4651-8E94-BEFB92CB2F38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 El 13 ag 2017, a les 11:49, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> va = escriure:
In any case, the = failure mode of getting a it wrong is a sub-optimal
path being chosen; but if ISP A's DNS server = takes five seconds to
respond, we'd get a = better result from just using the timely answer from
ISP B's and going over the suboptimal path to = get to the content (in
many cases, at = least).

Not = if the suboptimal path has substantially worse performance for the = duration of the session.

But only the client can = make that coupling (from DNS reply to connection
attempt). So if we're = just filtering the result set based on the address
the client uses (which = is how I interpret what you put in the draft),
we're degrading the = experience for any client that doesn't know how to
repeat the query from = another source address. So we'd effectively be
requiring hosts to = support MPvD; and we're not supposed to require host
changes, are = we?

Many hosts = we care about already support MPvD because the companies that sell the = software that runs on those hosts think it solves a useful problem. =   Adding support for MPvD on the homenet is a relatively small = change now that their stacks already support it.

As for a "degraded experience," do you = mean that if we select one upstream provider for a particular client, = that's going to result in a degraded experience for the user?   Why = would that be the case?

I can see how these = scenarios make sense for a device that know the
types of connection = (like a cell phone with cellular and WiFi links).
Less so in the home, = where all the client sees are different prefixes;
in this case, either = the network has to enforce policy (like the
failover scenario), or = we'll have to communicate more information to the
hosts, which goes back = to my point above about host changes...

Yes, in order to make this work we have = to communicate additional information to the host, and the host has to = use it.   That's why I described a fallback solution for hosts that = don't support this.   It's not clear that the solution I described = is the right one, of course; the point of saying something there was to = have a place where we can write whatever the advice is that we decide to = give when we figure this out; what I described would work, but it's = possible that an entirely RA-based solution would work just as well, in = which case personally I'd prefer it.

Right, = well, I'm not sure I have the energy to go argue with dnsop on
this one... :) But I = can probably live with a mechanism where we just
specify that the user = needs to have an option to override the default
behaviour (i.e., add = their own DNS servers which take precedence over
whatever we end up = specifying).

That's fine with me!
= --Apple-Mail=_DAF73656-553B-4651-8E94-BEFB92CB2F38-- From nobody Sun Aug 13 11:25:15 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96571321A6 for ; Sun, 13 Aug 2017 11:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 F7Uv8wr8CDpK for ; Sun, 13 Aug 2017 11:25:11 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644A81320D8 for ; Sun, 13 Aug 2017 11:25:11 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502648707; bh=lJDQSHOb10iKtzSlEHCBeztKFU0V3h3VtASaFszlTFQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UObSyvVwF6PdivnVoX/inURIYo3nooPSttJqL+a4qOl36+ni3AUaVUzXYeUXf1ITV Bo35FPLu+Zo+Wi5Gff3P5Zu+OXiP4SZ5MM8RWySh/AcBjRM3o8aRLk0f1Q9gcXwxvg 5Ji8wFgwewlwoc9SqJBL/OFpcIS7FuI8Vd3HKiw8XcQ2TzfhftT+85XyV4iVHD8CDm XHW8nkTnfoVhdsNwiLjASpaeflExzIZS6v6K8ShMI4tzmkO43YvwOaM7Lx8yJ5xhjV h9gOP/CIG4EN/0Ok0HD60mNMEfaHl2SOe10/uCuZ64oQqoVS/nqtOdsU2u72pXReTS FAo1gNH/jmBnw== To: Ted Lemon Cc: Juliusz Chroboczek , HOMENET In-Reply-To: <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> Date: Sun, 13 Aug 2017 20:25:09 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87lgmnxr3u.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 18:25:14 -0000 Ted Lemon writes: > El 13 ag 2017, a les 11:49, Toke H=C3=B8iland-J=C3=B8rgensen va escriure: >> In any case, the failure mode of getting a it wrong is a sub-optimal >> path being chosen; but if ISP A's DNS server takes five seconds to >> respond, we'd get a better result from just using the timely answer from >> ISP B's and going over the suboptimal path to get to the content (in >> many cases, at least). > > Not if the suboptimal path has substantially worse performance for the > duration of the session. Sure, it depends on the particular application (hence the "in many cases" in my original statement)... My point is just that it's not an obvious across the board win. >> But only the client can make that coupling (from DNS reply to connection >> attempt). So if we're just filtering the result set based on the address >> the client uses (which is how I interpret what you put in the draft), >> we're degrading the experience for any client that doesn't know how to >> repeat the query from another source address. So we'd effectively be >> requiring hosts to support MPvD; and we're not supposed to require host >> changes, are we? > > Many hosts we care about already support MPvD because the companies > that sell the software that runs on those hosts think it solves a > useful problem. Adding support for MPvD on the homenet is a > relatively small change now that their stacks already support it. Right, so we're adding it as an extra service for hosts that support it? That is fine with me, but then it shouldn't be a requirement. I.e., we can go "supporting MPvD is a good idea, and here is how you do it correctly", rather than the current "must support" language. > As for a "degraded experience," do you mean that if we select one > upstream provider for a particular client, that's going to result in a > degraded experience for the user? Why would that be the case? I mean that if we query all upstreams we get the best aggregate performance from all available DNS servers. Whereas if we limit queries to a particular ISP, we only get as good performance as that particular ISP can provide. If that was going to be the best on anyway, fine. If not, we are worse off by limiting queries to that ISP. >> I can see how these scenarios make sense for a device that know the >> types of connection (like a cell phone with cellular and WiFi links). >> Less so in the home, where all the client sees are different prefixes; >> in this case, either the network has to enforce policy (like the >> failover scenario), or we'll have to communicate more information to the >> hosts, which goes back to my point above about host changes... > > Yes, in order to make this work we have to communicate additional > information to the host, and the host has to use it. That's why I > described a fallback solution for hosts that don't support this. It's > not clear that the solution I described is the right one, of course; > the point of saying something there was to have a place where we can > write whatever the advice is that we decide to give when we figure > this out; what I described would work, but it's possible that an > entirely RA-based solution would work just as well, in which case > personally I'd prefer it. How do non-MPvD-aware hosts react to an announcement of an MPvD-specific DNS server? Does it ignore the server entirely, or does it ignore the PvD information and use the server anyway? >> Right, well, I'm not sure I have the energy to go argue with dnsop on >> this one... :) But I can probably live with a mechanism where we just >> specify that the user needs to have an option to override the default >> behaviour (i.e., add their own DNS servers which take precedence over >> whatever we end up specifying). > > That's fine with me! Cool :) -Toke From nobody Mon Aug 14 13:21:22 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFD113241D for ; Mon, 14 Aug 2017 13:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 QxZj6FcpkWme for ; Mon, 14 Aug 2017 13:21:18 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A31132415 for ; Mon, 14 Aug 2017 13:21:18 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id v7EKLETD012340; Mon, 14 Aug 2017 22:21:15 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 45131EB2F0; Mon, 14 Aug 2017 22:21:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id zpnakCBXga4u; Mon, 14 Aug 2017 22:21:13 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5C665EB2D0; Mon, 14 Aug 2017 22:21:09 +0200 (CEST) Date: Mon, 14 Aug 2017 22:21:08 +0200 Message-ID: <871sod3npn.wl-jch@irif.fr> From: Juliusz Chroboczek To: Ted Lemon Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , HOMENET In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 14 Aug 2017 22:21:16 +0200 (CEST) X-Miltered: at korolev with ID 5992063A.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5992063A.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5992063A.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 20:21:21 -0000 > Why do you think CDNs exist? What would happen if every home network suddenly > stopped using the technology that makes CDNs work? I thought I'd just mention that split-horizon DNS is just one possible technique. BGP anycast is another one. (AFAIK, Akamai use split-horizon DNS while Cloudflare use BGP anycast. No idea about Netflix.) Now, the interaction between source-specific routing, BGP anycast, and multipath at the higher layers, that's an interesting topic to argue about. -- Juliusz From nobody Mon Aug 14 13:24:55 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A19132415 for ; Mon, 14 Aug 2017 13:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 eJt8MubeEKDu for ; Mon, 14 Aug 2017 13:24:53 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC20D126E64 for ; Mon, 14 Aug 2017 13:24:52 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id v7EKOogi013448; Mon, 14 Aug 2017 22:24:50 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 542E6EB2F0; Mon, 14 Aug 2017 22:24:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ix1Mukt5BYbz; Mon, 14 Aug 2017 22:24:49 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6436AEB2D0; Mon, 14 Aug 2017 22:24:49 +0200 (CEST) Date: Mon, 14 Aug 2017 22:24:48 +0200 Message-ID: <87zib128z3.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: Ted Lemon , HOMENET In-Reply-To: <87shgvxybl.fsf@toke.dk> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 14 Aug 2017 22:24:50 +0200 (CEST) X-Miltered: at korolev with ID 59920712.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59920712.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 59920712.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 20:24:54 -0000 > But only the client can make that coupling (from DNS reply to connection > attempt). So if we're just filtering the result set based on the address > the client uses (which is how I interpret what you put in the draft), > we're degrading the experience for any client that doesn't know how to > repeat the query from another source address. So we'd effectively be > requiring hosts to support MPvD; and we're not supposed to require host > changes, are we? I think that's an important point, and one that Ted didn't adequately address in his reply. -- Juliusz From nobody Mon Aug 14 13:54:51 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53844126E64 for ; Mon, 14 Aug 2017 13:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 YhEnkrlC_9fr for ; Mon, 14 Aug 2017 13:54:45 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 5EC0F132422 for ; Mon, 14 Aug 2017 13:54:45 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id z18so56864963qka.4 for ; Mon, 14 Aug 2017 13:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1M+v9W2wGCk90axaK2Qcxe4TXFcKIb2ttI2SB74HtCw=; b=raGjfP5O6fosu2q0NBKUZM61SbhQCq+Bcpycr4nprzeWbEubxdGashyqfQNMQ7qyV4 UsY77rAYEvRk6+RuYyxtx9/g4EytUVlFuIIh6TFdK8IzEc5MVQ/DlpBT6UgiyaDRJYSa 9OgP9r7nNsQQlvD7gYkmyqj9fu2wiBBLY8q2SCS2IZB3NXQefPfs7C4/vvFkJrOtcr4j nOe7cmnWHLS9ycH/R4jjZA7QS+ncmHHQjp4MTC3jF9e2egemmBc3JPvW43hCSdtseWLC SatT7PiBZAqiEr7E6dJfZi+JlpZPl+op6uOp+V92zwsvGI4CHapnt0VQLEPy7w5h3xoJ dVGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1M+v9W2wGCk90axaK2Qcxe4TXFcKIb2ttI2SB74HtCw=; b=WYTQzP1K1TQKDr0Yyajt+SRgpZrObwmij1P7ht/DsQLOKDT+OUerjgbPOMAILD8bk8 kptDeM68/DvuGfOq6QjVAS2YVzD9bEisSKbbNjBNqKnKSi00t+Ny6TFKdHNn5LToQuIk By9q3trOuD0NTRbcvDujvQKug8RueaSvkseMk//jTM2dIS14vBhy20hNDX46mwlsCCf8 +1huHAXTn3tvXjedhAVCxCKT52klf7Id0j2OkaxvYLJt7LvTnz+YaymH34gFgLpJxQ72 z0/QxMr7hUjp1x1y0uAx0wr30T0ogvT3jBRphSXlTNZxVJLPgcclzh9HMYNp1kW82GTJ O2cw== X-Gm-Message-State: AHYfb5hbGHk56cwST5e1fOxyNg+cnvwYeP9+PkDqkBqPQ/etNkTdAd4F S4rXdBjD4Cg2HPNd+VwbUA== X-Received: by 10.55.197.143 with SMTP id k15mr4843452qkl.105.1502744084442; Mon, 14 Aug 2017 13:54:44 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id g37sm6069624qtb.20.2017.08.14.13.54.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 13:54:43 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_23BE3027-3858-467F-9E3D-56A472BB6F95" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 14 Aug 2017 16:54:42 -0400 In-Reply-To: <87lgmnxr3u.fsf@toke.dk> Cc: Juliusz Chroboczek , HOMENET To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 20:54:48 -0000 --Apple-Mail=_23BE3027-3858-467F-9E3D-56A472BB6F95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 El 13 ag 2017, a les 14:25, Toke H=C3=B8iland-J=C3=B8rgensen = va escriure: >> El 13 ag 2017, a les 11:49, Toke H=C3=B8iland-J=C3=B8rgensen = > va escriure: >>> In any case, the failure mode of getting a it wrong is a sub-optimal >>> path being chosen; but if ISP A's DNS server takes five seconds to >>> respond, we'd get a better result from just using the timely answer = from >>> ISP B's and going over the suboptimal path to get to the content (in >>> many cases, at least). >>=20 >> Not if the suboptimal path has substantially worse performance for = the >> duration of the session. >=20 > Sure, it depends on the particular application (hence the "in many > cases" in my original statement)... My point is just that it's not an > obvious across the board win. Indeed. However, it is never a lose. >>> But only the client can make that coupling (from DNS reply to = connection >>> attempt). So if we're just filtering the result set based on the = address >>> the client uses (which is how I interpret what you put in the = draft), >>> we're degrading the experience for any client that doesn't know how = to >>> repeat the query from another source address. So we'd effectively be >>> requiring hosts to support MPvD; and we're not supposed to require = host >>> changes, are we? >>=20 >> Many hosts we care about already support MPvD because the companies >> that sell the software that runs on those hosts think it solves a >> useful problem. Adding support for MPvD on the homenet is a >> relatively small change now that their stacks already support it. >=20 > Right, so we're adding it as an extra service for hosts that support = it? > That is fine with me, but then it shouldn't be a requirement. I.e., we > can go "supporting MPvD is a good idea, and here is how you do it > correctly", rather than the current "must support" language. If we don't require it, we can assume that it will not be supported. = It is likely that most hosts will support it, so if we don't support it, = we are missing an opportunity to make things work well on the homenet, = not just failing to add a "nice to have" feature. >> As for a "degraded experience," do you mean that if we select one >> upstream provider for a particular client, that's going to result in = a >> degraded experience for the user? Why would that be the case? >=20 > I mean that if we query all upstreams we get the best aggregate > performance from all available DNS servers. Whereas if we limit = queries > to a particular ISP, we only get as good performance as that = particular > ISP can provide. If that was going to be the best on anyway, fine. If > not, we are worse off by limiting queries to that ISP. If one ISP is performing substantially worse than the other, the right = thing to do is use only the one that's performing well. Neither "doing = nothing" nor "doing MPvDs" accomplishes this end. However, "doing = MPvDs" arguably comes closer. The downside is that if the lousy ISP = wins, hosts are stuck with it. This is a serious problem. It may = indeed be the case that a better choice for non-MPvD hosts is to give = them a name server that fans out to both ISPs. >>> I can see how these scenarios make sense for a device that know the >>> types of connection (like a cell phone with cellular and WiFi = links). >>> Less so in the home, where all the client sees are different = prefixes; >>> in this case, either the network has to enforce policy (like the >>> failover scenario), or we'll have to communicate more information to = the >>> hosts, which goes back to my point above about host changes... >>=20 >> Yes, in order to make this work we have to communicate additional >> information to the host, and the host has to use it. That's why I >> described a fallback solution for hosts that don't support this. It's >> not clear that the solution I described is the right one, of course; >> the point of saying something there was to have a place where we can >> write whatever the advice is that we decide to give when we figure >> this out; what I described would work, but it's possible that an >> entirely RA-based solution would work just as well, in which case >> personally I'd prefer it. >=20 > How do non-MPvD-aware hosts react to an announcement of an = MPvD-specific > DNS server? Does it ignore the server entirely, or does it ignore the > PvD information and use the server anyway? It has to be announced in such a way that non-MPvD hosts don't see it. --Apple-Mail=_23BE3027-3858-467F-9E3D-56A472BB6F95 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 El 13 ag 2017, a les 14:25, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> va = escriure:
El 13 ag 2017, a les 11:49, = Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> va escriure:
In any case, the failure mode of getting a it = wrong is a sub-optimal
path being chosen; but if ISP A's = DNS server takes five seconds to
respond, we'd get a = better result from just using the timely answer from
ISP = B's and going over the suboptimal path to get to the content (in
many cases, at least).

Not if the suboptimal path has substantially worse = performance for the
duration of the session.

Sure, it depends on = the particular application (hence the "in many
cases" in my original statement)... My point is = just that it's not an
obvious across the = board win.

Indeed.  However, it is never a = lose.

But only the client can make that coupling (from DNS reply to = connection
attempt). So if we're just filtering the result = set based on the address
the client uses (which is how I = interpret what you put in the draft),
we're degrading the = experience for any client that doesn't know how to
repeat = the query from another source address. So we'd effectively be
requiring hosts to support MPvD; and we're not supposed to = require host
changes, are we?
Many hosts we care about already support MPvD because the = companies
that sell the software that runs on those hosts = think it solves a
useful problem.   Adding = support for MPvD on the homenet is a
relatively small = change now that their stacks already support it.

Right, so we're = adding it as an extra service for hosts that support it?
That is fine with me, but then it shouldn't be a = requirement. I.e., we
can go "supporting = MPvD is a good idea, and here is how you do it
correctly", rather than the current "must = support" language.

If we don't = require it, we can assume that it will not be supported.   It is = likely that most hosts will support it, so if we don't support it, we = are missing an opportunity to make things work well on the homenet, not = just failing to add a "nice to have" feature.

As for a "degraded = experience," do you mean that if we select one
upstream = provider for a particular client, that's going to result in a
degraded experience for the user?   Why would that = be the case?

I mean that if we = query all upstreams we get the best aggregate
performance from all available DNS servers. = Whereas if we limit queries
to a particular = ISP, we only get as good performance as that particular
ISP can provide. If that was going to be the = best on anyway, fine. If
not, we are worse = off by limiting queries to that ISP.

If one ISP = is performing substantially worse than the other, the right thing to do = is use only the one that's performing well.   Neither "doing = nothing" nor "doing MPvDs" accomplishes this end.   However, "doing = MPvDs" arguably comes closer.   The downside is that if the lousy = ISP wins, hosts are stuck with it.   This is a serious problem. =   It may indeed be the case that a better choice for non-MPvD hosts = is to give them a name server that fans out to both = ISPs.

I can see how these scenarios make sense for a device that = know the
types of connection (like a cell phone with = cellular and WiFi links).
Less so in the home, where all = the client sees are different prefixes;
in this case, = either the network has to enforce policy (like the
failover = scenario), or we'll have to communicate more information to the
hosts, which goes back to my point above about host = changes...

Yes, in order to = make this work we have to communicate additional
information= to the host, and the host has to use it. That's why I
described a fallback solution for hosts that don't support = this. It's
not clear that the solution I described is the = right one, of course;
the point of saying something there = was to have a place where we can
write whatever the advice = is that we decide to give when we figure
this out; what I = described would work, but it's possible that an
entirely = RA-based solution would work just as well, in which case
personally I'd prefer it.

How do non-MPvD-aware hosts react to an = announcement of an MPvD-specific
DNS server? Does it = ignore the server entirely, or does it ignore the
PvD information and use the server = anyway?

It has to be announced in such a way that non-MPvD = hosts don't see it.

= --Apple-Mail=_23BE3027-3858-467F-9E3D-56A472BB6F95-- From nobody Mon Aug 14 13:55:33 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C46913242C for ; Mon, 14 Aug 2017 13:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 ksKJfmreITAa for ; Mon, 14 Aug 2017 13:55:31 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 EE06413242B for ; Mon, 14 Aug 2017 13:55:30 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id d145so57326857qkc.2 for ; Mon, 14 Aug 2017 13:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iHIHkPKBM6ePITYppttHJoYKH1CX9ZwxAloxyUsnu64=; b=1X4eo4DG0zu8URbamJ58DMjWaaDrBNxvEM1RPTUNxQsPXibHXQMsCT+tJqDapw0c0K 2cqswhzTGHCIjVWthE4CeEL3RpR/E1dSuxferTEum658JT1zprYjIgysqXOE4wPnU1vZ Bref+NofZihJcN3MLNs0kKISPAqgSYT+gu+/8DTs7Z2EyJ6xl73chSzwunOZGduozvLL rO4qxrZIoo7jcw8aEV+SBmhNn9t9MilX6z8DHRtQ6aCPYJYjkQoaVWoPp1aVbQBBFdqw M7gByHW6uA77BJhmrrqxtKK60cDq0NLQuC+gyawsaXKE54DbjJu86orae73TNLqQJ51e buzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iHIHkPKBM6ePITYppttHJoYKH1CX9ZwxAloxyUsnu64=; b=I/CzbVwL1sfsh8C5TM98lMFc8CssR052XcirfSlTHsXGIfO7GHegIWKO/rLsecDLcP XXef9DxPqWjNQ4s2AQ1mQkm+FoKP/1fqpiXCk1drImBWA1u7EgiHhcy6mz5DyyhYwUGA QtGONO+prlJHUPl0/M1wVrbAryR/gCqUcCR0mNvCPx02uZEh1Z8OY2AtCvcQCn14z3kE L+59MvGUJLXycCa+p7KEYcxBS0N/5nTrfGrJBB4cmaDZhmybZiYW82zuK0niP/4xixAk AfEjva8TVixPDvRZ3RL8JZPROc4880iN2djUIy5eZRVXRqIKPlC8tRAT6sYgWnN5t6BC E/Tw== X-Gm-Message-State: AHYfb5iNY33gnz3UJEE51aNkT13Lbz+tGmMAwxDtMaZNw9BNTV0LdvFH UKfFzMfjBdkxzYdXKKDpWg== X-Received: by 10.55.50.15 with SMTP id y15mr23235605qky.222.1502744130164; Mon, 14 Aug 2017 13:55:30 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id g37sm6069624qtb.20.2017.08.14.13.55.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 13:55:29 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_48256658-EC8A-4F59-BBFC-E2B44B2635FC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 14 Aug 2017 16:55:29 -0400 In-Reply-To: <871sod3npn.wl-jch@irif.fr> Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , HOMENET To: Juliusz Chroboczek References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <871sod3npn.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 20:55:32 -0000 --Apple-Mail=_48256658-EC8A-4F59-BBFC-E2B44B2635FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii El 14 ag 2017, a les 16:21, Juliusz Chroboczek va = escriure: > Now, the interaction between source-specific routing, BGP anycast, and > multipath at the higher layers, that's an interesting topic to argue = about. I actually disagree, but it's beside the point, because this is a = discussion about the homenet naming architecture. :) --Apple-Mail=_48256658-EC8A-4F59-BBFC-E2B44B2635FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 14 ag 2017, a les 16:21, Juliusz Chroboczek <jch@irif.fr> va = escriure:
Now, the = interaction between source-specific routing, BGP anycast, and
multipath at the higher layers, that's an = interesting topic to argue about.

I actually disagree, but it's beside the = point, because this is a discussion about the homenet naming = architecture. :)

= --Apple-Mail=_48256658-EC8A-4F59-BBFC-E2B44B2635FC-- From nobody Tue Aug 15 04:38:07 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D185B132195 for ; Tue, 15 Aug 2017 04:38:05 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 t_2TpXPfmvNh for ; Tue, 15 Aug 2017 04:38:03 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18E51320BE for ; Tue, 15 Aug 2017 04:38:02 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502797075; bh=DLG3RBLht02TeljqxeETeuW05Qi15GELHqU+Nvealhw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XsfhH1bDnMzL1NAn3DFA7PjANbsxvWcYfrihamBmvA1lv7Sx4zoPV8K4lkyxcCdru 9xxxE8fpOTyZRumW7lCj6zQSjCSNCHe/oqDAMuN+8x4takMo9FHPjXxUOVwdzsV3sU 5BNpvKPea1vpuVx1k/0roPebpud8qBCszJeJUPh8maEUkd/JqAIJ4d71YwXDe+3A1d JHNoJ+o3yQ/JIYHD7YHp5MYGzO1zJt4E+y88V0Fo796YCQEzdOTX+VIfw/Q1Ow0ZUp ZHVKrhNEg59K7CM5RAoKfukk6KOHh+SM87mijXafsoJGkTFTlzXmDQsldlketjIXqm M6ya/iEK4G5IQ== To: Ted Lemon Cc: Juliusz Chroboczek , HOMENET In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> Date: Tue, 15 Aug 2017 13:37:59 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87fuctxdrc.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 11:38:06 -0000 Ted Lemon writes: > El 13 ag 2017, a les 14:25, Toke H=C3=B8iland-J=C3=B8rgensen va escriure: >>> El 13 ag 2017, a les 11:49, Toke H=C3=B8iland-J=C3=B8rgensen > va escriure: >>>> In any case, the failure mode of getting a it wrong is a sub-optimal >>>> path being chosen; but if ISP A's DNS server takes five seconds to >>>> respond, we'd get a better result from just using the timely answer fr= om >>>> ISP B's and going over the suboptimal path to get to the content (in >>>> many cases, at least). >>>=20 >>> Not if the suboptimal path has substantially worse performance for the >>> duration of the session. >>=20 >> Sure, it depends on the particular application (hence the "in many >> cases" in my original statement)... My point is just that it's not an >> obvious across the board win. > > Indeed. However, it is never a lose. Erm, except when the suboptimal path does *not* have substantially worse performance for the duration of the session? CDNs are used for other things than Netflix... >>> Many hosts we care about already support MPvD because the companies >>> that sell the software that runs on those hosts think it solves a >>> useful problem. Adding support for MPvD on the homenet is a >>> relatively small change now that their stacks already support it. >>=20 >> Right, so we're adding it as an extra service for hosts that support it? >> That is fine with me, but then it shouldn't be a requirement. I.e., we >> can go "supporting MPvD is a good idea, and here is how you do it >> correctly", rather than the current "must support" language. > > If we don't require it, we can assume that it will not be supported. > It is likely that most hosts will support it, What are you basing this assessment on? > so if we don't support it, we are missing an opportunity to make > things work well on the homenet, not just failing to add a "nice to > have" feature. Well, I guess I'm not convinced that MPvD support is really required to 'make things work well'. But, well, if we can limit the complexity cost I guess that becomes less of a problem. >>> As for a "degraded experience," do you mean that if we select one >>> upstream provider for a particular client, that's going to result in a >>> degraded experience for the user? Why would that be the case? >>=20 >> I mean that if we query all upstreams we get the best aggregate >> performance from all available DNS servers. Whereas if we limit queries >> to a particular ISP, we only get as good performance as that particular >> ISP can provide. If that was going to be the best on anyway, fine. If >> not, we are worse off by limiting queries to that ISP. > > If one ISP is performing substantially worse than the other, the right > thing to do is use only the one that's performing well. Neither "doing > nothing" nor "doing MPvDs" accomplishes this end. However, "doing > MPvDs" arguably comes closer. Depending on the type of performance problem. If the performance problem is general, yes. If it is specific to DNS, there's no reason to not use the connection for other things; and the "send queries to all upstreams" solution will automatically converge to use the best-performing upstream. > The downside is that if the lousy ISP wins, hosts are stuck with it. > This is a serious problem. It may indeed be the case that a better > choice for non-MPvD hosts is to give them a name server that fans out > to both ISPs. On this we are agreed, I think :) >> How do non-MPvD-aware hosts react to an announcement of an MPvD-specific >> DNS server? Does it ignore the server entirely, or does it ignore the >> PvD information and use the server anyway? > > It has to be announced in such a way that non-MPvD hosts don't see it. Right, so if this is the case, how about we specify that routers MAY (or maybe even SHOULD) support MPvD-specific resolver addresses, and advertise the fact over HNCP. And that if a router receives such an announcement from another router it MUST announce the MPvD-specific resolver addresses over DHCP/RA. This way we ensure that *if* a router on the network implements MPvD it is going to work for the whole network; but routers can still opt to not implement the functionality itself if the implementer doesn't want to pay the implementation cost. -Toke From nobody Tue Aug 15 06:21:48 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5B8132198 for ; Tue, 15 Aug 2017 06:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 DwIcQsEXSVXq for ; Tue, 15 Aug 2017 06:21:44 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 23A431320D8 for ; Tue, 15 Aug 2017 06:21:44 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id v29so4121246qtv.3 for ; Tue, 15 Aug 2017 06:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tgB49eYNQHkCo7H0YSdvEh0IMplsqJT8X4XdV6NnArc=; b=M0SnQClipQbU8ahjvjbDQNTHDTqV2yueYqnqa/odIEBV0ihyrYgAIakd04HwL05t1s VtyC4Rqmaa0O3xMf5b4+Yk6jRs0WyGHKIJKIaEtYacLYWsx3rd2Bqb8uerq/AiYXTmJO UIz5K9h3ai3rnSqBHUFMSAZh1YU3TggPwYfGHJy47QnfpWTDTFnqtD8ilZy2SlfocKEh D4rdUtI/ywvajIpFU2Yfeejxuwtyde3qvIN0Dcs/vSeP0Uunk5Z3vYp2uecotyq9ynx8 fF8oMjiFgYT8vrx+5SiA8fbrwncDzmjyJYPAPuPB9fQH5WRgAw7P19rJaEi2dxIt19qj MeWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tgB49eYNQHkCo7H0YSdvEh0IMplsqJT8X4XdV6NnArc=; b=IbTFbHcumy/LHqgTr2pTsFewRvnCzCntN6MvNfudQN3nzSlPcKaNQcogSQzcwOlDvP FYL/wthtRWjSarfBuHvDvFsrL9GgyYg3RzX63sAhr+JxireIpG6do2aS+QRPsQDgd1KY jFFK6fJNFOzSJcwRcf6FAuK5wCRuOGhhZly+sGK9pCD0J9rug64DLIlK2ciZo3feRfwx aSB0U+Iac2qidYDTK8jAQf5qaoIuGiIeXm3/FuOLh1RPPVr3JTy+kt6b6sla31vhKQ6a qndLQeYv5oxK+MkHLhT7r7IQQWSIDGn+D3lScbcSn8f+OmhY8J8Ke+Qe3vTzRb3AnOq4 XVUw== X-Gm-Message-State: AHYfb5gs94q4UJN0pvgQYvscHgCtnqmUhmuXXCNiT538fe9VGGpv2fSo sRoFiHL5Lucee+JwKYN7cA== X-Received: by 10.200.39.105 with SMTP id h38mr39482983qth.268.1502803303145; Tue, 15 Aug 2017 06:21:43 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id r25sm6378557qki.42.2017.08.15.06.21.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 06:21:41 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_797AF541-8CF1-4838-8A2B-ED1DD72A91E1" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 15 Aug 2017 09:21:39 -0400 In-Reply-To: <87fuctxdrc.fsf@toke.dk> Cc: Juliusz Chroboczek , HOMENET To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87wp6byvw5.fsf@toke.dk> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 13:21:47 -0000 --Apple-Mail=_797AF541-8CF1-4838-8A2B-ED1DD72A91E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 El 15 ag 2017, a les 7:37, Toke H=C3=B8iland-J=C3=B8rgensen = va escriure: > Erm, except when the suboptimal path does *not* have substantially = worse > performance for the duration of the session? CDNs are used for other > things than Netflix... Simple answer: don't wait five seconds. > What are you basing this assessment on? The prevalence of support for MPvD in existing hosts? > Depending on the type of performance problem. If the performance = problem > is general, yes. If it is specific to DNS, there's no reason to not = use > the connection for other things; and the "send queries to all = upstreams" > solution will automatically converge to use the best-performing = upstream. I think we are wandering off into nonsense territory here. Have you = observed this sort of problem in the field? If so, can you describe = what happened? If not, why would we optimize for it? > Right, so if this is the case, how about we specify that routers MAY = (or > maybe even SHOULD) support MPvD-specific resolver addresses, and > advertise the fact over HNCP. And that if a router receives such an > announcement from another router it MUST announce the MPvD-specific > resolver addresses over DHCP/RA. This way we ensure that *if* a router > on the network implements MPvD it is going to work for the whole > network; but routers can still opt to not implement the functionality > itself if the implementer doesn't want to pay the implementation cost. Can you describe for us what this implementation cost is that you want = to avoid? --Apple-Mail=_797AF541-8CF1-4838-8A2B-ED1DD72A91E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 El 15 ag 2017, a les 7:37, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> va = escriure:
Erm, except when = the suboptimal path does *not* have substantially worse
performance for the duration of the session? = CDNs are used for other
things than = Netflix...

Simple = answer: don't wait five seconds.

What are you basing = this assessment on?

The prevalence of = support for MPvD in existing hosts?

Depending on the type = of performance problem. If the performance problem
is general, yes. If it = is specific to DNS, there's no reason to not use
the connection for = other things; and the "send queries to all upstreams"
solution will = automatically converge to use the best-performing upstream.

I think we are wandering off into nonsense = territory here.   Have you observed this sort of problem in the = field?   If so, can you describe what happened?   If not, why = would we optimize for it?

Right, so if this is the case, how about we specify that = routers MAY (or
maybe = even SHOULD) support MPvD-specific resolver addresses, and
advertise the fact over = HNCP. And that if a router receives such an
announcement from = another router it MUST announce the MPvD-specific
resolver addresses over = DHCP/RA. This way we ensure that *if* a router
on the network = implements MPvD it is going to work for the whole
network; but routers = can still opt to not implement the functionality
itself if the = implementer doesn't want to pay the implementation = cost.

Can you describe for = us what this implementation cost is that you want to = avoid?

= --Apple-Mail=_797AF541-8CF1-4838-8A2B-ED1DD72A91E1-- From nobody Tue Aug 15 07:44:22 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A9E1321CB; Tue, 15 Aug 2017 07:44:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: homenet-chairs@ietf.org, homenet@ietf.org, bs7652@att.com, terry.manderson@icann.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150280825956.21036.7719799040587283981.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 07:44:19 -0700 Archived-At: Subject: [homenet] homenet - New Meeting Session Request for IETF 100 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 14:44:20 -0000 A new meeting session request has just been submitted by Barbara Stark, a Chair of the homenet working group. --------------------------------------------------------- Working Group Name: Home Networking Area Name: Internet Area Session Requester: Barbara Stark Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: v6ops intarea dnsop dnssd 6man babel saag tls Second Priority: mptcp lpwan People who must be present: Stephen Farrell Terry Manderson Ray Bellis Barbara Stark Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Aug 15 12:38:50 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA6A126BF3 for ; Tue, 15 Aug 2017 12:38:48 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 3sytbwfRdMNB for ; Tue, 15 Aug 2017 12:38:46 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825271200F3 for ; Tue, 15 Aug 2017 12:38:46 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502825923; bh=dBCQjHFrDHnMbdrZxZQGOGHL8+GiEOjhaIN6+hrIuNw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=f273giSnHH94NuGVWIpPJ2Uigahsa0juuOvWh3DfrNIj+YbhUlsWfQ13uufd11kOJ G/wsU4SbEIpQcTHAVC97eK63Vo+d5eFx11NN0sClA7TSuhvyLzHm5e9ZieI1Xyn2h+ YSxgSoE265bhSWzNbGpyKok/K743lpmKLSPPDoGbBwjpmWLE2K6t+5XbGtA8yFpZx2 Hc2UYOVN+uwILB3A8lTYefjY6SVLWI4vYjz4e0G4GqtJKX/bCswzCjXwLpH26Wmq7y ZoKZmfn99RFcWYvHT1mVQ96GzS9Cml3tl+lVFf1HA0/YOTzEWKN9xZW+9gNIIupQDr 59FF8j6LRvF9w== To: Ted Lemon Cc: Juliusz Chroboczek , HOMENET In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> Date: Tue, 15 Aug 2017 21:38:47 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877ey4y62g.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 19:38:49 -0000 Ted Lemon writes: >> Depending on the type of performance problem. If the performance problem >> is general, yes. If it is specific to DNS, there's no reason to not use >> the connection for other things; and the "send queries to all upstreams" >> solution will automatically converge to use the best-performing upstream. > > I think we are wandering off into nonsense territory here. Have you > observed this sort of problem in the field? If so, can you describe > what happened? If not, why would we optimize for it? If you consider flaky ISP DNS servers to be "nonsense" you are clearly more fortunate with your ISPs than me. And that's before even going into the DNS censorship issue; in my part of the world ISP DNS servers are broken *by design*. >> Right, so if this is the case, how about we specify that routers MAY (or >> maybe even SHOULD) support MPvD-specific resolver addresses, and >> advertise the fact over HNCP. And that if a router receives such an >> announcement from another router it MUST announce the MPvD-specific >> resolver addresses over DHCP/RA. This way we ensure that *if* a router >> on the network implements MPvD it is going to work for the whole >> network; but routers can still opt to not implement the functionality >> itself if the implementer doesn't want to pay the implementation cost. > > Can you describe for us what this implementation cost is that you want > to avoid? Can you describe for us how multiplying the number of resolvers by N (or MxN if we follow your suggestion of running a full set of resolvers on every router) is *not* going to incur a significant implementation and debugability cost? -Toke From nobody Tue Aug 15 13:29:00 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58C41323C8 for ; Tue, 15 Aug 2017 13:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 TWb8UcqMFAyk for ; Tue, 15 Aug 2017 13:28:55 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 56AE51323C7 for ; Tue, 15 Aug 2017 13:28:55 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id a18so10669078qta.0 for ; Tue, 15 Aug 2017 13:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zlAbnbUEXp3wL3ZD4JehXAcGdK6kWuh3dXugSvlgoFc=; b=XiptRZ87f4Rj708MqJ81Tmw4wWDKN/SSzwFujldXHvoDLqhXeZOhjDzfuA3Dq4P9wP fWq++2mcNTdbtg2yquDbEBvlId/rcHgjJhweKe62i+Eti2ZsqiohvhV/6bYAfUswjSls LLTolcGkJkqI6BLNm/xykynyvcWrfQ7T7U7g89U0jsVTyxGmaMOnG8RZWpoX2B/OucQt /8+TdFm0xxBKYrtnbrKsS4SSHKfnadCryexk+pdOgWafRhKeOjUtdeBR78TctWB3QCoO 8O5dskyqIUoimB5XPJjQjlSmVVl0WmMZAIJSWq4NQb2jTJdmIO+qfIEnATE4GawH14NJ 2cOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zlAbnbUEXp3wL3ZD4JehXAcGdK6kWuh3dXugSvlgoFc=; b=ktCd+mtiqZmD+3XoCgZ60qLejqaMp/Mo/hVSeWAmtdTm11+qS/PLSCMTAQKNJA0D/g 7bES0j6xIEXf5b5/oTm9LDBR6AO6pEvDyuSMZ2b94TpM+ZBnbSWh5Ct56u2kmGVFnUra KmSVBbjwZMOQcbZHLo7NREVC2Jf6oHRk/jdv9H5w1Ko8fP/dP8eeeLOPylc+C1CHCoqw 55zK/Nz0G9OnQ0KFG8EB8A7bIMJuAZvBMeWJssW+Q2AX4d/2gkhg4XowVDMVHdwdyiGd jGc3lUBMRCxpfZEFRpB1BE1zDiyWG6O3aCI4vtfYlvkrqd8eyPXanTvON47xDeMzPpT9 pHJw== X-Gm-Message-State: AHYfb5jNgTWn7zupEPahAFbgsQDYZ1i7g2cCY2BYPQKEwm8V4btuaiN7 AEqtEFSGQXqRiaWD X-Received: by 10.200.0.9 with SMTP id a9mr38177035qtg.107.1502828934401; Tue, 15 Aug 2017 13:28:54 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id z199sm7026404qka.94.2017.08.15.13.28.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 13:28:53 -0700 (PDT) From: Ted Lemon Message-Id: <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6201853B-136F-4EA2-86AD-E56F4F89CA3C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 15 Aug 2017 16:28:52 -0400 In-Reply-To: <877ey4y62g.fsf@toke.dk> Cc: Juliusz Chroboczek , HOMENET To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 20:28:58 -0000 --Apple-Mail=_6201853B-136F-4EA2-86AD-E56F4F89CA3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 El 15 ag 2017, a les 15:38, Toke H=C3=B8iland-J=C3=B8rgensen = va escriure: >> I think we are wandering off into nonsense territory here. Have you >> observed this sort of problem in the field? If so, can you describe >> what happened? If not, why would we optimize for it? >=20 > If you consider flaky ISP DNS servers to be "nonsense" you are clearly > more fortunate with your ISPs than me. And that's before even going = into > the DNS censorship issue; in my part of the world ISP DNS servers are > broken *by design*. In both of these cases, you are better off doing what we discussed = earlier and setting up your own DNS cache, possibly with a whitelist for = domains you want to send to the ISP forwarder. >>> Right, so if this is the case, how about we specify that routers MAY = (or >>> maybe even SHOULD) support MPvD-specific resolver addresses, and >>> advertise the fact over HNCP. And that if a router receives such an >>> announcement from another router it MUST announce the MPvD-specific >>> resolver addresses over DHCP/RA. This way we ensure that *if* a = router >>> on the network implements MPvD it is going to work for the whole >>> network; but routers can still opt to not implement the = functionality >>> itself if the implementer doesn't want to pay the implementation = cost. >>=20 >> Can you describe for us what this implementation cost is that you = want >> to avoid? >=20 > Can you describe for us how multiplying the number of resolvers by N = (or > MxN if we follow your suggestion of running a full set of resolvers on > every router) is *not* going to incur a significant implementation and > debugability cost? It's just a bunch of ports/address pairs, with one thing listening on = all of them, and using the port/address pair as a behavioral selector. = I'm not going to say that it's zero effort, but it's not hard. = Honestly, every home router right now has some kind of DNS proxy or DNS = resolver in it; this is not a big change. Compared to, say, = implementing HNCP or DNSSD, it's utterly trivial. --Apple-Mail=_6201853B-136F-4EA2-86AD-E56F4F89CA3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 El 15 ag 2017, a les 15:38, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> va = escriure:
I think we are wandering off = into nonsense territory here.   Have you
observed = this sort of problem in the field?   If so, can you = describe
what happened?   If not, why would we = optimize for it?

If you consider = flaky ISP DNS servers to be "nonsense" you are clearly
more fortunate with your ISPs than me. And = that's before even going into
the DNS censorship = issue; in my part of the world ISP DNS servers are
broken *by design*.

In both of these = cases, you are better off doing what we discussed earlier and setting up = your own DNS cache, possibly with a whitelist for domains you want to = send to the ISP forwarder.

Right, so if this is the = case, how about we specify that routers MAY (or
maybe even = SHOULD) support MPvD-specific resolver addresses, and
advertise the fact over HNCP. And that if a router receives = such an
announcement from another router it MUST announce = the MPvD-specific
resolver addresses over DHCP/RA. This = way we ensure that *if* a router
on the network implements = MPvD it is going to work for the whole
network; but = routers can still opt to not implement the functionality
itself if the implementer doesn't want to pay the = implementation cost.

Can you = describe for us what this implementation cost is that you want
to avoid?

Can you describe = for us how multiplying the number of resolvers by N (or
MxN if we follow your suggestion of running a = full set of resolvers on
every router) is = *not* going to incur a significant implementation and
debugability cost?

It's = just a bunch of ports/address pairs, with one thing listening on all of = them, and using the port/address pair as a behavioral selector.   = I'm not going to say that it's zero effort, but it's not hard.   = Honestly, every home router right now has some kind of DNS proxy or DNS = resolver in it; this is not a big change.   Compared to, say, = implementing HNCP or DNSSD, it's utterly trivial.
= --Apple-Mail=_6201853B-136F-4EA2-86AD-E56F4F89CA3C-- From nobody Tue Aug 15 16:32:13 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B83132444 for ; Tue, 15 Aug 2017 16:32:11 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 mlZYgrVOZXzE for ; Tue, 15 Aug 2017 16:32:09 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE2C3132442 for ; Tue, 15 Aug 2017 16:32:08 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502839925; bh=en1C2Eg7BpFL5TWlmveuJ/PCTWjNNN3PyZK7Hpw9Xw8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=b0nmIC5BW/iSB7cwDmj2YbN0wvL4rPG7l+qfcvdyc5/wQK3oovKIkodEAJZlRJrPh 1ALukUhLH3u+LdJN3gbXhnIYL3ZsWpnAnMtecPQ0EH1CadnNqS4OzbY1BSaqzz8B15 HZtqAON4NDXvn4aV88MuSsrTn7UmmfjmIiw6riiodVvRADeAA6y+EObUODQNe2ZthE NnYor0JJH5yi/5X31aukbojh9oMlB9hespmx/KnfQlS8mPhTnhYHJxh2NogYZrofdW XQuOLyug3ORV9delHRCzQdilPUf3QseeaxpKv0G3I7d97LxXZrdaes3wa83RO+xP96 dFrBV7sOfq9eg== To: Ted Lemon Cc: Juliusz Chroboczek , HOMENET In-Reply-To: <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> Date: Wed, 16 Aug 2017 01:32:08 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <874lt8xv9j.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 23:32:11 -0000 Ted Lemon writes: > El 15 ag 2017, a les 15:38, Toke H=C3=B8iland-J=C3=B8rgensen va escriure: >>> I think we are wandering off into nonsense territory here. Have you >>> observed this sort of problem in the field? If so, can you describe >>> what happened? If not, why would we optimize for it? >>=20 >> If you consider flaky ISP DNS servers to be "nonsense" you are clearly >> more fortunate with your ISPs than me. And that's before even going into >> the DNS censorship issue; in my part of the world ISP DNS servers are >> broken *by design*. > > In both of these cases, you are better off doing what we discussed > earlier and setting up your own DNS cache, possibly with a whitelist > for domains you want to send to the ISP forwarder. Sure, and that's what I usually do. But if we can't specify that behaviour for homenet, at least trying all upstream DNS servers gives a better chance of finding one that works. >>>> Right, so if this is the case, how about we specify that routers MAY (= or >>>> maybe even SHOULD) support MPvD-specific resolver addresses, and >>>> advertise the fact over HNCP. And that if a router receives such an >>>> announcement from another router it MUST announce the MPvD-specific >>>> resolver addresses over DHCP/RA. This way we ensure that *if* a router >>>> on the network implements MPvD it is going to work for the whole >>>> network; but routers can still opt to not implement the functionality >>>> itself if the implementer doesn't want to pay the implementation cost. >>>=20 >>> Can you describe for us what this implementation cost is that you want >>> to avoid? >>=20 >> Can you describe for us how multiplying the number of resolvers by N (or >> MxN if we follow your suggestion of running a full set of resolvers on >> every router) is *not* going to incur a significant implementation and >> debugability cost? > > It's just a bunch of ports/address pairs, with one thing listening on > all of them, and using the port/address pair as a behavioral selector. > I'm not going to say that it's zero effort, but it's not hard. > Honestly, every home router right now has some kind of DNS proxy or > DNS resolver in it; this is not a big change. Compared to, say, > implementing HNCP or DNSSD, it's utterly trivial. You may be right that hacking up a working prototype isn't that hard. But the failure modes change from "the internet is down" or may "I cannot access site A", to "site A is working every third attempt, except it is entirely broken on device X" maybe even with an added "ah, but it works on device X if I go into the kitchen". Hmm, while writing this is occurred to me that it might make sense to just export the ISP DNS server(s) directly in the MPvD-only RAs? -Toke From nobody Tue Aug 15 17:33:09 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233D01323D4 for ; Tue, 15 Aug 2017 17:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 WKTD8h7qG8_6 for ; Tue, 15 Aug 2017 17:33:06 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 C3D6F1323B0 for ; Tue, 15 Aug 2017 17:33:05 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id u139so12685566qka.1 for ; Tue, 15 Aug 2017 17:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4FiczzGjjOcQG6VX+Yr6XXq++64elkd4wHAXYRm8Ezg=; b=GEbw2vUvPiOvo1Fj2h4tkW5H5RD/ZC6lCgPBeqLJKsY1403YsuQLWRdccTbQ0YhHHE z76mctuo82n18KAm7D4chmbfrtP21nzNdDUCVtrLKS6fD+bZSXZ82nR9gKiTRAjEfCUg 4qM4jBh9Wf8xDhBRzjgH0s7lHZUqUOuEv0QD4hn318O7c8Bk9zoeDfMyjFIv0ObIpxcS pn36M9WzIWOVmHnBupyDpBt7jbMVl1D86HZAds9v8Vl8ZX0Y6wJPNHPZCkT3wUz+EfpK zZLzA12ClspGNKZiMUjILHI+/hQx9rxBbFW8kMYOB6GwJha9YDPEvTFmBPnspu1qd4K8 +W2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4FiczzGjjOcQG6VX+Yr6XXq++64elkd4wHAXYRm8Ezg=; b=q/PTtUG2gkhCFKE/ED8IlfV41x9urQ28TVcBIyLDZzOWAJNa/VuDumx6Z05ECBADUO fainJXcbYlCjKJ+yYpxr1YqWOv1QBwJynMAWQnJHM5dZMGLkjyX6Gn4xEDynkTFos8Jo /ZPymVfrVQ2Y07RsXre32KZCOPUQADsIAkTyNFpoKKApp61eE08teMif6EPjERPGmGak 7a9k0GleYXWzlzGZgsVPpPynwbyBu0VyF5KaAEfwdBKSDWu7ybPZW8kf9GclLEjwm6Gf zpkl1qFcVEO6OSb2NMXUZq4M0DPgUyyR3v47rMbd8pc+up/O92PabOW1wd777SDWkHGZ 3t1g== X-Gm-Message-State: AHYfb5gXIrPi6ZwhidRGnIBE4XiaJZMkBT4E0sCRfIGQY8ZMbc8I2Zl9 bVS2s8Fc+myzzNAom/4qeQ== X-Received: by 10.55.182.6 with SMTP id g6mr13763519qkf.326.1502843584760; Tue, 15 Aug 2017 17:33:04 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id j90sm7489274qtb.73.2017.08.15.17.33.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 17:33:03 -0700 (PDT) From: Ted Lemon Message-Id: <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EEAB72F5-7369-4B39-B171-618949500E19" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 15 Aug 2017 20:33:02 -0400 In-Reply-To: <874lt8xv9j.fsf@toke.dk> Cc: Juliusz Chroboczek , HOMENET To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <874lt8xv9j.fsf@toke.dk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 00:33:08 -0000 --Apple-Mail=_EEAB72F5-7369-4B39-B171-618949500E19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 El 15 ag 2017, a les 19:32, Toke H=C3=B8iland-J=C3=B8rgensen = va escriure: >> In both of these cases, you are better off doing what we discussed >> earlier and setting up your own DNS cache, possibly with a whitelist >> for domains you want to send to the ISP forwarder. >=20 > Sure, and that's what I usually do. But if we can't specify that > behaviour for homenet, at least trying all upstream DNS servers gives = a > better chance of finding one that works. I'm really sorry, but I'm actually having trouble contextualizing the = failure mode that you are talking about here. Didn't I agree with you = in a previous message that we should try all the upstream DNS servers? > You may be right that hacking up a working prototype isn't that hard. > But the failure modes change from "the internet is down" or may "I > cannot access site A", to "site A is working every third attempt, = except > it is entirely broken on device X" maybe even with an added "ah, but > it works on device X if I go into the kitchen". Didn't we agree that we aren't round-robining? > Hmm, while writing this is occurred to me that it might make sense to > just export the ISP DNS server(s) directly in the MPvD-only RAs? This would certainly work, but now you can't have your nice local = resolver that does what you want. However, I think you are right that = this is the right default behavior for MPvD-aware devices. --Apple-Mail=_EEAB72F5-7369-4B39-B171-618949500E19 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 El 15 ag 2017, a les 19:32, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> va = escriure:
In both of these cases, you = are better off doing what we discussed
earlier and setting = up your own DNS cache, possibly with a whitelist
for = domains you want to send to the ISP forwarder.

Sure, and that's = what I usually do. But if we can't specify that
behaviour for homenet, at least trying all = upstream DNS servers gives a
better chance of = finding one that works.

I'm really = sorry, but I'm actually having trouble contextualizing the failure mode = that you are talking about here.   Didn't I agree with you in a = previous message that we should try all the upstream DNS = servers?

You may be right that hacking up a working prototype isn't = that hard.
But the failure modes change from "the = internet is down" or may "I
cannot access site = A", to "site A is working every third attempt, except
it is entirely broken on device X" maybe even = with an added "ah, but
it works on device = X if I go into the kitchen".

Didn't we agree = that we aren't round-robining?

Hmm, while writing this is occurred to me = that it might make sense to
just export the ISP = DNS server(s) directly in the MPvD-only RAs?

This = would certainly work, but now you can't have your nice local resolver = that does what you want.   However, I think you are right that this = is the right default behavior for MPvD-aware devices.

= --Apple-Mail=_EEAB72F5-7369-4B39-B171-618949500E19-- From nobody Wed Aug 16 00:55:31 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD874132510 for ; Wed, 16 Aug 2017 00:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 R818_ROeKcxq for ; Wed, 16 Aug 2017 00:55:28 -0700 (PDT) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4509A132551 for ; Wed, 16 Aug 2017 00:55:27 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id AEB085F40455; Wed, 16 Aug 2017 09:55:20 +0200 (CEST) Received: from [172.20.10.3] (tmo-100-232.customers.d1-online.com [80.187.100.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 2E4795F4004A; Wed, 16 Aug 2017 09:55:18 +0200 (CEST) From: "Ralf Weber" To: "Toke =?utf-8?b?SMO4aWxhbmQtSsO4cmdlbnNlbg==?=" Cc: "Ted Lemon" , HOMENET , "Juliusz Chroboczek" Date: Wed, 16 Aug 2017 09:55:22 +0200 Message-ID: In-Reply-To: <877ey4y62g.fsf@toke.dk> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 07:55:30 -0000 Moin! On 15 Aug 2017, at 21:38, Toke Høiland-Jørgensen wrote: > Ted Lemon writes: >> I think we are wandering off into nonsense territory here. Have you >> observed this sort of problem in the field? If so, can you describe >> what happened? If not, why would we optimize for it? > > If you consider flaky ISP DNS servers to be "nonsense" you are clearly > more fortunate with your ISPs than me. And that's before even going into > the DNS censorship issue; in my part of the world ISP DNS servers are > broken *by design*. And we wonder why there is no ISP/operator participation in the IETF... Your email address indicates you live in Denmark. I personally know people at ISPs in Denmark who run DNS resolvers for their customers and I in a previous job ran DNS servers for customers in Denmark, although the actual servers where located in Sweden and Germany. I can assure you that neither I nor my colleagues design DNS servers to be broken. If you have an issue with your ISP open a ticket with them and if they can't fix it switch ISPs. But don't blame all the ISPs to deliver broken service, without evidence. So long -Ralf From nobody Wed Aug 16 06:26:45 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B5C1252BA for ; Wed, 16 Aug 2017 06:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 NPIkD1wYeQHd for ; Wed, 16 Aug 2017 06:26:43 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C4F13213F for ; Wed, 16 Aug 2017 06:26:42 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502889995; bh=OTqO1KhibQvQdO9GH6EXlTJoQ5CxVedKBdMJmWmiCFE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OJLo3hwKtbU2MDeyWG1JzXj1iPhVlMiDdPsH4J8g759pWp2xag0mydXJYQxs+Wftn 3luo0CM8bCD5kUY/Hew+SxiH14TuXQlDfSHTTfdz9yEHaPXbSFjuzDIUhG3XplG5VO xAxg3l2c6/1dpoY4D/fYAfnfBgi94ZuEfU3hpbqFPnJxar7Vzu/plAxXjZurHq4UkS kIlUkuSQoNfHniYYd0Bcf/igm/3fK/FjI67Z4vTxwHH4gUCML+9z8ZMXbcHWtlO0GZ je51/LbOYZEBCx2k5wKCJRkaMxDj4RRRJqQ0Tp6mDuBko46SMFWY2SdYVkdh9rRsHe aQWnPTqrGjY3g== To: Ted Lemon Cc: Juliusz Chroboczek , HOMENET In-Reply-To: <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <874lt8xv9j.fsf@toke.dk> <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> Date: Wed, 16 Aug 2017 15:26:37 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <871soby776.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 13:26:45 -0000 Ted Lemon writes: > El 15 ag 2017, a les 19:32, Toke H=C3=B8iland-J=C3=B8rgensen va escriure: >>> In both of these cases, you are better off doing what we discussed >>> earlier and setting up your own DNS cache, possibly with a whitelist >>> for domains you want to send to the ISP forwarder. >>=20 >> Sure, and that's what I usually do. But if we can't specify that >> behaviour for homenet, at least trying all upstream DNS servers gives a >> better chance of finding one that works. > > I'm really sorry, but I'm actually having trouble contextualizing the > failure mode that you are talking about here. Didn't I agree with > you in a previous message that we should try all the upstream DNS > servers? Hmm, right, I guess you did. My point was more that an MPvD-aware client that only uses on PvD may experience worse performance than one that uses the in-home resolver. But I guess the client should be smart enough to deal with that? >> You may be right that hacking up a working prototype isn't that hard. >> But the failure modes change from "the internet is down" or may "I >> cannot access site A", to "site A is working every third attempt, except >> it is entirely broken on device X" maybe even with an added "ah, but >> it works on device X if I go into the kitchen". > > Didn't we agree that we aren't round-robining? Yeah, but I was referring to the failure mode for MPvD vs non-MPvD clients. I.e. if one of the resolvers fails for whatever reason, only MPvD-aware clients that happen to select that PvD will notice; whereas if there's only one resolver it will be very obvious when it's not working... >> Hmm, while writing this is occurred to me that it might make sense to >> just export the ISP DNS server(s) directly in the MPvD-only RAs? > > This would certainly work, but now you can't have your nice local > resolver that does what you want. However, I think you are right > that this is the right default behavior for MPvD-aware devices. I would keep the in-home resolver for clients that do not support MPvD; and probably also announce it as a separate PvD for MPvD-aware clients? Also, I think I would prefer running a single resolver in the home, rather than running one on every router. -Toke From nobody Wed Aug 16 06:34:00 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F88132196 for ; Wed, 16 Aug 2017 06:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 z2qdbJWFCRV8 for ; Wed, 16 Aug 2017 06:33:55 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A59513213F for ; Wed, 16 Aug 2017 06:33:55 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502890432; bh=xmd/iBvBlJSwcPgzdvi9khJDVNPuMAZ6xeloOR79w+8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=uh1ULwvn894+eAkFGX1SxLm8/hPsjoh4Px1lU/Q3Q8kznO9GwIV2QjP+YWgaM9d7c UOy5fkz+RGMEOinUFgZBUVLrwfks7KhtkSTNqMd8qpXxL8lp42ipIX1/51Hla5PGOH yIlNb8ksJoB7r8DMlQ52b2ctkiJS2V8AsF+b5Ot9QrwLvidWH3BnXx8DkMQ959GMFP 4grMsI/bGL2hBc9BmcpwlnZSOIKLPqpr1MW92Yf0iYPUbCDfTEUDXccQOlfAveG55h SJIg4F8cmyQr7b3MGp83Ww7Zpbdcm7n8lXNs+TnyWuUrCu/3xaz+99tMXtXlis3b1T kkL2SNbi3iVvw== To: Ralf Weber Cc: Ted Lemon , HOMENET , Juliusz Chroboczek In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> Date: Wed, 16 Aug 2017 15:33:55 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87y3qjwsak.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 13:33:57 -0000 Ralf Weber writes: > Moin! > > On 15 Aug 2017, at 21:38, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> Ted Lemon writes: >>> I think we are wandering off into nonsense territory here. Have you >>> observed this sort of problem in the field? If so, can you describe >>> what happened? If not, why would we optimize for it? >> >> If you consider flaky ISP DNS servers to be "nonsense" you are clearly >> more fortunate with your ISPs than me. And that's before even going into >> the DNS censorship issue; in my part of the world ISP DNS servers are >> broken *by design*. > And we wonder why there is no ISP/operator participation in the IETF... > Your email address indicates you live in Denmark. I personally know people > at ISPs in Denmark who run DNS resolvers for their customers and I in a > previous job ran DNS servers for customers in Denmark, although the actual > servers where located in Sweden and Germany. I can assure you that neither > I nor my colleagues design DNS servers to be broken. If you have an issue > with your ISP open a ticket with them and if they can't fix it switch ISP= s. > But don't blame all the ISPs to deliver broken service, without > evidence. Ah, I wasn't trying to imply that ISPs deliberately design sub-par services just to annoy their customers; sorry if it came across that way. My "broken by design" comment was referring specifically to DNS-based censorship [1]. -Toke [1] https://en.wikipedia.org/wiki/Censorship_in_denmark#Internet_censorship From nobody Wed Aug 16 06:37:25 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8551320D9 for ; Wed, 16 Aug 2017 06:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 glPF8L1twwve for ; Wed, 16 Aug 2017 06:37:21 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 BD2FF13201E for ; Wed, 16 Aug 2017 06:37:20 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id o124so11515304qke.3 for ; Wed, 16 Aug 2017 06:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RUwsglaYW+jRU/YAoshaUjcnzMvExvmPJneHrD1YHjg=; b=p+Ni9hojsRVVvp1O6XE+W6RXtZEFOCYJmj1Zoh1RTMqkM2H37crLfVA0+EHZy79B6f 6dewNK4voq/5ZaPhczBD5mZ+LMHOEX+t7Ag+62XxjvDS/OtOgpTL8GC4K64xcvOHTZiT +w22gq2AOTZKB+yayvtZl1zuXNrCXew3FTumjNZ700tJioFCi4UCiahrEW7d05cwWbsQ scx1vCQeWzoh1pcUK5uRQ5QY7Dk/4QjfcDh1JjjhDnqQujOdear6cc6gcbvfIXRTvF2B LSAr71Qyyjz4b3O5ull5uLl4P/1W6v9Q9F59q1UGo3g9XBb/4i1UwQQpzX3UsIc54dMu N/7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RUwsglaYW+jRU/YAoshaUjcnzMvExvmPJneHrD1YHjg=; b=L0Kh7vuyLCOS8uy+B+T6rlt/72vUQOl04jdFPBwEitkXsh5Zzvy+lHu7tmOshKVc+F 1aURIrYVIXUkg9qMULcbs0R/VkFVirYdNMr6wWJim0Zr9X7tdbcggnhLlEWQ+W2EzKCK E/ey95kbf+kjaUunhJr/NEj+ApwxbYATNDQg4Nsp7PRAAcq2rQSeHfBDN0TGMPAMylKu ipRvhhK1IPQ2DwvYx1iA5RnIMP20kIr/A2xb1ZHyT3vWpVUHnfXDfGs8tXc2xnDWvU5l zojD4qs1Cm9Q2qJmF2N1COixfSgIgXH4ZZ4ibi0w13EpPY0Y0TKQc/ZQibzQYNP5C4I7 JjFQ== X-Gm-Message-State: AHYfb5hQpAJ3HnNympncWHCQj9SQIX0U9kh790jI+H0DUt51yl+SMrUf MzonWBDTYMWy2OV+ X-Received: by 10.55.215.28 with SMTP id m28mr2264362qki.318.1502890639860; Wed, 16 Aug 2017 06:37:19 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id q19sm587998qta.2.2017.08.16.06.37.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 06:37:19 -0700 (PDT) From: Ted Lemon Message-Id: <769C4508-BB58-4BCB-A3CE-3657FB43A8AA@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EE2D7AA2-87E5-42D6-AFC6-8201F346D6F4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 16 Aug 2017 09:37:17 -0400 In-Reply-To: <871soby776.fsf@toke.dk> Cc: Juliusz Chroboczek , HOMENET To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <874lt8xv9j.fsf@toke.dk> <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> <871soby776.fsf@toke.dk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 13:37:23 -0000 --Apple-Mail=_EE2D7AA2-87E5-42D6-AFC6-8201F346D6F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 El 16 ag 2017, a les 9:26, Toke H=C3=B8iland-J=C3=B8rgensen = va escriure: > Ted Lemon > writes: >=20 >> El 15 ag 2017, a les 19:32, Toke H=C3=B8iland-J=C3=B8rgensen = va escriure: >>>> In both of these cases, you are better off doing what we discussed >>>> earlier and setting up your own DNS cache, possibly with a = whitelist >>>> for domains you want to send to the ISP forwarder. >>>=20 >>> Sure, and that's what I usually do. But if we can't specify that >>> behaviour for homenet, at least trying all upstream DNS servers = gives a >>> better chance of finding one that works. >>=20 >> I'm really sorry, but I'm actually having trouble contextualizing the >> failure mode that you are talking about here. Didn't I agree with >> you in a previous message that we should try all the upstream DNS >> servers? >=20 > Hmm, right, I guess you did. My point was more that an MPvD-aware = client > that only uses on PvD may experience worse performance than one that > uses the in-home resolver. But I guess the client should be smart > enough to deal with that? I think this is a real edge case. You have two connections, the DNS = server on one of them is broken, the DNS server on the other is not, but = the second connection performs so much worse than the first that you'd = rather use an answer from the DNS server on the second to contact a = service on the first. If you were in an engineering staff meeting trying to justify adding = extra code to do this, what would you have to say to get the group to = agree to do the work? What would that code look like? Sometimes things are just broken. Expecting a homenet router to solve = every possible configuration screwup on the part of the ISP isn't = realistic. As customers of these ISPs, we expect them to do a decent = job, and if an ISP fails often enough to make this code worth writing, = they probably need to be in a different business. >>> You may be right that hacking up a working prototype isn't that = hard. >>> But the failure modes change from "the internet is down" or may "I >>> cannot access site A", to "site A is working every third attempt, = except >>> it is entirely broken on device X" maybe even with an added "ah, but >>> it works on device X if I go into the kitchen". >>=20 >> Didn't we agree that we aren't round-robining? >=20 > Yeah, but I was referring to the failure mode for MPvD vs non-MPvD > clients. I.e. if one of the resolvers fails for whatever reason, only > MPvD-aware clients that happen to select that PvD will notice; whereas > if there's only one resolver it will be very obvious when it's not > working... That's not how PvDs work. You don't select one and only use that. = You try both. >>> Hmm, while writing this is occurred to me that it might make sense = to >>> just export the ISP DNS server(s) directly in the MPvD-only RAs? >>=20 >> This would certainly work, but now you can't have your nice local >> resolver that does what you want. However, I think you are right >> that this is the right default behavior for MPvD-aware devices. >=20 > I would keep the in-home resolver for clients that do not support = MPvD; > and probably also announce it as a separate PvD for MPvD-aware = clients? >=20 > Also, I think I would prefer running a single resolver in the home, > rather than running one on every router. I think there's some text in the document that was put in before I did = the dnssd discovery relay stuff and hasn't been updated since. There = does need to be a dnssd discovery relay running on every router. And = if the dnssd registration protocol is running over unicast, then we need = some kind of relay on port 53 on every router, so that we can tell that = the device that's doing the registration is on the local link. If we = do the registration through the discovery relay, this isn't necessary. = I don't remember how Stuart specified this, so I'm not sure. But the motivation for doing this is not that every router has to have a = caching recursive resolver running on it. --Apple-Mail=_EE2D7AA2-87E5-42D6-AFC6-8201F346D6F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 El 16 ag 2017, a les 9:26, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> va = escriure:
Ted Lemon = <mellon@fugue.com> = writes:

El 15 ag 2017, a les 19:32, = Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> va escriure:
In both of = these cases, you are better off doing what we discussed
earlier and setting up your own DNS cache, possibly with a = whitelist
for domains you want to send to the ISP = forwarder.

Sure, and that's = what I usually do. But if we can't specify that
behaviour = for homenet, at least trying all upstream DNS servers gives a
better chance of finding one that works.

I'm really sorry, but I'm = actually having trouble contextualizing the
failure mode = that you are talking about here.   Didn't I agree with
you in a previous message that we should try all the upstream = DNS
servers?

Hmm, right, I guess you did. My point was more = that an MPvD-aware client
that only uses on = PvD may experience worse performance than one that
uses the in-home resolver. But I guess the = client should be smart
enough to deal with = that?

I think this is a real edge case.   You have two = connections, the DNS server on one of them is broken, the DNS server on = the other is not, but the second connection performs so much worse than = the first that you'd rather use an answer from the DNS server on the = second to contact a service on the first.

If you were in an engineering staff meeting trying = to justify adding extra code to do this, what would you have to say to = get the group to agree to do the work?   What would that code look = like?

Sometimes things are just = broken.   Expecting a homenet router to solve every possible = configuration screwup on the part of the ISP isn't realistic.   As = customers of these ISPs, we expect them to do a decent job, and if an = ISP fails often enough to make this code worth writing, they probably = need to be in a different business.

You may be right that = hacking up a working prototype isn't that hard.
But the = failure modes change from "the internet is down" or may "I
cannot access site A", to "site A is working every third = attempt, except
it is entirely broken on device X" maybe = even with an added "ah, but
it works on device X if I go = into the kitchen".

Didn't we = agree that we aren't round-robining?

Yeah, but I was referring to the failure mode = for MPvD vs non-MPvD
clients. I.e. if = one of the resolvers fails for whatever reason, only
MPvD-aware clients that happen to select that = PvD will notice; whereas
if there's only one = resolver it will be very obvious when it's not
working...

That's not how = PvDs work.   You don't select one and only use that.   You try = both.

Hmm, while writing this is occurred to me that it might make = sense to
just export the ISP DNS server(s) directly in the = MPvD-only RAs?

This would = certainly work, but now you can't have your nice local
resolver that does what you want.   However, I = think you are right
that this is the right default = behavior for MPvD-aware devices.

I would keep the in-home resolver for clients = that do not support MPvD;
and probably also = announce it as a separate PvD for MPvD-aware clients?

Also, I think I would prefer running a = single resolver in the home,
rather than running = one on every router.

I = think there's some text in the document that was put in before I did the = dnssd discovery relay stuff and hasn't been updated since.   There = does need to be a dnssd discovery relay running on every router.   = And if the dnssd registration protocol is running over unicast, then we = need some kind of relay on port 53 on every router, so that we can tell = that the device that's doing the registration is on the local link. =   If we do the registration through the discovery relay, this isn't = necessary.   I don't remember how Stuart specified this, so I'm not = sure.

But the = motivation for doing this is not that every router has to have a caching = recursive resolver running on it.

= --Apple-Mail=_EE2D7AA2-87E5-42D6-AFC6-8201F346D6F4-- From nobody Wed Aug 16 06:40:17 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC0213201E for ; Wed, 16 Aug 2017 06:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 O5eMJSB5wlnh for ; Wed, 16 Aug 2017 06:40:14 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 11B271252BA for ; Wed, 16 Aug 2017 06:40:14 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id v29so20828075qtv.3 for ; Wed, 16 Aug 2017 06:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hiy4HWQndbJslrxLeZLbMOspZ32p+hFiLV0x1EqT1G0=; b=uQbxc5UZtkl0sBR0on9tsXhPoqoHrbfDpJVGGCIJMuhyJirobyGfJ+1U8b+I3MCaqj bFYG4nhswCaAHALMHSsm8WYmvXjU7CmXn8vHHGKT1ZNMXKt2wF6HdErXMunRqT8KwL+4 NUwt5BsfGInG5FOWa8kdIDkJVsUXuiGjVuaatOw2uU+NytSk+ta+VjZAsWWs6lcZdH1O GMAjKmD/wfubafLTWDvpRnnjsfQKQb9070ptBXV9d7dHrGRGoPmcTLN1ELoAnzj5WoCY VtHcUzlwtGtY8NDznzMIE0sJwCLAu8jcgITAGtleZh0dJZd8Fl8LUnovR8JcHhkScQOL 306A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hiy4HWQndbJslrxLeZLbMOspZ32p+hFiLV0x1EqT1G0=; b=gLXY26U5cN3JgUith/vaZhhc/12ai6TMQN/gWYPV9SMZtb3e93V8MeWf783ssTaw46 cF4YZpVI8egmN1WwhR98TeymYxVTrHQMR1gQE3p/ROdvF2IdeKxedTV94hI1USuGqB1Y EESsMyT3baZ9HEsbBHKuUiZ1jeKuDvWIV9aGjzQWhPskNuvvvJYL7n6W8EPS+bqLrFjx /shRDHByCKRLlEMZFqln8TzJEqP4BYu9s1P0dpNK7J00lnAQ0EUo8Kp4v2mg97igpKGU wrAJaqyMTYr10MsNCa2iWwgKfhpv8nFwfEdmwV4LU7DUfREPjQtzCp9vND+3QpSUoGob uhlg== X-Gm-Message-State: AHYfb5iotjbaxlKa9g/9K8Qma8FIxOwqZS/ZYbi4o11Kd8rrXN5UhTTc GMkzgAdx1UciwPjghflsdg== X-Received: by 10.237.59.140 with SMTP id r12mr2208885qte.47.1502890813183; Wed, 16 Aug 2017 06:40:13 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id i124sm552911qkf.43.2017.08.16.06.40.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 06:40:12 -0700 (PDT) From: Ted Lemon Message-Id: <8EA5872B-24B3-42DF-9A07-81FB6DC7118D@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F0902C0D-02E2-4D4D-903B-67045AD8A856" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 16 Aug 2017 09:40:11 -0400 In-Reply-To: <87y3qjwsak.fsf@toke.dk> Cc: Ralf Weber , HOMENET , Juliusz Chroboczek To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <87y3qjwsak.fsf@toke.dk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 13:40:16 -0000 --Apple-Mail=_F0902C0D-02E2-4D4D-903B-67045AD8A856 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 El 16 ag 2017, a les 9:33, Toke H=C3=B8iland-J=C3=B8rgensen = va escriure: > Ah, I wasn't trying to imply that ISPs deliberately design sub-par > services just to annoy their customers; sorry if it came across that > way. My "broken by design" comment was referring specifically to > DNS-based censorship [1]. Ah, if this is your concern, I think that's answered by the whitelisting = stuff I was talking about earlier. But in this case you really do need = to have separate caches per PvD, and the MPvD-aware clients on the net = need to be able to use them. We could say that this is optional to = support, though, and so if you want to pay for one router with this = feature, that router's resolver can be advertised in the PvD-aware path. --Apple-Mail=_F0902C0D-02E2-4D4D-903B-67045AD8A856 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 El 16 ag 2017, a les 9:33, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> va = escriure:
Ah, I wasn't trying = to imply that ISPs deliberately design sub-par
services just to annoy their customers; sorry if = it came across that
way. My "broken by = design" comment was referring specifically to
DNS-based censorship = [1].

Ah, = if this is your concern, I think that's answered by the whitelisting = stuff I was talking about earlier.   But in this case you really do = need to have separate caches per PvD, and the MPvD-aware clients on the = net need to be able to use them.   We could say that this is = optional to support, though, and so if you want to pay for one router = with this feature, that router's resolver can be advertised in the = PvD-aware path.

= --Apple-Mail=_F0902C0D-02E2-4D4D-903B-67045AD8A856-- From nobody Wed Aug 16 06:50:23 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F9A1320B5 for ; Wed, 16 Aug 2017 06:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 Mxv0HuSyPsl3 for ; Wed, 16 Aug 2017 06:50:20 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 6E50113201E for ; Wed, 16 Aug 2017 06:50:20 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id 16so21007502qtz.4 for ; Wed, 16 Aug 2017 06:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jODJu4bB3F1T4zYchYj1GvWsIURfO+bk3l8+Ew8KAE8=; b=HfL8rSVugXBF512uZIdm1L1AnbyjURejYsceP4em+mbKQxXANGUWvVr8bTuNfM40HQ Ls1wEHrVNePP2m8CErChtIPxYK4nnXrMZ2liEoe7i/tzfACr3/k7Z+QY3atjIJ0e8nV1 VYJkTRE2P2bc5QsdKUJp4Cw9ohs/yQG0MkbhNF6WA17vC6ypNV7drGhol16HPHKA4ZA5 ehlChnnVTautm3tKKlth5mRHouIyb13xWV74lx2tknDkrwx9rP0UJ8P3BIhNMwso8nDY OdHGv+TB4/4kmztwuSNCPhjxD0qp0HfXOakcXMV5yCvS3lVX9jhqMN2pSfgIOZr7gcnZ ss7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jODJu4bB3F1T4zYchYj1GvWsIURfO+bk3l8+Ew8KAE8=; b=fbWLKrsglCWiMjKepIEV3rkYTNWbNen2AlXBv6BC6Ogco923+Uk/jy0M2pFGeiFTUN ooLd3K/7SR2hklqWlqvn/SKe+9I2RrhHoz1vjwh9ilsmiLkxfwR3Ht6jYYhciZ+vLUSh McyVZtRodmxPdOMZ6vIgG/GLdLnPZFZ/JghsHThvoPKW/sIHNemcVZf+9vY43QcIcM5k yV3RKA991ocJgchMW6fBuhGsv40eHOf+jDHr9MbPkaP0wXDu3fAL2t7XnILkNz5mj2CP oGc6gbSwha69zoFSOEiLdi8+rTCHXxr8/EIGDdmdSPS4fqVYcxxR1mMIoHzW7pAt7blH GKqA== X-Gm-Message-State: AHYfb5hPDPxIMPYUnEt3aROZ70yD4pGxUeYcSEVybvOrCu8jLEA031SP /UFGaGJ8PzL00hNf X-Received: by 10.237.36.107 with SMTP id s40mr2593839qtc.137.1502891419532; Wed, 16 Aug 2017 06:50:19 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id f55sm611782qtc.18.2017.08.16.06.50.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 06:50:18 -0700 (PDT) From: Ted Lemon Message-Id: <16EE0CA3-4618-416C-91E1-F56FD7D8BB27@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CD422A6E-9287-46CD-B056-57FD032C6F96" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 16 Aug 2017 09:50:17 -0400 In-Reply-To: <8EA5872B-24B3-42DF-9A07-81FB6DC7118D@fugue.com> Cc: Ralf Weber , HOMENET , Juliusz Chroboczek To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <87y3qjwsak.fsf@toke.dk> <8EA5872B-24B3-42DF-9A07-81FB6DC7118D@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 13:50:22 -0000 --Apple-Mail=_CD422A6E-9287-46CD-B056-57FD032C6F96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii El 16 ag 2017, a les 9:40, Ted Lemon va escriure: > Ah, if this is your concern, I think that's answered by the = whitelisting stuff I was talking about earlier. But in this case you = really do need to have separate caches per PvD, and the MPvD-aware = clients on the net need to be able to use them. We could say that this = is optional to support, though, and so if you want to pay for one router = with this feature, that router's resolver can be advertised in the = PvD-aware path. BTW, I think we have probably carried this discussion as far as is = useful until a new rev of the draft is done. Daniel is working on a = new draft, he said, and when he's done his bit I'll do a pass as well = and try to capture the changes we've discussed here, and then we can = iterate again. :) --Apple-Mail=_CD422A6E-9287-46CD-B056-57FD032C6F96 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 16 ag 2017, a les 9:40, Ted Lemon <mellon@fugue.com> va = escriure:
Ah, if this is your concern, I = think that's answered by the whitelisting stuff I was talking about = earlier.   But in this case you really do need to have separate = caches per PvD, and the MPvD-aware clients on the net need to be able to = use them.   We could say that this is optional to support, though, = and so if you want to pay for one router with this feature, that = router's resolver can be advertised in the PvD-aware = path.

BTW, = I think we have probably carried this discussion as far as is useful = until a new rev of the draft is done.   Daniel is working on a new = draft, he said, and when he's done his bit I'll do a pass as well and = try to capture the changes we've discussed here, and then we can iterate = again. :)

= --Apple-Mail=_CD422A6E-9287-46CD-B056-57FD032C6F96-- From nobody Wed Aug 16 08:24:04 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EE21321D9 for ; Wed, 16 Aug 2017 08:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 KOuNmsBqcPBb for ; Wed, 16 Aug 2017 08:24:01 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B2A13248F for ; Wed, 16 Aug 2017 08:23:56 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502897030; bh=pBNZHQEcPSR+GFrfukxEffzTTGLfZpj/RA+ehl30uo0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=K3viESlWjokjraf7U4iP8kDcOFGc7X3U8frr033vETORGORsYPWXMYkoXM5Noe5E+ MEmQOHMbxWrZijgZPH/9B4AeoIr3vaYM6QyQFI9y2u8vImshtTRIOYJSSWru+6PuO1 nC4vgNSa7U2mfw5nULq9fSZvLqfIqypGOH9nrrIqMoQrdiOX3j7k/wGkPSD/wcELkW VX5m0EmVcw+OUCZdFmEAMQXP0Ui3Kqb/V8X3Tp2GtHvcMYkD2f8UYrGKnsfDv8t2j+ wmHMzcDAlX+5TDHqHUm2rgegvJGmtWwAyGWMw73YCfaQ6kDUc81Rpxdp0LGVWkJol+ XITX3NvMu2ztQ== To: Ted Lemon Cc: Juliusz Chroboczek , HOMENET In-Reply-To: <769C4508-BB58-4BCB-A3CE-3657FB43A8AA@fugue.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <874lt8xv9j.fsf@toke.dk> <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> <871soby776.fsf@toke.dk> <769C4508-BB58-4BCB-A3CE-3657FB43A8AA@fugue.com> Date: Wed, 16 Aug 2017 17:23:53 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87pobvwn7a.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 15:24:03 -0000 Ted Lemon writes: > El 16 ag 2017, a les 9:26, Toke H=C3=B8iland-J=C3=B8rgensen va escriure: >> Ted Lemon > writes: >>=20 >>> El 15 ag 2017, a les 19:32, Toke H=C3=B8iland-J=C3=B8rgensen va escriure: >>>>> In both of these cases, you are better off doing what we discussed >>>>> earlier and setting up your own DNS cache, possibly with a whitelist >>>>> for domains you want to send to the ISP forwarder. >>>>=20 >>>> Sure, and that's what I usually do. But if we can't specify that >>>> behaviour for homenet, at least trying all upstream DNS servers gives a >>>> better chance of finding one that works. >>>=20 >>> I'm really sorry, but I'm actually having trouble contextualizing the >>> failure mode that you are talking about here. Didn't I agree with >>> you in a previous message that we should try all the upstream DNS >>> servers? >>=20 >> Hmm, right, I guess you did. My point was more that an MPvD-aware client >> that only uses on PvD may experience worse performance than one that >> uses the in-home resolver. But I guess the client should be smart >> enough to deal with that? > > I think this is a real edge case. You have two connections, the DNS > server on one of them is broken, the DNS server on the other is not, > but the second connection performs so much worse than the first that > you'd rather use an answer from the DNS server on the second to > contact a service on the first. Well, it's quite clear from this discussion that we have different ideas about how likely this is. I think we'll just have to agree to disagree on that, for now at least... > If you were in an engineering staff meeting trying to justify adding > extra code to do this, what would you have to say to get the group to > agree to do the work? What would that code look like? Ah, but I'm not arguing for adding code, I'm arguing that we should remove some :) -Toke From nobody Wed Aug 16 08:24:21 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F260D132498 for ; Wed, 16 Aug 2017 08:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 6rK842wYSFrI for ; Wed, 16 Aug 2017 08:24:07 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F9B13249F for ; Wed, 16 Aug 2017 08:24:07 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502897045; bh=v/njsPFQmR19FoTTfq+soPT22/yHBmxZQ89yv6WcWQc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MCHquCOsA66bT5evvRv4ziDdwuOsN/OfhhTsDf/6MCP2xIAVniQ7uT9x39qvBiR0Z Wc4HBwj4uIHo39kwGkDFEYoy4kjZizsKVzuBG7WjAmYLZPLzbRE6xXC+n8NBtT3OOm 9ZgSGoiTQuJZEuSg0zIqDdSI7JOrcnxRncqvl0zOFa5Te9UV1fF2/lkMDEZVs+V9Ic qMSzY6UCXr69ONRL8/nHf2Vi7bzgn1yIBG+X11Tdptyea0KZeYAqSTdeYHWAGB2UYW V4omlIEIXBAb3DRcVwI6MxmBC/21eP6XsPolaHpZYC0NaVq1f5/OXv/rgk34dWXmyM c2fUEogbaUe1A== To: Ted Lemon Cc: Ralf Weber , HOMENET , Juliusz Chroboczek In-Reply-To: <16EE0CA3-4618-416C-91E1-F56FD7D8BB27@fugue.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <87y3qjwsak.fsf@toke.dk> <8EA5872B-24B3-42DF-9A07-81FB6DC7118D@fugue.com> <16EE0CA3-4618-416C-91E1-F56FD7D8BB27@fugue.com> Date: Wed, 16 Aug 2017 17:24:08 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87mv6zwn6v.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 15:24:09 -0000 Ted Lemon writes: > El 16 ag 2017, a les 9:40, Ted Lemon va escriure: >> Ah, if this is your concern, I think that's answered by the whitelisting stuff I was talking about earlier. But in this case you really do need to have separate caches per PvD, and the MPvD-aware clients on the net need to be able to use them. We could say that this is optional to support, though, and so if you want to pay for one router with this feature, that router's resolver can be advertised in the PvD-aware path. > > BTW, I think we have probably carried this discussion as far as is > useful until a new rev of the draft is done. Daniel is working on a > new draft, he said, and when he's done his bit I'll do a pass as well > and try to capture the changes we've discussed here, and then we can > iterate again. :) Yup, fine with me :) -Toke From nobody Wed Aug 16 12:50:41 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1764B1326D6 for ; Wed, 16 Aug 2017 12:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 ubx4XpqRBSB1 for ; Wed, 16 Aug 2017 12:50:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9644132350 for ; Wed, 16 Aug 2017 12:50:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 18E51E1ED for ; Wed, 16 Aug 2017 15:53:16 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 80ECA80B17 for ; Wed, 16 Aug 2017 15:50:36 -0400 (EDT) From: Michael Richardson To: HOMENET In-Reply-To: <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [homenet] tuscles and conflicting goals / trust with draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 19:50:40 -0000 --=-=-= Content-Type: text/plain Ted and Toke have many emails about DNS and servers and the like. I think that it would be useful to take a few steps back to understand some assumptions. Many of these are tied up in layer 8 and layer 9 issues. Toke wrote: in my part of the world ISP DNS servers are broken *by design* Ted meanwhile has written that that there are potential situations where one provider may intentially misconfigure something so that a customer will pick a more expensive way to get data. In both cases we are trying to build into our protocols some kind of defense against stupidity. In Homenet, we are really trying to defend against ISP stupidity, while trying to leverage intelligence from the ISP to guard against end-user stupidity. I don't pretend to capture their debate very well. A lot of the DNS publish/public/private, etc. debate centers around tuscles between clue-ful users (engineers) on this list who want to code something sensible so that they can share their clue with the clueless, vs other engineers who want to enable clue-ful ISPs to provide service to clueless users. Then the response from the first group is that this might force them to do stupid things which they have fought against for ages. I can not really characterise the debate very well, but this is what I think I know: 1) ISPs that insist on controlling too much in the homenet will find themselves fighting against Googles, Apples (and Microsoft) who want it to work right. We see this in the CAPPORT debates. By and large, "we" (the public) have "routed around" ISP stupidity, but the collatoral damage to the infrastructure has been immense. (e.g: NAPT44, SCTP, ...) 2) It's very hard to get people to vote with their wallet when it comes to poor ISP performance. Performance usually means speed, but of course there is a whole lot of other variables. The 300Mb/s-marketing-speed fiber vs high-quality 50Mb/s IPv6, and my very technical friends pick the "faster" connection.... Many times, it is because nobody has any actual information. Such as, how often they are really getting 300Mb/s, or how often they are using IPv6 via a bad tunnel. 3) We've tried in HOMENET to automate things; and at the DNS space we are getting to limit of how much policy we can derive automatically. There is SIGNIFICANT work that we can do to automate the implementation of the policy, if we can figure out what the policy is. So I suggest that in order to make progress, we should split things up into ways to implement a policy (assuming the policy is known a-priori), and ways in which can we collect information about when the policy is failing so that things can get fixed; perhaps by a local geek, perhaps by a clueful ISP helpdesk, or eventually, perhaps by a smarter HNCP end-point. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmUogwACgkQgItw+93Q 3WUQKgf/QmkYjUfFD6bKbTFmo6TvhewGP5s8BQJPSYl7RmBV0v0WNEKW7157QF/y yY1NZAdilIbl2ImSl2kpHxX0wq2WaIBnaI5MKzNPDZn9zitCYzA+MMHGuQNy6psl f0UelR3vppm6tlwNYSo2HDQ/GwpZtMEVJinqV6K2/uRbSLJheu8mC0/Dzrih2eHN bFg/69z6Ps0QtApzvjVo2TCHg1VRh8yLT9diavTJ3Zh+o9RC90iGAiAzQntSWl0Q DrAUXPpqG/ewgfi8olf1FRHMALeaHAXVll5y13QBM7hVOKzO92okkpBvjNfnZFTN xBO/bG3+rw1QbxfwChZ/VN8lw/uTXg== =l7ay -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 16 13:36:36 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B12C1326F3 for ; Wed, 16 Aug 2017 13:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=RxmRk0Ch; dkim=pass (1024-bit key) header.d=yitter.info header.b=LzDcmL97 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 UWldCAEumqrT for ; Wed, 16 Aug 2017 13:36:33 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5DB1326DB for ; Wed, 16 Aug 2017 13:36:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 424EDC09A0 for ; Wed, 16 Aug 2017 20:36:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1502915762; bh=7nhT7p+ZYebMef+SsHoXc1qF69NvZg0Wuq8vkNkes+s=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RxmRk0Chk12xHBER2bCB0gxSwuYRWWoICrfR1pxls5Pk0GHZpwgbUlAtJmL5NQRpE qJ23TrRBmCAx4ziIuCQpztNXuF0/ZMzQ4yKIVqIdz0oUJ5L8jP2i8pCRfoNREnMHtr HANXxorg5e1iiT/c96ZVHkjSogEnpGpYeeld8DG4= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yoq9T4vvx9EC for ; Wed, 16 Aug 2017 20:36:00 +0000 (UTC) Date: Wed, 16 Aug 2017 16:35:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1502915760; bh=7nhT7p+ZYebMef+SsHoXc1qF69NvZg0Wuq8vkNkes+s=; h=Date:From:To:Subject:References:In-Reply-To:From; b=LzDcmL97TEDwsfRdxiknfw6o+Adb3DWv579NtrTuX5sT/IBPDndRBbQ36v6fOPmGY pOy3NhapkDohGzTAwhBIl4SrOwy/rTXqzF9kQMlfXWneXSqTZ76lWqjzTZYDD2/HeB K2NL8bWwplhNak9l71ndX+nPdtboNMu4Fd5Fw/50= From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20170816203557.ieqnyepjqpoeq6um@mx4.yitter.info> References: <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <12755.1502913036@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12755.1502913036@obiwan.sandelman.ca> Archived-At: Subject: Re: [homenet] tuscles and conflicting goals / trust with draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 20:36:35 -0000 Hi, I think I mostly agree with Michael, but I think I would emphasise a couple other things: On Wed, Aug 16, 2017 at 03:50:36PM -0400, Michael Richardson wrote: > In Homenet, we are really trying to defend against > ISP stupidity, while trying to leverage intelligence from the ISP to guard > against end-user stupidity. I think we're trying to make the homenet a proper part of the Inter-net. The Internet, of course, is a network of networks. Part of the idea there is that each network makes its own rules, which is why we have to rely on voluntary interoperation. Historically this always depended on network administrators. What I think we're trying to do is to make network operation possible even when there is no administrator. Since there are lots of such basically no-administration networks about, that doesn't seem crazy. > ways to implement a policy (assuming the policy is known a-priori), and ways > in which can we collect information about when the policy is failing so that > things can get fixed; perhaps by a local geek, perhaps by a clueful ISP > helpdesk, or eventually, perhaps by a smarter HNCP end-point. I think this is right, given the goal I think we're aiming for. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Aug 16 13:48:29 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B521326CA for ; Wed, 16 Aug 2017 13:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 WW-_xR1bCOt9 for ; Wed, 16 Aug 2017 13:48:26 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 F0F7013233D for ; Wed, 16 Aug 2017 13:48:25 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id x191so26891187qka.5 for ; Wed, 16 Aug 2017 13:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=62dwGBWe1gr6GSh3sLcdTkYk5cIXuBjEbWc34DPz4i8=; b=LORaSYxjnupIzKwnz9pTTkA0TVkeBC51WpquILCqHB2fJhslxcShJDVLqyZmRMgYDX YZ80oNBfWmThcs12uluApu6C9oeneZBuqby8y+zoG1OqthPFQK+RAhcBnScOAN72otwh qtvTEZfbfJF5vK+HZYhGl8rHukZGjl+94Z1wC9Mdm2X2ncY0HBHNNWUdQR5OnStW3Nij sUv/Iclg2kxGssaKzFtPmkfO7dl1f3aRFFg0O6eRWXZcgLdtBNF06OHv+Wt+gBVaHEUD jXs1omevp9xioaPkiI8EiFUUG5KeKRuFwMB+tGFRCZ5FPd3FMw/HRly4DNcmi8/N89Pi oahg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=62dwGBWe1gr6GSh3sLcdTkYk5cIXuBjEbWc34DPz4i8=; b=CjUSxPOC5C7yW/Iy/ebahDaFGRZ6Clda4Pb3GUY4Eb8/NTsDOOcpzi5MSDCDizOX/K DmQ+PbAfm9Sh9Q52YdRLpgjNOWrcIl1iIa2LCRFTz5Rnhz2xEwRj1ApHkZ7qmXmvw2WR b95trzb0VvvtcycPGgzlI9XTfGk7HUaqCBt3t7Bx24Nm+4bIyjmB2csEG1jxAteNUcDR mslS+eWaF85k992ZXX2bTLQF7IVmgKNq9PWMTZux5PmD/ioJFkNUr6NyAsmLDtctslvG g63Z4dedLz47rv8iAl+IdiM03QoEdvBwG5Fh+jyUI9zCOxLaaSanwJqT7HhpH30m1Dcs nn9A== X-Gm-Message-State: AHYfb5hAzBXerF8I4zvQI3lcGeg6DVjRL3SCXy+cQdRT8ABKk47Xawxa /NjMX+Cd73xZfqhfEy0AJQ== X-Received: by 10.55.103.141 with SMTP id b135mr3898482qkc.16.1502916504950; Wed, 16 Aug 2017 13:48:24 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id l36sm1158736qte.31.2017.08.16.13.48.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 13:48:24 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BCD98A59-0AF9-43DC-A133-7230DBCDEE22" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 16 Aug 2017 16:48:23 -0400 In-Reply-To: <20170816203557.ieqnyepjqpoeq6um@mx4.yitter.info> Cc: homenet@ietf.org To: Andrew Sullivan References: <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <12755.1502913036@obiwan.sandelman.ca> <20170816203557.ieqnyepjqpoeq6um@mx4.yitter.info> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] tuscles and conflicting goals / trust with draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 20:48:28 -0000 --Apple-Mail=_BCD98A59-0AF9-43DC-A133-7230DBCDEE22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I tend to agree with Andrew's re-interpretation, but I would add a = caveat, which is that at least what I am trying to do is provide a DNS = architecture the presence of which will enable devices to have the = information and capabilities they need to operate successfully on a = multi-homed residential network. The fact that I've brought up a = couple of use cases that relate to provider attacks is an artifact of = where the conversation went, not a central theme in the work I'm trying = to do. My fear in reading Michael's message was that we'd go even further down = the rathole of over-specialization. That is not what I am trying to = work on. If it's what the working group wants to work on, I may be = able to help, or it may be work for someone else. This has been a = pretty frustrating process for me, because I feel like I'm trying to do = something sensible, I keep having to submit incremental versions of the = document at times when my head is in a different document I'm working on = to support the general goal, and I keep getting rotten tomatoes thrown = at me because the document that gets produced isn't done and isn't = consistent. This is understandable, but it would be nice if instead of = throwing rotten tomatoes people would help to do the work. --Apple-Mail=_BCD98A59-0AF9-43DC-A133-7230DBCDEE22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I tend to agree with Andrew's re-interpretation, but I would = add a caveat, which is that at least what I am trying to do is provide a = DNS architecture the presence of which will enable devices to have the = information and capabilities they need to operate successfully on a = multi-homed residential network.   The fact that I've brought up a = couple of use cases that relate to provider attacks is an artifact of = where the conversation went, not a central theme in the work I'm trying = to do.

My fear in = reading Michael's message was that we'd go even further down the rathole = of over-specialization.   That is not what I am = trying to work on.   If it's what the working group wants to work = on, I may be able to help, or it may be work for someone else.   = This has been a pretty frustrating process for me, because I feel like = I'm trying to do something sensible, I keep having to submit incremental = versions of the document at times when my head is in a different = document I'm working on to support the general goal, and I keep getting = rotten tomatoes thrown at me because the document that gets produced = isn't done and isn't consistent.   This is understandable, but it = would be nice if instead of throwing rotten tomatoes people would help = to do the work.

= --Apple-Mail=_BCD98A59-0AF9-43DC-A133-7230DBCDEE22-- From nobody Wed Aug 16 14:25:16 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525FD13271E for ; Wed, 16 Aug 2017 14:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 w1NdluFp1rih for ; Wed, 16 Aug 2017 14:25:12 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6500132031 for ; Wed, 16 Aug 2017 14:25:11 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id v7GLP9x3030177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Aug 2017 23:25:09 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id v7GLP3Fj021956; Wed, 16 Aug 2017 23:25:08 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 51039EB344; Wed, 16 Aug 2017 23:25:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 7q-05ie3UPmk; Wed, 16 Aug 2017 23:25:02 +0200 (CEST) Received: from trurl.irif.fr (user-46-112-10-35.play-internet.pl [46.112.10.35]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 24D63EB342; Wed, 16 Aug 2017 23:25:01 +0200 (CEST) Date: Wed, 16 Aug 2017 23:24:59 +0200 Message-ID: <87k223jjdg.wl-jch@irif.fr> From: Juliusz Chroboczek To: Ted Lemon Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , HOMENET In-Reply-To: <769C4508-BB58-4BCB-A3CE-3657FB43A8AA@fugue.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <874lt8xv9j.fsf@toke.dk> <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> <871soby776.fsf@toke.dk> <769C4508-BB58-4BCB-A3CE-3657FB43A8AA@fugue.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 16 Aug 2017 23:25:09 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 16 Aug 2017 23:25:09 +0200 (CEST) X-Miltered: at korolev with ID 5994B835.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5994B82F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5994B835.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5994B82F.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5994B835.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5994B82F.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 21:25:14 -0000 > I think this is a real edge case. You have two connections, the DNS server on > one of them is broken, the DNS server on the other is not, but the second > connection performs so much worse than the first That's exactly the kind of situation that we'd like Homenet to work well in. Connection A is a 1.5Mbit/s leased line, it's rock solid, and has rock solid infrastructure behind it. Connection B is consumer FTTH at 1Gbit/s, it's flaky, and it's backed by infrastructure that works on Mondays only. Quite frankly, if it's not for combining fast with reliable, I just don't see what's the purpose of having multiple connections. -- Juliusz From nobody Wed Aug 16 14:49:59 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90254132725 for ; Wed, 16 Aug 2017 14:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 NMBrxLWazz-J for ; Wed, 16 Aug 2017 14:49:55 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 B5B01132031 for ; Wed, 16 Aug 2017 14:49:55 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id i12so29304700pgr.3 for ; Wed, 16 Aug 2017 14:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qahR3isQroc9Q325peEUF3p4crOhc8hQrlv0G0kSz28=; b=CiDFAcfK15grOuVDbsvjdP0Pa6KoIeu6U8Au2RpZn7lv8TPLNrO/+S2SQqTbe+lcZx FXvLP38Wq4tXiyyKDqrJbkZ+M5siMwxw403PlGAbH2uEy5OB3JT4UZzgaUsId7gMAyoz SSeu3qGj+hxfm2kb8arfaWl152zEVbMWd/9ESMw8LF73tRc7alvEvHf1oveCx6BDKVKZ IZyDRFnVFJaXkprbC/06wFazNKvZN/Lns5wNkYsONUC0Sn1Q6Odb9405d2PCZsgqXtvr W7j7Sp7MHrITQzd5LKOIDOIhj7jKlUcu7WTItOAV/bNC//XgAMg6J1d75WkcQxQM1xfJ z/7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qahR3isQroc9Q325peEUF3p4crOhc8hQrlv0G0kSz28=; b=K6e6V1V1FwPlpfujd/pdXTQKavb8+89Hzsa7lMf0qjszoBNn0GLGn+GsMwyaMh9291 hyIedgnF3Hghi1c65SY+A0WZ1HBgHDRLyM06Afj5niecN7CKpGl5qEKBDiGAL3Eyp/YD 12dg0JjHE3KfOqm2bEfImdmZuRWSjM3/+nkfixVqthNvLzkUfZkEoVNE2FPSRPOWqTwM h/u4j2J3aZEeci3S/iryYlr7EoUBkux4j+p7LopO2yPvpRTeumYsYEGSsc1GUVf4Jg8W 8xsjC4gOIwnEwddbho3oPezq4gKAmK+9oOA7UOawvIV8+w8mkA4YSx45e8Axy6chkb05 jvWQ== X-Gm-Message-State: AHYfb5hJ+AdKEedkBHbBvjSLs5NlLU8PBI0AKcJI7t8O/HfV7ReE1iCo 5IZd6iOXNqPyOZuuHuO00FdrR/BY7heW X-Received: by 10.99.56.68 with SMTP id h4mr2912692pgn.52.1502920195383; Wed, 16 Aug 2017 14:49:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.142.144 with HTTP; Wed, 16 Aug 2017 14:49:54 -0700 (PDT) Received: by 10.100.142.144 with HTTP; Wed, 16 Aug 2017 14:49:54 -0700 (PDT) In-Reply-To: <87k223jjdg.wl-jch@irif.fr> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <874lt8xv9j.fsf@toke.dk> <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> <871soby776.fsf@toke.dk> <769C4508-BB58-4BCB-A3CE-3657FB43A8AA@fugue.com> <87k223jjdg.wl-jch@irif.fr> From: Ted Lemon Date: Wed, 16 Aug 2017 17:49:54 -0400 Message-ID: To: Juliusz Chroboczek Cc: HOMENET , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: multipart/alternative; boundary="f403045d33f25f39520556e5e0fe" Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 21:49:58 -0000 --f403045d33f25f39520556e5e0fe Content-Type: text/plain; charset="UTF-8" It's never for that purpose. It's to combine to normal connections so as to increase reliability. The scenario you just described would require a wormhole with one end in the 1990s. On Aug 16, 2017 5:25 PM, "Juliusz Chroboczek" wrote: > > I think this is a real edge case. You have two connections, the DNS > server on > > one of them is broken, the DNS server on the other is not, but the second > > connection performs so much worse than the first > > That's exactly the kind of situation that we'd like Homenet to work well > in. Connection A is a 1.5Mbit/s leased line, it's rock solid, and has > rock solid infrastructure behind it. Connection B is consumer FTTH at > 1Gbit/s, it's flaky, and it's backed by infrastructure that works on > Mondays only. > > Quite frankly, if it's not for combining fast with reliable, I just don't > see what's the purpose of having multiple connections. > > -- Juliusz > --f403045d33f25f39520556e5e0fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's never for that purpose. It's to combine to n= ormal connections so as to increase reliability. The scenario you just desc= ribed would require a wormhole with one end in the 1990s.=C2=A0

On Aug 16, 2017 5:25 PM= , "Juliusz Chroboczek" <jch@iri= f.fr> wrote:
= > I think this is a real edge case. You have two connections, the DNS se= rver on
> one of them is broken, the DNS server on the other is not, but the sec= ond
> connection performs so much worse than the first

That's exactly the kind of situation that we'd like Homenet to work= well
in.=C2=A0 Connection A is a 1.5Mbit/s leased line, it's rock solid, and= has
rock solid infrastructure behind it.=C2=A0 Connection B is consumer FTTH at=
1Gbit/s, it's flaky, and it's backed by infrastructure that works o= n
Mondays only.

Quite frankly, if it's not for combining fast with reliable, I just don= 't
see what's the purpose of having multiple connections.

-- Juliusz
--f403045d33f25f39520556e5e0fe-- From nobody Thu Aug 17 07:26:55 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFAA132444 for ; Thu, 17 Aug 2017 07:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 FneERHrwlr39 for ; Thu, 17 Aug 2017 07:26:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B56132153 for ; Thu, 17 Aug 2017 07:26:52 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 490DC2009E; Thu, 17 Aug 2017 10:29:33 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 11868806D2; Thu, 17 Aug 2017 10:26:51 -0400 (EDT) From: Michael Richardson To: Andrew Sullivan cc: homenet@ietf.org In-Reply-To: <20170816203557.ieqnyepjqpoeq6um@mx4.yitter.info> References: <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <12755.1502913036@obiwan.sandelman.ca> <20170816203557.ieqnyepjqpoeq6um@mx4.yitter.info> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [homenet] tuscles and conflicting goals / trust with draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 14:26:54 -0000 --=-=-= Content-Type: text/plain Andrew Sullivan wrote: >> ways to implement a policy (assuming the policy is known a-priori), >> and ways >> in which can we collect information about when the policy is failing >> so that >> things can get fixed; perhaps by a local geek, perhaps by a clueful ISP >> helpdesk, or eventually, perhaps by a smarter HNCP end-point. > I think this is right, given the goal I think we're aiming for. This suggests to me that the next step in HOMENET, which I think the naming architecture could lead, is to provide for (automatic) collection of statistics for diagnostics purposes. i.e. Homenet OAM. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmVp6oACgkQgItw+93Q 3WWHbQf+LxQJuas4aTu6BZgAIDb/g4KYEzbcigflUjRXhur+WakOG8brlkBDsEut Gl02WLMzdZSUV71O11vB3qkqWoO++lsxRfqXS+8DtYv6VK/A9TCTTWhnFytRI8gs D5hoB+H1NOlOnfJBDFfgXN5jeXEvat9AyQ5+S2o6gYBjrhfTabaRmwqGdzikMBqc 92/+0PWSsLXaKAJ637TfIkjQFWHvRwlb+wPn9DXPWZOhZQOFlMsd12ygCt0EhB7R KLp3F3LsLyq5qwnttHfoErH/syeXmHh8l8ySMSRyaDAkKFMGjPTv4M5/U2newnFP ED+IvBTj3dHZlJsBdr5b5cesEoCj3w== =AqYs -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 17 07:31:29 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40EF132392 for ; Thu, 17 Aug 2017 07:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 oXo_5NXfex8N for ; Thu, 17 Aug 2017 07:31:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D81A1200C5 for ; Thu, 17 Aug 2017 07:31:26 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CA9E52009E; Thu, 17 Aug 2017 10:34:07 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 94819806D2; Thu, 17 Aug 2017 10:31:25 -0400 (EDT) From: Michael Richardson To: Juliusz Chroboczek cc: Ted Lemon , HOMENET In-Reply-To: <87k223jjdg.wl-jch@irif.fr> References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <877eyaz2jm.fsf@toke.dk> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <87valry4o7.fsf@toke.dk> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <874lt8xv9j.fsf@toke.dk> <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> <871soby776.fsf@toke.dk> <769C4508-BB58-4BCB-A3CE-3657FB43A8AA@fugue.com> <87k223jjdg.wl-jch@irif.fr> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 14:31:28 -0000 --=-=-= Content-Type: text/plain Juliusz Chroboczek wrote: > That's exactly the kind of situation that we'd like Homenet to work well > in. Connection A is a 1.5Mbit/s leased line, it's rock solid, and has > rock solid infrastructure behind it. Connection B is consumer FTTH at > 1Gbit/s, it's flaky, and it's backed by infrastructure that works on > Mondays only. > Quite frankly, if it's not for combining fast with reliable, I just don't > see what's the purpose of having multiple connections. The 1.5Mb/s is for "work" use only (is very low-latency too), but tolerates some moderate amount of non-work traffic, as long as it's not so much that anyone notices. That's why you'd have two connections. Work traffic SHOULD not go out the flaky connection. That the result is what you describe (which I believe 200%...) is what happens is not the plan. It's not why the multiple connections are justified. Now, assume a second spouse working at home, with another "work" connection :-) (And of course, don't forget the mesh network to the neighbourhood) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmVqL0ACgkQgItw+93Q 3WXiMwgAg5+QXTwCB+p/JVs95uDX4cLNbdo5BrOyFH5qPmDQq2Y37lxf/7BWzDP3 8Od3vuclMce6V/QLSFQJp3bHhjXsvX6K0yl+4zEJQJ8A02VMMus2zLqlTZQjr2X+ tc2buWuNpSs7AK87+0FywqSUNhBMPaZFr+t0iQ76WMO3hbcUkt94QMqs5klEYZKN yfpqBYAzK44qHFQvLbyGZElFcrvdRYrN1kFtaW7KQqddSSw829d3H+wbM3g7rD4d k/FebTYNrcm8KZoCu7xppRm5NOjj4m8x/LNT8U/STHgFaXhEToP2334rzxxYq1n6 2Y+aGQ1/9wGxKEMZverIHAGkiRyucA== =14J3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 17 12:58:42 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE954132667 for ; Thu, 17 Aug 2017 12:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Ox9K2QMIPw4H for ; Thu, 17 Aug 2017 12:58:40 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1187A132677 for ; Thu, 17 Aug 2017 12:58:39 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v7HJtGhc015237; Thu, 17 Aug 2017 15:58:27 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2cdgshtrhc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Aug 2017 15:58:27 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7HJwPcH002528; Thu, 17 Aug 2017 15:58:26 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7HJwD8H002241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Aug 2017 15:58:17 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 17 Aug 2017 19:57:58 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.30]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0319.002; Thu, 17 Aug 2017 15:57:57 -0400 From: "STARK, BARBARA H" To: Michael Richardson , Andrew Sullivan CC: "homenet@ietf.org" Thread-Topic: [homenet] tuscles and conflicting goals / trust with draft-tldm-simple-homenet-naming CFA Thread-Index: AQHTFsj2MXong/D9uUm9fTZiPCRG26KHtAQAgAErM4D//+MN0A== Date: Thu, 17 Aug 2017 19:57:57 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DC00E2A@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <12755.1502913036@obiwan.sandelman.ca> <20170816203557.ieqnyepjqpoeq6um@mx4.yitter.info> <3387.1502980011@obiwan.sandelman.ca> In-Reply-To: <3387.1502980011@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.216.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-17_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708170321 Archived-At: Subject: Re: [homenet] tuscles and conflicting goals / trust with draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 19:58:42 -0000 > This suggests to me that the next step in HOMENET, which I think the nami= ng > architecture could lead, is to provide for (automatic) collection of stat= istics for > diagnostics purposes. > i.e. Homenet OAM. Not as chair... I disagree this has anything to do with the naming architecture. I have long felt the best way to accomplish this would be to have a discove= rable (DNS-SD) NetJSON (http://netjson.org/) "service" on all consumer rout= ers, which would supply NetJSON types via http. I agree supplying statistics info to the home network would be a good thing= for homenet to tackle.=20 I've been wanting to propose this for a while, but keep getting side-tracke= d. Barbara From nobody Thu Aug 17 13:11:00 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB7F132665 for ; Thu, 17 Aug 2017 13:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 OwjGueMhonRe for ; Thu, 17 Aug 2017 13:10:57 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80CE01243F6 for ; Thu, 17 Aug 2017 13:10:57 -0700 (PDT) X-Original-To: homenet@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3E88842927 for ; Thu, 17 Aug 2017 22:10:55 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 2C97F4291F; Thu, 17 Aug 2017 22:10:55 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 1E2C081C9; Thu, 17 Aug 2017 22:10:55 +0200 (CEST) Date: Thu, 17 Aug 2017 22:10:55 +0200 From: Gert Doering To: Ted Lemon Cc: Juliusz Chroboczek , HOMENET Message-ID: <20170817201054.GN45648@Space.Net> References: <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <874lt8xv9j.fsf@toke.dk> <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> <871soby776.fsf@toke.dk> <769C4508-BB58-4BCB-A3CE-3657FB43A8AA@fugue.com> <87k223jjdg.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 20:10:59 -0000 Hi, On Wed, Aug 16, 2017 at 05:49:54PM -0400, Ted Lemon wrote: > It's never for that purpose. It's to combine to normal connections so as to > increase reliability. The scenario you just described would require a > wormhole with one end in the 1990s. 1990s never had uplinks that fast *and* unreliable at the same time as many of today's consumer ISPs offer. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Aug 17 18:33:39 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A60132744 for ; Thu, 17 Aug 2017 18:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 ulos9Ggr2eVD for ; Thu, 17 Aug 2017 18:33:36 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 240E71326E1 for ; Thu, 17 Aug 2017 18:33:36 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id x77so2212668qka.5 for ; Thu, 17 Aug 2017 18:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4r/jXfB3BZD5H7n97IEdarA2hX+Z5XYQbJF8r8WlS9Y=; b=TMmBkV/bQCLcU1o9GYYuy5j6yvBDTaMSroZj/DhRcTzE45YurOXJqOXd8bQL/MgE4/ Gma8V/xr1fItQ1NiUvJCun1yVFIYjN5wrKqv4M77sDapT+Yn0h/MKb65+Ln7Zdm1Jngn ydqyXb4tB0lvjsH1TRsC2tZScDxOwFapCV2+3mGI816hXoYT8yy+7oY6byLTfnkxvJpM VHIRnfu7sSwia/dU3+NBf/TWNe95Mwbnk6o/xhzewdb1ACzxXm6lT6yxHAkG2PKOky/6 kVj+Gze2YD3qU5LY7Q0dbEBFXsq5t1i0z9d8D4cr3GkWo/RNuBgWWdt8FZEwm/k8fy5N FodQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4r/jXfB3BZD5H7n97IEdarA2hX+Z5XYQbJF8r8WlS9Y=; b=PDzfXKLlNgOi+/n0Pio3hKbDcULcKWhp4kvhWcrWHL7+6CEG3ISuZMOO0D6bCc0KjO 5DlQg+/1eSpXZOVqrMEcoh5GGmCn68DJ+UBcKEQgYV8an37lFS9maF5xAdJk3YZ2YkhE SCy8wN19jtQ71xRQg2R+WAGHfajGidNry2uC15xwwh/QBrp8k+PWTsZcZh+LjmF5rcc3 khAtRixMQwQqfoUXJKcEssR1EBxI1TU4dlPWt746Q8VS+Ly2Qp5o/l7SfrLi3PNaRdnt oTznJzVXqBI+SpB3ialGTX5A5A7oQVhqmdnrlsHb/LXmf1CusVKHTo8h8QlvTFu4N63U YP+w== X-Gm-Message-State: AHYfb5ilKizmOgX+Dsa5p+tohZcTHQ3P5Nt5SK3VswyWm4UdIrKZr5Qb PXM+BkU0UIMeIU9rtRHzVGHU X-Received: by 10.55.98.213 with SMTP id w204mr4218985qkb.175.1503020015328; Thu, 17 Aug 2017 18:33:35 -0700 (PDT) Received: from [10.0.30.153] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id t5sm3389767qtb.89.2017.08.17.18.33.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 18:33:34 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3002DF9C-6D08-4D40-B3AB-010EEFFC58E8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 17 Aug 2017 21:33:32 -0400 In-Reply-To: <20170817201054.GN45648@Space.Net> Cc: Juliusz Chroboczek , HOMENET To: Gert Doering References: <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <874lt8xv9j.fsf@toke.dk> <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> <871soby776.fsf@toke.dk> <769C4508-BB58-4BCB-A3CE-3657FB43A8AA@fugue.com> <87k223jjdg.wl-jch@irif.fr> <20170817201054.GN45648@Space.Net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 01:33:38 -0000 --Apple-Mail=_3002DF9C-6D08-4D40-B3AB-010EEFFC58E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 El 17 ag 2017, a les 16:10, Gert Doering va escriure: > 1990s never had uplinks that fast *and* unreliable at the same time=20 > as many of today's consumer ISPs offer. That was my point: you tunnel to the 1990's to get the leased line (a = term that I think most people would just squint at nowadays and have no = idea what you meant). The lossy fast connection you'd get to = directly=E2=80=94no need for a wormhole. But in practice, (a) the = lossy connection isn't anywhere near as lossy as you are implying; if it = were, you couldn't use it. And (b) even if it were, I don't think = anything we are talking about here would actually help with that. So I = think it would be wise if we took this use case off the table, unless = someone can characterize it better. Reasoning on the basis of = charicatures isn't going to get us anywhere. --Apple-Mail=_3002DF9C-6D08-4D40-B3AB-010EEFFC58E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 El 17 ag 2017, a les 16:10, Gert Doering <gert@space.net> va = escriure:
1990s never had = uplinks that fast *and* unreliable at the same time 
as many of today's consumer ISPs = offer.

That was my point: you tunnel to the 1990's = to get the leased line (a term that I think most people would just = squint at nowadays and have no idea what you meant).   The lossy = fast connection you'd get to directly=E2=80=94no need for a wormhole. =   But in practice, (a) the lossy connection isn't anywhere near as = lossy as you are implying; if it were, you couldn't use it.  And = (b) even if it were, I don't think anything we are talking about here = would actually help with that.   So I think it would be wise if we = took this use case off the table, unless someone can characterize it = better.   Reasoning on the basis of charicatures isn't going to get = us anywhere.

= --Apple-Mail=_3002DF9C-6D08-4D40-B3AB-010EEFFC58E8-- From nobody Fri Aug 18 02:41:19 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6A213293B for ; Fri, 18 Aug 2017 02:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 Q4qkUjMWZY_g for ; Fri, 18 Aug 2017 02:41:16 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51BD13243A for ; Fri, 18 Aug 2017 02:41:15 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id v7I9fDtn009313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 Aug 2017 11:41:13 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id v7I9f7T0028465; Fri, 18 Aug 2017 11:41:12 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9C3F3EB344; Fri, 18 Aug 2017 11:41:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id gPwky8OV5AGB; Fri, 18 Aug 2017 11:41:06 +0200 (CEST) Received: from trurl.irif.fr (user-46-112-84-118.play-internet.pl [46.112.84.118]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B536BEB343; Fri, 18 Aug 2017 11:41:01 +0200 (CEST) Date: Fri, 18 Aug 2017 11:40:57 +0200 Message-ID: <8760dl9psm.wl-jch@irif.fr> From: Juliusz Chroboczek To: Ted Lemon Cc: HOMENET In-Reply-To: References: <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <874lt8xv9j.fsf@toke.dk> <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> <871soby776.fsf@toke.dk> <769C4508-BB58-4BCB-A3CE-3657FB43A8AA@fugue.com> <87k223jjdg.wl-jch@irif.fr> <20170817201054.GN45648@Space.Net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 18 Aug 2017 11:41:13 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 18 Aug 2017 11:41:13 +0200 (CEST) X-Miltered: at korolev with ID 5996B639.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5996B633.006 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5996B639.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5996B633.006 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5996B639.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5996B633.006 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 09:41:18 -0000 > I don't think anything we are talking about here would actually help > with that. If the fast connection's DNS server replies after a delay or not at all, and the slow connection's DNS server replies in a timely manner, using a smart resolver across all the available DNS servers will improve latency. Both dnsmasq and (I believe) bind will do the smart thing. (Which does not consist in sending the request to all servers, contrary to what you appear to believe.) -- Juliusz From nobody Fri Aug 18 06:21:51 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8346C13240D for ; Fri, 18 Aug 2017 06:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham 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 6mHu7vzUHjVB for ; Fri, 18 Aug 2017 06:21:29 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967351323C0 for ; Fri, 18 Aug 2017 06:21:28 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v7IDFwZq017012 for ; Fri, 18 Aug 2017 09:21:25 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2cds4xc96f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 18 Aug 2017 09:21:25 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7IDLOjq007495 for ; Fri, 18 Aug 2017 09:21:24 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7IDLIGR007407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 18 Aug 2017 09:21:20 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi131.aldc.att.com (RSA Interceptor) for ; Fri, 18 Aug 2017 13:21:07 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.30]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0319.002; Fri, 18 Aug 2017 09:21:07 -0400 From: "STARK, BARBARA H" To: "homenet@ietf.org" Thread-Topic: homenet "no host changes" assumption and DNS Thread-Index: AdMYFPIEV1k/IIYrQxOO94GV5djuUw== Date: Fri, 18 Aug 2017 13:21:06 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DC0163F@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.210.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-18_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708180212 Archived-At: Subject: [homenet] homenet "no host changes" assumption and DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 13:21:39 -0000 No hat. I'm proposing something radical here. Let the tomatoes fly. I'd like to question whether we really need to maintain the "no changes to = the host" assumption when it comes to architecting homenet DNS. Currently, there is no host that expects to use .home.arpa (or any other do= main) inside the premises. There is no host that expects a general-purpose = in-home domain name system to work or be present. The widest use of in-home= domains is the way ISPs use domains like ".home". To the best of my knowle= dge, they use those for access to the ISP-supplied router's HTTP-served con= tent. Nothing else. The "no host changes" tenet was primarily about not bre= aking existing host functionality. A fully functional in-home domain name s= ystem is not something any legacy host has expectations or functionality fo= r. As long as we don't break usage of Internet DNS, there should not be any= requirement or mandate that we have to make in-home DNS work for legacy ho= sts. If we got rid of the "no changes to host" tenet (for hosts that can make us= e of the home naming architecture), that would give us much more freedom to= create an in-home DNS architecture without a dependency on homenet routers= implementing the DNS Proxy kludge. Or any other kludge. It would let us cr= eate an architecture that would finally start to move us away from DNS Prox= y and other methods that intercept DNS queries to make supposedly "intellig= ent" decisions on behalf of stupid hosts. And we would not be further entre= nching use of these DNS intercept functions. I would like to require the hosts that want to make use of the new homenet = naming architecture responsible for understanding the different provisionin= g domains and simultaneously launching queries to the advertised (or intern= ally configured) DNS servers for each provisioning domain.=20 The host that gets multiple DNS responses needs to be responsible for makin= g the decision that's right for it. In the case of multiple Internet connec= tions: if the application needs high bandwidth and low loss but latency isn= 't important (e.g., streaming video), then maybe it picks the high bandwidt= h high latency low loss connection. If it needs low latency but not much ba= ndwidth (e.g., VoIP), then maybe it picks the low bandwidth low latency con= nection. The CE router should not be making this decision (which DNS respon= se to supply to the host) on behalf of apps it knows nothing about. Make the home domain a different provisioning domain, and insist that hosts= wanting to make use of domain names in the home domain must understand pro= visioning domains and how to use and interact with them. The home domain DN= S server can be advertised by mDNS or other means. I truly believe we need to start moving towards providing hosts with the in= fo they need to make their own decisions. DNS Proxy mandates (or other DNS = intercept mechanisms) are antithetical to this.=20 Barbara From nobody Fri Aug 18 06:26:53 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEF813235B for ; Fri, 18 Aug 2017 06:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-com.20150623.gappssmtp.com 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 PtY9jlcJhxQE for ; Fri, 18 Aug 2017 06:26:48 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 252C0132391 for ; Fri, 18 Aug 2017 06:26:47 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id 16so53527343qtz.4 for ; Fri, 18 Aug 2017 06:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S9/sGlZNFDN0+mCslmRcUwc+nfWZDgmuq1XlzzWjTlA=; b=nQR73O0y8xyIChIWLNg5P0VmteYGYsgc3XKAfOOKWS2vRacAXRo8GbAJBsFJEG2ZTb CJTgeEYG6HdDvxBXHS4MqeYUiJ/os0M1eZdD4+SSoWCYFpyrJkrbI5NmZlWGOc9P521y /gqCVm5GbO0GQfg1YvXc4FXxwlfowauB8LbO57+Gfj6Cbw+fO/hw/dBrcrUWdvv4aBHP H2w/SiMR7X8wTVofnpI5u92Z3k7r0Vns6bYMXhz034x2RtEAhg2oN0DoQTYzmXqBEmz2 v2PCDoV70EJe8D3rSDKka+GNujLO8H+v/PvD96J5spV4+aL1Q+z+bRWyDF1iHRGhyGZ7 zhlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S9/sGlZNFDN0+mCslmRcUwc+nfWZDgmuq1XlzzWjTlA=; b=LJEqvGAN6mwaJNnRsSdhv5+6/RbeJJdep0s3mnFZR+D6VSEL+s+4vDHX/ZC7Ny50bA jsDVgYY2ExBzQuNdnWTHU2SjPnBLwCynnubO/l/m/moAQVFRL9M9DCG7RO00AohRXlil 3yh6aD5+3tC2TsLo1P0/8pfxRlusDfzaQn3rwBK+M0pkQr3d2Kr8ja3CboSMH09ArXXp j3Lr1Dj1eMnVvef9eUl9x/AwU1IaxhwZ/r9akQP5xwiZA6xo2EKHi5v9fxFZ6NqHMY/u CF4nWQHLy38XuFBAfhAXdvlxZMgnyeTqScaDQBpGb5Sy28InAzrTPP8iktebiiO2lWoW rjQA== X-Gm-Message-State: AHYfb5hs7BuIe9YL6EKVHxXMRZlfe2rxkDbrbCZ1Sgfb7guKX2IcI0DU WjnF10GtvS66TbPR X-Received: by 10.200.3.94 with SMTP id w30mr3581590qtg.225.1503062806236; Fri, 18 Aug 2017 06:26:46 -0700 (PDT) Received: from [10.0.30.153] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id z187sm3533840qke.1.2017.08.18.06.26.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 06:26:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DC0163F@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Fri, 18 Aug 2017 09:26:42 -0400 Cc: "homenet@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6114DC0163F@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] homenet "no host changes" assumption and DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 13:26:52 -0000 I think that what you are proposing here is great, except that I don't = think we actually _need_ to go out of charter on this. I think that = what Toke has been advocating can be worked into the framework you are = describing, so that you and I! get what we want, and Toke gets what he = wants. > El 18 ag 2017, a les 9:21, STARK, BARBARA H va = escriure: >=20 > No hat. > I'm proposing something radical here. Let the tomatoes fly. > I'd like to question whether we really need to maintain the "no = changes to the host" assumption when it comes to architecting homenet = DNS. > Currently, there is no host that expects to use .home.arpa (or any = other domain) inside the premises. There is no host that expects a = general-purpose in-home domain name system to work or be present. The = widest use of in-home domains is the way ISPs use domains like ".home". = To the best of my knowledge, they use those for access to the = ISP-supplied router's HTTP-served content. Nothing else. The "no host = changes" tenet was primarily about not breaking existing host = functionality. A fully functional in-home domain name system is not = something any legacy host has expectations or functionality for. As long = as we don't break usage of Internet DNS, there should not be any = requirement or mandate that we have to make in-home DNS work for legacy = hosts. >=20 > If we got rid of the "no changes to host" tenet (for hosts that can = make use of the home naming architecture), that would give us much more = freedom to create an in-home DNS architecture without a dependency on = homenet routers implementing the DNS Proxy kludge. Or any other kludge. = It would let us create an architecture that would finally start to move = us away from DNS Proxy and other methods that intercept DNS queries to = make supposedly "intelligent" decisions on behalf of stupid hosts. And = we would not be further entrenching use of these DNS intercept = functions. >=20 > I would like to require the hosts that want to make use of the new = homenet naming architecture responsible for understanding the different = provisioning domains and simultaneously launching queries to the = advertised (or internally configured) DNS servers for each provisioning = domain.=20 >=20 > The host that gets multiple DNS responses needs to be responsible for = making the decision that's right for it. In the case of multiple = Internet connections: if the application needs high bandwidth and low = loss but latency isn't important (e.g., streaming video), then maybe it = picks the high bandwidth high latency low loss connection. If it needs = low latency but not much bandwidth (e.g., VoIP), then maybe it picks the = low bandwidth low latency connection. The CE router should not be making = this decision (which DNS response to supply to the host) on behalf of = apps it knows nothing about. >=20 > Make the home domain a different provisioning domain, and insist that = hosts wanting to make use of domain names in the home domain must = understand provisioning domains and how to use and interact with them. = The home domain DNS server can be advertised by mDNS or other means. >=20 > I truly believe we need to start moving towards providing hosts with = the info they need to make their own decisions. DNS Proxy mandates (or = other DNS intercept mechanisms) are antithetical to this.=20 > Barbara >=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Fri Aug 18 07:31:05 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D480413218C for ; Fri, 18 Aug 2017 07:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-com.20150623.gappssmtp.com 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 brwth88Sq0Aw for ; Fri, 18 Aug 2017 07:31:01 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 A3B2B132402 for ; Fri, 18 Aug 2017 07:31:01 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id b4so6767037qta.1 for ; Fri, 18 Aug 2017 07:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fwf90+cYNwHzN6EvUYTEp1p5a7i48lCPTI8AfbwN4Zo=; b=czYRYVh1wHqgoHOxZjBgkAFBOkb7Q71/isvKh3yFGpvJZA831C27CSjVrwcwSxEXmM cU1rdJqmt77PVg2NtevL4Ru27D3QfqDQZuOwoYu3Ar9D9laKXHtdQ2sEcWeztbE24DP/ 7RM+dtAUgN7V6B785aaQ5JBtUnDRvnv84pbKp/D0KOO/54jf5Q1HcoiLii848c6TwCjQ p7KTM9KjX//7Gd3awpv9WB95K2Odk0le7YZZkTq1pUTtnl737+wwmM5mIUM0dz4uowAB wEetlrRNJLrc+4B4rrojEl46+dNWLMtZgu/UX/2WxTZMZFYb2Oh2iiWhQJIpiQNIUtOt B/Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fwf90+cYNwHzN6EvUYTEp1p5a7i48lCPTI8AfbwN4Zo=; b=ViCnjZsWbL6M1IE21H3A09mDkuhPq7BLoEHMFTy3O4bzDWskMle9QNXK4NBcBzYm02 VJ2SHkxi2VrJ7qdnmyhCZUXDide8AAWbS8z261Z6V6UGtdVc9XuxqSM6O7i+2N4PTd3j /oUirMgOdcVYlrZg83xCatQSeq0AaCZfRYl513TI57JCyZe7EPaWYQxhlIGJG/SRMStN r5Bb8JVbjR1gYPqSAsn5HHCg2+O6adOq2WwyMmk3nrQZl5UybwG/qQoI/oID44LCGo4k bIPAF4UdqQ3XFixMJ5uB35vauiym3LZognzs9TbWhXTFzdVLNKJBZBKH0u7BomY5xzvM /OnA== X-Gm-Message-State: AHYfb5hOCl9vaIpIiHSmdbb7lPC/9E8opU7vCJeEfapNfbax92JCwVee Fw38bcVyMZnHzfebzQVypQ== X-Received: by 10.237.60.104 with SMTP id u37mr7880096qte.83.1503066660675; Fri, 18 Aug 2017 07:31:00 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id b52sm3978943qta.88.2017.08.18.07.30.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 07:30:59 -0700 (PDT) From: Ted Lemon Message-Id: <65C445C6-F288-4131-8B32-838AA0FB9809@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5CD107F8-9E47-4021-AD19-0E13B52CB318" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 18 Aug 2017 10:30:57 -0400 In-Reply-To: <8760dl9psm.wl-jch@irif.fr> Cc: HOMENET To: Juliusz Chroboczek References: <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <874lt8xv9j.fsf@toke.dk> <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> <871soby776.fsf@toke.dk> <769C4508-BB58-4BCB-A3CE-3657FB43A8AA@fugue.com> <87k223jjdg.wl-jch@irif.fr> <20170817201054.GN45648@Space.Net> <8760dl9psm.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 14:31:05 -0000 --Apple-Mail=_5CD107F8-9E47-4021-AD19-0E13B52CB318 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii El 18 ag 2017, a les 5:40, Juliusz Chroboczek va escriure: > If the fast connection's DNS server replies after a delay or not at = all, > and the slow connection's DNS server replies in a timely manner, using > a smart resolver across all the available DNS servers will improve = latenc Yes, but if your fast connection is lossy, it's not fast. Lossy looks = like congestion, so TCP slows down. There's nothing we can do in the = resolver to fix this. You want less complexity, but to successfully = determine which link is the right one to use at the network level is a = very hard problem, much harder than anything we are talking about here. = It might be an interesting research topic, but it doesn't make sense = for you to raise it as an argument in favor of one or another options = for configuring resolvers. --Apple-Mail=_5CD107F8-9E47-4021-AD19-0E13B52CB318 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 18 ag 2017, a les 5:40, Juliusz Chroboczek <jch@irif.fr> va = escriure:
If the fast = connection's DNS server replies after a delay or not at all,
and the slow connection's DNS server replies in = a timely manner, using
a smart resolver = across all the available DNS servers will improve = latenc

Yes, = but if your fast connection is lossy, it's not fast.   Lossy looks = like congestion, so TCP slows down.   There's nothing we can do in = the resolver to fix this.   You want less complexity, but to = successfully determine which link is the right one to use at the network = level is a very hard problem, much harder than anything we are talking = about here.   It might be an interesting research topic, but it = doesn't make sense for you to raise it as an argument in favor of one or = another options for configuring resolvers.

= --Apple-Mail=_5CD107F8-9E47-4021-AD19-0E13B52CB318-- From nobody Fri Aug 18 07:51:06 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB31132405 for ; Fri, 18 Aug 2017 07:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=SqaWDWka; dkim=pass (1024-bit key) header.d=yitter.info header.b=TsXHC8PR 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 fYHdoJUY1v6M for ; Fri, 18 Aug 2017 07:51:02 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE4C126BFD for ; Fri, 18 Aug 2017 07:51:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id B9D9EC09A0 for ; Fri, 18 Aug 2017 14:51:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1503067861; bh=SNol8mnBxD4gMBwsqiSRASyS9pGSu3EdKWI8Blr764U=; h=Date:From:To:Subject:References:In-Reply-To:From; b=SqaWDWkatiJNn0UH/Nz4fmksq79pYt2qR+FETrJWLxsX8z/Mn1ySqndjl8P/aHtlR Zs7X/lGxoRaq+RabK2jGXztb+LmJGFu5PLuhaBHxMRL3O+xrASOAzvp+1mlUIz82aM 8zy3QxNwqxe+1FJirDJ19S/FyazOlgicegPwSk18= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LB5JAPcgzN8h for ; Fri, 18 Aug 2017 14:51:00 +0000 (UTC) Date: Fri, 18 Aug 2017 10:50:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1503067860; bh=SNol8mnBxD4gMBwsqiSRASyS9pGSu3EdKWI8Blr764U=; h=Date:From:To:Subject:References:In-Reply-To:From; b=TsXHC8PRpsD59mNVAAuI3qacrLCDN3oX2pnWw1I97XeynNfEOPa15fevFWVsptr9r zNuzdFI6YKWwwhdB8xvzElZop3dhWuu5KqFWk8h0V04wo2ZMP16Dxy4N7+tgch8Bq5 HVNQHcsBXW2/heHOB8UQVccPZuWjxEgraEisH6xs= From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20170818145059.hgyoazgrejopz5nz@mx4.yitter.info> References: <2D09D61DDFA73D4C884805CC7865E6114DC0163F@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DC0163F@GAALPA1MSGUSRBF.ITServices.sbc.com> Archived-At: Subject: Re: [homenet] homenet "no host changes" assumption and DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 14:51:04 -0000 Hi, On Fri, Aug 18, 2017 at 01:21:06PM +0000, STARK, BARBARA H wrote: > Currently, there is no host that expects to use .home.arpa (or any other domain) inside the premises. I don't think the "or any other domain" claim is true. At the very least, _lots_ of hosts are already using local. in homenets -- indeed, that's how we got to this pass. > There is no host that expects a general-purpose in-home domain name system to work or be present. That's because there is no host that "expects an in-home domain name system" at all. I think your position is starting from a position with which I disagree pretty strongly. In my view, what we did many years ago was hook up individual machines to an ISP's network. When broadband home access came along, we continued to pretend that the link in the CPE was just a node in an ISP's network, and pretended that the home network was not a first-class network that was internetworked together with other networks to make the Internet. We ended up with multiple classes of network, some of which are only kinda part of the Internet. The reason that homenet is being worked on in the IETF as opposed to, say, the Broadband Forum, is exactly that we are trying to provide internetworking services for these surprisingly sophisticated, unmanaged networks. So to say that there's no "general-purpose in-home domain name system" misses the point: it's _the_ domain name system, and the homenet is part of that global DNS just as surely as com. is, and participates in the global name space just as surely as onion. and local. do. So, the reason we can't expect host changes for naming is because any plan for internetworking that starts, "First, upgrade all the hosts," is doomed. That hasn't worked since 1983. > If we got rid of the "no changes to host" tenet (for hosts that can make use of the home naming architecture), that would give us much more freedom to create an in-home DNS architecture without a dependency on homenet routers implementing the DNS Proxy kludge. Or any other kludge. It would let us create an architecture that would finally start to move us away from DNS Proxy and other methods that intercept DNS queries to make supposedly "intelligent" decisions on behalf of stupid hosts. And we would not be further entrenching use of these DNS intercept functions. > I don't understand how you can claim the above: the plain fact of the matter is that we have multiple domain-name-using protocols in action here: at the very least, mDNS, DNS, and LLMNR, and maybe Tor resolution and some other stuff. If what you're saying instead is that hosts are supposed to know which networking context they're living in, then perhaps we need a radical rethinking of what we're working on. It _might_ be the case that end to end is the wrong model given the kinds of things we turn out to be attaching to the Internet (this was part of what got discussed in the IAB's technical plenary last November). But if that's what we're doing, I think this WG needs at the very least to go through a round of rechartering so that the rest of the IETF understands that we are proposing a really significant break with the nominal Internet architecture. I'm not convinced that the WG has the patience to do such an effort, BTW. But I think this is a pretty fundamental change you're proposing, and I think it would not be wrong for the IETF to push back pretty hard against such a change should the WG come out with documents that embed such an assumption. > I would like to require the hosts that want to make use of the new homenet naming architecture responsible for understanding the different provisioning domains and simultaneously launching queries to the advertised (or internally configured) DNS servers for each provisioning domain. > DNS doesn't work that way, is the problem. It doesn't have a mode bit. What you are proposing is homenet-DNS; it's a new protocol. Maybe that's the right answer, but I'm far from convinced that this is the place to create DNSbis. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Aug 18 08:28:15 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C6E13296D for ; Fri, 18 Aug 2017 08:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 9dn-DhHS8fhd for ; Fri, 18 Aug 2017 08:28:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353EF132977 for ; Fri, 18 Aug 2017 08:28:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A8220E20C; Fri, 18 Aug 2017 11:24:12 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EC11880E71; Fri, 18 Aug 2017 11:21:26 -0400 (EDT) From: Michael Richardson To: "STARK\, BARBARA H" cc: Andrew Sullivan , "homenet\@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DC00E2A@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <12755.1502913036@obiwan.sandelman.ca> <20170816203557.ieqnyepjqpoeq6um@mx4.yitter.info> <3387.1502980011@obiwan.sandelman.ca> <2D09D61DDFA73D4C884805CC7865E6114DC00E2A@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [homenet] tuscles and conflicting goals / trust with draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 15:28:13 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable STARK, BARBARA H wrote: >> This suggests to me that the next step in HOMENET, which I think the= naming >> architecture could lead, is to provide for (automatic) collection of= statistics for >> diagnostics purposes. >> i.e. Homenet OAM. > Not as chair... > I disagree this has anything to do with the naming architecture. The reason I suggest that the naming architecture could lead this, is becau= se due to the multi-provider nature, we get specifically interesting statistics From=20end-systems about how well they are communicating with their intended targets. Further, in order to deal with this kind of thing, there are host changes desired, so doing OAM on those changes seems like not too much a st= retch. For instance, how many times did they pick a src/dst combination for a DNS query, or a data transmission, for which there was a communication failure? > I have long felt the best way to accomplish this would be to have a > discoverable (DNS-SD) NetJSON (http://netjson.org/) "service" on all > consumer routers, which would supply NetJSON types via http. > I agree supplying statistics info to the home network would be a good > thing for homenet to tackle. > I've been wanting to propose this for a while, but keep getting side-= tracked. You have described a mechanism to collect the statistics, and it seems like= a very good suggestion. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmXBfYACgkQgItw+93Q 3WVlqAf/Vm7723flb1+y8wg1qf3ardBXrZVcKNFTlFDy+IAuWsvR/X0mzwjv2xy7 +hl8n1mRO32atW6wa8yiznPP8s19X3CZyzkd9FSF9V61UZsN5/dOVkoGvyMqiDF5 H2WnDJ+IP40z8kb7ICkS3RzgYZtEvLXaTYuWBfaSAmzGucjk6ZxdatdQma3XTiMg J6cdaJ3MiNkT1TKskfZaquRrI8bdGkHmLr1/fHK4HdGZWj3Wbiy5WUI5OOp6yCnu HX6O2uWqU/j9qs2i+ui6osXGm1/4Hc+0hHLV4p9QXhkL/9R95qYkYtKV0AYito5c sx6JNZ3HZPOzBwzu96ATD9ABhh71fw== =x6ab -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 18 08:38:56 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8781329A9 for ; Fri, 18 Aug 2017 08:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 kBOyUt0WszOs for ; Fri, 18 Aug 2017 08:38:52 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF8D1320E3 for ; Fri, 18 Aug 2017 08:38:52 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1503070729; bh=82R3rMO97/5JJoCxl1THHpJq7uwSSwDR97B/W4BU5B4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=F/txdAAE4eaFUHMA1anZKkIhbcaVQJUcrU92/JtL3Kg6fd9wt2MU/3iOuESDMbnxN VMq3iKOExf7Aw76itR5xQ/14HJdo50iUXNjKeitqqrpfoXGo1bfwIQfYtk7ae+GWsX ++50QSBpFnt8ntxhywVgUOjQLudxNaTdfX0hO6CX9ZRLSw5Yz/YjKwJjI68WlKqbMY /IJBv5OOC+cDK25rLnKEsvRZkHPBi/Sqs6WOej0yNFzzJoyf+uKiWAsUAyB32goeTz BwAuiDYESdcYjKX9u1EQDrJjI8hYodVQq+sO3WddL3n0P21Bht5DzhcBmuNVuDZnAB AWW+RpjT7zpOQ== To: Ted Lemon , "STARK\, BARBARA H" Cc: "homenet\@ietf.org" In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DC0163F@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Fri, 18 Aug 2017 17:38:53 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87bmncx4vm.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] homenet "no host changes" assumption and DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 15:38:54 -0000 Ted Lemon writes: > I think that what you are proposing here is great, except that I don't > think we actually _need_ to go out of charter on this. I think that > what Toke has been advocating can be worked into the framework you are > describing, so that you and I! get what we want, and Toke gets what he > wants. Yeah, I think so too. I.e., we can create a framework that will work for existing hosts and still provide the information for more capable hosts to do their thing. Whether these more capable hosts will actually end up performing better is another matter; but I guess we'll see about that... ;) -Toke From nobody Fri Aug 18 09:44:23 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1CB132A13; Fri, 18 Aug 2017 09:43:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault To: Cc: draft-ietf-homenet-dot.all@ietf.org, homenet@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150307463977.14156.2178189421671973906@ietfa.amsl.com> Date: Fri, 18 Aug 2017 09:43:59 -0700 Archived-At: Subject: [homenet] Secdir last call review of draft-ietf-homenet-dot-12 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 16:44:00 -0000 Reviewer: Daniel Migault Review result: Has Nits Thank you for writing the draft. Please find my comments. I hope there are helpful. Yours, Daniel Special Use Domain 'home.arpa.' draft-ietf-homenet-dot-12 Abstract This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.', and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I would personally start by saying the document defines a special-use domain name and then defines the behavior. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 11, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Pfister & Lemon Expires February 11, 2018 [Page 1] Internet-Draft dot homenet August 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3 4. Domain Name Reservation Considerations . . . . . . . . . . . 3 5. Updates to Home Networking Control Protocol . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Delegation of 'home.arpa.' . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Users and devices within a home network (hereafter "homenet") require devices and services to be identified by names that are unique within the boundaries of the homenet [RFC7368]. The naming mechanism needs to function without configuration from the user. While it may be possible for a name to be delegated by an ISP, homenets must also function in the absence of such a delegation. A default name with a scope limited to each individual homenet needs to be used. This document corrects an error in [RFC7788], replacing '.home' with 'home.arpa.' as the default domain-name for homenets. '.home' had been selected as the most user-friendly option. However, there are existing uses of '.home' that may be in conflict with this use: evidence indicates that '.home' queries frequently leak out and reach the root name servers [ICANN1] [ICANN2]. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I believe that more important than the leak is that the introduction of .home in the root zone has been identified as highly risky. Another reason for not adopting it are also some uncertainty about its introduction into the root zone. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% In addition, it's necessary, for compatibility with DNSSEC (Section 6), that an insecure delegation ([RFC4035] section 4.3) be present for the name. There is an existing process for allocating names under '.arpa' [RFC3172]. No such process is available for requesting a similar delegation in the root at the request of the IETF, which does not administer that zone. As a result, the use of '.home' is deprecated. This document registers the domain '.home.arpa.' as a special-use domain name [RFC6761] and specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names whose rightmost non-terminal labels are 'home.arpa.'. Queries for Pfister & Lemon Expires February 11, 2018 [Page 2] Internet-Draft dot homenet August 2017 names ending with '.home.arpa.' are of local significance within the scope of a homenet, meaning that identical queries will result in different results from one homenet to another. In other words, a name ending in 'home.arpa.' is not globally unique. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I think the text mentioned in the beginning of the paragraph above should be in the abstract. That was the sense of my previous comment. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Although this document makes specific reference to RFC7788, it is not intended that the use of 'home.arpa.' be restricted solely to networks where HNCP is deployed; it is rather the case that 'home.arpa.' is the correct domain for uses like the one described for '.home' in RFC7788: local name service in residential homenets. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. General Guidance The domain name '.home.arpa.' is to be used for naming within residential homenets. Names ending with '.home.arpa.' reference a locally-served zone, the contents of which are unique only to a particular homenet, and are not globally unique. Such names refer to nodes and/or services that are located within a homenet (e.g., a printer, or a toaster). DNS queries for names ending with '.home.arpa.' are resolved using local resolvers on the homenet. Such queries MUST NOT be recursively forwarded to servers outside the logical boundaries of the homenet. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: "local resolvers" seems to me mis-leading. Your resolver may be local but still forward the query to the Global Internet. I do not see better ways to say it other than inside the boundaries of the homenet. Maybe we could say: DNS queries for names ending with '.home.arpa.' are resolved using homenet specific resolution mechanisms. Eventually an informational reference to the simple naming architecture may be added so the reader can refer to the doc for further information. For full disclosure Ted and I are co-authors. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Some service discovery user interfaces that are expected to be used on homenets conceal information such as domain names from end users. However, it is still expected that in some cases, users will need to see, remember, and even type, names ending with 'home.arpa.'. It is therefore desirable that users identify the domain and understand that using it expresses the intention to connect to a service that is specific to the homenet to which they are connected. Enforcing the fulfillment of this intention is out of scope for this document. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I have difficulties understanding the paragraph above. If the idea is to say home.arpa has special meaning that should be considered by GUIs I would propose the following ordering. It is therefore desirable that users identify the domain and understand that using it expresses the intention to connect to a service that is specific to the homenet to which they are connected. Some service discovery user interfaces that are expected to be used on homenets conceal information such as domain names from end users. However, it is still expected that in some cases, users will need to see, remember, and even type, names ending with 'home.arpa.'. Enforcing the fulfillment of this intention is out of scope for this document. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 4. Domain Name Reservation Considerations This section defines the behavior of systems involved in domain name resolution when resolving queries for names ending with '.home.arpa.' (as per [RFC6761]). Pfister & Lemon Expires February 11, 2018 [Page 3] Internet-Draft dot homenet August 2017 1. Users can use names ending with '.home.arpa.' just as they would use any other domain name. The 'home.arpa.' name is chosen to be readily recognized by users as signifying that the name is addressing a service on the homenet to which the user's device is connected. 2. Application software SHOULD NOT treat names ending in 'home.arpa.' differently than other names. In particular, there is no basis for trusting names that are subdomains of 'home.arpa.' (see Section 6). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: a domain name ending in home.arpa may be resolved differently that a regular domain name. As a result a different treatment is applied. I think that "treat" means that no special meaning - other that the domain name is inside the homenet boundaries - should be associated to a home.arpa. If I am correct I would limit the consideration to the name rather then the application. I would suggest the text below: names ending in home.arpa SHOULD NOT be associated any other properties than the affiliation to the homenet. In particular, there is no basis for trusting names that are subdomains of 'home.arpa.' (see Section 6). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 3. Name resolution APIs and libraries MUST NOT recognize names that end in '.home.arpa.' as special and MUST NOT treat them differently. Name resolution APIs MUST send queries for such names to a recursive DNS server that is configured to be authoritative for the 'home.arpa.' zone appropriate to the homenet. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I believe the text below does not concern the library but the resolver. It is different to say libraries MUST NOT have specific considerations for home.arpa than a resolution service that may use different libraries MUST NOT consider the home.arpa differently. My understanding of the text below is that the resolver and the authoritative server for the home.arpa MUST be co-located. The reasons I think this is not exact is that resolution for home.arpa can also be provided by other mechanisms than an authoritative server. Typically, resolution can be done by requesting Authoritative Servers, Advertising Proxies, Hybrid Proxies (now called Discovery Proxies).... The other reason is do not see the text below accurate is that you may have a DNS Proxy that transparently to the end user split the resolution between homenet specific resolutions when home.arpa is encountered while other names are sent to the ISP resolver. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% One or more IP addresses for recursive DNS servers will usually be supplied to the client through router advertisements or DHCP. If a host is configured to use a resolver other than one that is authoritative for the appropriate 'home.arpa.' zone, the client may be unable to resolve, or may receive incorrect results for, names in sub domains of 'home.arpa.'. 4. Caching resolvers conforming to this specification MUST support DNSSEC queries. While validation is not required, it is strongly encouraged; a caching resolver that does not validate answers that can be validated may cache invalid data; this will prevent validating stub resolvers from successfully validating answers. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I see the text above as a recommendation for caching resolvers in the homenet, but the relation to the home.arpa is unclear to me. Was the intention to say that names under the home.arpa zone SHOULD be secured with DNSSEC so caching resolvers MUST support DNSSEC validation. In addition, these caching resolvers MUST also be able to be configured with a Trust Anchor for the home.arpa. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3). That is, queries for domains that are subdomains of 'home.arpa.' MUST NOT be forwarded, with one important exception: a query for a DS record when the DO bit ([RFC4035] section 3.2.1) set MUST return the correct answer for that question, including correct information in the authority section that proves that the record is nonexistent. So for example a query for the NS record for 'home.arpa.' MUST NOT result in that query being forwarded to an upstream cache nor to the authoritative DNS server for '.arpa.'. However, as necessary to provide accurate authority information, a query for the DS record MUST result in whatever queries are necessary being forwarded; typically, this will just be a query for the DS record, since the necessary authority information will be included in the authority section of the response if the DO bit is set. Pfister & Lemon Expires February 11, 2018 [Page 4] Internet-Draft dot homenet August 2017 In addition to the behavior specified above, recursive resolvers that can be used in a homenet MUST be configurable with a delegation to an authoritative server for that particular homenet's instance of the domain 'home.arpa.'. It is permissible to combine the recursive resolver function for general DNS lookups with an authoritative resolver for 'home.arpa.'; in this case, rather than forwarding queries for subdomains of 'home.arpa.' to an authoritative server, the caching resolver answers them authoritatively. The behavior with respect to forwarding queries specifically for 'home.arpa.' remains the same. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: The full consideration seems to me to be conformance to RFC6303. In particular the recommendations for DNSSEC in RFC 6303 seems to me accurated and are not specifically mentioned here. Maybe that should be clearly stated that all considerations of RFC6303 should be considered as home.arpa is of local scope. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 5. No special processing of 'home.arpa.' is required for authoritative DNS server implementations. It is possible that an authoritative DNS server might attempt to check the authoritative servers for 'home.arpa.' for a delegation beneath that name before answering authoritatively for such a delegated name. In such a case, because the name always has only local significance there will be no such delegation in the 'home.arpa.' zone, and so the server would refuse to answer authoritatively for such a zone. A server that implements this sort of check MUST be configurable so that either it does not do this check for the 'home.arpa.' domain, or it ignores the results of the check. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I understand this as being incorrect. The resolver can also be configured with a trust anchor. I would refer to the RFC6303: As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA namespaces, the zones listed above will need to be delegated as insecure delegations, or be within insecure zones. This will allow DNSSEC validation to succeed for queries in these spaces despite not being answered from the delegated servers. It is recommended that sites actively using these namespaces secure them using DNSSEC [RFC4035] by publishing and using DNSSEC trust anchors. This will protect the clients from accidental import of unsigned responses from the Internet. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 6. DNS server operators MAY configure an authoritative server for 'home.arpa.' for use in homenets and other home networks. The operator for the DNS servers authoritative for 'home.arpa.' in the global DNS will configure any such servers as described in Section 7. 7. 'home.arpa.' is a subdomain of the 'arpa' top-level domain, which is operated by IANA under the authority of the Internet Architecture Board according to the rules established in [RFC3172]. There are no other registrars for .arpa. 5. Updates to Home Networking Control Protocol The final paragraph of Home Networking Control Protocol [RFC7788], section 8, is updated as follows: OLD: Names and unqualified zones are used in an HNCP network to provide naming and service discovery with local significance. A network- wide zone is appended to all single labels or unqualified zones in order to qualify them. ".home" is the default; however, an administrator MAY configure the announcement of a Domain-Name TLV Pfister & Lemon Expires February 11, 2018 [Page 5] Internet-Draft dot homenet August 2017 (Section 10.6) for the network to use a different one. In case multiple are announced, the domain of the node with the greatest node identifier takes precedence. NEW: Names and unqualified zones are used in an HNCP network to provide naming and service discovery with local significance. A network- wide zone is appended to all single labels or unqualified zones in order to qualify them. 'home.arpa.' is the default; however, an administrator MAY configure the announcement of a Domain-Name TLV (Section 10.6) for the network to use a different one. In case multiple are announced, the domain of the node with the greatest node identifier takes precedence. The 'home.arpa.' special-use name does not require a special resolution protocol. Names for which the rightmost two labels are 'home.arpa.' are resolved using the DNS protocol [RFC1035]. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: If home.arpa are no different than other resolutions and we start from the root zone responses are likely to be NXDOMAIN. I think we should clarify that DNS is used as a transport protocol, but that resolution may be handled differently. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 6. Security Considerations A DNS record that is returned as a response to a query for an FQDN in the domain '.home.arpa.' is expected to have local significance. It is expected to be returned by a server involved in name resolution for the homenet the device is connected in. However, such response MUST NOT be considered more trustworthy than would be a similar response for any other DNS query. Because 'home.arpa.' is not globally scoped and cannot be secured using DNSSEC based on the root domain's trust anchor, there is no way to tell, using a standard DNS query, in which homenet scope an answer belongs. Consequently, users may experience surprising results with such names when roaming to different homenets. To prevent this from happening, it may be useful for the resolver to identify different homenets on which it has resolved names, but this is out of scope for this document. It is not possible to install a trust anchor for this zone in the '.arpa' zone. The reason for this is that in order to do so, it would be necessary to have the key-signing key for the zone ([RFC4034] Section 5). Since the zone is not globally unique, no one key would work. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I think that DS is meant rather than trust anchor. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% An alternative would be to install a authenticated denial of existence ([RFC4033] Section 3.2). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: This is unclear where the denial of existence is set. Is that in the home.arpa zone or the arpa zone. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% However, this assumes that validation is being done on a caching resolver that is aware of the special local meaning of 'home.arpa.'. If a host stub resolver attempts to validate a name in 'home.arpa.', an authenticated denial Pfister & Lemon Expires February 11, 2018 [Page 6] Internet-Draft dot homenet August 2017 of existence of 'home' as a subdomain of 'arpa.' would cause the validation to fail. Therefore, the only delegation that will allow names under 'home.arpa.' to be resolved is an insecure delegation, as in [RFC6303] section 7. Consequently, unless a trust anchor for the particular instance of the 'home.arpa.' zone being validated is manually configured on the validating resolver, DNSSEC signing of names within the 'home.arpa.' zone is not possible. Although in principle it might be useful to install a trust anchor for a particular instance of 'home.arpa.', it's reasonable to expect that a host with such a trust anchor might from time to time connect to more than one network with its own instance of 'home.arpa.'. Such a host would be unable to access services on any instance of 'home.arpa.' other than the one for which a trust anchor was configured. It is in principle possible to attach an identifier to an instance of 'home.arpa.' that could be used to identify which trust anchor to rely on for validating names in that particular instance. However, the security implications of this are complicated, and such a mechanism, as well as a discussion of those implications, is out of scope for this document. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: There are also some privacy issues associated to leaking names outside the homenet boundaries. For example daniel_smith.home.arpa reveal the identity of the member of the homenet, my_ipad.home.arpa reveals the devices you own, the application. home.arpa may also used in larger environment such as corporate / private. going from one to the other may also leak such information. The leak can be from the homenet to the outside world in which case one neeed to control the queries sent. But in intruder (or guest) may also access the homenet and proceed to discovery of the names. As a result even though homenet is believe to be a trusted environment, care should be considered while publishing under the home.arpa. as well as whose the information is accessible to. They might be collision as well. myprinter.home.arpa may be found in various environments, and upon discovery you may also - in this example - print confidential information to that printer. In some case you may not even be aware, for example, if your printing information failed home, and is re-activated once you are in another environment. As information may be sensitive it may be encrypted using IPsec DTLS as described by dprive for both authentication and confidentiality. When the trust anchor is configured in the resolver, these must be able to roll-over the key and should follows the requirements for DNSSEC validators. if it is impossible for a resolver to see the difference between an attack and a re-key we are in trouble. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 7. Delegation of 'home.arpa.' In order to be fully functional, there must be a delegation of 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST NOT include a DS record, and MUST point to one or more black hole servers, for example 'blackhole-1.iana.org.' and 'blackhole- 2.iana.org.'. The reason that this delegation must not be signed is that not signing the delegation breaks the DNSSEC chain of trust, which prevents a validating stub resolver from rejecting names published under 'home.arpa.' on a homenet name server. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: The zone home.arpa MUST NOT be seen as belonging to the homenet. As a result, NS and DS records for home.arpa does not have meanings outside a specific domain. A Public server outside the boundaries of the homenet MUST consider this traffic as irrelevant and sink. Redirection to as112 without coordination with as112 operator may rather be performed using DNAME. I believe more text should document the two alternative. With the proposed configuration, the query will be directed to a server that is not authoritative for the zone. The response is likely to be REFUSED, while in the other case it is likely to be NXDOMAIN. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 8. IANA Considerations IANA is requested to record the domain name 'home.arpa.' in the Special-Use Domain Names registry [SUDN]. IANA is requested, with the approval of IAB, to implement the delegation requested in Section 7. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: OK if IANA may make the direct way work. In that case is there any need to update a registry for zone served by as112? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From nobody Fri Aug 18 09:52:22 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DFD132A0A; Fri, 18 Aug 2017 09:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 twuFlkV1sb21; Fri, 18 Aug 2017 09:52:11 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAFD13219F; Fri, 18 Aug 2017 09:52:08 -0700 (PDT) X-AuditID: c618062d-b7bff70000004f0a-ed-5997323043f0 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 94.E8.20234.03237995; Fri, 18 Aug 2017 20:30:08 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0352.000; Fri, 18 Aug 2017 12:52:06 -0400 From: Daniel Migault To: Daniel Migault , "secdir@ietf.org" CC: "draft-ietf-homenet-dot.all@ietf.org" , "homenet@ietf.org" , "ietf@ietf.org" Thread-Topic: [secdir] Secdir last call review of draft-ietf-homenet-dot-12 Thread-Index: AQHTGEFPNcIi2xMGa0+hL4jWilNTs6KKUyPA Date: Fri, 18 Aug 2017 16:52:06 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CD0C08@eusaamb107.ericsson.se> References: <150307463977.14156.2178189421671973906@ietfa.amsl.com> In-Reply-To: <150307463977.14156.2178189421671973906@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPuK6B0fRIg2nrtCwef5zCZvF+0SEW i2cb57NYfFj4kMWBxWPJkp9MAYxRXDYpqTmZZalF+nYJXBk3f2xmL7j2krHiX5NhA+O5LYxd jJwcEgImEvff7mTrYuTiEBI4yihxcskXVghnOaNE69J2NpAqNgEjibZD/ewgtohAuMSjHWcZ QYqYBWYzSizuWMYCkhAW8JJYuGgWG0SRt0RHz3co20ji9oE/YOtYBFQljny5xwRi8wr4Shzf eQusV0jAWWLa0adgcU4BF4lZO7czg9iMAmIS30+tAYszC4hL3HoynwnibAGJJXvOM0PYohIv H/9jhbCVJD7+ns8OUa8jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsC RpZVjBylxQU5uelGBpsYgdFxTIJNdwfj/emehxgFOBiVeHgT1aZHCrEmlhVX5h5ilOBgVhLh FXg2LVKINyWxsiq1KD++qDQntfgQozQHi5I474TzFyKEBNITS1KzU1MLUotgskwcnFINjF39 ayqWb4ybJPt3pnhCcPv9m9LyatcXbLjq++D6jKv2UhsfrzqfvjFhoaWs0e095hMk5NrnZJZt f3mjUds7ucnK9f0P8Sfdy/OSzT4++CXzdpnyq27Jtp0P7u5hFGY0Tn0q+NExlPGsbcu1zU1v HvP831pygV2RZ+sBlWcxxxecdNDacS3VM0uJpTgj0VCLuag4EQDRky9wigIAAA== Archived-At: Subject: Re: [homenet] [secdir] Secdir last call review of draft-ietf-homenet-dot-12 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 16:52:15 -0000 Hi,=20 I used the web form and expected that the boilerplate would automatically b= e added. This explains why the introduction may look a bit directive or dry= . To clarify the scope of my reviews, I am adding the boilerplate below. I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. Yours,=20 Daniel -----Original Message----- From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Daniel Migault Sent: Friday, August 18, 2017 12:44 PM To: secdir@ietf.org Cc: draft-ietf-homenet-dot.all@ietf.org; homenet@ietf.org; ietf@ietf.org Subject: [secdir] Secdir last call review of draft-ietf-homenet-dot-12 Reviewer: Daniel Migault Review result: Has Nits Thank you for writing the draft. Please find my comments. I hope they are h= elpful.=20 Yours, Daniel =20 Special Use Domain 'home.arpa.' draft-ietf-homenet-dot-12 Abstract This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.', and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 MGLT: I would personally start by saying the document defines a special-us= e domain name and then defines the behavior.=20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 =20 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 11, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Pfister & Lemon Expires February 11, 2018 [Page 1] Internet-Draft dot homenet August 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3 4. Domain Name Reservation Considerations . . . . . . . . . . . 3 5. Updates to Home Networking Control Protocol . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Delegation of 'home.arpa.' . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Users and devices within a home network (hereafter "homenet") require devices and services to be identified by names that are unique within the boundaries of the homenet [RFC7368]. The naming mechanism needs to function without configuration from the user. While it may be possible for a name to be delegated by an ISP, homenets must also function in the absence of such a delegation. A default name with a scope limited to each individual homenet needs to be used. This document corrects an error in [RFC7788], replacing '.home' with 'home.arpa.' as the default domain-name for homenets. '.home' had been selected as the most user-friendly option. However, there are existing uses of '.home' that may be in conflict with this use: evidence indicates that '.home' queries frequently leak out and reach the root name servers [ICANN1] [ICANN2]. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: I believe that more important than the leak is that the introductio= n of .home in the root zone has been identified as highly risky. Another r= eason for not adopting it are also some uncertainty about its introduction into the root zone. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 In addition, it's necessary, for compatibility with DNSSEC (Section 6), that an insecure delegation ([RFC4035] section 4.3) be present for the name. There is an existing process for allocating names under '.arpa' [RFC3172]. No such process is available for requesting a similar delegation in the root at the request of the IETF, which does not administer that zone. As a result, the use of '.home' is deprecated. This document registers the domain '.home.arpa.' as a special-use domain name [RFC6761] and specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names whose rightmost non-terminal labels are 'home.arpa.'. Queries for Pfister & Lemon Expires February 11, 2018 [Page 2] Internet-Draft dot homenet August 2017 names ending with '.home.arpa.' are of local significance within the scope of a homenet, meaning that identical queries will result in different results from one homenet to another. In other words, a name ending in 'home.arpa.' is not globally unique. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: I think the text mentioned in the beginning of the paragraph above sh= ould be in the abstract. That was the sense of my previous comment.=20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 Although this document makes specific reference to RFC7788, it is not intended that the use of 'home.arpa.' be restricted solely to networks where HNCP is deployed; it is rather the case that 'home.arpa.' is the correct domain for uses like the one described for '.home' in RFC7788: local name service in residential homenets. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. General Guidance The domain name '.home.arpa.' is to be used for naming within residential homenets. Names ending with '.home.arpa.' reference a locally-served zone, the contents of which are unique only to a particular homenet, and are not globally unique. Such names refer to nodes and/or services that are located within a homenet (e.g., a printer, or a toaster). DNS queries for names ending with '.home.arpa.' are resolved using local resolvers on the homenet. Such queries MUST NOT be recursively forwarded to servers outside the logical boundaries of the homenet. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: "local resolvers" seems to me mis-leading. Your resolver may be local= but still forward the query to the Global Internet. I do not see better wa= ys to say it other than inside the boundaries of the homenet. Maybe we could say: =20 =20 DNS queries for names ending with '.home.arpa.' are resolved using homenet specific resolution mechanisms.=20 Eventually an informational reference to the simple naming architecture may= be added so the reader can refer to the doc for further information. For f= ull disclosure Ted and I are co-authors. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 Some service discovery user interfaces that are expected to be used on homenets conceal information such as domain names from end users. However, it is still expected that in some cases, users will need to see, remember, and even type, names ending with 'home.arpa.'. It is therefore desirable that users identify the domain and understand that using it expresses the intention to connect to a service that is specific to the homenet to which they are connected. Enforcing the fulfillment of this intention is out of scope for this document. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: I have difficulties understanding the paragraph above. If the idea is= to say home.arpa has special meaning that should be considered by GUIs I w= ould propose the following ordering. It is therefore desirable that users identify the domain and understand that using it expresses the intention to connect to a service that is specific to the homenet to which they are connected.=20 Some service discovery user interfaces that are expected to be used on homenets conceal information such as domain names from end users. However, it is still expected that in some cases, users will need to see, remember, and even type, names ending with 'home.arpa.'. =20 Enforcing the fulfillment of this intention is out of scope for this document. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 4. Domain Name Reservation Considerations This section defines the behavior of systems involved in domain name resolution when resolving queries for names ending with '.home.arpa.' (as per [RFC6761]). Pfister & Lemon Expires February 11, 2018 [Page 3] Internet-Draft dot homenet August 2017 1. Users can use names ending with '.home.arpa.' just as they would use any other domain name. The 'home.arpa.' name is chosen to be readily recognized by users as signifying that the name is addressing a service on the homenet to which the user's device is connected. 2. Application software SHOULD NOT treat names ending in 'home.arpa.' differently than other names. In particular, there is no basis for trusting names that are subdomains of 'home.arpa.' (see Section 6). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: a domain name ending in home.arpa may be resolved differently that a = regular domain name. As a result a different treatment is applied. I think = that "treat" means that no special meaning - other that the domain name is = inside the homenet boundaries - should be associated to a home.arpa. If I a= m correct I would limit the consideration to the name rather then the appli= cation.=20 I would suggest the text below: =09 names ending in home.arpa SHOULD NOT be associated any other properties tha= n the affiliation to the homenet. In particular, there is no basis for trusting names that are subdomains of 'home.arpa.' (see Section 6). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =09 =20 3. Name resolution APIs and libraries MUST NOT recognize names that end in '.home.arpa.' as special and MUST NOT treat them differently. Name resolution APIs MUST send queries for such names to a recursive DNS server that is configured to be authoritative for the 'home.arpa.' zone appropriate to the homenet. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: I believe the text below does not concern the library but the resolve= r. It is different to say libraries MUST NOT have specific considerations f= or home.arpa than a resolution service that may use different libraries MUS= T NOT consider the home.arpa differently.=20 My understanding of the text below is that the resolver and the authoritati= ve server for the home.arpa MUST be co-located. The reasons I think this is= not exact is that resolution for home.arpa can also be provided by other m= echanisms than an authoritative server. Typically, resolution can be done b= y requesting Authoritative Servers, Advertising Proxies, Hybrid Proxies (no= w called Discovery Proxies).... The other reason is do not see the text below accurate is that you may have= a DNS Proxy that transparently to the end user split the resolution betwee= n homenet specific resolutions when home.arpa is encountered while other na= mes are sent to the ISP resolver. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 =20 One or more IP addresses for recursive DNS servers will usually be supplied to the client through router advertisements or DHCP. If a host is configured to use a resolver other than one that is authoritative for the appropriate 'home.arpa.' zone, the client may be unable to resolve, or may receive incorrect results for, names in sub domains of 'home.arpa.'. 4. Caching resolvers conforming to this specification MUST support DNSSEC queries. While validation is not required, it is strongly encouraged; a caching resolver that does not validate answers that can be validated may cache invalid data; this will prevent validating stub resolvers from successfully validating answers. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: I see the text above as a recommendation for caching resolvers in the= homenet, but the relation to the home.arpa is unclear to me.=20 Was the intention to say that names under the home.arpa zone SHOULD be secu= red with DNSSEC so caching resolvers MUST support DNSSEC validation. In add= ition, these caching resolvers MUST also be able=20 to be configured with a Trust Anchor for the home.arpa. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3). That is, queries for domains that are subdomains of 'home.arpa.' MUST NOT be forwarded, with one important exception: a query for a DS record when the DO bit ([RFC4035] section 3.2.1) set MUST return the correct answer for that question, including correct information in the authority section that proves that the record is nonexistent. So for example a query for the NS record for 'home.arpa.' MUST NOT result in that query being forwarded to an upstream cache nor to the authoritative DNS server for '.arpa.'. However, as necessary to provide accurate authority information, a query for the DS record MUST result in whatever queries are necessary being forwarded; typically, this will just be a query for the DS record, since the necessary authority information will be included in the authority section of the response if the DO bit is set. Pfister & Lemon Expires February 11, 2018 [Page 4] Internet-Draft dot homenet August 2017 In addition to the behavior specified above, recursive resolvers that can be used in a homenet MUST be configurable with a delegation to an authoritative server for that particular homenet's instance of the domain 'home.arpa.'. It is permissible to combine the recursive resolver function for general DNS lookups with an authoritative resolver for 'home.arpa.'; in this case, rather than forwarding queries for subdomains of 'home.arpa.' to an authoritative server, the caching resolver answers them authoritatively. The behavior with respect to forwarding queries specifically for 'home.arpa.' remains the same. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: The full consideration seems to me to be conformance to RFC6303. In particular the recommendations for DNSSEC in RFC 6303 seems to me accura= ted and are not specifically mentioned here. Maybe that should be clearly s= tated that all considerations of RFC6303 should be considered as home.arpa = is of local scope.=20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 5. No special processing of 'home.arpa.' is required for authoritative DNS server implementations. It is possible that an authoritative DNS server might attempt to check the authoritative servers for 'home.arpa.' for a delegation beneath that name before answering authoritatively for such a delegated name. In such a case, because the name always has only local significance there will be no such delegation in the 'home.arpa.' zone, and so the server would refuse to answer authoritatively for such a zone. A server that implements this sort of check MUST be configurable so that either it does not do this check for the 'home.arpa.' domain, or it ignores the results of the check. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: I understand this as being incorrect. The resolver can also be config= ured with a trust anchor. I would refer to the RFC6303: As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA namespaces, the zones listed above will need to be delegated as insecure delegations, or be within insecure zones. This will allow DNSSEC validation to succeed for queries in these spaces despite not being answered from the delegated servers. It is recommended that sites actively using these namespaces secure them using DNSSEC [RFC4035] by publishing and using DNSSEC trust anchors. This will protect the clients from accidental import of unsigned responses from the Internet. =20 =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 =20 6. DNS server operators MAY configure an authoritative server for 'home.arpa.' for use in homenets and other home networks. The operator for the DNS servers authoritative for 'home.arpa.' in the global DNS will configure any such servers as described in Section 7. =20 7. 'home.arpa.' is a subdomain of the 'arpa' top-level domain, which is operated by IANA under the authority of the Internet Architecture Board according to the rules established in [RFC3172]. There are no other registrars for .arpa. 5. Updates to Home Networking Control Protocol The final paragraph of Home Networking Control Protocol [RFC7788], section 8, is updated as follows: OLD: Names and unqualified zones are used in an HNCP network to provide naming and service discovery with local significance. A network- wide zone is appended to all single labels or unqualified zones in order to qualify them. ".home" is the default; however, an administrator MAY configure the announcement of a Domain-Name TLV Pfister & Lemon Expires February 11, 2018 [Page 5] Internet-Draft dot homenet August 2017 (Section 10.6) for the network to use a different one. In case multiple are announced, the domain of the node with the greatest node identifier takes precedence. NEW: Names and unqualified zones are used in an HNCP network to provide naming and service discovery with local significance. A network- wide zone is appended to all single labels or unqualified zones in order to qualify them. 'home.arpa.' is the default; however, an administrator MAY configure the announcement of a Domain-Name TLV (Section 10.6) for the network to use a different one. In case multiple are announced, the domain of the node with the greatest node identifier takes precedence. The 'home.arpa.' special-use name does not require a special resolution protocol. Names for which the rightmost two labels are 'home.arpa.' are resolved using the DNS protocol [RFC1035]. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: If home.arpa are no different than other resolutions and we start fro= m the root zone responses are likely to be NXDOMAIN. I think we should clar= ify that DNS is used as a transport protocol, but that resolution may be ha= ndled differently. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 =20 6. Security Considerations A DNS record that is returned as a response to a query for an FQDN in the domain '.home.arpa.' is expected to have local significance. It is expected to be returned by a server involved in name resolution for the homenet the device is connected in. However, such response MUST NOT be considered more trustworthy than would be a similar response for any other DNS query. Because 'home.arpa.' is not globally scoped and cannot be secured using DNSSEC based on the root domain's trust anchor, there is no way to tell, using a standard DNS query, in which homenet scope an answer belongs. Consequently, users may experience surprising results with such names when roaming to different homenets. To prevent this from happening, it may be useful for the resolver to identify different homenets on which it has resolved names, but this is out of scope for this document. It is not possible to install a trust anchor for this zone in the '.arpa' zone. The reason for this is that in order to do so, it would be necessary to have the key-signing key for the zone ([RFC4034] Section 5). Since the zone is not globally unique, no one key would work. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 MGLT: I think that DS is meant rather than trust anchor. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 An alternative would be to install a authenticated denial of existence ([RFC4033] Section 3.2). =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 MGLT: This is unclear where the denial of existence is set. Is that in the = home.arpa zone or the arpa zone.=20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 However, this assumes that validation is being done on a caching resolver that is aware of the special local meaning of 'home.arpa.'. If a host stub resolver attempts to validate a name in 'home.arpa.', an authenticated denial Pfister & Lemon Expires February 11, 2018 [Page 6] Internet-Draft dot homenet August 2017 of existence of 'home' as a subdomain of 'arpa.' would cause the validation to fail. Therefore, the only delegation that will allow names under 'home.arpa.' to be resolved is an insecure delegation, as in [RFC6303] section 7. Consequently, unless a trust anchor for the particular instance of the 'home.arpa.' zone being validated is manually configured on the validating resolver, DNSSEC signing of names within the 'home.arpa.' zone is not possible. Although in principle it might be useful to install a trust anchor for a particular instance of 'home.arpa.', it's reasonable to expect that a host with such a trust anchor might from time to time connect to more than one network with its own instance of 'home.arpa.'. Such a host would be unable to access services on any instance of 'home.arpa.' other than the one for which a trust anchor was configured. It is in principle possible to attach an identifier to an instance of 'home.arpa.' that could be used to identify which trust anchor to rely on for validating names in that particular instance. However, the security implications of this are complicated, and such a mechanism, as well as a discussion of those implications, is out of scope for this document. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 MGLT: There are also some privacy issues associated to leaking names outsid= e the homenet boundaries. For example daniel_smith.home.arpa reveal the ide= ntity of the member of the homenet, my_ipad.home.arpa reveals the devices y= ou own, the application.=20 home.arpa may also used in larger environment such as corporate / private. = going from one to the other may also leak such information.=20 The leak can be from the homenet to the outside world in which case one nee= ed to control the queries sent. But in intruder (or guest) may also access = the homenet and proceed to discovery of the names.=20 As a result even though homenet is believe to be a trusted environment, car= e should be considered while publishing under the home.arpa. as well as whose the information is accessible to. =20 They might be collision as well. myprinter.home.arpa may be found in variou= s environments, and upon discovery you may also - in this example - print c= onfidential information to that printer.=20 In some case you may not even be aware, for example, if your printing infor= mation failed home, and is re-activated once you are in another environment= . =20 As information may be sensitive it may be encrypted using IPsec DTLS as des= cribed by dprive for both authentication and confidentiality.=20 When the trust anchor is configured in the resolver, these must be able to = roll-over the key and should follows the requirements for DNSSEC validators= . if it is impossible for a resolver to see the difference between an attac= k and a re-key we are in trouble.=20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 =20 =20 7. Delegation of 'home.arpa.' In order to be fully functional, there must be a delegation of 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST NOT include a DS record, and MUST point to one or more black hole servers, for example 'blackhole-1.iana.org.' and 'blackhole- 2.iana.org.'. The reason that this delegation must not be signed is that not signing the delegation breaks the DNSSEC chain of trust, which prevents a validating stub resolver from rejecting names published under 'home.arpa.' on a homenet name server. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 MGLT: The zone home.arpa MUST NOT be seen as belonging to the homenet. As a= result, NS and DS records for home.arpa does not have meanings outside a s= pecific domain. A Public server outside the boundaries of the homenet MUST = consider this traffic as=20 irrelevant and sink. =20 Redirection to as112 without coordination with as112 operator may rather be= performed using DNAME. I believe more text should document the two alterna= tive. With the proposed configuration, the query will be directed to a serv= er that is not authoritative for the zone. The response is likely to be REF= USED, while in the other case it is likely to be NXDOMAIN. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 =20 =20 8. IANA Considerations IANA is requested to record the domain name 'home.arpa.' in the Special-Use Domain Names registry [SUDN]. IANA is requested, with the approval of IAB, to implement the delegation requested in Section 7. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 MGLT: OK if IANA may make the direct way work. In that case is there any n= eed to update a registry for zone served by as112?=20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Fri Aug 18 14:46:25 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D5B132027 for ; Fri, 18 Aug 2017 14:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 tSu9ZXXDKjii for ; Fri, 18 Aug 2017 14:46:22 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DFC9126B6E for ; Fri, 18 Aug 2017 14:46:21 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id v7ILkJnQ032186; Fri, 18 Aug 2017 23:46:20 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id EF735EB2D0; Fri, 18 Aug 2017 23:46:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ItZVGmyLrQLx; Fri, 18 Aug 2017 23:46:19 +0200 (CEST) Received: from trurl.irif.fr (user-46-112-136-198.play-internet.pl [46.112.136.198]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 016D4EB274; Fri, 18 Aug 2017 23:46:15 +0200 (CEST) Date: Fri, 18 Aug 2017 23:46:14 +0200 Message-ID: <87lgmg8s7t.wl-jch@irif.fr> From: Juliusz Chroboczek To: Ted Lemon Cc: HOMENET In-Reply-To: <65C445C6-F288-4131-8B32-838AA0FB9809@fugue.com> References: <87fuctxdrc.fsf@toke.dk> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <874lt8xv9j.fsf@toke.dk> <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> <871soby776.fsf@toke.dk> <769C4508-BB58-4BCB-A3CE-3657FB43A8AA@fugue.com> <87k223jjdg.wl-jch@irif.fr> <20170817201054.GN45648@Space.Net> <8760dl9psm.wl-jch@irif.fr> <65C445C6-F288-4131-8B32-838AA0FB9809@fugue.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 18 Aug 2017 23:46:20 +0200 (CEST) X-Miltered: at korolev with ID 5997602B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5997602B.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5997602B.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 21:46:24 -0000 >> If the fast connection's DNS server replies after a delay or not at all, >> and the slow connection's DNS server replies in a timely manner, using >> a smart resolver across all the available DNS servers will improve latenc > Yes, but if your fast connection is lossy, it's not fast. Lossy looks like > congestion, so TCP slows down. I never said the fast connection was lossy. The scenario I'm envisioning is one in which the DNS server behind the fast link is laggy. Ted, DNS latency is a significant part of what the web people call "time to first byte". DNS resolvers make serious efforts to minimise that latency by keeping RTT and loss statistics and picking the best resolver. I don't know if you agree, but I suspect that any protocol that causes web latency to increase is not going to get deployed easily. -- Juliusz From nobody Sun Aug 20 10:41:39 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9320F1321C0 for ; Sun, 20 Aug 2017 10:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham 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 NQpfRwIOeccf for ; Sun, 20 Aug 2017 10:41:36 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156FA13209C for ; Sun, 20 Aug 2017 10:41:36 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v7KHYquF036443; Sun, 20 Aug 2017 13:41:26 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2cegskqmbk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 20 Aug 2017 13:41:26 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7KHfPLp016747; Sun, 20 Aug 2017 13:41:25 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7KHfJBA016699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Aug 2017 13:41:21 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi134.aldc.att.com (RSA Interceptor); Sun, 20 Aug 2017 17:41:07 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.30]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0319.002; Sun, 20 Aug 2017 13:41:07 -0400 From: "STARK, BARBARA H" To: Andrew Sullivan , "homenet@ietf.org" Thread-Topic: [homenet] homenet "no host changes" assumption and DNS Thread-Index: AdMYFPIEV1k/IIYrQxOO94GV5djuUwAPfxiAAAKO9ZA= Date: Sun, 20 Aug 2017 17:41:06 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DC02FF7@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DC0163F@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170818145059.hgyoazgrejopz5nz@mx4.yitter.info> In-Reply-To: <20170818145059.hgyoazgrejopz5nz@mx4.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.224.173] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-20_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708200288 Archived-At: Subject: Re: [homenet] homenet "no host changes" assumption and DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 17:41:39 -0000 > > Currently, there is no host that expects to use .home.arpa (or any othe= r > domain) inside the premises. >=20 > I don't think the "or any other domain" claim is true. At the very least= , _lots_ > of hosts are already using local. in homenets -- indeed, that's how we go= t to > this pass. Yes. I should have been clearer. I meant this in the context of DNS. Though= mDNS uses the same protocol semantics and Record structure as DNS, I see m= DNS as a rather distinct architecture from that of DNS. Maybe I'm mistaken = in looking at it that way. I'm not aware of widespread use by hosts of loc= al. for DNS queries. Implementations for processing (when to send, how to r= espond, what to do with the info) of mDNS and DNS tend to be distinct. =20 > > There is no host that expects a general-purpose in-home domain name > system to work or be present. >=20 > That's because there is no host that "expects an in-home domain name > system" at all. I think your position is starting from a position with w= hich I > disagree pretty strongly. =20 My primary position is that homenet solutions must do no harm. They must no= t cause people to have a worse or more frustrating experience and must not= impose cost on anyone who does not benefit from them (cause other people's= experience to be worse by making one person's experience better). My secondary position is they should create an improved user experience. An= d the improvement should be desirable by average people, perceived by these= people to be worth the cost, and easy for these people to get. In the context of homenet naming architecture, my position is that a soluti= on must meet these "do no harm" and "create an improved experience" positio= ns. > In my view, what we did many years ago was hook > up individual machines to an ISP's network. When broadband home access > came along, we continued to pretend that the link in the CPE was just a n= ode > in an ISP's network, and pretended that the home network was not a first- > class network that was internetworked together with other networks to > make the Internet. We ended up with multiple classes of network, some of > which are only kinda part of the Internet. I don't understand this concept of first and second class networks. I do se= e a distinction between my home network and networks that participate as pa= rt of the "public" Internet (including access ISP networks). My home networ= k is mine. I don't care whether it uses the same architectural elements as = in the "public" Internet as long as it does what I want. I recently partici= pated in writing a paper with a number of other technology people from vari= ous companies, and one thing we determined was we could not decide on a def= inition of "the Internet". So I don't know what definition you use. I do kn= ow that by my definition, my home network is not part of "the Internet", an= d I don't ever want it to be part of "the Internet". I do not want it to be= assimilated. This doesn't make my home network a lower class network, IMO.= It makes it a distinct and different network. I agree we have ended up wit= h multiple networks. I disagree they are of different classes. They are, si= mply, different. I've spent many years focused on understanding and meeting the needs of con= sumers and their home networks. I believe my view of my home network is con= sistent with how most people think of their home network. If you ask an ave= rage person whether their home network is part of the Internet, I believe t= hey will say "no". =20 > The reason that homenet is being worked on in the IETF as opposed to, say= , > the Broadband Forum, is exactly that we are trying to provide > internetworking services for these surprisingly sophisticated, unmanaged > networks. So to say that there's no "general-purpose in-home domain name > system" misses the point: it's _the_ domain name system, and the homenet > is part of that global DNS just as surely as com. is, and participates in= the > global name space just as surely as onion. and local. do. I'm not quite sure what you mean by "global DNS" or what conclusions I shou= ld draw from this statement. AFAIK, local. is only used with mDNS (which, a= s I mentioned above, I consider to be distinct from DNS, in spite of using = the same protocol semantics and record structures). I do know, absolutely, = that I don't ever want my home network names exposed to the public Internet= or resolvable by everyone "out there". I also know that I don't care how s= imilar or dissimilar my home network naming architecture is to "global DNS"= , as long as it works and meets my needs. And I'm quite sure this sentiment= is very much shared by regular consumers -- the target homenet deployers.= =20 =20 > So, the reason we can't expect host changes for naming is because any pla= n > for internetworking that starts, "First, upgrade all the hosts," > is doomed. That hasn't worked since 1983. I have no expectation of updating *all* hosts. But I do think it may be rea= sonable to expect "if a host wants to participate in the brand new homenet = naming architecture, it must be updated". There's a difference between *all= * hosts and a conditional set of hosts. I'm aware of many home network cons= umer electronics devices (TVs, Blu-ray players, etc.) that were shipped wit= h no DNS or mDNS support at all. I'm quite sure no-one is expecting to supp= ort these devices in a homenet naming architecture. If you agree our soluti= on doesn't have to handle hosts with neither DNS nor mDNS, then we agree th= e set of hosts we need to consider is conditional. We are disagreeing on wh= at the condition is that defines the set. I predicate my conditional expect= ations on "must do no harm and should improve the user experience". BTW, I'= m pretty sure that any HTML browser from 1983 would provide an excruciating= ly bad user experience in today's Internet. I don't even think there are ma= ny browsers in use today that don't do HTML5. If the upgrade is easy, and p= eople care (because they don't like the un-upgraded experience or because t= hey like what the upgrade provides), then it will happen. If the feature is= something people care absolutely nothing about, no-one will be incented to= implement or apply the upgrade. If the feature is something people like an= d want, the incentive will exist on all sides. If we think no-one will care= , then we shouldn't be doing this. > > If we got rid of the "no changes to host" tenet (for hosts that can mak= e use > of the home naming architecture), that would give us much more freedom to > create an in-home DNS architecture without a dependency on homenet > routers implementing the DNS Proxy kludge. Or any other kludge. It would > let us create an architecture that would finally start to move us away fr= om > DNS Proxy and other methods that intercept DNS queries to make > supposedly "intelligent" decisions on behalf of stupid hosts. And we woul= d > not be further entrenching use of these DNS intercept functions. > > >=20 > I don't understand how you can claim the above: the plain fact of the mat= ter > is that we have multiple domain-name-using protocols in action > here: at the very least, mDNS, DNS, and LLMNR, and maybe Tor resolution > and some other stuff. If what you're saying instead is that hosts are > supposed to know which networking context they're living in, then perhaps > we need a radical rethinking of what we're working on. It _might_ be the > case that end to end is the wrong model given the kinds of things we turn > out to be attaching to the Internet (this was part of what got discussed = in the > IAB's technical plenary last November). But if that's what we're doing, = I think > this WG needs at the very least to go through a round of rechartering so = that > the rest of the IETF understands that we are proposing a really significa= nt > break with the nominal Internet architecture. I'm not convinced that the= WG > has the patience to do such an effort, BTW. But I think this is a pretty > fundamental change you're proposing, and I think it would not be wrong fo= r > the IETF to push back pretty hard against such a change should the WG com= e > out with documents that embed such an assumption. As chair: OK. I hear you. But I'll need to understand this better. =20 > > I would like to require the hosts that want to make use of the new > homenet naming architecture responsible for understanding the different > provisioning domains and simultaneously launching queries to the advertis= ed > (or internally configured) DNS servers for each provisioning domain. > > >=20 > DNS doesn't work that way, is the problem. It doesn't have a mode bit. > What you are proposing is homenet-DNS; it's a new protocol. > Maybe that's the right answer, but I'm far from convinced that this is th= e > place to create DNSbis. I'm not proposing any changes to the DNS (or mDNS) protocol or DNS record s= tructure. But I think what I am proposing I should put into a different ema= il so I can describe it in more detail. Barbara =20 > Best regards, >=20 > A > -- > Andrew Sullivan > ajs@anvilwalrusden.com From nobody Sun Aug 20 20:15:14 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA691252BA for ; Sun, 20 Aug 2017 20:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=LiXEaocH; dkim=pass (1024-bit key) header.d=yitter.info header.b=R7AW1/Pt 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 SsVk672iKfMj for ; Sun, 20 Aug 2017 20:15:11 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97DA61200F3 for ; Sun, 20 Aug 2017 20:15:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 26706C09A0 for ; Mon, 21 Aug 2017 03:15:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1503285310; bh=J8/RABYDXNoC7g9BA8Xkhhu6XLricMxIiUTMCAtUJY4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=LiXEaocHiHdVk0Ni80bEHnlaZRj7qQM/n6wrdVSD+FZlDoK9cdhYjzeiSEtzDh9XG c8mkfRqq5vauP3Iyfg+ODc35g+510xnu9cedoxSUJa2tBlpF17/hLNPXgbpqwzX6cq 00s31w2RmOZ72yxqx29shBfHnjoxGnoN9K5G0ypA= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQq-r6IYTJiz for ; Mon, 21 Aug 2017 03:15:08 +0000 (UTC) Date: Sun, 20 Aug 2017 23:15:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1503285308; bh=J8/RABYDXNoC7g9BA8Xkhhu6XLricMxIiUTMCAtUJY4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=R7AW1/Pt/Eyrx+6+VD5wUFyeRuLsZDAUv+YwZu7AUKlvQTFHBtLU308INhLj3k12Y yvgCdQzIVUDkoggxLA3TpAJZQmbmdz/znEdxo48gBGAEG1LZXB4ROB4SEo222ya2hN 0AUjDftMcTLCVFi3TgMcWIzCjIORjCzqxpU5kVtg= From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20170821031506.fkmcmpoma3sovrgv@mx4.yitter.info> References: <2D09D61DDFA73D4C884805CC7865E6114DC0163F@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170818145059.hgyoazgrejopz5nz@mx4.yitter.info> <2D09D61DDFA73D4C884805CC7865E6114DC02FF7@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DC02FF7@GAALPA1MSGUSRBF.ITServices.sbc.com> Archived-At: Subject: Re: [homenet] homenet "no host changes" assumption and DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 03:15:13 -0000 On Sun, Aug 20, 2017 at 05:41:06PM +0000, STARK, BARBARA H wrote: > Yes. I should have been clearer. I meant this in the context of > DNS. Though mDNS uses the same protocol semantics and Record > structure as DNS, I see mDNS as a rather distinct architecture from > that of DNS. Maybe I'm mistaken in looking at it that way. I'm not > aware of widespread use by hosts of local. for DNS > queries. Implementations for processing (when to send, how to > respond, what to do with the info) of mDNS and DNS tend to be > distinct. What you say there is both true and not true. The reason mDNS (and LLMNR, for that matter) use domain names and not some other naming scheme is because every application in the world knows what to do with a domain name: pass it down to the resolution library. Therefore, what domain-name-using protocols that depend on a special magic "protocol switch" label do is rely on the resolution libraries to catch the "special" name, and send that name down the alternative resolution path. This is what mDNS does with local. and it's what Tor does with onion. and so on. It therefore _can't_ be true that it uses a really distinct architecture, because it's stuck with labels and the whole rest of the decisions made for us in the early 1980s by the makers of DNS. But it is a distinct architecture in that, once you are sure that you have someone playing in the new rules, you can make different decisions. > > My primary position is that homenet solutions must do no harm. They must not cause people to have a worse or more frustrating experience and must not impose cost on anyone who does not benefit from them (cause other people's experience to be worse by making one person's experience better). I think you're going to be disappointed, then. Lookups for local. leak to the global DNS all the time, and I think we should expect the same for home.arpa. All we can do is warn people. > My secondary position is they should create an improved user experience. And the improvement should be desirable by average people, perceived by these people to be worth the cost, and easy for these people to get. Which people are you talking about? If the goal here is people who have the faintest idea that there _is_ a naming system involved, then I suggest we already have the answer: literally anyone who knows that is in a position today to run some sort of split-brain DNS and make everything work. What we were supposed to be working on, I thought, was a situation where nobody thought it was "worth the cost" because they had no idea that there was anything to trade. That's what mDNS, when working correctly, mostly does. I think that is what we're supposed to be aiming for, without the restriction to the local link. > I do see a distinction between my home network and networks that participate as part of the "public" Internet (including access ISP networks). Of course you do. You do networks for a living. Even some people who work in the office I used to go to, who were supposed to be involved in selling Internetty things, did not seem to understand the kind of local net/office net/Internet kinds of distinctions that you are making. I have never had the slightest luck in explaining these distinctions to my parents, even though my father was, before he retired, an actual rocket scientist; and even though I was in an earlier career able to explain to undergraduates why "If you don't eat your peas, you can't have dessert" did not mean that if you ate your peas you got dessert. Distinctions among networks are, I suspect, nowhere near as clear to others as to us. I believe that's precisely part of the reason the group got chartered: network operators at universities -- the people you'd most expect to understand network distinctions -- wanted various link-local stuff to work on the "campus" or "site local" scope. >we could not decide on a definition of "the Internet". So I don't know what definition you use. A network of other networks linked together by the common underlying Internet Protocol, ostensively definable by the relationship "can send a packet to". At least in the most general sense. This is of course automatically problematic because of v4 and v6, which necessarily means that we are working on two different internets today. I think that's probably correct. > I believe my view of my home network is consistent with how most people think of their home network. If you ask an average person whether their home network is part of the Internet, I believe they will say "no". > I believe that if you ask an average person that question, they will say, "What?" I don't think that people think in the terms you mean. They simply want their things to be accessible when they want them where they want them, ad they want others not to be able to do that, and this is why everything has moved into the "cloud" even though that is inefficient in many cases. > I'm not quite sure what you mean by "global DNS" The global DNS is the domain name system used by the Internet. >AFAIK, local. is only used with mDNS At least theoretically (though as I noted it leaks). But it's a domain name that is, because of an IANA registry, reserved from allocation in the global DNS. > I do know, absolutely, that I don't ever want my home network names exposed to the public Internet or resolvable by everyone "out there". > That's nice, but that is not in fact what the architecture document this WG produced suggested. There are definitely use cases we have that involve exposing things "in the homenet" to "the public Internet". The most obvious one is the file server in my house, which is useful to me if I happen to be on the road. Stuart has mentioned the printer in his house, because apparently he sometimes prints things at home when he is on the road. The idea that people at home might need access from outside the homenet to things _in_ the homenet doesn't seem silly to me, and so I don't think we get to rule it out of scope unless we just decide that we won't solve that problem. > I have no expectation of updating *all* hosts. But I do think it may be reasonable to expect "if a host wants to participate in the brand new homenet naming architecture, it must be updated". I guess I just don't know which hosts these are supposed to be. The idea, as I understood it, was that we were not going to require ordinary users, who are not managing these networks now, to make the kinds of decisions you seem to be assuming. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Aug 21 11:52:46 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505E31320C9 for ; Mon, 21 Aug 2017 11:52:45 -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=google.com 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 HVmobO46Z7Xy for ; Mon, 21 Aug 2017 11:52:43 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 9BF4F120720 for ; Mon, 21 Aug 2017 11:52:43 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id m133so22504843pga.5 for ; Mon, 21 Aug 2017 11:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+SpmwrsNpE7Eol8IZB0ufaX8X2LkI05iER82ixOjYJw=; b=HJlps1XXWfWCkf0FaGanbIBVMa+xvdEI/A/aXoll9ijTpvXjYgsvsK9b2gSR+JIVq7 vodcJGwpM8mnEJTq6d+MORBNfWcjM1wekWOWjTWVZ+mhsaPk2gsfbtuOCavtKZ1SFv5K qL/LKHoUmm6enXgS+d5qId313yI9i5E+Xwj36mh3eINx/gMnIe8mCSQ080G3OVVAg6FZ ITRf/D3MzLnAmDl5e4wOSF5d8MVY0CmQjdtNqyHb4DoT97wKHnaF4p2AyDtSlOLhdsJV bNaC8Cw48FYVIu5i2EizkJm/ZSZ/hanswNW3Fp5krML9rx6n4SasgeETFZjqv0bN8gSp YUDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+SpmwrsNpE7Eol8IZB0ufaX8X2LkI05iER82ixOjYJw=; b=ekiBadU/Rg/6A8qEQPVEmF+RHTctfHiGNGbdbhY39fjjRIuP35GlakVwOami/1rb5m RnXEDR/qyfUUe1MmtXY9A/xWmrdN229/MzFBV+SjG7z4xdQFNmsHSb8K0htcc15qWXrR 2SG+/VPfTTRuVuOzPqgCX8yw4oTq6WNW3PlIS32mHZ32bmYKQkdQGLApoLtFsHQjnMKJ DAloP6N/EkRpplrAwfWRCGDnwG7cb0BJwD5oZsaeM+dZv8xw2aJ9jYhNNxOG1jPDOC0k p0iXKe5EcpeuLcEOEc4xcf9g9LWKjOTCJ+3KYt97UT1sSVAXXXxzWyk4BJ5mK2gG7Aj9 npow== X-Gm-Message-State: AHYfb5j3de7+tQk5MMfO/If9Pzqq9E/nenXTUJicE0FfsJTKIpqJGxhT O6oKV8tn33o1AGjJRg0epw== X-Received: by 10.84.229.9 with SMTP id b9mr16064919plk.216.1503341562966; Mon, 21 Aug 2017 11:52:42 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:6022:7220:c250:720? ([2620:0:10e7:10:6022:7220:c250:720]) by smtp.gmail.com with ESMTPSA id t6sm25994857pgt.80.2017.08.21.11.52.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Aug 2017 11:52:42 -0700 (PDT) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_17450F2B-D950-4749-93CB-B55889383804" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 21 Aug 2017 11:52:57 -0700 In-Reply-To: <20170818145059.hgyoazgrejopz5nz@mx4.yitter.info> Cc: homenet@ietf.org To: Andrew Sullivan References: <2D09D61DDFA73D4C884805CC7865E6114DC0163F@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170818145059.hgyoazgrejopz5nz@mx4.yitter.info> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] homenet "no host changes" assumption and DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 18:52:45 -0000 --Apple-Mail=_17450F2B-D950-4749-93CB-B55889383804 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 18, 2017, at 07:50, Andrew Sullivan = wrote: >=20 > Maybe that's the right answer, but I'm far from convinced that this is = the place to create DNSbis. p1. I=E2=80=99m far from convinced that yet another incremental = refinement of DNS can be sufficient or even necessary. p2. I'm quite certain that HOMENET is the wrong place to attempt it. --james woodyatt > --Apple-Mail=_17450F2B-D950-4749-93CB-B55889383804 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 18, 2017, at 07:50, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:

Maybe that's the = right answer, but I'm far from convinced that this is the place to create = DNSbis.

p1. I=E2=80=99m far from convinced that = yet another incremental refinement of DNS can be sufficient or even = necessary.

p2. = I'm quite certain that HOMENET is the wrong place to attempt = it.

--james = woodyatt <jhw@google.com>


= --Apple-Mail=_17450F2B-D950-4749-93CB-B55889383804-- From nobody Mon Aug 21 16:20:57 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17AB132AD0 for ; Mon, 21 Aug 2017 16:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 kYwDq97B-_Q8 for ; Mon, 21 Aug 2017 16:20:53 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B47132AD1 for ; Mon, 21 Aug 2017 16:20:53 -0700 (PDT) Received: from dooku.sandelman.ca (modemcable017.184-58-74.mc.videotron.ca [74.58.184.17]) by relay.sandelman.ca (Postfix) with ESMTPS id 9F7F91F906 for ; Mon, 21 Aug 2017 23:20:51 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id C5A912906; Tue, 22 Aug 2017 01:20:29 +0200 (CEST) From: Michael Richardson To: "homenet\@ietf.org" In-reply-to: <2D09D61DDFA73D4C884805CC7865E6114DC02FF7@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DC0163F@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170818145059.hgyoazgrejopz5nz@mx4.yitter.info> <2D09D61DDFA73D4C884805CC7865E6114DC02FF7@GAALPA1MSGUSRBF.ITServices.sbc.com> Comments: In-reply-to "STARK, BARBARA H" message dated "Sun, 20 Aug 2017 17:41:06 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 21 Aug 2017 19:20:29 -0400 Message-ID: <19664.1503357629@dooku.sandelman.ca> Archived-At: Subject: Re: [homenet] homenet "no host changes" assumption and DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 23:20:56 -0000 --=-=-= Content-Type: text/plain STARK, BARBARA H wrote: > number of other technology people from various companies, and one thing > we determined was we could not decide on a definition of "the > Internet". So I don't know what definition you use. I do know that by > my definition, my home network is not part of "the Internet", and I My definition for capital-Internet: The set of networks which are directly reachable ("icmp ping") and are enumerated in the "public" BGP4 tables. So, in traditional v4 land, only your edge router was part of The Internet by this definition. IPv6, Teredo, and PCP/UPnP changed this to include more and more hosts that are behind the router. Of course, your router might have a policy preventing internal hosts being directly reachable. (RFC6408 suggests that policy I think) For instance, one might require some kind VPN to be established in order to reach, in which case it is not "directly" > don't ever want it to be part of "the Internet". I do not want it to be > assimilated. This doesn't make my home network a lower class network, > IMO. It makes it a distinct and different network. I agree we have > ended up with multiple networks. I disagree they are of different > classes. They are, simply, differen! t. I think that a lot of people in this group want to make sure that your network (whether or not you think of it as part of the "Internet"), remains your network, and does not become an extension of the ISPs network. > I've spent many years focused on understanding and meeting the needs of > consumers and their home networks. I believe my view of my home network > is consistent with how most people think of their home network. If you > ask an average person whether their home network is part of the > Internet, I believe they will say "no". I think that it depends a lot on how they use it, and what kind of education they have had. Most of my older relatives think in terms of computers, and Internet. The Internet connects their computers, they don't have a home network. That's a result of ISP "propaganda", in my opinion. >> So, the reason we can't expect host changes for naming is because any >> plan for internetworking that starts, "First, upgrade all the hosts," >> is doomed. That hasn't worked since 1983. > I have no expectation of updating *all* hosts. But I do think it may be > reasonable to expect "if a host wants to participate in the brand new > homenet naming architecture, it must be updated". There's a difference > between *all* hosts and a conditional set of hosts. I'm aware of many +1 -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZm2q9AAoJEJVM4Vb9/EKQ1cEH/2sGw0MzCMrL0upz2S1CboDN dcJqI7t73vQDkRTK/4KC+aFBG7EWIemCURTUqeetOGV9if5B6H3/hIPc5r75quYf RM6Yy7t9egB9GBdaz/ihtxCsJf4TjkvrPyK3bY/qafEx+IawG0GTQWsBiNo8Eioz 4Uyvm9tyGkVcQ6ygQOmHWJB96JHlzOTf8u3ZXo3yZPZLFoG0ye2JaD+ZQRv41/mM 4a9XA0QTYFG66jPCCpykR5LDVLDZ1IPrtsJ97DmSsH1d9LpgPs2M+zca/62FgAxH DisFC6u/IMJvdNMSSLICuMbUup5RKZEhaxvxTH6Z48bZnhq1+2Ql1Z0VQjVwjIc= =jycQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 24 04:20:27 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7A713293C; Thu, 24 Aug 2017 04:20:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dale Worley To: Cc: draft-ietf-homenet-dot.all@ietf.org, homenet@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150357360963.24287.5193275103043411365@ietfa.amsl.com> Date: Thu, 24 Aug 2017 04:20:09 -0700 Archived-At: Subject: [homenet] Genart last call review of draft-ietf-homenet-dot-12 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 11:20:10 -0000 Reviewer: Dale Worley Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-homenet-dot-12 Reviewer: Dale R. Worley Review Date: 2017-08-24 IETF LC End Date: 2017-08-25 IESG Telechat date: 2017-08-31 Summary: This draft is ready for publication as a Standards Track RFC. It has some nits that should be considered before publication. 4. Domain Name Reservation Considerations 3. Name resolution APIs MUST send queries for such names to a recursive DNS server that is configured to be authoritative for the 'home.arpa.' zone appropriate to the homenet. If I understand the terminology correctly, this rules out sending the query to a DNS server that recursively sends the query to a server that is authoritative for home.arpa. If that is intended and there are technical reasons for making this prescription, that's OK, but I want to check that that is intended, as this rule is stricter than the similar rule in the second paragraph of item 4, which is qualified "Unless configured otherwise". 4. Domain Name Reservation Considerations There are 5 paragraphs under item 4. It might be worth giving them separate numbers, or if they truly form a unified topic, giving them sub-numbers 4a, 4b, etc. 6. Security Considerations Therefore, the only delegation that will allow names under 'home.arpa.' to be resolved is an insecure delegation, as in [RFC6303] section 7. In context what this means is clear, but its literal meaning is sufficiently incorrect that I think it could be clarified, perhaps to Therefore, the only delegation that will allow names under 'home.arpa.' to be resolved by a validating resolver that is not aware of the local meaning is an insecure delegation, as in [RFC6303] section 7. [EOF] From nobody Sun Aug 27 15:31:43 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A05132192; Sun, 27 Aug 2017 15:31:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-homenet-dot@ietf.org, Ray Bellis , homenet-chairs@ietf.org, ray@bellis.me.uk, homenet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150387310145.9847.9781162791273875182.idtracker@ietfa.amsl.com> Date: Sun, 27 Aug 2017 15:31:41 -0700 Archived-At: Subject: [homenet] Spencer Dawkins' No Objection on draft-ietf-homenet-dot-12: (with COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 22:31:41 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-homenet-dot-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you folks for putting this together. I know it's important. From nobody Mon Aug 28 15:07:33 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BAC1321C8; Mon, 28 Aug 2017 15:07:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-homenet-dot@ietf.org, Ray Bellis , homenet-chairs@ietf.org, ray@bellis.me.uk, homenet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150395805175.13203.12325524217824839037.idtracker@ietfa.amsl.com> Date: Mon, 28 Aug 2017 15:07:31 -0700 Archived-At: Subject: [homenet] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 22:07:32 -0000 Adam Roach has entered the following ballot position for draft-ietf-homenet-dot-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 4 contains a list that it describes as defining "the behavior of [DNS] systems". Item number 7 seems to be something else: I don't know what code or configuration would result from this statement. Maybe move this item to section 3? I'm having a hard time reconciling the normative requirement in section 4: Name resolution APIs and libraries MUST NOT recognize names that end in '.home.arpa.' as special and MUST NOT treat them differently. With the explanation in section 6: it may be useful for the resolver to identify different homenets on which it has resolved names Doesn't this mitigation in the security section require name resolution libraries to recognize names that end in ".home.arpa." as special so that it can treat them differently? From nobody Mon Aug 28 15:29:48 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DE9132139; Mon, 28 Aug 2017 15:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 54cslXnTL-1y; Mon, 28 Aug 2017 15:29:44 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D24132113; Mon, 28 Aug 2017 15:29:41 -0700 (PDT) Received: from mail.nominum.com (sjc1-exch01.win.nominum.com [IPv6:2620:0:b60:fab4:1026:2045:f02a:5f75]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C6AB874003F; Mon, 28 Aug 2017 22:29:10 +0000 (UTC) Received: from cavall.ether.lede.home (24.60.163.103) by SJC1-EXCH01.WIN.NOMINUM.COM (64.89.235.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1034.26; Mon, 28 Aug 2017 15:29:06 -0700 From: Ted Lemon Message-ID: <6A42DD6D-CE4C-4172-BE83-C0A259A4368D@nominum.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_90859136-B7B9-47F8-B226-95F264D42F68" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 28 Aug 2017 18:29:08 -0400 In-Reply-To: <150395805175.13203.12325524217824839037.idtracker@ietfa.amsl.com> CC: The IESG , , Ray Bellis , , To: Adam Roach References: <150395805175.13203.12325524217824839037.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) X-Originating-IP: [24.60.163.103] X-ClientProxiedBy: SJC1-EXCH02.WIN.NOMINUM.COM (64.89.235.69) To SJC1-EXCH01.WIN.NOMINUM.COM (64.89.235.83) Archived-At: Subject: Re: [homenet] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 22:29:46 -0000 --Apple-Mail=_90859136-B7B9-47F8-B226-95F264D42F68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" El Aug 28, 2017, a les 6:07 PM, Adam Roach va = escriure: > Section 4 contains a list that it describes as defining "the behavior = of [DNS] > systems". Item number 7 seems to be something else: I don't know what = code or > configuration would result from this statement. Maybe move this item = to section > 3? This is the format that RFC 6761 requires us to follow, which is why = it's being done this way. I think the text makes sense if you read it = with the RFC 6761 list of criteria in section 5 in mind. So I don't = think it makes sense to move it, although I agree it scans a bit = strangely. :) > With the explanation in section 6: >=20 > it may be useful for the resolver to identify different > homenets on which it has resolved names >=20 > Doesn't this mitigation in the security section require name = resolution > libraries to recognize names that end in ".home.arpa." as special so = that it > can treat them differently? Section 6 is talking about future work. If we come up with a way to do = this, then it would update this document, changing the normative = requirement. --Apple-Mail=_90859136-B7B9-47F8-B226-95F264D42F68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" El Aug 28, 2017, a les 6:07 PM, Adam Roach <adam@nostrum.com> va = escriure:
Section 4 contains a = list that it describes as defining "the behavior of [DNS]
systems". Item number 7 = seems to be something else: I don't know what code or
configuration would = result from this statement. Maybe move this item to section
3?

This is the = format that RFC 6761 requires us to follow, which is why it's being done = this way.   I think the text makes sense if you read it with the = RFC 6761 list of criteria in section 5 in mind.   So I don't think = it makes sense to move it, although I agree it scans a bit strangely. = :)

With the explanation in section 6:

  it may be useful for the = resolver to identify different
  homenets = on which it has resolved names

Doesn't this mitigation in the security section = require name resolution
libraries to = recognize names that end in ".home.arpa." as special so that = it
can treat them = differently?

Section 6 is talking about future work.   If we come up = with a way to do this, then it would update this document, changing the = normative requirement.


= --Apple-Mail=_90859136-B7B9-47F8-B226-95F264D42F68-- From nobody Mon Aug 28 20:19:13 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7888D132661; Mon, 28 Aug 2017 20:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 jNXuUkXP8Wi7; Mon, 28 Aug 2017 20:19:04 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 74CDA1321AC; Mon, 28 Aug 2017 20:19:04 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7T3Iu1h048456 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 28 Aug 2017 22:18:59 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Ted Lemon Cc: draft-ietf-homenet-dot@ietf.org, homenet-chairs@ietf.org, homenet@ietf.org, The IESG , Ray Bellis References: <150395805175.13203.12325524217824839037.idtracker@ietfa.amsl.com> <6A42DD6D-CE4C-4172-BE83-C0A259A4368D@nominum.com> From: Adam Roach Message-ID: Date: Mon, 28 Aug 2017 22:18:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <6A42DD6D-CE4C-4172-BE83-C0A259A4368D@nominum.com> Content-Type: multipart/alternative; boundary="------------C02325CF1CE4AAAE5D397158" Content-Language: en-US Archived-At: Subject: Re: [homenet] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 03:19:07 -0000 This is a multi-part message in MIME format. --------------C02325CF1CE4AAAE5D397158 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/28/17 5:29 PM, Ted Lemon wrote: > El Aug 28, 2017, a les 6:07 PM, Adam Roach > va escriure: >> Section 4 contains a list that it describes as defining "the behavior >> of [DNS] >> systems". Item number 7 seems to be something else: I don't know what >> code or >> configuration would result from this statement. Maybe move this item >> to section >> 3? > > This is the format that RFC 6761 requires us to follow, which is why > it's being done this way. I think the text makes sense if you read > it with the RFC 6761 list of criteria in section 5 in mind. So I > don't think it makes sense to move it, although I agree it scans a bit > strangely. :) Oh! That makes a lot more sense -- I should have chased down that section in 6761. I think what's tripping me up is the introduction in the homenet-dot draft: "This section defines the behavior of systems involved in domain name resolution when resolving queries for names ending with '.home.arpa.' (as per [RFC6761])." -- it would be clearer if it said something more like "This section reserves the '.home.arpa.' subdomain according to the procedures outlined in [RFC6761] section 4." (I'll also note that 6761 appears to require this to be "a subsection of the 'IANA Considerations' section", so you might consider moving it accordingly -- this would have been somewhat less confusing if it were clearer that it's part of the registration process, which putting it in the 'IANA Considerations' section would have done.) > >> With the explanation in section 6: >> >> it may be useful for the resolver to identify different >> homenets on which it has resolved names >> >> Doesn't this mitigation in the security section require name resolution >> libraries to recognize names that end in ".home.arpa." as special so >> that it >> can treat them differently? > > Section 6 is talking about future work. If we come up with a way to > do this, then it would update this document, changing the normative > requirement. To me, this reads as something that could be done unilaterally by the local resolver according to their own reasonable notion of what the proper mitigations might be here. I would suggest rephrasing to make it clearer that this suggestion pertains to _future_ work; e.g., "To prevent this from happening, future documents may define behavior that allows resolvers to identify and distinguish among different homenets on which they have resolved names, and take appropriate measures to avoid such confusion." /a --------------C02325CF1CE4AAAE5D397158 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/28/17 5:29 PM, Ted Lemon wrote:
El Aug 28, 2017, a les 6:07 PM, Adam Roach <adam@nostrum.com> va escriure:
Section 4 contains a list that it describes as defining "the behavior of [DNS]
systems". Item number 7 seems to be something else: I don't know what code or
configuration would result from this statement. Maybe move this item to section
3?

This is the format that RFC 6761 requires us to follow, which is why it's being done this way.   I think the text makes sense if you read it with the RFC 6761 list of criteria in section 5 in mind.   So I don't think it makes sense to move it, although I agree it scans a bit strangely. :)

Oh! That makes a lot more sense -- I should have chased down that section in 6761. I think what's tripping me up is the introduction in the homenet-dot draft: "This section defines the behavior of systems involved in domain name resolution when resolving queries for names ending with '.home.arpa.' (as per [RFC6761])." -- it would be clearer if it said something more like "This section reserves the '.home.arpa.' subdomain according to the procedures outlined in [RFC6761] section 4."

(I'll also note that 6761 appears to require this to be "a subsection of the 'IANA Considerations' section", so you might consider moving it accordingly -- this would have been somewhat less confusing if it were clearer that it's part of the registration process, which putting it in the 'IANA Considerations' section would have done.)

With the explanation in section 6:

  it may be useful for the resolver to identify different
  homenets on which it has resolved names

Doesn't this mitigation in the security section require name resolution
libraries to recognize names that end in ".home.arpa." as special so that it
can treat them differently?

Section 6 is talking about future work.   If we come up with a way to do this, then it would update this document, changing the normative requirement.


To me, this reads as something that could be done unilaterally by the local resolver according to their own reasonable notion of what the proper mitigations might be here. I would suggest rephrasing to make it clearer that this suggestion pertains to _future_ work; e.g., "To prevent this from happening, future documents may define behavior that allows resolvers to identify and distinguish among different homenets on which they have resolved names, and take appropriate measures to avoid such confusion."


/a

--------------C02325CF1CE4AAAE5D397158-- From nobody Tue Aug 29 06:53:21 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49FC13293C; Tue, 29 Aug 2017 06:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 YAt6YatoYdib; Tue, 29 Aug 2017 06:53:10 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D81132A81; Tue, 29 Aug 2017 06:53:10 -0700 (PDT) Received: from mail.nominum.com (sjc1-exch01.win.nominum.com [IPv6:2620:0:b60:fab4:1026:2045:f02a:5f75]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 5762D740054; Tue, 29 Aug 2017 13:52:39 +0000 (UTC) Received: from cavall.w50.lede.home (24.60.163.103) by SJC1-EXCH01.WIN.NOMINUM.COM (64.89.235.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1034.26; Tue, 29 Aug 2017 06:52:35 -0700 From: Ted Lemon Message-ID: <04D01C5D-4CE8-4EB2-97CB-A5C29F6C2931@nominum.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_875B15D6-F7D8-4BE7-9E5C-82D4761F1668" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 29 Aug 2017 09:52:36 -0400 In-Reply-To: CC: , , HOMENET , The IESG , Ray Bellis To: Adam Roach References: <150395805175.13203.12325524217824839037.idtracker@ietfa.amsl.com> <6A42DD6D-CE4C-4172-BE83-C0A259A4368D@nominum.com> X-Mailer: Apple Mail (2.3273) X-Originating-IP: [24.60.163.103] X-ClientProxiedBy: SJC1-EXCH02.WIN.NOMINUM.COM (64.89.235.69) To SJC1-EXCH01.WIN.NOMINUM.COM (64.89.235.83) Archived-At: Subject: Re: [homenet] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 13:53:15 -0000 --Apple-Mail=_875B15D6-F7D8-4BE7-9E5C-82D4761F1668 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" OK, these both sound like worthwhile updates to the doc. I will add = them to my working copy and send proposed diffs later today (I'm in the = middle of processing the gen-art review). > El Aug 28, 2017, a les 11:18 PM, Adam Roach va = escriure: >=20 > On 8/28/17 5:29 PM, Ted Lemon wrote: >> El Aug 28, 2017, a les 6:07 PM, Adam Roach > va escriure: >>> Section 4 contains a list that it describes as defining "the = behavior of [DNS] >>> systems". Item number 7 seems to be something else: I don't know = what code or >>> configuration would result from this statement. Maybe move this item = to section >>> 3? >>=20 >> This is the format that RFC 6761 requires us to follow, which is why = it's being done this way. I think the text makes sense if you read it = with the RFC 6761 list of criteria in section 5 in mind. So I don't = think it makes sense to move it, although I agree it scans a bit = strangely. :) >=20 > Oh! That makes a lot more sense -- I should have chased down that = section in 6761. I think what's tripping me up is the introduction in = the homenet-dot draft: "This section defines the behavior of systems = involved in domain name resolution when resolving queries for names = ending with '.home.arpa.' (as per [RFC6761])." -- it would be clearer if = it said something more like "This section reserves the '.home.arpa.' = subdomain according to the procedures outlined in [RFC6761] section 4." >=20 > (I'll also note that 6761 appears to require this to be "a subsection = of the 'IANA Considerations' section", so you might consider moving it = accordingly -- this would have been somewhat less confusing if it were = clearer that it's part of the registration process, which putting it in = the 'IANA Considerations' section would have done.) >>=20 >>> With the explanation in section 6: >>>=20 >>> it may be useful for the resolver to identify different >>> homenets on which it has resolved names >>>=20 >>> Doesn't this mitigation in the security section require name = resolution >>> libraries to recognize names that end in ".home.arpa." as special so = that it >>> can treat them differently? >>=20 >> Section 6 is talking about future work. If we come up with a way to = do this, then it would update this document, changing the normative = requirement. >=20 > To me, this reads as something that could be done unilaterally by the = local resolver according to their own reasonable notion of what the = proper mitigations might be here. I would suggest rephrasing to make it = clearer that this suggestion pertains to _future_ work; e.g., "To = prevent this from happening, future documents may define behavior that = allows resolvers to identify and distinguish among different homenets on = which they have resolved names, and take appropriate measures to avoid = such confusion." >=20 >=20 >=20 > /a >=20 --Apple-Mail=_875B15D6-F7D8-4BE7-9E5C-82D4761F1668 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" OK, these both sound like worthwhile updates to the doc. =   I will add them to my working copy and send proposed diffs later = today (I'm in the middle of processing the gen-art review).

El Aug 28, 2017, a les 11:18 PM, Adam Roach <adam@nostrum.com> va = escriure:

On 8/28/17 5:29 PM, Ted Lemon wrote:
El Aug 28, 2017, a les = 6:07 PM, Adam Roach <adam@nostrum.com> va escriure:
Section 4 contains a list that it = describes as defining "the behavior of [DNS]
systems". Item number 7 seems to = be something else: I don't know what code or
configuration would result from = this statement. Maybe move this item to section
3?

This is the format that RFC 6761 = requires us to follow, which is why it's being done this way.   I = think the text makes sense if you read it with the RFC 6761 list of = criteria in section 5 in mind.   So I don't think it makes sense to = move it, although I agree it scans a bit strangely. = :)

Oh! That makes a = lot more sense -- I should have chased down that section in 6761. I = think what's tripping me up is the introduction in the homenet-dot = draft: "This section defines the behavior of systems involved in domain = name resolution when resolving queries for names ending with = '.home.arpa.' (as per [RFC6761])." -- it would be clearer if it said = something more like "This section reserves the '.home.arpa.' subdomain = according to the procedures outlined in [RFC6761] section 4."

(I'll also note that 6761 appears to require = this to be "a subsection of the 'IANA Considerations' section", so you = might consider moving it accordingly -- this would have been somewhat = less confusing if it were clearer that it's part of the registration = process, which putting it in the 'IANA Considerations' section would = have done.)

With the explanation in section 6:

  it may be useful for the resolver to = identify different
  homenets on which = it has resolved names

Doesn't this mitigation in the security section require = name resolution
libraries to recognize names = that end in ".home.arpa." as special so that it
can treat them = differently?

Section 6 is talking about future work.   If we come up = with a way to do this, then it would update this document, changing the = normative requirement.


To me, this reads as = something that could be done unilaterally by the local resolver = according to their own reasonable notion of what the proper mitigations = might be here. I would suggest rephrasing to make it clearer that this = suggestion pertains to _future_ work; e.g., "To prevent this from = happening, future documents may define behavior that allows resolvers to = identify and distinguish among different homenets on which they have = resolved names, and take appropriate measures to avoid such = confusion."


/a


= --Apple-Mail=_875B15D6-F7D8-4BE7-9E5C-82D4761F1668-- From nobody Tue Aug 29 12:47:03 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 837111321AA; Tue, 29 Aug 2017 12:47:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-homenet-dot@ietf.org, Ray Bellis , homenet-chairs@ietf.org, ray@bellis.me.uk, homenet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150403602253.32177.6734059019373307193.idtracker@ietfa.amsl.com> Date: Tue, 29 Aug 2017 12:47:02 -0700 Archived-At: Subject: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-dot-12: (with DISCUSS and COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 19:47:02 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-homenet-dot-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft! The SecDir review raised a few important points I'd like to discuss that should be easy to resolve. The first is adding in privacy considerations in his comments for the Security considerations section posted here for convenience (but a response to his full thread might be best): There are also some privacy issues associated to leaking names outside the homenet boundaries. For example daniel_smith.home.arpa reveal the identity of the member of the homenet, my_ipad.home.arpa reveals the devices you own, the application. home.arpa may also used in larger environment such as corporate / private. going from one to the other may also leak such information. The leak can be from the homenet to the outside world in which case one neeed to control the queries sent. But in intruder (or guest) may also access the homenet and proceed to discovery of the names. As a result even though homenet is believe to be a trusted environment, care should be considered while publishing under the home.arpa. as well as whose the information is accessible to. They might be collision as well. myprinter.home.arpa may be found in various environments, and upon discovery you may also - in this example - print confidential information to that printer. In some case you may not even be aware, for example, if your printing information failed home, and is re-activated once you are in another environment. As information may be sensitive it may be encrypted using IPsec DTLS as described by dprive for both authentication and confidentiality. When the trust anchor is configured in the resolver, these must be able to roll-over the key and should follows the requirements for DNSSEC validators. if it is impossible for a resolver to see the difference between an attack and a re-key we are in trouble. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The other comments raised by the SecDir review should get a response, especially those on section 4 as there are some wording suggestions to better clarify what is intended in the document. https://mailarchive.ietf.org/arch/msg/secdir/E7fjRdo94abFW5nqjVBbLspvkww From nobody Tue Aug 29 13:19:37 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E990132D91 for ; Tue, 29 Aug 2017 13:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 D5L1RZg_kbZt for ; Tue, 29 Aug 2017 13:19:29 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 90E1B132D95 for ; Tue, 29 Aug 2017 13:19:26 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id w42so19579961qtg.5 for ; Tue, 29 Aug 2017 13:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qWIduuDuYGt5EdgFuLdz0Y3AGSVNNdJaUdHvcx2EJBs=; b=m+NE/8Ordoy9LVYV8n39U+f+c1toS279Tp3H3DtyU+QdasLLFRUA/BvKbpjxJ4fnD0 5FG1OCsylMvrwe2OPjDSViUfV9hcOodYVZpOCM0ep3DX4o8cwEehL+qNZdSPfnnjNL6L e+8eDiFWOvOiZ78CYt9NIxqdWu94EfaaCAuvKO+ij2m3vwf0+sXih6q2l3ZVaIyUTEdc sksGbLX/xdtf3y02qBjsrjuPQ5/qyoxHl4clpmQf2s5PT5a4XPp8pwQpdpFqSNZdQdkT 6fhGQbN1QIxPW6fHvjrtl5q6z+X4gmUhj9DyCcr6FSIVjfYHNatWY12jGyasXL8Vx4Cj 8QAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qWIduuDuYGt5EdgFuLdz0Y3AGSVNNdJaUdHvcx2EJBs=; b=c3y5jxfKSUCR4BE/ys5lsSVgIuaHKoDEJ+TYB6CE5DKolrHNYN75dXWDSiKno5urEu Nss16VtUSi0HXv3UroXokbBxV9kdzcYDbQLU9DIt2tFNyzKh07nabLLmtQWOhd0eODN3 hZW4acSn+x4/J59fpJIaSvqnvn4YGNSgqI7W656UDqfKVu/DlSfjQP1HOxYp7Ukewohx u246CNN3aE11sE5X896Tm2k7JdAz3joRkYVmX/A1hEjeafvBBq2ZQzyHz0wi9/u7UDuI RUF1l699B9BMr/iUWsHFeo7oz7dh3pxrV095VcYxylY2z7cD+OsmsquIvfZ8cjt2wZV0 BCYw== X-Gm-Message-State: AHYfb5gkZGNAU1NaS1+YCDAqYmImJAIZTMVBqduslAX8fM1Z24qaKZW1 B3DX2y195/t0JaED X-Received: by 10.200.8.234 with SMTP id y39mr7347877qth.275.1504037965557; Tue, 29 Aug 2017 13:19:25 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id a12sm2455533qta.90.2017.08.29.13.19.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Aug 2017 13:19:24 -0700 (PDT) From: Ted Lemon Message-Id: <91A4FB6F-3782-4807-B828-5F65DF841831@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B3433182-592E-462C-BA46-D79FA1DAB0D1" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 29 Aug 2017 16:19:23 -0400 In-Reply-To: <150403602253.32177.6734059019373307193.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-homenet-dot@ietf.org, homenet-chairs@ietf.org, homenet@ietf.org, ray@bellis.me.uk To: Kathleen Moriarty References: <150403602253.32177.6734059019373307193.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-dot-12: (with DISCUSS and COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 20:19:32 -0000 --Apple-Mail=_B3433182-592E-462C-BA46-D79FA1DAB0D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think these secdir comments are actually out of scope for this work = (I'll comment in detail inline). In order to mitigate the problems = described, we would have to do work that is already being done in other = working group documents (e.g. draft-tldm-simple-homenet-naming-01). If = you are interested in where this work is going, it would be better to = wait a week or two and read the working group draft, which has been = adopted and is due for a -00 submission. Suggestions to use DTLS don't make sense, because we aren't allowed to = require changes on the hosts. Hosts currently do MDNS and spew private = information all over the place; that problem is actually already being = addressed by vendors. The printer security problem is significant and = is being discussed in the working group. Again, DTLS doesn't really = address this, because there is no PKI solution. It might make sense to have a presentation on this next month when we = meet in Boston=E2=80=94I'd be curious to get feedback from you and some = of the other security folks on what we've been talking about. I'm = preparing a presentation for NIST in two weeks that will cover this = topic as well, so I may be able to use some of that in Boston, if it = makes sense to give me time on the agenda (I've presented quite a few = times, so it might be too soon for me to present again). Anyway, the point is that I don't think I can answer this discuss by = making substantive changes to the document. > On Aug 29, 2017, at 3:47 PM, Kathleen Moriarty = wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > There are also some privacy issues associated to leaking names outside = the > homenet boundaries. For example daniel_smith.home.arpa reveal the = identity of > the member of the homenet, my_ipad.home.arpa reveals the devices you = own, the > application. >=20 > home.arpa may also used in larger environment such as corporate / = private. > going from one to the other may also leak such information. >=20 > The leak can be from the homenet to the outside world in which case = one neeed > to control the queries sent. But in intruder (or guest) may also = access the > homenet and proceed to discovery of the names. As a result even though = homenet > is believe to be a trusted environment, care should be considered = while > publishing under the home.arpa. as well as whose the information is = accessible > to. The only sense in which the homenet is considered to be a trusted = environment is that we have no choice but to treat it as if it were in = some sense isolated from the global internet. It is absolutely true = that any device that gains access to the homenet can enumerate all = published names. The cure, which is well known, is to not publish = names that expose private information. The dnssd working group has = developed a solution to this problem: = https://tools.ietf.org/html/draft-ietf-dnssd-privacy-02 = This doesn't work for printers. Use of home.arpa in environments other than home networks is not being = recommended in this document, and hence the mention of that as an issue = seems like a non sequitur. > They might be collision as well. myprinter.home.arpa may be found in = various > environments, and upon discovery you may also - in this example - = print > confidential information to that printer. In some case you may not = even be > aware, for example, if your printing information failed home, and is > re-activated once you are in another environment. I think what is meant here is that if you are at home and have a printer = named "myprinter.home.arpa." and then later on you are at someone else's = home, or at a malicious coffee shop, there might be a printer there also = named "myprinter.home.arpa.", that there is no way to detect this = problem. This is true, but by no means a new problem. This problem = is already explicitly called out in the security considerations section, = so I don't think additional text is needed. If you think that example = text is needed, I can add that. This is a problem we very much want to solve. If you look at = https://datatracker.ietf.org/doc/draft-sctl-service-registration/?include_= text=3D1 = you can see that we are working on this. A device that does = service registration generates a public/private key pair and uses the = public key to defend its ownership of the name; what is important about = this is that you can tell the difference between two printers with the = same name by looking up their public key, and you can in principle use = that key to authenticate the printer when you connect with it via TLS. = So if you roam to a home that has a printer with the same name as your = printer, an API that understands the registration protocol will not = mistakenly connect to that printer as if it were the same printer. Unfortunately this is not current practice, and it will probably be = years before it _becomes_ current practice, but we are doing our best to = create the infrastructure that will allow this to happen. Making = non-actionable statements about it in this document doesn't seem like a = good idea when we are doing real work to actually solve the problem. = The purpose of this document is simply to allocate the name and document = its use under RFC 6761, not to exhaustively define the architecture in = which that name will be used. > As information may be sensitive it may be encrypted using IPsec DTLS = as > described by dprive for both authentication and confidentiality. This is an example of what I mean by a "non-actionable statement." = There is no way to establish authentication using a PKI trust anchor = under home.arpa, so this statement is not in any way actionable at = present; recommending that readers do this is simply telling them to go = on a wild goose chase. > When the trust anchor is configured in the resolver, these must be = able to > roll-over the key and should follows the requirements for DNSSEC = validators. if > it is impossible for a resolver to see the difference between an = attack and a > re-key we are in trouble. This statement is similarly not actionable (in this document). There = is at present no trust anchor. There can't be. We are talking about = an extension to validating resolvers that know about home.arpa that will = make it possible to tell which homenet you are on in much the same way = that the registration protocol I referenced earlier. Making sure that = we correctly handle the re-keying problem is definitely a good idea, and = one that I hadn't thought of yet, but it's not something we could = possibly address in _this_ document. --Apple-Mail=_B3433182-592E-462C-BA46-D79FA1DAB0D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I think these secdir comments are actually out of scope for = this work (I'll comment in detail inline).   In order to mitigate = the problems described, we would have to do work that is already being = done in other working group documents (e.g. = draft-tldm-simple-homenet-naming-01).   If you are interested in = where this work is going, it would be better to wait a week or two and = read the working group draft, which has been adopted and is due for a = -00 submission.

Suggestions to use DTLS don't make sense, because we aren't = allowed to require changes on the hosts.   Hosts currently do MDNS = and spew private information all over the place; that problem is = actually already being addressed by vendors.   The printer security = problem is significant and is being discussed in the working group. =   Again, DTLS doesn't really address this, because there is no PKI = solution.

It = might make sense to have a presentation on this next month when we meet = in Boston=E2=80=94I'd be curious to get feedback from you and some of = the other security folks on what we've been talking about.   I'm = preparing a presentation for NIST in two weeks that will cover this = topic as well, so I may be able to use some of that in Boston, if it = makes sense to give me time on the agenda (I've presented quite a few = times, so it might be too soon for me to present again).

Anyway, the point is = that I don't think I can answer this discuss by making substantive = changes to the document.

On = Aug 29, 2017, at 3:47 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:
---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

There are also some privacy issues = associated to leaking names outside the
homenet = boundaries. For example daniel_smith.home.arpa reveal the identity of
the member of the homenet, my_ipad.home.arpa reveals the = devices you own, the
application.

home.arpa may also used in larger environment such as = corporate / private.
going from one to the other may also = leak such information.

The leak can be from = the homenet to the outside world in which case one neeed
to = control the queries sent. But in intruder (or guest) may also access = the
homenet and proceed to discovery of the names. As a = result even though homenet
is believe to be a trusted = environment, care should be considered while
publishing = under the home.arpa. as well as whose the information is accessible
to.

The only sense in which the homenet is considered to be = a trusted environment is that we have no choice but to treat it as if it = were in some sense isolated from the global internet.   It is = absolutely true that any device that gains access to the homenet can = enumerate all published names.   The cure, which is well known, is = to not publish names that expose private information.   The dnssd = working group has developed a solution to this problem: https://tools.ietf.org/html/draft-ietf-dnssd-privacy-02

This doesn't work for = printers.

Use of home.arpa in = environments other than home networks is not being recommended in this = document, and hence the mention of that as an issue seems like a non = sequitur.

They might be collision as = well. myprinter.home.arpa may be found in various
environments, and upon discovery you may also - in this = example - print
confidential information to that printer. = In some case you may not even be
aware, for example, if = your printing information failed home, and is
re-activated = once you are in another environment.

I think = what is meant here is that if you are at home and have a printer named = "myprinter.home.arpa." and then later on you are at someone else's home, = or at a malicious coffee shop, there might be a printer there also named = "myprinter.home.arpa.", that there is no way to detect this problem. =   This is true, but by no means a new problem.   This problem = is already explicitly called out in the security considerations section, = so I don't think additional text is needed.   If you think that = example text is needed, I can add that.

This is a problem we very much want to solve. =   If you look at  https://datatracker.ietf.org/doc/draft-sctl-service-registratio= n/?include_text=3D1 you can see that we are working on this. =   A device that does service registration generates a = public/private key pair and uses the public key to defend its ownership = of the name; what is important about this is that you can tell the = difference between two printers with the same name by looking up their = public key, and you can in principle use that key to authenticate the = printer when you connect with it via TLS.   So if you roam to a = home that has a printer with the same name as your printer, an API that = understands the registration protocol will not mistakenly connect to = that printer as if it were the same printer.

Unfortunately this is not current practice, and it = will probably be years before it _becomes_ current practice, but we are = doing our best to create the infrastructure that will allow this to = happen.   Making non-actionable statements about it in this = document doesn't seem like a good idea when we are doing real work to = actually solve the problem.   The purpose of this document is = simply to allocate the name and document its use under RFC 6761, not to = exhaustively define the architecture in which that name will be = used.

As information may be = sensitive it may be encrypted using IPsec DTLS as
described = by dprive for both authentication and confidentiality.

This is an = example of what I mean by a "non-actionable statement."   There is = no way to establish authentication using a PKI trust anchor under = home.arpa, so this statement is not in any way actionable at present; = recommending that readers do this is simply telling them to go on a wild = goose chase.

When the trust anchor is = configured in the resolver, these must be able to
roll-over = the key and should follows the requirements for DNSSEC validators. if
it is impossible for a resolver to see the difference between = an attack and a
re-key we are in trouble.

This = statement is similarly not actionable (in this document).   There = is at present no trust anchor.   There can't be.   We are = talking about an extension to validating resolvers that know about = home.arpa that will make it possible to tell which homenet you are on in = much the same way that the registration protocol I referenced earlier. =   Making sure that we correctly handle the re-keying problem is = definitely a good idea, and one that I hadn't thought of yet, but it's = not something we could possibly address in _this_ = document.

= --Apple-Mail=_B3433182-592E-462C-BA46-D79FA1DAB0D1-- From nobody Tue Aug 29 13:30:06 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97248132D99 for ; Tue, 29 Aug 2017 13:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 UlrUe463KK01 for ; Tue, 29 Aug 2017 13:30:03 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 DE91D132D95 for ; Tue, 29 Aug 2017 13:30:02 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id o63so20192629qkb.3 for ; Tue, 29 Aug 2017 13:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=48gMt7wKuzY/OBN68sFQ2Mwq1XHbfjkbjZ+Z2AS6P3w=; b=ME/vFVV93T6ocqsxCmqxEq2hBalvM80yrxZml/Ouej2i6wanKEhn29S0Nj5SGryU2Z mhYHVB4gQIE2RwR+W0JWC9NM+84y/iYr5v1AbeRr8jHF8KqvbKhCvKk61DOq71355cFi WeJ+JGHNVzoqwK8f19dQb+UXvqNwL1wiJKBFd2MQfk3Uyy7o28130CsHLorh8kZzlKVH dgfbzxQC8e7fWp1wLp+UyNpyemlYzyV94X/LTEap88s7GBg3xY3LjWU2ENHCov/X/36R NB1OflIJtEXKp0i1xa1Dob1klEKBrgxUULYnTWi7qoPV29FU/QVaewMQftJDJFSkD8hG cvTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=48gMt7wKuzY/OBN68sFQ2Mwq1XHbfjkbjZ+Z2AS6P3w=; b=uTPCkcjrJUIpfrVUPkNS/VMAOECwmIceVD8Lg5JdHpEuAqZsOafJdhb8rUnKWuWn61 vWbO3tZ48wqICR80fEbKd0foFkoimVgQl3wlNuppjZS4Hh5f0S4TsAaWQISTKil6Twsr 2ty6Ff322OX4urqZAFiEXwueaPBUPZGQoLMY8J1aPFciyyOaQmqUa2meTh8tf2Ixtal/ m5TXeT9p352za6qh/KPyoL4p/tPZe+TghnXXqZQB99urVCFUE2rOGqHnLlarD5QMDDLz sX/MmUrzcS9uce3g0BEWTMagBTPGVe6IzOdqfoos5EBAVhoLDTdMxYKBynA8COmc0O7f iKLA== X-Gm-Message-State: AHYfb5gaR/ObyR/HsoUr6DPx9zbhpnNQ2UogNRzharfQ/cGtFlueE4YY vInw0zx4Xs5xGgiK X-Received: by 10.55.201.206 with SMTP id m75mr8119186qkl.12.1504038602079; Tue, 29 Aug 2017 13:30:02 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id d187sm2475365qkg.91.2017.08.29.13.30.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Aug 2017 13:30:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <150403602253.32177.6734059019373307193.idtracker@ietfa.amsl.com> Date: Tue, 29 Aug 2017 16:30:00 -0400 Cc: The IESG , draft-ietf-homenet-dot@ietf.org, homenet-chairs@ietf.org, HOMENET , ray@bellis.me.uk Content-Transfer-Encoding: quoted-printable Message-Id: <72593E73-342E-4062-B9F7-069635D6509A@fugue.com> References: <150403602253.32177.6734059019373307193.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-dot-12: (with DISCUSS and COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 20:30:04 -0000 Oh, Daniel's comment on point 3 is correct, and I've already updated the = text based on the gen-art review. :) From nobody Tue Aug 29 16:25:58 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12733132A9B for ; Tue, 29 Aug 2017 16:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 8s9ovqydEkkI for ; Tue, 29 Aug 2017 16:25:51 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 7E2E2132A94 for ; Tue, 29 Aug 2017 16:25:47 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id k126so21764515qkb.4 for ; Tue, 29 Aug 2017 16:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GB2cTi96LQ3rKjrtascfxo3KrpxcqHIkgf/o0kBN898=; b=CoDp4DNb62+z4mU2W1QDdmo+CNjAtLbemfR41CUh+nZ+Zb8cx7JGc2YBfStFuGDdfx iIrAhBvq319R6vIkMeUa0UGVNv4FuktAHLQ3PrY2+1fBuhHqSyltKw44SWhPoPiDAhmj nomKuJZINCCPCZhQaOro6OO/mrv9m4Qx2rI5clZk8/1ouD3qn++OrettBkPmcObK6Vi9 GgUmFsQ8b0Qtwtb5DOg0d67oI25CNdTOLwOpKC7r18SdyEvGzVhHhGDLrVmhd4D2dMpr W3I0Hane4eyMHVy34DVfgew4Nn0ddQaw2I8mnqAPr4vl6rtaphTbqTESzLLc+q4BXp4r TyeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GB2cTi96LQ3rKjrtascfxo3KrpxcqHIkgf/o0kBN898=; b=qtUCIl210RTCeyORszXBzvuyqPq1J5ZDGX5NrHIQlMp3DKtDjElaQdedVod4oVFIs1 dqe6jwtol/T3+oZKWmmvAfXtvD/11HzIJWoovqz6O7Pj0A7J6DFwtUu9DbYw3YuHVb5T cPmi3OWvN5GiyoVXyeGfY5dwiMvXPFdR274LRQJtCNS7DFP/u3cQZhYqhWB8yM3mhelm /egdoLZRnwSkBei3DLHwlABKRU8cAyNNw8lvK5dKqkdzfme7NZ7nAjVOLaijbCtGGiba EMWjtKk72+Px2aNU0F5U6TV0/9S7rklSOPclIYMdGmoYm6xhPER2pl4H4TQGJf6Sol0r t87Q== X-Gm-Message-State: AHYfb5gXJRdQqiDrFnFYzZEU1/c0i9kC1f8U9jiOyxWRne2IPpkEG8Zj bWPcU/dqdBGntlQR X-Received: by 10.55.73.212 with SMTP id w203mr8479724qka.115.1504049146485; Tue, 29 Aug 2017 16:25:46 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id v11sm2733678qti.87.2017.08.29.16.25.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Aug 2017 16:25:45 -0700 (PDT) From: Ted Lemon Message-Id: <4B072264-2824-4433-A24D-DF5D2FD5A085@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9B9FF9B6-762E-4B34-8BD4-C45CE1938AFD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 29 Aug 2017 19:25:44 -0400 In-Reply-To: <150357360963.24287.5193275103043411365@ietfa.amsl.com> Cc: General area reviewing team , draft-ietf-homenet-dot.all@ietf.org, HOMENET To: Dale Worley References: <150357360963.24287.5193275103043411365@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 23:25:52 -0000 --Apple-Mail=_9B9FF9B6-762E-4B34-8BD4-C45CE1938AFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 El Aug 24, 2017, a les 7:20 AM, Dale Worley va = escriure: > 4. Domain Name Reservation Considerations >=20 > 3. Name resolution APIs MUST send queries for such > names to a recursive DNS server that is configured to be > authoritative for the 'home.arpa.' zone appropriate to the > homenet. >=20 > If I understand the terminology correctly, this rules out sending the > query to a DNS server that recursively sends the query to a server > that is authoritative for home.arpa. If that is intended and there > are technical reasons for making this prescription, that's OK, but I > want to check that that is intended, as this rule is stricter than the > similar rule in the second paragraph of item 4, which is qualified > "Unless configured otherwise". Wow. The text here is just flat wrong: recursive name servers aren't = authoritative. You can of course combine them, but this text doesn't = agree with some other text later in the document. What the text is = supposed to be saying is that the stub resolver has to use the recursive = resolver that was provided by the network; if it uses a manually = configured resolver, it may get the wrong answer. I will have to = rework this text=E2=80=94thanks so much for calling this to my = attention, even though what you noticed isn't exactly what's wrong! :) As for the discrepancy itself, the reason for this is that recursive = resolvers are supposed to stop home.arpa queries leaking to the root, = whereas stub resolvers can (must!) fob that responsibility off on the = recursive resolver. If they are configured to send these queries to, = e.g., 8.8.8.8, we just have to hope that google doesn't forward them to = the root (as would be consistent with the text in item 4). > There are 5 paragraphs under item 4. It might be worth giving them > separate numbers, or if they truly form a unified topic, giving them > sub-numbers 4a, 4b, etc. I've updated the document to separate this out into three lettered = subheads. We can't change the numbering, because that's required by = RFC 6761, but I agree that it's clearer if the three separate topics are = split out. > In context what this means is clear, but its literal meaning is > sufficiently incorrect that I think it could be clarified, perhaps to >=20 > Therefore, the only delegation that will allow names under > 'home.arpa.' to be resolved by a validating resolver that is not > aware of the local meaning is an insecure delegation, as in > [RFC6303] section 7. I like the new text, and have copied it into the document. Thanks! --Apple-Mail=_9B9FF9B6-762E-4B34-8BD4-C45CE1938AFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
El Aug 24, 2017, a les 7:20 AM, Dale Worley <worley@ariadne.com> = va escriure:
4.  Domain Name Reservation = Considerations

  3. =  Name resolution APIs MUST send queries for such
      names to a = recursive DNS server that is configured to be
      authoritative = for the 'home.arpa.' zone appropriate to the
      homenet.

If I understand the terminology = correctly, this rules out sending the
query to a DNS = server that recursively sends the query to a server
that is authoritative for home.arpa.  If = that is intended and there
are technical = reasons for making this prescription, that's OK, but I
want to check that that is intended, as this = rule is stricter than the
similar rule in the = second paragraph of item 4, which is qualified
"Unless configured = otherwise".

Wow.   The text here is just flat wrong: recursive name = servers aren't authoritative.   You can of course combine them, but = this text doesn't agree with some other text later in the document. =   What the text is supposed to be saying is that the stub resolver = has to use the recursive resolver that was provided by the network; if = it uses a manually configured resolver, it may get the wrong answer. =   I will have to rework this text=E2=80=94thanks so much for = calling this to my attention, even though what you noticed isn't exactly = what's wrong!   :)

As for the discrepancy itself, the reason for this is that = recursive resolvers are supposed to stop home.arpa queries leaking to = the root, whereas stub resolvers can (must!) fob that responsibility off = on the recursive resolver.   If they are configured to send these = queries to, e.g., 8.8.8.8, we just have to hope that google doesn't = forward them to the root (as would be consistent with the text in item = 4).

There are 5 paragraphs under item 4.  It might be worth = giving them
separate= numbers, or if they truly form a unified topic, giving them
sub-numbers 4a, 4b, = etc.

I've = updated the document to separate this out into three lettered subheads. =   We can't change the numbering, because that's required by RFC = 6761, but I agree that it's clearer if the three separate topics are = split out.

In context what this = means is clear, but its literal meaning is
sufficiently incorrect that I think it could be clarified, = perhaps to

  Therefore, = the only delegation that will allow names under
  'home.arpa.' = to be resolved by a validating resolver that is not
  aware of = the local meaning is an insecure delegation, as in
  [RFC6303] = section 7.

I = like the new text, and have copied it into the document.   = Thanks!

= --Apple-Mail=_9B9FF9B6-762E-4B34-8BD4-C45CE1938AFD-- From nobody Tue Aug 29 19:03:27 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624B91321A5 for ; Tue, 29 Aug 2017 19:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 0LX6zJWuPT8o for ; Tue, 29 Aug 2017 19:03:15 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 C9F961320C9 for ; Tue, 29 Aug 2017 19:03:14 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id k126so22763218qkb.4 for ; Tue, 29 Aug 2017 19:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=02jvH5tqYuRSttIYJWbrvNUqe9Gbyh80Ze62j3UWZNY=; b=g8dtw8HO2kLFmGA2S36Xowzy6r29avse6b0VrxnUjPnZg3V92WbRNQrh+GWElBmhRZ 5OYze/jnu5va+r4yvV5Kv8FI9ubV0xLnr6SqFEr3lTLsoaWmFMl3c/D+82maMehY0xbC QyY6SDFdBwtTAWC7jtkWy08bj4VOAYBrjBpDEScAJDiHGPSkQ6QtXpoD+xTUIOF46ZRl IkfgWWl2Pcslv0/8tftNPd9uG6f1lCd40Bwci/BYM/0/42+r1yuae4fK21wIfZh8oVJx Kca2QDCI6/QF9rosm1clCaoiC4MSCd2ZR1PJufc/8vXI/J6avaCKvf+Xw3QKzayVZjmZ gstQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=02jvH5tqYuRSttIYJWbrvNUqe9Gbyh80Ze62j3UWZNY=; b=lFL5od6hJ+887HBce3MfqnK8vpHoQO74kmUPBSo89gQotPSGdd+1G/+X+9/kCbNC01 DB5R7GFZqjwUp2ce3N+GPjqfmcdel00/poRS2hpagtH1+uR8f9HNVGQmCc/gQZdeuTC8 Pzuv3MakvHzUrZ5lETOS8777uqiDDov8cuTb0iLxqejHmrs4y1DObIH+1UVJjiUqZfcM HFah181TIY1P4XDaWE3LMrknFj/bP9Qsxjte9HB7rsvbZEJW/iItCv8q5KsFyGxEizZ0 OXS2B87zcNXdfNy2MTw4LWfoGrBZOrLAPN7qZsD+jwLo/kfzi3CbrVrejLoEAVCuSJFb EhoA== X-Gm-Message-State: AHYfb5gddCEAZJd/YdtfHaHrn7fLPn+fNmD6A7VcAWxW/jalqxcwi8fu SyMcgsAuS9LPckyV X-Received: by 10.55.103.151 with SMTP id b145mr8231501qkc.78.1504058593596; Tue, 29 Aug 2017 19:03:13 -0700 (PDT) Received: from cavall.w50.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id q88sm2973371qtd.80.2017.08.29.19.03.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Aug 2017 19:03:12 -0700 (PDT) From: Ted Lemon Message-Id: <5C378A81-AB6B-4F2F-8D97-CDED30D788AE@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_35742441-512C-4B16-A871-25F8F5ED881A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 29 Aug 2017 22:03:10 -0400 In-Reply-To: <150307463977.14156.2178189421671973906@ietfa.amsl.com> Cc: secdir@ietf.org, HOMENET To: Daniel Migault References: <150307463977.14156.2178189421671973906@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Secdir last call review of draft-ietf-homenet-dot-12 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 02:03:21 -0000 --Apple-Mail=_35742441-512C-4B16-A871-25F8F5ED881A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the review, Daniel. I've included changes based on your = observations inline. On Aug 18, 2017, at 12:43 PM, Daniel Migault = wrote: > Abstract >=20 > This document specifies the behavior that is expected from the = Domain > Name System with regard to DNS queries for names ending with > '.home.arpa.', and designates this domain as a special-use domain > name. 'home.arpa.' is designated for non-unique use in residential > home networks. Home Networking Control Protocol (HNCP) is updated = to > use the 'home.arpa.' domain instead of '.home'. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I would personally start by saying the document defines a > special-use domain name and then defines the behavior.=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 No change > Users and devices within a home network (hereafter "homenet") = require > devices and services to be identified by names that are unique = within > the boundaries of the homenet [RFC7368]. The naming mechanism needs > to function without configuration from the user. While it may be > possible for a name to be delegated by an ISP, homenets must also > function in the absence of such a delegation. A default name with a > scope limited to each individual homenet needs to be used. >=20 > This document corrects an error in [RFC7788], replacing '.home' with > 'home.arpa.' as the default domain-name for homenets. '.home' had > been selected as the most user-friendly option. However, there are > existing uses of '.home' that may be in conflict with this use: > evidence indicates that '.home' queries frequently leak out and = reach > the root name servers [ICANN1] [ICANN2]. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I believe that more important than the leak is that the=20 > introduction of .home in the root zone has been identified as > highly risky. Another reason for not adopting it are also some > uncertainty about its introduction into the root zone. =20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 This is irrelevant, because the IETF hasn't asked ICANN for a = delegation. We deliberately left out this discussion because it's a = moot point now and potentially a political hot potato. I personally = agree with you that this is important, but I think despite its = importance, we got out of that what we needed, and it's better not to = mention it here. > This document registers the domain '.home.arpa.' as a special-use > domain name [RFC6761] and specifies the behavior that is expected > from the Domain Name System with regard to DNS queries for names > whose rightmost non-terminal labels are 'home.arpa.'. Queries for > names ending with '.home.arpa.' are of local significance within the > scope of a homenet, meaning that identical queries will result in > different results from one homenet to another. In other words, a > name ending in 'home.arpa.' is not globally unique. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I think the text mentioned in the beginning of the paragraph=20 > above should be in the abstract. That was the sense of my previous > comment.=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 The point of an abstract is to give a quick summary of what the document = does, not to recapitulate what it does. This is a bit of a hobby horse = for me, so I'm not going to lengthen the abstract to include more = details unless my AD tells me I have to. I do appreciate your point, = but I do not think that the additional text that you are referring to is = necessary in the abstract. > DNS queries for names ending with '.home.arpa.' are resolved using > local resolvers on the homenet. Such queries MUST NOT be = recursively > forwarded to servers outside the logical boundaries of the homenet. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: "local resolvers" seems to me mis-leading. Your resolver may > be local but still forward the query to the Global Internet. I do > not see better ways to say it other than inside the boundaries of > the homenet. Maybe we could say: =20 >=20 > DNS queries for names ending with '.home.arpa.' are resolved using > homenet specific resolution mechanisms.=20 >=20 > Eventually an informational reference to the simple naming=20 > architecture may be added so the reader can refer to the doc > for further information. For full disclosure Ted and I are > co-authors. =20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 The document makes this really clear in a later section. The text you = are proposing to add makes it _less_ clear. I do not think this change = is a good idea. > Some service discovery user interfaces that are expected to be used > on homenets conceal information such as domain names from end users. > However, it is still expected that in some cases, users will need to > see, remember, and even type, names ending with 'home.arpa.'. It is > therefore desirable that users identify the domain and understand > that using it expresses the intention to connect to a service that = is > specific to the homenet to which they are connected. Enforcing the > fulfillment of this intention is out of scope for this document. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I have difficulties understanding the paragraph above. If=20 > the idea is to say home.arpa has special meaning that should be > considered by GUIs I would propose the following ordering. >=20 > It is > therefore desirable that users identify the domain and understand > that using it expresses the intention to connect to a service that = is > specific to the homenet to which they are connected.=20 > Some service discovery user interfaces that are expected to be used > on homenets conceal information such as domain names from end users. > However, it is still expected that in some cases, users will need to > see, remember, and even type, names ending with 'home.arpa.'. =20 > Enforcing the > fulfillment of this intention is out of scope for this document. =20= > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 The text here is actually present as a justification for why we wanted = '.home' but didn't get eliminated. I don't think there'd be consensus = to completely eliminated it, but I've clarified it by taking out the = text that I think confused you: Some service discovery user interfaces that are expected to be used on homenets conceal information such as domain names from end users. However, it is still expected that in some cases, users will need to see, remember, and even type, names ending with 'home.arpa.'. The working group hopes that this name will in some way indicate to as many readers as possible that such domain names are referring to devices in the home, but we recognize that it is an imperfect solution. > 2. Application software SHOULD NOT treat names ending in > 'home.arpa.' differently than other names. In particular, there > is no basis for trusting names that are subdomains of > 'home.arpa.' (see Section 6). >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: a domain name ending in home.arpa may be resolved differently > that a regular domain name. As a result a different treatment is=20 > applied. I think that "treat" means that no special meaning - other > that the domain name is inside the homenet boundaries - should be=20 > associated to a home.arpa. If I am correct I would limit the=20 > consideration to the name rather then the application.=20 > I would suggest the text below: > =09 > names ending in home.arpa SHOULD NOT be associated any other=20 > properties than the affiliation to the homenet. In particular, there > is no basis for trusting names that are subdomains of > 'home.arpa.' (see Section 6). > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 This section is present in accordance with RFC 6761 and is required to = talk about applications, so this change would not make sense in that = context. I agree that talking about applications in this case is = fraught, but with that in mind I think the text is as good as we can do. = I think that your proposed change makes it less clear, because you = haven't said what you mean by "properties." The only property that I = think is really important here is trust, so clarifying that "home.arpa" = does not imply extra trust is important. Think of this in the context = of https://w3c.github.io/webappsec-secure-contexts/ = . This text is to = specifically exclude that sort of assumption, not that I think the W3C = would make such a mistake! > 3. Name resolution APIs and libraries MUST NOT recognize names that > end in '.home.arpa.' as special and MUST NOT treat them > differently. Name resolution APIs MUST send queries for such > names to a recursive DNS server that is configured to be > authoritative for the 'home.arpa.' zone appropriate to the > homenet. =20 >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I believe the text below does not concern the library but=20 > the resolver. It is different to say libraries MUST NOT have=20 > specific considerations for home.arpa than a resolution service=20 > that may use different libraries MUST NOT consider the home.arpa > differently.=20 > My understanding of the text below is that the resolver and the > authoritative server for the home.arpa MUST be co-located. The > reasons I think this is not exact is that resolution for=20 > home.arpa can also be provided by other mechanisms than an=20 > authoritative server. Typically, resolution can be done by=20 > requesting Authoritative Servers, Advertising Proxies, Hybrid=20 > Proxies (now called Discovery Proxies).... > The other reason is do not see the text below accurate is that > you may have a DNS Proxy that transparently to the end user split > the resolution between homenet specific resolutions when home.arpa > is encountered while other names are sent to the ISP resolver. > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 No, this text is required by RFC 6761 to address the behavior of local = stub resolvers and resolution libraries. Changing it to talk about = recursive resolvers and proxies would make it incorrect according to = those requirements. That said, I have substantially revised that text = and it may now make more sense to you: 3. Name resolution APIs and libraries MUST NOT recognize names that end in '.home.arpa.' as special and MUST NOT treat them as = having special significance, except that it may be necessary that such APIs not bypass the locally configured recursive resolvers. One or more IP addresses for recursive DNS servers will usually be supplied to the client through router advertisements or DHCP. For an administrative domain that uses names in 'home.arpa.', such as a homenet, the recursive resolvers provided by that domain will be able to answer queries for subdomains of home.arpa; other resolvers will not, or will provide answers = that are not correct within that administrative domain. A host that is configured to use a resolver other than one that has been provided by the local network may be unable to resolve, or may receive incorrect results for, names in sub domains of 'home.arpa.'. In order to avoid this, it is permissible that hosts use the locally-provided resolvers for resolving 'home.arpa.' even when they are configured to use other resolvers. I also added this related text to the security considerations section: In Section 4, item 3, an exception is made to the behavior of stub resolvers allowing them to query local resolvers for subdomains of 'home.arpa.' even when they have been manually configured to use other resolvers. This behavior obviously has security and privacy implications, and may not be desirable depending on the context. It may be better to simply ignore this exception and, when one or more recursive resolvers are configured manually, simply fail to provide correct answers for subdomains of 'home.arpa.'. At this time we do not have operational experience that would guide us in making this decision; implementors are encouraged to consider the context in which their software will be deployed when deciding how to resolve this question. > 4. Caching resolvers conforming to this specification MUST support > DNSSEC queries. While validation is not required, it is = strongly > encouraged; a caching resolver that does not validate answers > that can be validated may cache invalid data; this will prevent > validating stub resolvers from successfully validating answers. > =20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I see the text above as a recommendation for caching resolvers > in the homenet, but the relation to the home.arpa is unclear to me.=20 > Was the intention to say that names under the home.arpa zone SHOULD=20 > be secured with DNSSEC so caching resolvers MUST support DNSSEC=20 > validation. In addition, these caching resolvers MUST also be able=20 > to be configured with a Trust Anchor for the home.arpa. =20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 The text was actually incorrect. I've substantially rewritten that = item: A. Recursive resolvers at sites using 'home.arpa.' MUST transparently support DNSSEC queries: queries for DNSSEC records and queries with the DO bit set ([RFC4035] section 3.2.1) . While validation is not required, it is strongly encouraged; a caching recursive resolver that does not validate answers that can be validated may cache invalid data; this will prevent validating stub resolvers from successfully validating answers. The other requirements you list are impossible, because we don't have a = mechanism for generating such trust anchors, nor for disambiguating = between different instances of such trust anchors that a host may need = in order to use resources on different homenets. Furthermore, = requiring host changes is out of charter. I agree with you in = principle that this needs to happen, and as you are aware we are working = on addressing this problem, both in homenet and in dnssd. But we can't = address it here. > It is permissible to combine the recursive resolver function for > general DNS lookups with an authoritative resolver for > 'home.arpa.'; in this case, rather than forwarding queries for > subdomains of 'home.arpa.' to an authoritative server, the > caching resolver answers them authoritatively. The behavior = with > respect to forwarding queries specifically for 'home.arpa.' > remains the same. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: The full consideration seems to me to be conformance to RFC6303. > In particular the recommendations for DNSSEC in RFC 6303 seems to me > accurated and are not specifically mentioned here. Maybe that should=20= > be clearly stated that all considerations of RFC6303 should be=20 > considered as home.arpa is of local scope.=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 I think you are missing the point of this text. The behavior for = RFC6303 was already specified a few paragraphs earlier, and is required = for all resolvers, not just homenet resolvers. This text is simply = allowing a homenet router implementation to either implement a caching = server and a separate authoritative server, or merge the two into a = hybrid authoritative/recursive server. You can do this today with an = out-of-the-box BIND 9 installation. =20 > 5. No special processing of 'home.arpa.' is required for > authoritative DNS server implementations. It is possible that = an > authoritative DNS server might attempt to check the = authoritative > servers for 'home.arpa.' for a delegation beneath that name > before answering authoritatively for such a delegated name. In > such a case, because the name always has only local significance > there will be no such delegation in the 'home.arpa.' zone, and = so > the server would refuse to answer authoritatively for such a > zone. A server that implements this sort of check MUST be > configurable so that either it does not do this check for the > 'home.arpa.' domain, or it ignores the results of the check. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I understand this as being incorrect. The resolver can also be = configured=20 > with a trust anchor. I would refer to the RFC6303: >=20 > As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA > namespaces, the zones listed above will need to be delegated as > insecure delegations, or be within insecure zones. This will allow > DNSSEC validation to succeed for queries in these spaces despite not > being answered from the delegated servers. >=20 > It is recommended that sites actively using these namespaces secure > them using DNSSEC [RFC4035] by publishing and using DNSSEC trust > anchors. This will protect the clients from accidental import of > unsigned responses from the Internet. =20 > =20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 This text is about authoritative servers, not resolvers. = Locally-served zones are covered under item 4. > The 'home.arpa.' special-use name does not require a special > resolution protocol. Names for which the rightmost two labels = are > 'home.arpa.' are resolved using the DNS protocol [RFC1035]. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: If home.arpa are no different than other resolutions and we=20 > start from the root zone responses are likely to be NXDOMAIN. I=20 > think we should clarify that DNS is used as a transport protocol,=20 > but that resolution may be handled differently. > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 No, this is incorrect. The DNS protocol is being used to do = resolution. No host changes are required. > It is not possible to install a trust anchor for this zone in the > '.arpa' zone. The reason for this is that in order to do so, it > would be necessary to have the key-signing key for the zone > ([RFC4034] Section 5). Since the zone is not globally unique, no = one > key would work. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I think that DS is meant rather than trust anchor. > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 A DS record is a trust anchor. I've updated it as follows: It is not possible to install a trust anchor (a DS RR) for this zone = in the '.arpa' zone. The reason for this is that in order to do so, it would be necessary to have the key-signing key for the zone ([RFC4034] Section 5). Since the zone is not globally unique, no one key would work. > An alternative would be to install a authenticated denial of > existence ([RFC4033] Section 3.2). =20 >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: This is unclear where the denial of existence is set. Is=20 > that in the home.arpa zone or the arpa zone.=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 There is only one place where it can be set. I have updated the text = as follows: An alternative would be to provide a authenticated denial of existence ([RFC4033] Section 3.2). This would be done simply by not having a delegation from the 'arpa.' zone.=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: There are also some privacy issues associated to leaking names > outside the homenet boundaries. For example daniel_smith.home.arpa > reveal the identity of the member of the homenet, my_ipad.home.arpa > reveals the devices you own, the application.=20 This is a known issue, and it's up to the vendors of devices to decide = how much they are willing to reveal. There is work going on in dnssd = to provide a secure way of doing this. It's out of scope for this = document. The document doesn't create a new problem here. > home.arpa may also used in larger environment such as corporate /=20 > private. going from one to the other may also leak such information.=20= Use of home.arpa is for home networks. If a corporate environment uses = it, it's no different than them using some other ad-hoc name. > The leak can be from the homenet to the outside world in which case > one neeed to control the queries sent. But in intruder (or guest)=20 > may also access the homenet and proceed to discovery of the names.=20 > As a result even though homenet is believe to be a trusted = environment,=20 > care should be considered while publishing under the home.arpa. as > well as whose the information is accessible to. =20 Yes, an attacker can suborn your home router, and if they do, your = privacy will be more easily violated. And, as with existing = technology, devices may or may not reveal private information about you = to the network. This is not a problem that we are creating with this = document, and it is not a problem we can solve with this document. = Work to solve this is ongoing; I would prefer to publish this document = now rather than holding it up waiting for that other work. > They might be collision as well. myprinter.home.arpa may be found > in various environments, and upon discovery you may also -=20 > in this example - print confidential information to that printer.=20 > In some case you may not even be aware, for example, if your=20 > printing information failed home, and is re-activated once you=20 > are in another environment. =20 This issue is already documented in the security considerations section. > As information may be sensitive it may be encrypted using IPsec=20 > DTLS as described by dprive for both authentication and = confidentiality.=20 How would we arrange to distribute the trust anchor here? PKI won't = work. I don't see how we would establish trust with IKE either. = Again, work is going on in dnssd to provide an infrastructure that would = allow this, but right now this is empty advice: this is a document about = home networks, operated by end users, so if there isn't a way to do this = automatically, there is no point in saying that end users should do it: = they are never going to read this document. > When the trust anchor is configured in the resolver, these must be > able to roll-over the key and should follows the requirements for = DNSSEC > validators. if it is impossible for a resolver to see the difference=20= > between an attack and a re-key we are in trouble.=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 This is an excellent point, and we should consider it when we write the = document where we explain how to manage these trust anchors. This is = work that I fully intend to do in homenet, but right now this point = doesn't make sense to mention here because this document doesn't provide = an automatic way of setting up trust anchors. > In order to be fully functional, there must be a delegation of > 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST > NOT include a DS record, and MUST point to one or more black hole > servers, for example 'blackhole-1.iana.org.' and 'blackhole- > 2.iana.org.'. The reason that this delegation must not be signed is > that not signing the delegation breaks the DNSSEC chain of trust, > which prevents a validating stub resolver from rejecting names > published under 'home.arpa.' on a homenet name server. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: The zone home.arpa MUST NOT be seen as belonging to the=20 > homenet. As a result, NS and DS records for home.arpa does not=20 > have meanings outside a specific domain. A Public server outside=20 > the boundaries of the homenet MUST consider this traffic as=20 > irrelevant and sink. =20 >=20 > Redirection to as112 without coordination with as112 operator=20 > may rather be performed using DNAME. I believe more text should=20 > document the two alternative. With the proposed configuration,=20 > the query will be directed to a server that is not authoritative for=20= > the zone. The response is likely to be REFUSED, while in the other=20 > case it is likely to be NXDOMAIN. > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 This document was reviewed extensively in DNSOP. The text specifies = what is supposed to happen. It's not a discussion: it's a directive to = IANA and an explanation for the IAB, which operates .arpa. I cannot = make this change without breaking the document. > 8. IANA Considerations >=20 > IANA is requested to record the domain name 'home.arpa.' in the > Special-Use Domain Names registry [SUDN]. IANA is requested, with > the approval of IAB, to implement the delegation requested in > Section 7. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: OK if IANA may make the direct way work. In that case is=20 > there any need to update a registry for zone served by as112?=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 Yes. As far as I know the text gives IANA the information they need to = do; I do not know how they operate their black hole servers, so I am = trusting that these instructions are sufficient. They have been = reviewed by people who understand this problem better than I do, like = Andrew Sullivan, Paul Hoffman and Mark Andrews. I was specifically = advised not to overspecify this. I would rather take their word on = this than yours, if you will forgive my saying so. :) Thanks for the detailed review. I didn't take all of your suggestions = as written, but the document has definitely been improved as a result of = this review. --Apple-Mail=_35742441-512C-4B16-A871-25F8F5ED881A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Thanks for the review, Daniel.   I've = included changes based on your observations inline.

On Aug 18, 2017, at 12:43 PM, Daniel = Migault <daniel.migault@ericsson.com> wrote:
Abstract

=   This document specifies the behavior that is expected from = the Domain
  Name System with regard to DNS = queries for names ending with
  '.home.arpa.', = and designates this domain as a special-use domain
=   name. 'home.arpa.' is designated for non-unique use in = residential
  home networks.  Home = Networking Control Protocol (HNCP) is updated to
=   use the 'home.arpa.' domain instead of '.home'.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      
MGLT: I would = personally start by saying the document defines a
= special-use domain name and then defines the behavior.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      

No = change

  Users and devices within a home = network (hereafter "homenet") require
  devices = and services to be identified by names that are unique within
  the boundaries of the homenet [RFC7368]. =  The naming mechanism needs
  to function = without configuration from the user.  While it may be
=   possible for a name to be delegated by an ISP, homenets must = also
  function in the absence of such a = delegation.  A default name with a
  scope = limited to each individual homenet needs to be used.

  This document corrects an error in [RFC7788], = replacing '.home' with
  'home.arpa.' as the = default domain-name for homenets. '.home' had
=   been selected as the most user-friendly option. =  However, there are
  existing uses of = '.home' that may be in conflict with this use:
=   evidence indicates that '.home' queries frequently leak out = and reach
  the root name servers [ICANN1] = [ICANN2].

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: I believe that more important = than the leak is that the
introduction of .home in the = root zone has been identified as
highly risky. Another = reason for not adopting it are also some
uncertainty = about its introduction into the root zone.    
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

This is irrelevant, because the IETF hasn't asked ICANN = for a delegation.   We deliberately left out this discussion = because it's a moot point now and potentially a political hot potato. =   I personally agree with you that this is important, but I think = despite its importance, we got out of that what we needed, and it's = better not to mention it here.

=   This document registers the domain '.home.arpa.' as a = special-use
  domain name [RFC6761] and = specifies the behavior that is expected
  from = the Domain Name System with regard to DNS queries for names
=   whose rightmost non-terminal labels are 'home.arpa.'. =  Queries for
  names ending with '.home.arpa.' = are of local significance within the
  scope of = a homenet, meaning that identical queries will result in
=   different results from one homenet to another.  In = other words, a
  name ending in 'home.arpa.' is = not globally unique.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: I think the text mentioned in = the beginning of the paragraph
above should be in the = abstract. That was the sense of my previous
comment.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      

The point = of an abstract is to give a quick summary of what the document does, not = to recapitulate what it does.   This is a bit of a hobby horse for = me, so I'm not going to lengthen the abstract to include more details = unless my AD tells me I have to.   I do appreciate your point, but = I do not think that the additional text that you are referring to is = necessary in the abstract.

  DNS = queries for names ending with '.home.arpa.' are resolved using
  local resolvers on the homenet.  Such = queries MUST NOT be recursively
  forwarded to = servers outside the logical boundaries of the homenet.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: "local resolvers" seems to me = mis-leading. Your resolver may
be local but still forward = the query to the Global Internet. I do
not see better ways = to say it other than inside the boundaries of
the homenet. = Maybe we could say:   

=   DNS queries for names ending with '.home.arpa.' are resolved = using
  homenet specific resolution mechanisms. =

Eventually an informational reference to = the simple naming
architecture may be added so the reader = can refer to the doc
for further information. For full = disclosure Ted and I are
co-authors.  
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

The document makes this really clear in a later = section.   The text you are proposing to add makes it _less_ clear. =   I do not think this change is a good idea.

  Some service discovery user interfaces that are = expected to be used
  on homenets conceal = information such as domain names from end users.
=   However, it is still expected that in some cases, users will = need to
  see, remember, and even type, names = ending with 'home.arpa.'.  It is
=   therefore desirable that users identify the domain and = understand
  that using it expresses the = intention to connect to a service that is
=   specific to the homenet to which they are connected. =  Enforcing the
  fulfillment of this = intention is out of scope for this document.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: I have difficulties = understanding the paragraph above. If
the idea is to say = home.arpa has special meaning that should be
considered by = GUIs I would propose the following ordering.

It is
  therefore desirable that = users identify the domain and understand
  that = using it expresses the intention to connect to a service that is
  specific to the homenet to which they are = connected.
Some service discovery user interfaces that = are expected to be used
  on homenets conceal = information such as domain names from end users.
=   However, it is still expected that in some cases, users will = need to
  see, remember, and even type, names = ending with 'home.arpa.'.  
Enforcing the
  fulfillment of this intention is out of scope = for this document.   
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

The text here is actually present as a justification = for why we wanted '.home' but didn't get eliminated.   I don't = think there'd be consensus to completely eliminated it, but I've = clarified it by taking out the text that I think confused = you:

    Some =
service discovery user interfaces that are expected to be used
    on homenets conceal information such as domain names from end users.
    However, it is still expected that in some cases, users will need to
    see, remember, and even type, names ending with 'home.arpa.'.  The
    working group hopes that this name will in some way indicate to as
    many readers as possible that such domain names are referring to
    devices in the home, but we recognize that it is an imperfect
    solution.

  2. =  Application software SHOULD NOT treat names ending in
=       'home.arpa.' differently than other = names.  In particular, there
=       is no basis for trusting names that = are subdomains of
=       'home.arpa.' (see Section 6).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: a domain name ending in = home.arpa may be resolved differently
that a regular = domain name. As a result a different treatment is
applied. = I think that "treat" means that no special meaning - other
that the domain name is inside the homenet boundaries - = should be
associated to a home.arpa. If I am correct I = would limit the
consideration to the name rather then the = application.
I would suggest the text below:
=
names ending in home.arpa SHOULD NOT be associated = any other
properties than the affiliation to the homenet. = In particular, there
=       is no basis for trusting names that = are subdomains of
=       'home.arpa.' (see Section 6).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

This section is present in accordance with RFC 6761 and = is required to talk about applications, so this change would not make = sense in that context.   I agree that talking about applications in = this case is fraught, but with that in mind I think the text is as good = as we can do.   I think that your proposed change makes it less = clear, because you haven't said what you mean by "properties."   = The only property that I think is really important here is trust, so = clarifying that "home.arpa" does not imply extra trust is important. =   Think of this in the context of https://w3c.github.io/webappsec-secure-contexts/.   = This text is to specifically exclude that sort of assumption, not that I = think the W3C would make such a mistake!

  3.  Name resolution APIs and libraries MUST NOT = recognize names that
=       end in '.home.arpa.' as special and = MUST NOT treat them
=       differently.  Name resolution = APIs MUST send queries for such
=       names to a recursive DNS server that = is configured to be
=       authoritative for the 'home.arpa.' = zone appropriate to the
=       homenet.  

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: I believe the text below does = not concern the library but
the resolver. It is different = to say libraries MUST NOT have
specific considerations = for home.arpa than a resolution service
that may use = different libraries MUST NOT consider the home.arpa
differently.
My understanding of the text = below is that the resolver and the
authoritative server = for the home.arpa MUST be co-located. The
reasons I think = this is not exact is that resolution for
home.arpa can = also be provided by other mechanisms than an
authoritative = server. Typically, resolution can be done by
requesting = Authoritative Servers, Advertising Proxies, Hybrid
Proxies = (now called Discovery Proxies)....
The other reason is do = not see the text below accurate is that
you may have a DNS = Proxy that transparently to the end user split
the = resolution between homenet specific resolutions when home.arpa
is encountered while other names are sent to the ISP = resolver.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

No, this text is required by RFC 6761 to address the = behavior of local stub resolvers and resolution libraries.   = Changing it to talk about recursive resolvers and proxies would make it = incorrect according to those requirements.   That said, I have = substantially revised that text and it may now make more sense to = you:

    3.  Name =
resolution APIs and libraries MUST NOT recognize names that
        end in '.home.arpa.' as special and MUST NOT treat them as =
having
        special significance, except that it may be necessary that such
        APIs not bypass the locally configured recursive =
resolvers.
        One or more IP addresses for recursive DNS =
servers will usually
        be supplied to the client through router advertisements or DHCP.
        For an administrative domain that uses names in 'home.arpa.',
        such as a homenet, the recursive resolvers provided by that
        domain will be able to answer queries for subdomains of
        home.arpa; other resolvers will not, or will provide answers =
that
        are not correct within that administrative domain.
    =
    A host that is configured to use a resolver other than one that
        has been provided by the local network may be unable to resolve,
        or may receive incorrect results for, names in sub domains of
        'home.arpa.'.  In order to avoid this, it is permissible that
        hosts use the locally-provided resolvers for resolving
        'home.arpa.' even when they are configured to use other
        resolvers.
I also added this related text = to the security considerations section:

    In Section =
4, item 3, an exception is made to the behavior of stub
    resolvers allowing them to query local resolvers for subdomains of
    'home.arpa.' even when they have been manually configured to use
    other resolvers.  This behavior obviously has security and privacy
    implications, and may not be desirable depending on the context.  It
    may be better to simply ignore this exception and, when one or more
    recursive resolvers are configured manually, simply fail to provide
    correct answers for subdomains of 'home.arpa.'.  At this time we do
    not have operational experience that would guide us in making this
    decision; implementors are encouraged to consider the context in
    which their software will be deployed when deciding how to resolve
    this question.
  4.  Caching = resolvers conforming to this specification MUST support
=       DNSSEC queries.  While = validation is not required, it is strongly
=       encouraged; a caching resolver that = does not validate answers
=       that can be validated may cache = invalid data; this will prevent
=       validating stub resolvers from = successfully validating answers.
=   
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: I see the text above as a = recommendation for caching resolvers
in the homenet, but = the relation to the home.arpa is unclear to me.
Was the = intention to say that names under the home.arpa zone SHOULD
be secured with DNSSEC so caching resolvers MUST support = DNSSEC
validation. In addition, these caching resolvers = MUST also be able
to be configured with a Trust Anchor = for the home.arpa.   
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

The text was actually incorrect.   I've = substantially rewritten that item:

        A.  Recursive resolvers at sites using 'home.arpa.'  =
MUST
            transparently support DNSSEC queries: queries for DNSSEC
            records and queries with the DO bit set ([RFC4035] section
            3.2.1) .  While validation is not required, it is strongly
            encouraged; a caching recursive resolver that does not
            validate answers that can be validated may cache invalid
            data; this will prevent validating stub resolvers from
            successfully validating answers.

The other requirements you list are = impossible, because we don't have a mechanism for generating such trust = anchors, nor for disambiguating between different instances of such = trust anchors that a host may need in order to use resources on = different homenets.   Furthermore, requiring host changes is out of = charter.   I agree with you in principle that this needs to happen, = and as you are aware we are working on addressing this problem, both in = homenet and in dnssd.   But we can't address it here.

      It is = permissible to combine the recursive resolver function for
=       general DNS lookups with an = authoritative resolver for
=       'home.arpa.'; in this case, rather = than forwarding queries for
=       subdomains of 'home.arpa.' to an = authoritative server, the
=       caching resolver answers them = authoritatively.  The behavior with
=       respect to forwarding queries = specifically for 'home.arpa.'
=       remains the same.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: The full consideration seems = to me to be conformance to RFC6303.
In particular the = recommendations for DNSSEC in RFC 6303 seems to me
accurated= and are not specifically mentioned here. Maybe that should
be clearly stated that all considerations of RFC6303 should = be
considered as home.arpa is of local scope.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

I think you are missing the point of this text. =  The behavior for RFC6303 was already specified a few paragraphs = earlier, and is required for all resolvers, not just homenet resolvers. =   This text is simply allowing a homenet router implementation to = either implement a caching server and a separate authoritative server, = or merge the two into a hybrid authoritative/recursive server.   = You can do this today with an out-of-the-box BIND 9 = installation.
   
  5.  No special processing of 'home.arpa.' = is required for
=       authoritative DNS server = implementations.  It is possible that an
=       authoritative DNS server might = attempt to check the authoritative
=       servers for 'home.arpa.' for a = delegation beneath that name
=       before answering authoritatively for = such a delegated name.  In
=       such a case, because the name always = has only local significance
=       there will be no such delegation in = the 'home.arpa.' zone, and so
=       the server would refuse to answer = authoritatively for such a
=       zone.  A server that implements = this sort of check MUST be
=       configurable so that either it does = not do this check for the
=       'home.arpa.' domain, or it ignores = the results of the check.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: I understand this as being = incorrect. The resolver can also be configured
with a = trust anchor. I would refer to the RFC6303:

= As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
=   namespaces, the zones listed above will need to be delegated = as
  insecure delegations, or be within = insecure zones.  This will allow
  DNSSEC = validation to succeed for queries in these spaces despite not
  being answered from the delegated servers.

  It is recommended that sites = actively using these namespaces secure
  them = using DNSSEC [RFC4035] by publishing and using DNSSEC trust
=   anchors.  This will protect the clients from = accidental import of
  unsigned responses from = the Internet. =   
  
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

This text is about authoritative servers, not = resolvers.   Locally-served zones are covered under item = 4.

     The = 'home.arpa.' special-use name does not require a special
=      resolution protocol.  Names for which = the rightmost two labels are
=      'home.arpa.' are resolved using the DNS = protocol [RFC1035].

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: If home.arpa are no different = than other resolutions and we
start from the root zone = responses are likely to be NXDOMAIN. I
think we should = clarify that DNS is used as a transport protocol,
but = that resolution may be handled differently.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

No, this is incorrect.   The DNS protocol is being = used to do resolution.   No host changes are = required.

  It is not possible to = install a trust anchor for this zone in the
=   '.arpa' zone.  The reason for this is that in order to = do so, it
  would be necessary to have the = key-signing key for the zone
  ([RFC4034] = Section 5).  Since the zone is not globally unique, no one
  key would work.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      
MGLT: I think that = DS is meant rather than trust anchor.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

A DS record is a trust anchor.   I've updated it = as follows:

  It is not possible to = install a trust anchor (a DS RR) for this zone in the
  '.arpa' zone.  The reason for this is that = in order to do so, it
  would be necessary to = have the key-signing key for the zone
  ([RFC4034]= Section 5).  Since the zone is not globally unique, no one
  key would work.

  An alternative would be to = install a authenticated denial of
  existence = ([RFC4033] Section 3.2).  

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      
MGLT: This is = unclear where the denial of existence is set. Is
that in = the home.arpa zone or the arpa zone.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

There is only one place where it can be set.   I = have updated the text as follows:
    An =
alternative would be to provide a authenticated denial of
    existence ([RFC4033] Section 3.2).  This would be done simply by not
    having a delegation from the 'arpa.' zone.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      
MGLT: There are = also some privacy issues associated to leaking names
outside= the homenet boundaries. For example daniel_smith.home.arpa
reveal the identity of the member of the homenet, = my_ipad.home.arpa
reveals the devices you own, the = application.

This is a known issue, and it's up to the vendors of = devices to decide how much they are willing to reveal.   There is = work going on in dnssd to provide a secure way of doing this.   = It's out of scope for this document.   The document doesn't create = a new problem here.

home.arpa may also used in = larger environment such as corporate /
private. going = from one to the other may also leak such information.

Use of = home.arpa is for home networks.   If a corporate environment uses = it, it's no different than them using some other ad-hoc = name.

The leak can be from the homenet to the = outside world in which case
one neeed to control the = queries sent. But in intruder (or guest)
may also access = the homenet and proceed to discovery of the names.
As a = result even though homenet is believe to be a trusted environment,
care should be considered while publishing under the = home.arpa. as
well as whose the information is accessible = to.   

Yes, an attacker can suborn your home router, and if = they do, your privacy will be more easily violated.   And, as with = existing technology, devices may or may not reveal private information = about you to the network.   This is not a problem that we are = creating with this document, and it is not a problem we can solve with = this document.   Work to solve this is ongoing; I would prefer to = publish this document now rather than holding it up waiting for that = other work.

They might be collision as = well. myprinter.home.arpa may be found
in various = environments, and upon discovery you may also -
in this = example - print confidential information to that printer.
In some case you may not even be aware, for example, if your =
printing information failed home, and is re-activated = once you
are in another environment.  

This issue = is already documented in the security considerations = section.

As information may be = sensitive it may be encrypted using IPsec
DTLS as = described by dprive for both authentication and confidentiality.

How would = we arrange to distribute the trust anchor here?   PKI won't work. =   I don't see how we would establish trust with IKE either.   = Again, work is going on in dnssd to provide an infrastructure that would = allow this, but right now this is empty advice: this is a document about = home networks, operated by end users, so if there isn't a way to do this = automatically, there is no point in saying that end users should do it: = they are never going to read this document.

When the trust anchor is configured in the resolver, these = must be
able to roll-over the key and should follows the = requirements for DNSSEC
validators. if it is impossible = for a resolver to see the difference
between an attack = and a re-key we are in trouble.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

This is an excellent point, and we should consider it = when we write the document where we explain how to manage these trust = anchors.   This is work that I fully intend to do in homenet, but = right now this point doesn't make sense to mention here because this = document doesn't provide an automatic way of setting up trust = anchors.

  In order to be fully = functional, there must be a delegation of
=   'home.arpa.' in the '.arpa.' zone [RFC3172].  This = delegation MUST
  NOT include a DS record, and = MUST point to one or more black hole
  servers, = for example 'blackhole-1.iana.org.' and 'blackhole-
=   2.iana.org.'. =  The reason that this delegation must not be signed is
=   that not signing the delegation breaks the DNSSEC chain of = trust,
  which prevents a validating stub = resolver from rejecting names
  published under = 'home.arpa.' on a homenet name server.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      
MGLT: The zone = home.arpa MUST NOT be seen as belonging to the
homenet. = As a result, NS and DS records for home.arpa does not
have = meanings outside a specific domain. A Public server outside
the boundaries of the homenet MUST consider this traffic as =
irrelevant and sink.    

Redirection to as112 without coordination with as112 operator =
may rather be performed using DNAME. I believe more text = should
document the two alternative. With the proposed = configuration,
the query will be directed to a server = that is not authoritative for
the zone. The response is = likely to be REFUSED, while in the other
case it is = likely to be NXDOMAIN.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      

This = document was reviewed extensively in DNSOP.   The text specifies = what is supposed to happen.   It's not a discussion: it's a = directive to IANA and an explanation for the IAB, which operates .arpa. =   I cannot make this change without breaking the = document.

8.  IANA = Considerations

  IANA is = requested to record the domain name 'home.arpa.' in the
=   Special-Use Domain Names registry [SUDN].  IANA is = requested, with
  the approval of IAB, to = implement the delegation requested in
  Section = 7.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      
MGLT: OK if IANA = may make the direct way work. In that case is
there any = need to update a registry for zone served by as112?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      

Yes. =   As far as I know the text gives IANA the information they need to = do; I do not know how they operate their black hole servers, so I am = trusting that these instructions are sufficient.   They have been = reviewed by people who understand this problem better than I do, like = Andrew Sullivan, Paul Hoffman and Mark Andrews.   I was = specifically advised not to overspecify this.   I would rather take = their word on this than yours, if you will forgive my saying so. = :)

Thanks for the detailed review. =   I didn't take all of your suggestions as written, but the = document has definitely been improved as a result of this = review.

= --Apple-Mail=_35742441-512C-4B16-A871-25F8F5ED881A-- From nobody Tue Aug 29 19:10:21 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 771B91320C9; Tue, 29 Aug 2017 19:10:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: homenet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150405901943.21561.1407404793036303047@ietfa.amsl.com> Date: Tue, 29 Aug 2017 19:10:19 -0700 Archived-At: Subject: [homenet] I-D Action: draft-ietf-homenet-dot-13.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 02:10:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking WG of the IETF. Title : Special Use Domain 'home.arpa.' Authors : Pierre Pfister Ted Lemon Filename : draft-ietf-homenet-dot-13.txt Pages : 10 Date : 2017-08-29 Abstract: This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.', and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-homenet-dot-13 https://datatracker.ietf.org/doc/html/draft-ietf-homenet-dot-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dot-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 29 23:57:08 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7720413239E; Tue, 29 Aug 2017 23:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 WPWnAnWIFYFd; Tue, 29 Aug 2017 23:57:05 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96A813238E; Tue, 29 Aug 2017 23:57:04 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id E629634A5C0; Wed, 30 Aug 2017 06:56:15 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D0D85160044; Wed, 30 Aug 2017 06:56:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B9F1F160045; Wed, 30 Aug 2017 06:56:15 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9cyB5tN30us1; Wed, 30 Aug 2017 06:56:15 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 69D05160044; Wed, 30 Aug 2017 06:56:15 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0370C83A30AE; Wed, 30 Aug 2017 16:56:13 +1000 (AEST) To: Ted Lemon Cc: Dale Worley , draft-ietf-homenet-dot.all@ietf.org, General area reviewing team , HOMENET From: Mark Andrews References: <150357360963.24287.5193275103043411365@ietfa.amsl.com> <4B072264-2824-4433-A24D-DF5D2FD5A085@fugue.com> In-reply-to: Your message of "Tue, 29 Aug 2017 19:25:44 -0400." <4B072264-2824-4433-A24D-DF5D2FD5A085@fugue.com> Date: Wed, 30 Aug 2017 16:56:13 +1000 Message-Id: <20170830065613.0370C83A30AE@rock.dv.isc.org> Archived-At: Subject: Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 06:57:06 -0000 In message <4B072264-2824-4433-A24D-DF5D2FD5A085@fugue.com>, Ted Lemon writes: > El Aug 24, 2017, a les 7:20 AM, Dale Worley va > escriure: > > 4. Domain Name Reservation Considerations > > > > 3. Name resolution APIs MUST send queries for such > > names to a recursive DNS server that is configured to be > > authoritative for the 'home.arpa.' zone appropriate to the > > homenet. > > > > If I understand the terminology correctly, this rules out sending the > > query to a DNS server that recursively sends the query to a server > > that is authoritative for home.arpa. If that is intended and there > > are technical reasons for making this prescription, that's OK, but I > > want to check that that is intended, as this rule is stricter than the > > similar rule in the second paragraph of item 4, which is qualified > > "Unless configured otherwise". > > Wow. The text here is just flat wrong: recursive name servers aren't > authoritative. You can of course combine them, but this text doesn't > agree with some other text later in the document. What the text is > supposed to be saying is that the stub resolver has to use the recursive > resolver that was provided by the network; if it uses a manually > configured resolver, it may get the wrong answer. I will have to rework > this text—thanks so much for calling this to my attention, even though > what you noticed isn't exactly what's wrong! :) > > As for the discrepancy itself, the reason for this is that recursive > resolvers are supposed to stop home.arpa queries leaking to the root, > whereas stub resolvers can (must!) fob that responsibility off on the > recursive resolver. If they are configured to send these queries to, > e.g., 8.8.8.8, we just have to hope that google doesn't forward them to > the root (as would be consistent with the text in item 4). Or the recursive server has learnt that 8.8.8.8 is "special" and is the equivalent of the root servers in terms of keeping local traffic local. Maintaining the list of don't leak too recursive servers is a "interesting" problem. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Aug 30 08:21:40 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A7D132196; Wed, 30 Aug 2017 08:21:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-homenet-dot@ietf.org, Ray Bellis , homenet-chairs@ietf.org, ray@bellis.me.uk, homenet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150410649967.21619.10797102336617899934.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 08:21:39 -0700 Archived-At: Subject: [homenet] Kathleen Moriarty's No Objection on draft-ietf-homenet-dot-13: (with COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:21:39 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-homenet-dot-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for queuing up changes from the SecDir review and adding mention of privacy implications into the security considerations section. I read through the responses on the SecDir list and agree with the statements and changes made. https://mailarchive.ietf.org/arch/msg/secdir/E7fjRdo94abFW5nqjVBbLspvkww From nobody Wed Aug 30 09:26:50 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513031321A1; Wed, 30 Aug 2017 09:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 oknKNdSO2MET; Wed, 30 Aug 2017 09:26:32 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F51C13202D; Wed, 30 Aug 2017 09:26:32 -0700 (PDT) Received: from mail.nominum.com (sjc1-exch01.win.nominum.com [IPv6:2620:0:b60:fab4:1026:2045:f02a:5f75]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 777C0740037; Wed, 30 Aug 2017 16:26:01 +0000 (UTC) Received: from cavall.ether.lede.home (24.60.163.103) by SJC1-EXCH01.WIN.NOMINUM.COM (64.89.235.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1034.26; Wed, 30 Aug 2017 09:25:57 -0700 From: Ted Lemon Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_CABCAD0D-2374-46B7-A2AA-3BCCB4321D7A" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 30 Aug 2017 12:25:58 -0400 In-Reply-To: CC: , , HOMENET , The IESG , Ray Bellis To: Adam Roach References: <150395805175.13203.12325524217824839037.idtracker@ietfa.amsl.com> <6A42DD6D-CE4C-4172-BE83-C0A259A4368D@nominum.com> X-Mailer: Apple Mail (2.3273) X-Originating-IP: [24.60.163.103] X-ClientProxiedBy: SJC1-EXCH02.WIN.NOMINUM.COM (64.89.235.69) To SJC1-EXCH01.WIN.NOMINUM.COM (64.89.235.83) Archived-At: Subject: Re: [homenet] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 16:26:34 -0000 --Apple-Mail=_CABCAD0D-2374-46B7-A2AA-3BCCB4321D7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Argh, I spaced out on doing these changes because the security review = was so extensive. Sorry about that. I'm making changes to my version = of the document, but I will refrain from further confusing the = datatracker=E2=80=94assuming that this document is approved tomorrow, I = can submit an update with these changes and any others that come up on = the telechat. > On Aug 28, 2017, at 11:18 PM, Adam Roach wrote: > Oh! That makes a lot more sense -- I should have chased down that = section in 6761. I think what's tripping me up is the introduction in = the homenet-dot draft: "This section defines the behavior of systems = involved in domain name resolution when resolving queries for names = ending with '.home.arpa.' (as per [RFC6761])." -- it would be clearer if = it said something more like "This section reserves the '.home.arpa.' = subdomain according to the procedures outlined in [RFC6761] section 4." The requirement to put this in the IANA considerations section is = actually probably a bad idea, because it would create a lot of = irrelevant chaff for the IANA to parse through. I think it was = well-intended, but I've never actually seen it done this way in previous = RFC 6761 allocations. That said, your basic point is correct=E2=80=94the= re should be a better explanation of what's going on in this section. = I've updated the introductory text for this section as follows: This section specifies considerations for systems involved in = domain name resolution when resolving queries for names ending with '.home.arpa.'. = Each items in this section addresses some aspect of the DNS or the process of resolving = domain names that would be affected by this special use allocation. Detailed explanations = of these items can be found in , Section 5. >>> With the explanation in section 6: >>>=20 >>> it may be useful for the resolver to identify different >>> homenets on which it has resolved names >>>=20 >>> Doesn't this mitigation in the security section require name = resolution >>> libraries to recognize names that end in ".home.arpa." as special so = that it >>> can treat them differently? >>=20 >> Section 6 is talking about future work. If we come up with a way to = do this, then it would update this document, changing the normative = requirement. >=20 > To me, this reads as something that could be done unilaterally by the = local resolver according to their own reasonable notion of what the = proper mitigations might be here. I would suggest rephrasing to make it = clearer that this suggestion pertains to _future_ work; e.g., "To = prevent this from happening, future documents may define behavior that = allows resolvers to identify and distinguish among different homenets on = which they have resolved names, and take appropriate measures to avoid = such confusion." >=20 >=20 Yup, that makes sense. Proposed update: To prevent this from happening, it could be useful for the = resolver to securely differentiate between different homenets, and between = identical names on different homenets. However, a mechanism for doing this has not yet = been standardized, and doing so is out of scope for this document. It is expected = that this will be explored in future work. OK? --Apple-Mail=_CABCAD0D-2374-46B7-A2AA-3BCCB4321D7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Argh, I spaced out on doing these changes because the = security review was so extensive.   Sorry about that.   I'm = making changes to my version of the document, but I will refrain from = further confusing the datatracker=E2=80=94assuming that this document is = approved tomorrow, I can submit an update with these changes and any = others that come up on the telechat.

On = Aug 28, 2017, at 11:18 PM, Adam Roach <adam@nostrum.com> = wrote:
Oh! That makes a lot more sense -- I should have chased down = that section in 6761. I think what's tripping me up is the introduction = in the homenet-dot draft: "This section defines the behavior of systems = involved in domain name resolution when resolving queries for names = ending with '.home.arpa.' (as per [RFC6761])." -- it would be clearer if = it said something more like "This section reserves the '.home.arpa.' = subdomain according to the procedures outlined in [RFC6761] section = 4."

The requirement = to put this in the IANA considerations section is actually probably a = bad idea, because it would create a lot of irrelevant chaff for the IANA = to parse through.   I think it was well-intended, but I've never = actually seen it done this way in previous RFC 6761 allocations.   = That said, your basic point is correct=E2=80=94there should be a better = explanation of what's going on in this section.   I've updated the = introductory text for this section as follows:

This section specifies = considerations for systems involved in domain name = resolution
when resolving queries for names = ending with '.home.arpa.'.  Each items in this = section
addresses some aspect of the DNS = or the process of resolving domain names that would be
affected = by this special use allocation.  Detailed explanations of these = items can be
found in <xref = target=3D"RFC6761"/>, Section 5.


With the explanation in section 6:

  it may be useful for the resolver to = identify different
  homenets on which = it has resolved names

Doesn't this mitigation in the security section require = name resolution
libraries to recognize names = that end in ".home.arpa." as special so that it
can treat them = differently?

Section 6 is talking about future work.   If we come up = with a way to do this, then it would update this document, changing the = normative requirement.


To me, this reads as = something that could be done unilaterally by the local resolver = according to their own reasonable notion of what the proper mitigations = might be here. I would suggest rephrasing to make it clearer that this = suggestion pertains to _future_ work; e.g., "To prevent this from = happening, future documents may define behavior that allows resolvers to = identify and distinguish among different homenets on which they have = resolved names, and take appropriate measures to avoid such = confusion."


Yup, that makes sense.   = Proposed update:

 To = prevent this from happening, it could be useful for the resolver to = securely
 differentiate between = different homenets, and between identical names on = different
 homenets.  However, a = mechanism for doing this has not yet been standardized, = and
=  doing so is out of scope for this document.  It is = expected that this will be explored in
=  future work.

OK?

= --Apple-Mail=_CABCAD0D-2374-46B7-A2AA-3BCCB4321D7A-- From nobody Wed Aug 30 09:59:37 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A85B1321B7; Wed, 30 Aug 2017 09:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham 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 RJMb95l_nwTf; Wed, 30 Aug 2017 09:59:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8F0061321A6; Wed, 30 Aug 2017 09:59:27 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7UGxKiI038566 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Aug 2017 11:59:22 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Ted Lemon Cc: draft-ietf-homenet-dot@ietf.org, homenet-chairs@ietf.org, HOMENET , The IESG , Ray Bellis References: <150395805175.13203.12325524217824839037.idtracker@ietfa.amsl.com> <6A42DD6D-CE4C-4172-BE83-C0A259A4368D@nominum.com> From: Adam Roach Message-ID: <0c093268-374a-8a38-e36f-193575fa4b5a@nostrum.com> Date: Wed, 30 Aug 2017 11:59:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1B7EDD3BF3323C795980EAE2" Content-Language: en-US Archived-At: Subject: Re: [homenet] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 16:59:30 -0000 This is a multi-part message in MIME format. --------------1B7EDD3BF3323C795980EAE2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks. Both changes look good to me. /a On 8/30/17 11:25, Ted Lemon wrote: > Argh, I spaced out on doing these changes because the security review > was so extensive.   Sorry about that.   I'm making changes to my > version of the document, but I will refrain from further confusing the > datatracker—assuming that this document is approved tomorrow, I can > submit an update with these changes and any others that come up on the > telechat. > >> On Aug 28, 2017, at 11:18 PM, Adam Roach > > wrote: >> Oh! That makes a lot more sense -- I should have chased down that >> section in 6761. I think what's tripping me up is the introduction in >> the homenet-dot draft: "This section defines the behavior of systems >> involved in domain name resolution when resolving queries for names >> ending with '.home.arpa.' (as per [RFC6761])." -- it would be clearer >> if it said something more like "This section reserves the >> '.home.arpa.' subdomain according to the procedures outlined in >> [RFC6761] section 4." > > The requirement to put this in the IANA considerations section is > actually probably a bad idea, because it would create a lot of > irrelevant chaff for the IANA to parse through.   I think it was > well-intended, but I've never actually seen it done this way in > previous RFC 6761 allocations.   That said, your basic point is > correct—there should be a better explanation of what's going on in > this section.   I've updated the introductory text for this section as > follows: > > This section specifies considerations for systems involved in domain > name resolution > when resolving queries for names ending with '.home.arpa.'.  Each > items in this section > addresses some aspect of the DNS or the process of resolving domain > names that would be > affected by this special use allocation.  Detailed explanations of > these items can be > found in , Section 5. > > >>>> With the explanation in section 6: >>>> >>>>   it may be useful for the resolver to identify different >>>>   homenets on which it has resolved names >>>> >>>> Doesn't this mitigation in the security section require name resolution >>>> libraries to recognize names that end in ".home.arpa." as special >>>> so that it >>>> can treat them differently? >>> >>> Section 6 is talking about future work. If we come up with a way to >>> do this, then it would update this document, changing the normative >>> requirement. >> >> >> To me, this reads as something that could be done unilaterally by the >> local resolver according to their own reasonable notion of what the >> proper mitigations might be here. I would suggest rephrasing to make >> it clearer that this suggestion pertains to _future_ work; e.g., "To >> prevent this from happening, future documents may define behavior >> that allows resolvers to identify and distinguish among different >> homenets on which they have resolved names, and take appropriate >> measures to avoid such confusion." >> >> > Yup, that makes sense.   Proposed update: > >  To prevent this from happening, it could be useful for the resolver > to securely >  differentiate between different homenets, and between identical names > on different >  homenets.  However, a mechanism for doing this has not yet been > standardized, and >  doing so is out of scope for this document.  It is expected that this > will be explored in >  future work. > > OK? > --------------1B7EDD3BF3323C795980EAE2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks. Both changes look good to me.

/a

On 8/30/17 11:25, Ted Lemon wrote:
Argh, I spaced out on doing these changes because the security review was so extensive.   Sorry about that.   I'm making changes to my version of the document, but I will refrain from further confusing the datatracker—assuming that this document is approved tomorrow, I can submit an update with these changes and any others that come up on the telechat.

On Aug 28, 2017, at 11:18 PM, Adam Roach <adam@nostrum.com> wrote:
Oh! That makes a lot more sense -- I should have chased down that section in 6761. I think what's tripping me up is the introduction in the homenet-dot draft: "This section defines the behavior of systems involved in domain name resolution when resolving queries for names ending with '.home.arpa.' (as per [RFC6761])." -- it would be clearer if it said something more like "This section reserves the '.home.arpa.' subdomain according to the procedures outlined in [RFC6761] section 4."

The requirement to put this in the IANA considerations section is actually probably a bad idea, because it would create a lot of irrelevant chaff for the IANA to parse through.   I think it was well-intended, but I've never actually seen it done this way in previous RFC 6761 allocations.   That said, your basic point is correct—there should be a better explanation of what's going on in this section.   I've updated the introductory text for this section as follows:

This section specifies considerations for systems involved in domain name resolution
when resolving queries for names ending with '.home.arpa.'.  Each items in this section
addresses some aspect of the DNS or the process of resolving domain names that would be
affected by this special use allocation.  Detailed explanations of these items can be
found in <xref target="RFC6761"/>, Section 5.


With the explanation in section 6:

  it may be useful for the resolver to identify different
  homenets on which it has resolved names

Doesn't this mitigation in the security section require name resolution
libraries to recognize names that end in ".home.arpa." as special so that it
can treat them differently?

Section 6 is talking about future work.   If we come up with a way to do this, then it would update this document, changing the normative requirement.


To me, this reads as something that could be done unilaterally by the local resolver according to their own reasonable notion of what the proper mitigations might be here. I would suggest rephrasing to make it clearer that this suggestion pertains to _future_ work; e.g., "To prevent this from happening, future documents may define behavior that allows resolvers to identify and distinguish among different homenets on which they have resolved names, and take appropriate measures to avoid such confusion."


Yup, that makes sense.   Proposed update:

 To prevent this from happening, it could be useful for the resolver to securely
 differentiate between different homenets, and between identical names on different
 homenets.  However, a mechanism for doing this has not yet been standardized, and
 doing so is out of scope for this document.  It is expected that this will be explored in
 future work.

OK?


--------------1B7EDD3BF3323C795980EAE2-- From nobody Wed Aug 30 12:10:50 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E6513219B; Wed, 30 Aug 2017 12:10:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-homenet-dot@ietf.org, Ray Bellis , homenet-chairs@ietf.org, ray@bellis.me.uk, homenet@ietf.org, jrmitche@puck.nether.net X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150412024935.21586.6465698628844336921.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 12:10:49 -0700 Archived-At: Subject: [homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 19:10:49 -0000 Warren Kumari has entered the following ballot position for draft-ietf-homenet-dot-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1: Section 4. Domain Name Reservation Considerations, Subsection 4 If I'm a recursive server and I am configured "with a delegation to an authoritative server for that particular homenet’s instance of the domain ’home.arpa.’." then I have a local zone containing "home.arpa IN NS ". Unless I'm really confused, this means that I have to make myself authoritative for .arpa, which will a: break everything else in .arpa, and b: will (correctly!) be DNSSEC bogus to validating stubs. (See also #5). Perhaps you mean that there should be something like (BINDism): zone "home.arpa" { type forward; forwarders { 192.0.2.1; 192.0.2.2; }; }; This possibility only came to me after much thought, and I do not think that it could be described as "a delegation". I also do not think that this is a standard / well defined behavior. 2: Section 4. Domain Name Reservation Considerations, Subsection 4 "Caching resolvers conforming to this specification MUST support DNSSEC queries." This is a MUST, so it's important to understand, but I don't understand what it actually means. What is a "DNSSEC query"? It is just one with the DO bit? It is one looking for a DS / RRSIG / similar as the qtype? I don't know what this means, so I don't know if it applies to me / what I should do. 3: "Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3). That is, queries for domains that are subdomains of ’home.arpa.’ MUST NOT be forwarded, with one important exception: ..." This says that I must not forward for *domains* that are *subdomains* of home.arpa. The example shows a lookup for NS for 'home.arpa', so presumably this is actually talking about subdomains of home.arpa. So, I have no idea what to do for lookups within home.arpa itself -- what do I do with query for the A record for printer.home.arpa? It is simply a name within home.arpa; I have no way of knowing if it is a subdomain of home.arpa but it certainly isn't a domain that is a subdomain of home.arpa (because there are only three label, not four). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Major issues: 1: I think that this document could benefit from additional review in the DNSOP WG - it got some (https://www.ietf.org/mail-archive/web/dnsop/current/msg19620.html), but that was a: while it was still homenet. b: primarily focused in terms of RFC6761 and not on the whole systems / interaction with existing behaviors, c: largely devolved into "does this do go in the root zone or not"?, d: 9 revisions back. The document feels vague about much of the details / expected behavior from all of the different players, and I think more focused review from more DNS people would help. 2: What is a "caching resolver"? It is the same as a "recursive resolver"? Or is it a "full-service resolver"? The fact that the answer to RFC6761 Q4 uses both terms makes me think that they are different, but I don't know how. 3: The document says: "Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3).", but I do not see this being added to the locally served zones registry. This was raised in a previous review (Jon Mitchell, OpsDir (for v03) https://datatracker.ietf.org/doc/review-ietf-homenet-dot-03-opsdir-early-mitchell-2017-03-18/ ), and not implemented. I'm assuming there is a reason, but I haven't found the discussion. 4: The document describes what recursive servers should do with queries for things in home.arpa, but seems to gloss over some detail -- I think that the document would benefit from an overview showing the stub (and / or validating stub), an internal recursive / proxy, an external recursive, the local authoritative for home.arpa, and the .arpa servers, and clearly explain what the expected behavior / role for each one under various scenarios is. 5: Even with the above answered, I remain confused by the "what does a recursive resolver do" bit -- this discusses what a recursive server should do with a DS query for home.arpa - this (obviously) exists to prevent DNSSEC validating stubs from believing that foo.home.arpa is bogus. It also means that it is expected that queries from stubs will sometimes arrive at these recursive resolvers (and they "MUST behave as described in Locally Served Zones" is not simply to prevent pollution). If a query for printer.bedroom.home.arpa does arrive at a recursive, and it is configured as a locally served zone, it will return NXDOMAIN. This (obviously) breaks the lookup for printer.bedroom.home.arpa, but RFC8020 (" NXDOMAIN: There Really Is Nothing Underneath ") also says that this means that nothing exists in bedroom.home.arpa - I think that there needs to be some more text describing the deployment, and which set of queries go where. 6: Section 7. Delegation of ’home.arpa.’ This delegation MUST NOT include a DS record, and MUST point to one or more black hole servers, for example ’blackhole-1.iana.org.’ and ’blackhole- 2.iana.org.’. I fully agree with the DS bit, but the "blackhole" bit feels VERY hand-wavey. Currently a lookup for home.arpa to these returns REFUSED instead of NXDOMAIN: $ dig +nostat +nocmd home.arpa @blackhole-2.iana.org ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 7826 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;home.arpa. IN A The document just delegates this to ’blackhole-1.iana.org.’ and ’blackhole- 2.iana.org.’ - they're are not authoritative for home.arpa (and nothing in the doc makes them so), and so this does not return NXDOMAIN and instead amplifies the query load. Delegating them to RFC7535 servers *may* help, but I'm not sure. 7: "In addition to the behavior specified above, recursive resolvers that can be used in a homenet MUST be configurable with a delegation to an authoritative server for that particular homenet’s instance of the domain ’home.arpa.’." -- Ok, but how does this interact with the requirements on local-zones? I'm *guessing* it overrides it, and if I get a query for printer.livingroom.home.arpa I should "forward" it to the authoritative servers? The document also seems Minor issues / nits: 1: Section 1. Introduction. "A default name with a scope limited to each individual homenet needs to be used." -- I don't understand the "needs to be used" - perhaps "needs to be defined"? Otherwise it sounds like, if the ISP delegates a name, implementations must ignore it. Adding "In these cases," to the beginning of this sentence may clarify. 2: "No such process is available for requesting a similar delegation in the root" -- I think this would be better as "No such process is *currently* available...." 3: Section 3. General Guidance " Names ending with ’.home.arpa.’ reference a locally-served zone," -- the term "locally-served zone" has specific meaning in the DNS context - see https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-05. I'd suggest clarifying that this is not what you mean here. 4: Section 4. Domain Name Reservation Considerations It seems that a number of readers didn't get that this next bit is to answer the questions from 6761 - I'd suggest something like: "This section contains answers to the questions posed in Section 5 of RFC6761 and define the behavior of systems involved in domain name resolution when resolving queries for names ending with ’.home.arpa.’. 5: " ... zone, the client may be unable to resolve, or may receive incorrect results for, names in sub domains of ’home.arpa.’." -- "names in sub domains of 'home.arpa.'" are things like foo.bar.home.arpa -- do you just mean "names in 'home.arpa'" ? 6: "a query for a DS record when the DO bit ([RFC4035] section 3.2.1) set MUST return " -- missing "is" after the closing parens? 7: Section 6 - Security Considerations "To prevent this from happening, it may be useful for the resolver to identify different homenets on which it has resolved names, but this is out of scope for this document." -- is this a stub resolver? recursive? both? 8: "An alternative would be to install a authenticated denial of existence ([RFC4033] Section 3.2)." -- 1: *an* authenticated and 2: "authenticated denial of existence *record*" (I think. I'm not quite sure on the wording here, and suspect it would need more text, like "DNSSEC records proving authenticated denial of existence.") From nobody Wed Aug 30 12:54:53 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D24A132A8F for ; Wed, 30 Aug 2017 12:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 UG3JqZy296fA for ; Wed, 30 Aug 2017 12:54:48 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 E5F43132027 for ; Wed, 30 Aug 2017 12:54:47 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id a77so32528620qkb.1 for ; Wed, 30 Aug 2017 12:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M0MNZeFZlW0ky2xH3vKghsTWVkZ2PywoeRdx2npJEvU=; b=eEzPqSyRA4X2n/PNSgGyje4RZPbp+9UXiuJ184FbrfvWqGcsSuHsR6NYiU7IiFtskc tKbm5voQ/HGM9nKRUexly6ZZD3UcM8zt3V1/5FFp2Nl9322EyzuK3bkJ1txssaPTBO7L Pfj/Zm0Hf46FR8jbP1dMBemCRqbfiZSI1ubb+ZzRFHfBJ3yYZw/xB4u/oxKksa3j9cgM y7mkBjDLfF86UzOTiZHu3GtYFG8mq6j14gIe6AegjiwQI7VIxmfu4/6Rt95/Kvn6Skv8 oMUSkxTO/knebCiQjrsWnz3hDhg5sRUfIb2UpvO0cMHchwhv3ztjaNEmhPtJ/USBzN0n zytw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M0MNZeFZlW0ky2xH3vKghsTWVkZ2PywoeRdx2npJEvU=; b=kr3Qg5oX5iRliCv8rIxWl7T9zmVQtaUGbywXomh1U0dcMZaoYkMvptIUTKNZTZ7upz RLMd95DzkXL1oGEryf8ZeLSWySovFJ/5ydws4TTOzKiyXFNeEOd0NA79dCkWDwmkXjEM JeDnmP/Nwc1qIDAkGuxHXKfLdhpUlEJXrNdPTU9+1+1sKaLDipQYJ+XJrPRWp0GMo0Zc XNEdNaTEAEOXKOGUL8ha8TfAVEr0L4jxTTai/EZ6B3B+KCF0WpsKUmlyocVcB2ZHAhep p4vjMFf6OabT/4DnI9THR++HAI8eQdkBxBx+1amw4G6ypgJ9w3t7SjhWEN1znNbQp9vd 0TVQ== X-Gm-Message-State: AHYfb5ir5yuCIyRgk0sTNCNmJSWuqDD0SUHNm8Owk6HX2c/cjwR84lxs PghiLw5vY+v2MV33 X-Received: by 10.55.76.195 with SMTP id z186mr621138qka.172.1504122886723; Wed, 30 Aug 2017 12:54:46 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id z35sm4394949qtb.34.2017.08.30.12.54.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 12:54:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <150412024935.21586.6465698628844336921.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 15:54:44 -0400 Cc: The IESG , draft-ietf-homenet-dot@ietf.org, homenet-chairs@ietf.org, HOMENET , ray@bellis.me.uk, jrmitche@puck.nether.net Content-Transfer-Encoding: quoted-printable Message-Id: <11D94BA1-4B9A-467A-991E-166B17769D09@fugue.com> References: <150412024935.21586.6465698628844336921.idtracker@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 19:54:52 -0000 On Aug 30, 2017, at 3:10 PM, Warren Kumari wrote: > 1: Section 4. Domain Name Reservation Considerations, Subsection 4 > If I'm a recursive server and I am configured "with a delegation to an > authoritative server for that particular homenet=E2=80=99s instance of = the domain > =E2=80=99home.arpa.=E2=80=99." then I have a local zone containing = "home.arpa IN NS =20 > ". Unless I'm really confused, this = means > that I have to make myself authoritative for .arpa, which will a: = break > everything else in .arpa, and b: will (correctly!) be DNSSEC bogus to > validating stubs. (See also #5). Perhaps you mean that there should be > something like (BINDism): zone "home.arpa" { > type forward; > forwarders { 192.0.2.1; 192.0.2.2; }; > }; > This possibility only came to me after much thought, and I do not = think that it > could be described as "a delegation". I also do not think that this is = a > standard / well defined behavior. Yup, that's bogus. Is this better? In addition to the behavior specified above, recursive = resolvers that can be used in a homenet MUST be configurable to forward queries for = 'home.arpa.' and subdomains of 'home.arpa.' to an authoritative server for = 'home.arpa.'. This server will provide authoritative data for 'home.arpa.' within a particular = homenet. The special handling for DS records for the 'home.arpa.' delegation = is still required. > 2: Section 4. Domain Name Reservation Considerations, Subsection 4 > "Caching resolvers conforming to this specification MUST support = DNSSEC > queries." This is a MUST, so it's important to understand, but I don't > understand what it actually means. What is a "DNSSEC query"? It is = just one > with the DO bit? It is one looking for a DS / RRSIG / similar as the = qtype? I > don't know what this means, so I don't know if it applies to me / what = I should > do. I think this is clarified in the -13 version of the document. Is this = review based on that version, or on -12? Here is the new text: Recursive resolvers at sites using 'home.arpa.' MUST = transparently support DNSSEC queries: queries for DNSSEC records and queries = with the DO bit set ( section 3.2.1). While = validation is not required, it is strongly encouraged: a caching recursive resolver = that does not validate answers that can be validated may cache invalid data. = This in turn will prevent validating stub resolvers from successfully validating = answers. > 3: "Unless configured otherwise, recursive resolvers and DNS proxies = MUST > behave as described in Locally Served Zones ([RFC6303] Section 3). = That is, > queries for domains that are subdomains of =E2=80=99home.arpa.=E2=80=99 = MUST NOT be forwarded, > with one important exception: ..." This says that I must not forward = for > *domains* that are *subdomains* of home.arpa. The example shows a = lookup for NS > for 'home.arpa', so presumably this is actually talking about = subdomains of > home.arpa. So, I have no idea what to do for lookups within home.arpa = itself > -- what do I do with query for the A record for printer.home.arpa? It = is simply > a name within home.arpa; I have no way of knowing if it is a subdomain = of > home.arpa but it certainly isn't a domain that is a subdomain of = home.arpa > (because there are only three label, not four). Yes, the other text had the same problem. How about "queries for = 'home.arpa.' and subdomains of 'home.arpa.'"? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Major issues: >=20 > 1: I think that this document could benefit from additional review in = the DNSOP > WG - it got some > (https://www.ietf.org/mail-archive/web/dnsop/current/msg19620.html), = but that > was a: while it was still homenet. b: primarily focused in terms of = RFC6761 and > not on the whole systems / interaction with existing behaviors, c: = largely > devolved into "does this do go in the root zone or not"?, d: 9 = revisions back. > The document feels vague about much of the details / expected behavior = from all > of the different players, and I think more focused review from more = DNS people > would help. I disagree. The document has had substantial review from DNSOP people, = including recently. They are mentioned in the acknowledgments. I = think that I've fixed a couple of the things in -13 that triggered this = reaction. In particular: > 2: What is a "caching resolver"? It is the same as a "recursive = resolver"? Or > is it a "full-service resolver"? The fact that the answer to RFC6761 = Q4 uses > both terms makes me think that they are different, but I don't know = how. The term "caching resolver" was carried over from 6761. What is meant = here is "recursive resolver" or "full service resolver," which I think = are synonyms. I updated the text to take out "caching", since = "resolver" clearly has an antecedent of "recursive resolver" and I don't = think needs to be qualified in this way twice in the same paragraph. > 3: The document says: "Unless configured otherwise, recursive = resolvers and DNS > proxies MUST behave as described in Locally Served Zones ([RFC6303] = Section > 3).", but I do not see this being added to the locally served zones = registry. > This was raised in a previous review (Jon Mitchell, OpsDir (for v03) > = https://datatracker.ietf.org/doc/review-ietf-homenet-dot-03-opsdir-early-m= itchell-2017-03-18/ > ), and not implemented. I'm assuming there is a reason, but I haven't = found the > discussion. Because I was being lazy and didn't actually chase down what Dale had = said to see that indeed it was necessary. I've added this to IANA = Considerations: IANA is further requested to create a new subregistry within the = "Locally-Served DNS Zones" registry , titled = "Transport-Independent Locally-Served DNS Zones", with the same format as the other subregistries. IANA = is requested to add an entry in this new registry for 'home.arpa.' with the description = "Homenet Special-Use Domain", listing this document as the reference. > 4: The document describes what recursive servers should do with = queries for > things in home.arpa, but seems to gloss over some detail -- I think = that the > document would benefit from an overview showing the stub (and / or = validating > stub), an internal recursive / proxy, an external recursive, the local > authoritative for home.arpa, and the .arpa servers, and clearly = explain what > the expected behavior / role for each one under various scenarios is. Could you look at the -13 version of the document, with the changes I = provided for your DISCUSS, and see if you still think this is necessary? = The bulk of what you are requesting is really out of scope for the = original intended purpose of this document. I agree that more detail = is needed, but the plan was to document that in a document that was = under less time pressure. > 5: Even with the above answered, I remain confused by the "what does a > recursive resolver do" bit -- this discusses what a recursive server = should do > with a DS query for home.arpa - this (obviously) exists to prevent = DNSSEC > validating stubs from believing that foo.home.arpa is bogus. It also = means that > it is expected that queries from stubs will sometimes arrive at these = recursive > resolvers (and they "MUST behave as described in Locally Served Zones" = is not > simply to prevent pollution). If a query for printer.bedroom.home.arpa = does > arrive at a recursive, and it is configured as a locally served zone, = it will > return NXDOMAIN. This (obviously) breaks the lookup for > printer.bedroom.home.arpa, but RFC8020 (" NXDOMAIN: There Really Is = Nothing > Underneath ") also says that this means that nothing exists in > bedroom.home.arpa - I think that there needs to be some more text = describing > the deployment, and which set of queries go where. All of the relevant DNS protocol agents are expected to behave as = normal, with the stated exceptions. As the document says, stubs are = expected to send queries to whatever recursive resolvers are configured = by the network. On a normal network, the resolver would indeed respond = with NXDOMAIN, and this would be correct. This is the specified, and = intended, behavior. If the local recursive resolver is a homenet resolver, it's expected to = divert queries for home.arpa, except the DS record, to the local server = authoritative for home.arpa. That server will provide answers which = will validate, because the DS record provably doesn't exist. > 6: Section 7. Delegation of =E2=80=99home.arpa.=E2=80=99 > This delegation MUST NOT include a DS record, and MUST point to one or = more > black hole servers, for example =E2=80=99blackhole-1.iana.org.=E2=80=99 = and =E2=80=99blackhole- > 2.iana.org.=E2=80=99. I fully agree with the DS bit, but the = "blackhole" bit feels VERY > hand-wavey. Currently a lookup for home.arpa to these returns REFUSED = instead > of NXDOMAIN: $ dig +nostat +nocmd home.arpa @blackhole-2.iana.org ;; = Got > answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 7826 ;; = flags: qr > rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: = recursion > requested but not available >=20 > ;; QUESTION SECTION: > ;home.arpa. IN A >=20 > The document just delegates this to =E2=80=99blackhole-1.iana.org.=E2=80= =99 and =E2=80=99blackhole- > 2.iana.org.=E2=80=99 - they're are not authoritative for home.arpa = (and nothing in the > doc makes them so), and so this does not return NXDOMAIN and instead = amplifies > the query load. Delegating them to RFC7535 servers *may* help, but I'm = not sure. We were specifically asked to trust that IAB/IANA would deal with this, = and to not put explicit operator instructions in the document. I agree = that those two servers need configuration changes; this is up to the IAB = and IANA (as their operator) to make happen. > 7: "In addition to the behavior specified above, recursive resolvers = that can > be used in a homenet MUST be configurable with a delegation to an > authoritative server for that particular homenet=E2=80=99s instance of = the domain > =E2=80=99home.arpa.=E2=80=99." -- Ok, but how does this interact with = the requirements on > local-zones? I'm *guessing* it overrides it, and if I get a query for > printer.livingroom.home.arpa I should "forward" it to the = authoritative > servers? The document also seems I think you left that sentence unfinished, but perhaps the new text I = propose above for this bit helps? > Minor issues / nits: > 1: Section 1. Introduction. > "A default name with a scope limited to each individual homenet needs = to be > used." -- I don't understand the "needs to be used" - perhaps "needs = to be > defined"? Otherwise it sounds like, if the ISP delegates a name, > implementations must ignore it. Adding "In these cases," to the = beginning of > this sentence may clarify. How about: Users and devices within a home network (hereafter "homenet") = require devices and services to be identified by names that are unique within the = boundaries of the homenet . The naming mechanism needs to = function without configuration from the user. While it may be possible for a name to be = delegated by an ISP, homenets must also function in the absence of such a delegation. This = document reserves the name 'home.arpa.' to serve as the default name for this purpose, = with with a scope limited to each individual homenet. > 2: "No such process is available for requesting a similar delegation = in the > root" -- I think this would be better as "No such process is = *currently* > available...." The IAB has made it pretty clear that they do not intend for such a = process to ever be available, in the sense that they do not wish to open = a discussion with ICANN with the purpose of creating such a process. I = can leave the door open here anyway if you want, but that's why the text = reads the way it does. I think an early version actually said = "currently," but I may be mistaken. > 3: Section 3. General Guidance > " Names ending with =E2=80=99.home.arpa.=E2=80=99 reference a = locally-served zone," -- the term > "locally-served zone" has specific meaning in the DNS context - see > https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-05. I'd = suggest > clarifying that this is not what you mean here. The text in terminology-bis gives exactly the intended meaning. > 4: Section 4. Domain Name Reservation Considerations > It seems that a number of readers didn't get that this next bit is to = answer > the questions from 6761 - I'd suggest something like: > "This section contains answers to the questions posed in Section 5 = of > RFC6761 and define the behavior of systems involved in domain name > resolution when resolving queries for names ending with = =E2=80=99.home.arpa.=E2=80=99. I've proposed the following text in response to Adam's comment: This section specifies considerations for systems involved in = domain name resolution when resolving queries for names ending with '.home.arpa.'. = Each item in this section addresses some aspect of the DNS or the process of resolving = domain names that would be affected by this special use allocation. Detailed explanations = of these items can be found in , Section 5. > 5: " ... zone, the client may be unable to resolve, or may receive = incorrect > results for, names in sub domains of =E2=80=99home.arpa.=E2=80=99." -- = "names in sub domains of > 'home.arpa.'" are things like foo.bar.home.arpa -- do you just mean = "names in > 'home.arpa'" ? How about: A host that is configured to use a resolver other than one = that has been provided by the local network may be unable to resolve, or may receive = incorrect results for, subdomains of 'home.arpa.'. I try to avoid using "in" to mean "subdomain of" because it feels = imprecise. > 6: "a query for a DS record when the DO bit ([RFC4035] section 3.2.1) = set MUST > return " -- missing "is" after the closing parens? Changed "when" to "with". > 7: Section 6 - Security Considerations > "To prevent this from happening, it may be useful for the resolver to = identify > different homenets on which it has resolved names, but this is out of = scope for > this document." -- is this a stub resolver? recursive? both? Good point. The resolver on the host. I hesitate to say "stub = resolver" because it might not be a stub resolver. I changed it to = "the resolver on the host." > 8: "An alternative would be to install a authenticated denial of = existence > ([RFC4033] Section 3.2)." -- 1: *an* authenticated and 2: = "authenticated denial > of existence *record*" (I think. I'm not quite sure on the wording = here, and > suspect it would need more text, like "DNSSEC records proving = authenticated > denial of existence.") .arpa doesn't use NSEC3. So there is no record specific to = 'home.arpa.'=E2=80=94there's just an NXT record pointing past = 'home.arpa.' The text in -13 says "This would be done simply by not = having a delegation from the 'arpa.' zone." From nobody Wed Aug 30 12:59:41 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EAC126B7E for ; Wed, 30 Aug 2017 12:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 Neki7dDzv6Xv for ; Wed, 30 Aug 2017 12:59:38 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 D542E132A05 for ; Wed, 30 Aug 2017 12:59:33 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id k126so32666602qkb.4 for ; Wed, 30 Aug 2017 12:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DMVHSy26eDrZrGZsLMN4dKz0sxT5lbw5HeL6W2am+Bw=; b=HLi7Pb5rWOss42Ny9zAssRLRMJJjZcGvLFF47VoASdMgoRdwuKmC59vZ/iR3xUZBjz X1ACURs+c9FrRBAuFSMKsk79c6R5FP+Ja82tNGtBz5Gc+8yQQ6yVt7EvqxoV4BZl7vbr Eqkj3LxQybCQvdM+r7Y03kHBtzFPKZ+5qcl18CRfBTkzRZg3TmljEE9PCPwvQDaJfdm2 A+Zj9SgR0N45M8yPPdPiDweJrlNeCgihR09R4NxX6CBtOFr1tEc332nIVgkCniw2/Bwt AKdSXvU2Lrz6QhnwQRomHYIQ/VLBBQZ9jSIdlsQN494ojcwZaefH2nAkiTTdMVP718/T NryA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DMVHSy26eDrZrGZsLMN4dKz0sxT5lbw5HeL6W2am+Bw=; b=I7aJpgue8vcpGNvoi8q1NylaM7k+yY0P52UbSf0RzWEMRdHjD8tTLRQkZELCYd6yUw DdWqRPYVNjS4tcrjJvpeTNI1NgCfHMy9m+PAYu7jRzFnQxH7zBQde1e1B10UrIEMX//u BI5NtLarHd9jKABnb65CYPhXQ0kk3iT3ZOAph4v9ZTKwwGjZB5IfdBWBkkaNWokF2nVl vL4zEYFWzdYN342rCM6CT+OYe3U1rDlDtQ456QQEbTXl86AHp4SmTMYuM0EoV+Rf7rMW pca6kcI3A6jn1w2lIudJ0dJGtuaLNZnQwMVRx+yOUlFLkpdOJ9wjIeJx02OQvRFrYmGR 75NQ== X-Gm-Message-State: AHYfb5jsKNmWefNzQiwa3Il1yFndtkGnUydZ1il7lVWESwYYuY4w6X/5 KNLKL0GOhgcjwi2NV6MO+g== X-Received: by 10.55.204.214 with SMTP id n83mr606536qkl.47.1504123172957; Wed, 30 Aug 2017 12:59:32 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id a63sm4292956qkb.45.2017.08.30.12.59.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 12:59:32 -0700 (PDT) From: Ted Lemon Message-Id: <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EC046B7F-F20A-49A9-A87E-8BA05B33CB26" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 30 Aug 2017 15:59:31 -0400 In-Reply-To: <5C378A81-AB6B-4F2F-8D97-CDED30D788AE@fugue.com> Cc: secdir@ietf.org, HOMENET To: Daniel Migault References: <150307463977.14156.2178189421671973906@ietfa.amsl.com> <5C378A81-AB6B-4F2F-8D97-CDED30D788AE@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Secdir last call review of draft-ietf-homenet-dot-12 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 19:59:40 -0000 --Apple-Mail=_EC046B7F-F20A-49A9-A87E-8BA05B33CB26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 29, 2017, at 10:03 PM, Ted Lemon wrote: > Yes. As far as I know the text gives IANA the information they need = to do; I do not know how they operate their black hole servers, so I am = trusting that these instructions are sufficient. They have been = reviewed by people who understand this problem better than I do, like = Andrew Sullivan, Paul Hoffman and Mark Andrews. I was specifically = advised not to overspecify this. I would rather take their word on = this than yours, if you will forgive my saying so. :) Argh. Warren made me look more closely, and you were right. Sorry = for doubting. :] Here is the new text for the IANA considerations = section: IANA is further requested to create a new subregistry within the = "Locally-Served DNS Zones" registry , titled = "Transport-Independent Locally-Served DNS Zones", with the same format as the other subregistries. IANA = is requested to add an entry in this new registry for 'home.arpa.' with the description = "Homenet Special-Use Domain", listing this document as the reference. --Apple-Mail=_EC046B7F-F20A-49A9-A87E-8BA05B33CB26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 29, 2017, at 10:03 PM, Ted Lemon <mellon@fugue.com> = wrote:
Yes.   As far as I know the = text gives IANA the information they need to do; I do not know how they = operate their black hole servers, so I am trusting that these = instructions are sufficient.   They have been reviewed by people = who understand this problem better than I do, like Andrew Sullivan, Paul = Hoffman and Mark Andrews.   I was specifically advised not to = overspecify this.   I would rather take their word on this than = yours, if you will forgive my saying so. = :)

Argh. =   Warren made me look more closely, and you were right.   = Sorry for doubting.   :]   Here is the new text for the IANA = considerations section:

IANA is further requested to create a new = subregistry within the "Locally-Served DNS
= Zones" = registry <xref target=3D"LSDZ"/>, titled "Transport-Independent = Locally-Served DNS
Zones", with the same format as the other = subregistries.  IANA is requested to add an
entry in this new registry for 'home.arpa.' = with the description "Homenet Special-Use
= Domain", = listing this document as the reference.

= --Apple-Mail=_EC046B7F-F20A-49A9-A87E-8BA05B33CB26-- From nobody Wed Aug 30 14:09:30 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D31132940 for ; Wed, 30 Aug 2017 14:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 73M3k3NvGq6V for ; Wed, 30 Aug 2017 14:09:23 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 60295132A81 for ; Wed, 30 Aug 2017 14:09:23 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id 40so21083768wrv.5 for ; Wed, 30 Aug 2017 14:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4RQ0p+Zj6EvcO493BNvm0WtE5VUmoPGCY/SSFQEznSA=; b=K3NM96kqpb8FpjDILBH9U4H96AGoca+s/X/gVlgvYQGFWrNVOb81uAcAt0kzpIVtPs i+YspPbuENfK3/WgzE1pMuN0oY0daRmhLrFyXcDhavPFsqexepluC/03D1syaDEnCAmv +3zlxqT7qClYUPqajxo8vjGrMXZiJeTYU3Y1gKaaRgbdINSEAGQjLl1rZkDL1nJjimjE mYKeiGAnLeFn2fcyt95NSzoH6jjf8fzkna3fEJEI4WCm/pZtegyUoPa5x1kgybd8V34F Ov88bIJ1G9h1ZQXDVXgoMStwvytdidIKlReP/xrJqYAuFRknX6RvaU/37ZpLP5+k2kOU Wz/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4RQ0p+Zj6EvcO493BNvm0WtE5VUmoPGCY/SSFQEznSA=; b=EWtIWx2UkGOvgZblQzSl/q8ak2vCq55mibziMEJlxEbczK1eS4NHG60v3XwcU3Y05Y 3ssgm4SxlbceiznWHe36eeCkVwyxzZNKQf7z3Tg0jMuSAmXLemKTsa1uu5Tq7j/rKX+P S6WXB7jn+P6uEtA72oXjN2+EQcLB8CoNynv62ls1bY83ZQEqZBehX2ZYJbFfu7ZSrIwH diZtUVVQXZbx4v8+2pZ5DXWzYWHCcD2TucHlb0/MMA2K7AY3U4n7fI1GDR1kWhPf8Aji 1JY3R2LmAhXS0vCBKc604OLgFPWJ66hRFTk+QkxHQHDLmYAaGOAUibD2bqG1kRswP96k tpJA== X-Gm-Message-State: AHYfb5hlcMCVPJJGr3C36pFuVFQyXvs9U9GAxG/MSmy3fbWN/3TwsrOf As6cgg6V5c16Fp9MCV0J7rIG/x5fTtYR X-Received: by 10.223.153.36 with SMTP id x33mr1576669wrb.263.1504127361547; Wed, 30 Aug 2017 14:09:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Wed, 30 Aug 2017 14:08:40 -0700 (PDT) In-Reply-To: <11D94BA1-4B9A-467A-991E-166B17769D09@fugue.com> References: <150412024935.21586.6465698628844336921.idtracker@ietfa.amsl.com> <11D94BA1-4B9A-467A-991E-166B17769D09@fugue.com> From: Warren Kumari Date: Wed, 30 Aug 2017 17:08:40 -0400 Message-ID: To: Ted Lemon Cc: The IESG , draft-ietf-homenet-dot@ietf.org, homenet-chairs@ietf.org, HOMENET , Ray Bellis , Jon Mitchell Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 21:09:27 -0000 Ok, I'm surprised - I spent much time with this review, and felt bad submitting a number of DISCUSS points close to the telechat. I thought that addressing them might end up in this going back to the WG -- but, your (really quick) responses more than adequately addresses my DISCUSS (and major concerns). Thank you, I'm clearing my discuss position -- more inline, but I'm a happy camper. On Wed, Aug 30, 2017 at 3:54 PM, Ted Lemon wrote: > On Aug 30, 2017, at 3:10 PM, Warren Kumari wrote: >> 1: Section 4. Domain Name Reservation Considerations, Subsection 4 >> If I'm a recursive server and I am configured "with a delegation to an >> authoritative server for that particular homenet=E2=80=99s instance of t= he domain >> =E2=80=99home.arpa.=E2=80=99." then I have a local zone containing "home= .arpa IN NS >> ". Unless I'm really confused, this me= ans >> that I have to make myself authoritative for .arpa, which will a: break >> everything else in .arpa, and b: will (correctly!) be DNSSEC bogus to >> validating stubs. (See also #5). Perhaps you mean that there should be >> something like (BINDism): zone "home.arpa" { >> type forward; >> forwarders { 192.0.2.1; 192.0.2.2; }; >> }; >> This possibility only came to me after much thought, and I do not think = that it >> could be described as "a delegation". I also do not think that this is a >> standard / well defined behavior. > > Yup, that's bogus. Is this better? > > In addition to the behavior specified above, recursive re= solvers that can be used in > a homenet MUST be configurable to forward queries for 'ho= me.arpa.' and subdomains of > 'home.arpa.' to an authoritative server for 'home.arpa.'.= This server will provide > authoritative data for 'home.arpa.' within a particular h= omenet. The special > handling for DS records for the 'home.arpa.' delegation i= s still required. Much better, thanks. > > >> 2: Section 4. Domain Name Reservation Considerations, Subsection 4 >> "Caching resolvers conforming to this specification MUST support DNSSEC >> queries." This is a MUST, so it's important to understand, but I don't >> understand what it actually means. What is a "DNSSEC query"? It is just= one >> with the DO bit? It is one looking for a DS / RRSIG / similar as the qty= pe? I >> don't know what this means, so I don't know if it applies to me / what I= should >> do. > > I think this is clarified in the -13 version of the document. Is this r= eview based on that version, or on -12? Here is the new text: > > Recursive resolvers at sites using 'home.arpa.' MUST tran= sparently support > DNSSEC queries: queries for DNSSEC records and queries wi= th the DO bit set > ( section 3.2.1). While valida= tion is not required, it > is strongly encouraged: a caching recursive resolver that= does not validate > answers that can be validated may cache invalid data. Th= is in turn will prevent > validating stub resolvers from successfully validating an= swers. WFM. > >> 3: "Unless configured otherwise, recursive resolvers and DNS proxies MUS= T >> behave as described in Locally Served Zones ([RFC6303] Section 3). That= is, >> queries for domains that are subdomains of =E2=80=99home.arpa.=E2=80=99 = MUST NOT be forwarded, >> with one important exception: ..." This says that I must not forward for >> *domains* that are *subdomains* of home.arpa. The example shows a lookup= for NS >> for 'home.arpa', so presumably this is actually talking about subdomains= of >> home.arpa. So, I have no idea what to do for lookups within home.arpa i= tself >> -- what do I do with query for the A record for printer.home.arpa? It is= simply >> a name within home.arpa; I have no way of knowing if it is a subdomain o= f >> home.arpa but it certainly isn't a domain that is a subdomain of home.ar= pa >> (because there are only three label, not four). > > Yes, the other text had the same problem. How about "queries for 'home.= arpa.' and subdomains of 'home.arpa.'"? WFM. Thanks. > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Major issues: >> >> 1: I think that this document could benefit from additional review in th= e DNSOP >> WG - it got some >> (https://www.ietf.org/mail-archive/web/dnsop/current/msg19620.html), but= that >> was a: while it was still homenet. b: primarily focused in terms of RFC6= 761 and >> not on the whole systems / interaction with existing behaviors, c: large= ly >> devolved into "does this do go in the root zone or not"?, d: 9 revisions= back. >> The document feels vague about much of the details / expected behavior f= rom all >> of the different players, and I think more focused review from more DNS = people >> would help. > > I disagree. The document has had substantial review from DNSOP people, = including recently. They are mentioned in the acknowledgments. I think = that I've fixed a couple of the things in -13 that triggered this reaction.= In particular: > >> 2: What is a "caching resolver"? It is the same as a "recursive resolver= "? Or >> is it a "full-service resolver"? The fact that the answer to RFC6761 Q4 = uses >> both terms makes me think that they are different, but I don't know how. > > The term "caching resolver" was carried over from 6761. What is meant h= ere is "recursive resolver" or "full service resolver," which I think are s= ynonyms. I updated the text to take out "caching", since "resolver" clear= ly has an antecedent of "recursive resolver" and I don't think needs to be = qualified in this way twice in the same paragraph. Also WFM. > >> 3: The document says: "Unless configured otherwise, recursive resolvers = and DNS >> proxies MUST behave as described in Locally Served Zones ([RFC6303] Sect= ion >> 3).", but I do not see this being added to the locally served zones regi= stry. >> This was raised in a previous review (Jon Mitchell, OpsDir (for v03) >> https://datatracker.ietf.org/doc/review-ietf-homenet-dot-03-opsdir-early= -mitchell-2017-03-18/ >> ), and not implemented. I'm assuming there is a reason, but I haven't fo= und the >> discussion. > > Because I was being lazy and didn't actually chase down what Dale had sai= d to see that indeed it was necessary. Hey, at least y'er honest :-) > I've added this to IANA Considerations: > > IANA is further requested to create a new subregistry within the = "Locally-Served DNS > Zones" registry , titled "Transport-Indepe= ndent Locally-Served DNS > Zones", with the same format as the other subregistries. IANA is= requested to add an > entry in this new registry for 'home.arpa.' with the description = "Homenet Special-Use > Domain", listing this document as the reference. Again, WFM. > >> 4: The document describes what recursive servers should do with queries = for >> things in home.arpa, but seems to gloss over some detail -- I think that= the >> document would benefit from an overview showing the stub (and / or valid= ating >> stub), an internal recursive / proxy, an external recursive, the local >> authoritative for home.arpa, and the .arpa servers, and clearly explain = what >> the expected behavior / role for each one under various scenarios is. > > Could you look at the -13 version of the document, with the changes I pro= vided for your DISCUSS, and see if you still think this is necessary? The= bulk of what you are requesting is really out of scope for the original in= tended purpose of this document. I agree that more detail is needed, but = the plan was to document that in a document that was under less time pressu= re. Will do. These are only comments, so not blocking anyway -- if the plan is to sometime flesh out in another document, also, WFM. > >> 5: Even with the above answered, I remain confused by the "what does a >> recursive resolver do" bit -- this discusses what a recursive server sho= uld do >> with a DS query for home.arpa - this (obviously) exists to prevent DNSSE= C >> validating stubs from believing that foo.home.arpa is bogus. It also mea= ns that >> it is expected that queries from stubs will sometimes arrive at these re= cursive >> resolvers (and they "MUST behave as described in Locally Served Zones" i= s not >> simply to prevent pollution). If a query for printer.bedroom.home.arpa d= oes >> arrive at a recursive, and it is configured as a locally served zone, it= will >> return NXDOMAIN. This (obviously) breaks the lookup for >> printer.bedroom.home.arpa, but RFC8020 (" NXDOMAIN: There Really Is Noth= ing >> Underneath ") also says that this means that nothing exists in >> bedroom.home.arpa - I think that there needs to be some more text descri= bing >> the deployment, and which set of queries go where. > > All of the relevant DNS protocol agents are expected to behave as normal,= with the stated exceptions. As the document says, stubs are expected to = send queries to whatever recursive resolvers are configured by the network.= On a normal network, the resolver would indeed respond with NXDOMAIN, an= d this would be correct. This is the specified, and intended, behavior. > > If the local recursive resolver is a homenet resolver, it's expected to d= ivert queries for home.arpa, except the DS record, to the local server auth= oritative for home.arpa. That server will provide answers which will vali= date, because the DS record provably doesn't exist. > >> 6: Section 7. Delegation of =E2=80=99home.arpa.=E2=80=99 >> This delegation MUST NOT include a DS record, and MUST point to one or m= ore >> black hole servers, for example =E2=80=99blackhole-1.iana.org.=E2=80=99 = and =E2=80=99blackhole- >> 2.iana.org.=E2=80=99. I fully agree with the DS bit, but the "blackhole"= bit feels VERY >> hand-wavey. Currently a lookup for home.arpa to these returns REFUSED in= stead >> of NXDOMAIN: $ dig +nostat +nocmd home.arpa @blackhole-2.iana.org ;; Got >> answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 7826 ;; flag= s: qr >> rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursi= on >> requested but not available >> >> ;; QUESTION SECTION: >> ;home.arpa. IN A >> >> The document just delegates this to =E2=80=99blackhole-1.iana.org.=E2=80= =99 and =E2=80=99blackhole- >> 2.iana.org.=E2=80=99 - they're are not authoritative for home.arpa (and = nothing in the >> doc makes them so), and so this does not return NXDOMAIN and instead amp= lifies >> the query load. Delegating them to RFC7535 servers *may* help, but I'm n= ot sure. > > We were specifically asked to trust that IAB/IANA would deal with this, a= nd to not put explicit operator instructions in the document. I agree tha= t those two servers need configuration changes; this is up to the IAB and I= ANA (as their operator) to make happen. Okey dokey. Didn't know the "specifically asked" bit, I'll trust $whoever_asked has a reason. > >> 7: "In addition to the behavior specified above, recursive resolvers tha= t can >> be used in a homenet MUST be configurable with a delegation to an >> authoritative server for that particular homenet=E2=80=99s instance of t= he domain >> =E2=80=99home.arpa.=E2=80=99." -- Ok, but how does this interact with t= he requirements on >> local-zones? I'm *guessing* it overrides it, and if I get a query for >> printer.livingroom.home.arpa I should "forward" it to the authoritative >> servers? The document also seems > > I think you left that sentence unfinished, but perhaps the new text I pro= pose above for this bit helps? Hey, it is! (I copied and pasted from an earlier draft of comments...) -- your text above solves much of these issues. > >> Minor issues / nits: >> 1: Section 1. Introduction. >> "A default name with a scope limited to each individual homenet needs to= be >> used." -- I don't understand the "needs to be used" - perhaps "needs to = be >> defined"? Otherwise it sounds like, if the ISP delegates a name, >> implementations must ignore it. Adding "In these cases," to the beginnin= g of >> this sentence may clarify. > > How about: > > Users and devices within a home network (hereafter "homenet") req= uire devices and > services to be identified by names that are unique within the bou= ndaries of the homenet > . The naming mechanism needs to functio= n without configuration > from the user. While it may be possible for a name to be delegate= d by an ISP, homenets > must also function in the absence of such a delegation. This doc= ument reserves the > name 'home.arpa.' to serve as the default name for this purpose, = with with a scope > limited to each individual homenet. > Poifect! >> 2: "No such process is available for requesting a similar delegation in = the >> root" -- I think this would be better as "No such process is *currently* >> available...." > > The IAB has made it pretty clear that they do not intend for such a proce= ss to ever be available, in the sense that they do not wish to open a discu= ssion with ICANN with the purpose of creating such a process. I can leave= the door open here anyway if you want, but that's why the text reads the w= ay it does. I think an early version actually said "currently," but I may= be mistaken. > Ok. I predict that there will be a process at some point, but I'll just reserve the right to say "I told you so!!!!" then :-) >> 3: Section 3. General Guidance >> " Names ending with =E2=80=99.home.arpa.=E2=80=99 reference a locally-se= rved zone," -- the term >> "locally-served zone" has specific meaning in the DNS context - see >> https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-05. I'd sug= gest >> clarifying that this is not what you mean here. > > The text in terminology-bis gives exactly the intended meaning. I disagree! Ok. You are 100% correct. I'd always viewed "locally-served zone" as "those things in RFC6303 / which recursives serve an empty zone for", but I new see the definition. To save others from equal embarrassment is may be worth pointing at this definition (or not). > >> 4: Section 4. Domain Name Reservation Considerations >> It seems that a number of readers didn't get that this next bit is to an= swer >> the questions from 6761 - I'd suggest something like: >> "This section contains answers to the questions posed in Section 5 of >> RFC6761 and define the behavior of systems involved in domain name >> resolution when resolving queries for names ending with =E2=80=99.home= .arpa.=E2=80=99. > > I've proposed the following text in response to Adam's comment: > > This section specifies considerations for systems involved in dom= ain name resolution > when resolving queries for names ending with '.home.arpa.'. Each= item in this section > addresses some aspect of the DNS or the process of resolving doma= in names that would be > affected by this special use allocation. Detailed explanations o= f these items can be > found in , Section 5. > WFM. >> 5: " ... zone, the client may be unable to resolve, or may receive inco= rrect >> results for, names in sub domains of =E2=80=99home.arpa.=E2=80=99." -- "= names in sub domains of >> 'home.arpa.'" are things like foo.bar.home.arpa -- do you just mean "nam= es in >> 'home.arpa'" ? > > How about: > > A host that is configured to use a resolver other than one th= at has been provided by > the local network may be unable to resolve, or may receive in= correct results for, > subdomains of 'home.arpa.'. > > I try to avoid using "in" to mean "subdomain of" because it feels impreci= se. Ok. > >> 6: "a query for a DS record when the DO bit ([RFC4035] section 3.2.1) se= t MUST >> return " -- missing "is" after the closing parens? > > Changed "when" to "with". Oh! That's better. > >> 7: Section 6 - Security Considerations >> "To prevent this from happening, it may be useful for the resolver to id= entify >> different homenets on which it has resolved names, but this is out of sc= ope for >> this document." -- is this a stub resolver? recursive? both? > > Good point. The resolver on the host. I hesitate to say "stub resolve= r" because it might not be a stub resolver. I changed it to "the resolver= on the host." WFM. > >> 8: "An alternative would be to install a authenticated denial of existen= ce >> ([RFC4033] Section 3.2)." -- 1: *an* authenticated and 2: "authenticated= denial >> of existence *record*" (I think. I'm not quite sure on the wording here,= and >> suspect it would need more text, like "DNSSEC records proving authentica= ted >> denial of existence.") > > .arpa doesn't use NSEC3. So there is no record specific to 'home.arpa.'= =E2=80=94there's just an NXT record pointing past 'home.arpa.' The text i= n -13 says "This would be done simply by not having a delegation from the '= arpa.' zone." WFM. > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Aug 30 14:10:31 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88878132A90; Wed, 30 Aug 2017 14:10:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-homenet-dot@ietf.org, Ray Bellis , homenet-chairs@ietf.org, ray@bellis.me.uk, homenet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150412742455.21586.6888949775762296619.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 14:10:24 -0700 Archived-At: Subject: [homenet] Warren Kumari's No Objection on draft-ietf-homenet-dot-13: (with COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 21:10:24 -0000 Warren Kumari has entered the following ballot position for draft-ietf-homenet-dot-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This was originally a DISCUSS, but Ted nicely (and quickly!) addressed my concerns - clearing. Major issues: 1: I think that this document could benefit from additional review in the DNSOP WG - it got some (https://www.ietf.org/mail-archive/web/dnsop/current/msg19620.html), but that was a: while it was still homenet. b: primarily focused in terms of RFC6761 and not on the whole systems / interaction with existing behaviors, c: largely devolved into "does this do go in the root zone or not"?, d: 9 revisions back. The document feels vague about much of the details / expected behavior from all of the different players, and I think more focused review from more DNS people would help. 2: What is a "caching resolver"? It is the same as a "recursive resolver"? Or is it a "full-service resolver"? The fact that the answer to RFC6761 Q4 uses both terms makes me think that they are different, but I don't know how. 3: The document says: "Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3).", but I do not see this being added to the locally served zones registry. This was raised in a previous review (Jon Mitchell, OpsDir (for v03) https://datatracker.ietf.org/doc/review-ietf-homenet-dot-03-opsdir-early-mitchell-2017-03-18/ ), and not implemented. I'm assuming there is a reason, but I haven't found the discussion. 4: The document describes what recursive servers should do with queries for things in home.arpa, but seems to gloss over some detail -- I think that the document would benefit from an overview showing the stub (and / or validating stub), an internal recursive / proxy, an external recursive, the local authoritative for home.arpa, and the .arpa servers, and clearly explain what the expected behavior / role for each one under various scenarios is. 5: Even with the above answered, I remain confused by the "what does a recursive resolver do" bit -- this discusses what a recursive server should do with a DS query for home.arpa - this (obviously) exists to prevent DNSSEC validating stubs from believing that foo.home.arpa is bogus. It also means that it is expected that queries from stubs will sometimes arrive at these recursive resolvers (and they "MUST behave as described in Locally Served Zones" is not simply to prevent pollution). If a query for printer.bedroom.home.arpa does arrive at a recursive, and it is configured as a locally served zone, it will return NXDOMAIN. This (obviously) breaks the lookup for printer.bedroom.home.arpa, but RFC8020 (" NXDOMAIN: There Really Is Nothing Underneath ") also says that this means that nothing exists in bedroom.home.arpa - I think that there needs to be some more text describing the deployment, and which set of queries go where. 6: Section 7. Delegation of ’home.arpa.’ This delegation MUST NOT include a DS record, and MUST point to one or more black hole servers, for example ’blackhole-1.iana.org.’ and ’blackhole- 2.iana.org.’. I fully agree with the DS bit, but the "blackhole" bit feels VERY hand-wavey. Currently a lookup for home.arpa to these returns REFUSED instead of NXDOMAIN: $ dig +nostat +nocmd home.arpa @blackhole-2.iana.org ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 7826 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;home.arpa. IN A The document just delegates this to ’blackhole-1.iana.org.’ and ’blackhole- 2.iana.org.’ - they're are not authoritative for home.arpa (and nothing in the doc makes them so), and so this does not return NXDOMAIN and instead amplifies the query load. Delegating them to RFC7535 servers *may* help, but I'm not sure. 7: "In addition to the behavior specified above, recursive resolvers that can be used in a homenet MUST be configurable with a delegation to an authoritative server for that particular homenet’s instance of the domain ’home.arpa.’." -- Ok, but how does this interact with the requirements on local-zones? I'm *guessing* it overrides it, and if I get a query for printer.livingroom.home.arpa I should "forward" it to the authoritative servers? The document also seems Minor issues / nits: 1: Section 1. Introduction. "A default name with a scope limited to each individual homenet needs to be used." -- I don't understand the "needs to be used" - perhaps "needs to be defined"? Otherwise it sounds like, if the ISP delegates a name, implementations must ignore it. Adding "In these cases," to the beginning of this sentence may clarify. 2: "No such process is available for requesting a similar delegation in the root" -- I think this would be better as "No such process is *currently* available...." 3: Section 3. General Guidance " Names ending with ’.home.arpa.’ reference a locally-served zone," -- the term "locally-served zone" has specific meaning in the DNS context - see https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-05. I'd suggest clarifying that this is not what you mean here. 4: Section 4. Domain Name Reservation Considerations It seems that a number of readers didn't get that this next bit is to answer the questions from 6761 - I'd suggest something like: "This section contains answers to the questions posed in Section 5 of RFC6761 and define the behavior of systems involved in domain name resolution when resolving queries for names ending with ’.home.arpa.’. 5: " ... zone, the client may be unable to resolve, or may receive incorrect results for, names in sub domains of ’home.arpa.’." -- "names in sub domains of 'home.arpa.'" are things like foo.bar.home.arpa -- do you just mean "names in 'home.arpa'" ? 6: "a query for a DS record when the DO bit ([RFC4035] section 3.2.1) set MUST return " -- missing "is" after the closing parens? 7: Section 6 - Security Considerations "To prevent this from happening, it may be useful for the resolver to identify different homenets on which it has resolved names, but this is out of scope for this document." -- is this a stub resolver? recursive? both? 8: "An alternative would be to install a authenticated denial of existence ([RFC4033] Section 3.2)." -- 1: *an* authenticated and 2: "authenticated denial of existence *record*" (I think. I'm not quite sure on the wording here, and suspect it would need more text, like "DNSSEC records proving authenticated denial of existence.") -- Original DISCUSS for posterity -- 1: Section 4. Domain Name Reservation Considerations, Subsection 4 If I'm a recursive server and I am configured "with a delegation to an authoritative server for that particular homenet’s instance of the domain ’home.arpa.’." then I have a local zone containing "home.arpa IN NS ". Unless I'm really confused, this means that I have to make myself authoritative for .arpa, which will a: break everything else in .arpa, and b: will (correctly!) be DNSSEC bogus to validating stubs. (See also #5). Perhaps you mean that there should be something like (BINDism): zone "home.arpa" { type forward; forwarders { 192.0.2.1; 192.0.2.2; }; }; This possibility only came to me after much thought, and I do not think that it could be described as "a delegation". I also do not think that this is a standard / well defined behavior. 2: Section 4. Domain Name Reservation Considerations, Subsection 4 "Caching resolvers conforming to this specification MUST support DNSSEC queries." This is a MUST, so it's important to understand, but I don't understand what it actually means. What is a "DNSSEC query"? It is just one with the DO bit? It is one looking for a DS / RRSIG / similar as the qtype? I don't know what this means, so I don't know if it applies to me / what I should do. 3: "Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3). That is, queries for domains that are subdomains of ’home.arpa.’ MUST NOT be forwarded, with one important exception: ..." This says that I must not forward for *domains* that are *subdomains* of home.arpa. The example shows a lookup for NS for 'home.arpa', so presumably this is actually talking about subdomains of home.arpa. So, I have no idea what to do for lookups within home.arpa itself -- what do I do with query for the A record for printer.home.arpa? It is simply a name within home.arpa; I have no way of knowing if it is a subdomain of home.arpa but it certainly isn't a domain that is a subdomain of home.arpa (because there are only three label, not four). From nobody Wed Aug 30 16:20:12 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EBA13243A; Wed, 30 Aug 2017 16:20:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-homenet-dot@ietf.org, Ray Bellis , homenet-chairs@ietf.org, ray@bellis.me.uk, homenet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150413520708.16860.14531912464478386147.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 16:20:07 -0700 Archived-At: Subject: [homenet] Eric Rescorla's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 23:20:07 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-homenet-dot-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- A. Recursive resolvers at sites using 'home.arpa.' MUST transparently support DNSSEC queries: queries for DNSSEC records and queries with the DO bit set ([RFC4035] section 3.2.1). While validation is not required, it is strongly encouraged: a caching recursive resolver that does not validate answers that can be validated may cache invalid data. This in turn will prevent validating stub resolvers from successfully validating answers. I don't understand the rationale for this requirement. As I understand it from this document, stuff ending in home.arpa cannot be DNSSEC validated, so what's it the business of this document to levy the requirement on sites which support home.arpa that they do anything with DNSSEC at all. From nobody Wed Aug 30 19:35:08 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA02132620 for ; Wed, 30 Aug 2017 19:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 C90skxpl16X8 for ; Wed, 30 Aug 2017 19:35:01 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C921323B8 for ; Wed, 30 Aug 2017 19:35:01 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id nFJsdq8rl3nDonFJsd65wV; Thu, 31 Aug 2017 02:35:00 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-01v.sys.comcast.net with SMTP id nFJqdanuqJ7dKnFJqdpNF6; Thu, 31 Aug 2017 02:34:59 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v7V2YvQB023106; Wed, 30 Aug 2017 22:34:57 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v7V2YuUw023103; Wed, 30 Aug 2017 22:34:56 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Ted Lemon Cc: gen-art@ietf.org, draft-ietf-homenet-dot.all@ietf.org, homenet@ietf.org In-Reply-To: <4B072264-2824-4433-A24D-DF5D2FD5A085@fugue.com> (mellon@fugue.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 30 Aug 2017 22:34:56 -0400 Message-ID: <87k21kforz.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCkb7H/HtkFJM3Fg6AdV5aGHulRKVD1zZowYT9+JLvGyGFkNzEXmybJRxMKmRKuPqw/M9qPc+zwi7CvgeKOpmsbTApBLTeVtJwroOZ8fZxcGq0QGJAsO VYIUVg5ZHjRia5rRq494WFDIg8kPsivjUEbYsz1ADpd4dsMzLfhgLB5mDY+oO3yi+T3LNB8TNaVGlCx5bhcy/VCALXp5DFPp6xcnUwJktrHxuOZlpznvHZj8 f4Ti4lvKk884ru/oh46qlisWiez7husbdfhdUcIZTW0= Archived-At: Subject: Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 02:35:03 -0000 Ted Lemon writes: > I've updated the document to separate this out into three lettered > subheads. We can't change the numbering, because that's required by > RFC 6761, but I agree that it's clearer if the three separate topics > are split out. I hadn't realized from the draft that the items in section 4 are meant to parallel the items in section 5 of RFC 6761, since the connecting text is only "(as per [RFC 6761])". Perhaps it would help to amplify that to "(per the template in [RFC 6761] section 5)". Dale From nobody Wed Aug 30 19:42:20 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526781329A8 for ; Wed, 30 Aug 2017 19:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 r0Ib2Jhidb1u for ; Wed, 30 Aug 2017 19:42:16 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 9790D132925 for ; Wed, 30 Aug 2017 19:42:16 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id r62so24441147pfj.0 for ; Wed, 30 Aug 2017 19:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gSOhKXyZ1tSoVXkCeWS0xBBrVUC/O/Rhhg6Qghn4+P8=; b=aRs+jOPhWpy/cAK2FNtEtZOu38dYmNQVRUMVSdHAsnXDsb6d74oLsm32ACR8Cv8DPC t/Uo7BPeiypUwX3pUDlzhjJq4rgFL7fuVkyaByw/3q4EnxvD5NO60tv6gVvC8IlGs2/9 lq9Mg9fIwJ7/kZugDveX4clUtNt/uHlSpOwOCQ2YhRJsQu98RY9tE8WQ9/A6Ihd+4JLE 4cqP4dY0EKVisqV4p2pYAPz19HkESg673eRSG9J0m0miWJVclsIa6ii95cGroExL6Lca lpOoFi1B7MC5n6NQ5nwEnJKlUN/plA0QBqNltZjLnEyq5VbS3XVtUyNi/cMvQ+m2zf6P lWTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gSOhKXyZ1tSoVXkCeWS0xBBrVUC/O/Rhhg6Qghn4+P8=; b=sJSukVFAU8X4x2jGeCXtO58VJyp1hhmGCg3y8e3gj1yDo2gkIhkoPYeAeXs0T0f68o 3iQupG05yiA1PB89UB0zRScD2dyeAZsR79epQCxcoT9OS0q6elxuPJwqEWcBT4/S+Ep/ 59XCDXMRxb8FZzb+0XPS+6QC5abb3zn2X5xZ5afN27/8xbdXpnsMemRNZT5J2h/oIegY j7paxevRWGWnyMSiADA8IeFnvQIenhLErjptfkbZxu8gVCWKhtx+9O6oyD5vOLsAq+tw opGuj7v7g3fMl4cl7+5F7MWIm/1gMKEnvU31OETqFZhfVXFf4VOT6t2FJQQ0LZ6suKdJ V2lw== X-Gm-Message-State: AHYfb5g954C8CbzJng+J0EMlhI0KL1+l3Z91FJ56+4qUbO/5605jV/Nq AnK5pVCe99RrvAZFO6kwb+4Nk2xOoL5p X-Received: by 10.84.215.206 with SMTP id g14mr839019plj.357.1504147336110; Wed, 30 Aug 2017 19:42:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.152.98 with HTTP; Wed, 30 Aug 2017 19:41:35 -0700 (PDT) In-Reply-To: <87k21kforz.fsf@hobgoblin.ariadne.com> References: <4B072264-2824-4433-A24D-DF5D2FD5A085@fugue.com> <87k21kforz.fsf@hobgoblin.ariadne.com> From: Ted Lemon Date: Wed, 30 Aug 2017 22:41:35 -0400 Message-ID: To: "Dale R. Worley" Cc: gen-art@ietf.org, draft-ietf-homenet-dot.all@ietf.org, HOMENET Content-Type: multipart/alternative; boundary="f403045c7b12a8bb6c05580397f8" Archived-At: Subject: Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 02:42:19 -0000 --f403045c7b12a8bb6c05580397f8 Content-Type: text/plain; charset="UTF-8" Yup, Adam Roach caught that as well and the document will be updated with some new text: This section specifies considerations for systems involved in domain name resolution when resolving queries for names ending with '.home.arpa.'. Each item in this section addresses some aspect of the DNS or the process of resolving domain names that would be affected by this special use allocation. Detailed explanations of these items can be found in , Section 5. On Wed, Aug 30, 2017 at 10:34 PM, Dale R. Worley wrote: > Ted Lemon writes: > > I've updated the document to separate this out into three lettered > > subheads. We can't change the numbering, because that's required by > > RFC 6761, but I agree that it's clearer if the three separate topics > > are split out. > > I hadn't realized from the draft that the items in section 4 are meant > to parallel the items in section 5 of RFC 6761, since the connecting > text is only "(as per [RFC 6761])". Perhaps it would help to amplify > that to "(per the template in [RFC 6761] section 5)". > > Dale > --f403045c7b12a8bb6c05580397f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yup, Adam Roach caught that as well and the document will = be updated with some new text:

	This section specifies co=
nsiderations for systems involved in domain name resolution
	when resolving queries for names ending with '.home.arpa.'.  Each =
item in this section
	addresses some aspect of the DNS or the process of resolving domain names =
that would be
	affected by this special use allocation.  Detailed explanations of these i=
tems can be
	found in <xref target=3D"RFC6761"/>, Section 5.

On Wed, Au= g 30, 2017 at 10:34 PM, Dale R. Worley <worley@ariadne.com>= wrote:
Ted Lemon <mellon@fugue.com> writes:
> I've updated the document to separate this out into three lettered=
> subheads.=C2=A0 =C2=A0We can't change the numbering, because that&= #39;s required by
> RFC 6761, but I agree that it's clearer if the three separate topi= cs
> are split out.

I hadn't realized from the draft that the items in section 4 are= meant
to parallel the items in section 5 of RFC 6761, since the connecting
text is only "(as per [RFC 6761])".=C2=A0 Perhaps it would help t= o amplify
that to "(per the template in [RFC 6761] section 5)".

Dale

--f403045c7b12a8bb6c05580397f8-- From nobody Thu Aug 31 00:49:33 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51901320D9; Thu, 31 Aug 2017 00:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 vBe-JsMnZ77K; Thu, 31 Aug 2017 00:49:31 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9FB1320B5; Thu, 31 Aug 2017 00:49:31 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 263D83494AF; Thu, 31 Aug 2017 07:49:24 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 13B4B160044; Thu, 31 Aug 2017 07:49:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E7AD2160053; Thu, 31 Aug 2017 07:49:23 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RWv2cLCSIFtI; Thu, 31 Aug 2017 07:49:23 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 90CB7160044; Thu, 31 Aug 2017 07:49:23 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EFC3B83DAC59; Thu, 31 Aug 2017 17:49:20 +1000 (AEST) To: Ted Lemon Cc: Daniel Migault , HOMENET , secdir@ietf.org From: Mark Andrews References: <150307463977.14156.2178189421671973906@ietfa.amsl.com> <5C378A81-AB6B-4F2F-8D97-CDED30D788AE@fugue.com> <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com> In-reply-to: Your message of "Wed, 30 Aug 2017 15:59:31 -0400." <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com> Date: Thu, 31 Aug 2017 17:49:20 +1000 Message-Id: <20170831074920.EFC3B83DAC59@rock.dv.isc.org> Archived-At: Subject: Re: [homenet] Secdir last call review of draft-ietf-homenet-dot-12 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 07:49:33 -0000 In message <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com>, Ted Lemon writes: > > On Aug 29, 2017, at 10:03 PM, Ted Lemon wrote: > > Yes. As far as I know the text gives IANA the information they need > > to do; I do not know how they operate their black hole servers, so I am > > trusting that these instructions are sufficient. They have been > > reviewed by people who understand this problem better than I do, like > > Andrew Sullivan, Paul Hoffman and Mark Andrews. I was specifically > > advised not to overspecify this. I would rather take their word on this > > than yours, if you will forgive my saying so. :) > > Argh. Warren made me look more closely, and you were right. Sorry for > doubting. :] Here is the new text for the IANA considerations section: > > IANA is further requested to create a new subregistry within the > "Locally-Served DNS Zones" registry , titled > "Transport-Independent Locally-Served DNS Zones", with the same > format as the other subregistries. IANA is requested to add an > entry in this new registry for 'home.arpa.' with the description > "Homenet Special-Use Domain", listing this document as the reference. It is up to IANA as to how they implement the delegation. We just specify the requirements (insecure delegation to a empty zone). We don't need to prescribe *where* leaked traffic is sunk. IANA has decades of experience with moving traffic flows if needed. The simplest delegation is back to the servers for .arpa. The servers can be updated by IANA if/when they need to sink the traffic somewhere else. The AS112 server however not the set of servers to sink the traffic too as they are not under IANA's control and there is no way to get them all to serve home.arpa. If there is another round I would remove , and MUST point to one or more black hole servers, for example 'blackhole-1.iana.org.' and 'blackhole- 2.iana.org.' as it is a over specification. Just let IANA manage it. B.T.W. blackhole-1.iana.org and blackhole-2.iana.org aren't really blackholes as they respond to queries. Operators if blackhole-1.iana.org and blackhole-2.iana.org are required to ensure that they do answer and to withdraw routing anouncements for them when they fail to do so. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Aug 31 04:32:52 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C31132D60 for ; Thu, 31 Aug 2017 04:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 qaBswXBcZU9x for ; Thu, 31 Aug 2017 04:32:44 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 37E46132D5F for ; Thu, 31 Aug 2017 04:32:42 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id u11so1561866qtu.1 for ; Thu, 31 Aug 2017 04:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XzYoKjdkYY8KC+ausGT3XQEVT06A0lz1n+DLyE9Pt9M=; b=fUqEcuIjzUPxgRGnGVi+ajEwV6TBgI5TV6piv4OtuSjPnwNJB81vWe9tC+EIk1owPG UcnmcZlwrz/Nx64TuBJuBz0hCK+gy5+Eolc0XwKqT+KvKVUokApyNJ0XH3+8oESaprQm BciIAg+7Y/YouSCEiQ6A2wl5CcjTC5iyOZAPwBEKyj71jnzfnRTHK7fmBAnblAJJhmdP kk73GXqZ88L1KFhUR8GNlzOiD/0Ohss+yFRaCLhDNbG9l4fRS5k+Dp99jPclt9J7Yf58 xZRk/DVxbtycDnnL0Y65XZkCC3p/hgyTGtQ28ktv8WEs0w1ni5Tj1K+He1VoUoUybXdE aa9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XzYoKjdkYY8KC+ausGT3XQEVT06A0lz1n+DLyE9Pt9M=; b=m23n1TI1pNt04HhlmwGTyjiUABe2o3v2Biq6RUXFGtZIagGBOSwX8BeqT/UvaZICC7 QA9VcoCcxx4TD5U/Tuyn5nJ5Z1q20na2ftRAS3xnWuSqHVlgkUYgV7sjzXVAKGOTm9no AxRkNrEsVe7EGoWXyjd18Clo9ut9o6thGGT0PLZOIaBQwSH3g0QqjzTxM+OKkPMNQPI/ NkcHbgeJ8FpoYVtj21PjYBw4t38TXZSe/1JWbOBrprNnZv1nlWdEy3ZY4rYsQ9tdppWF vKrX7fDm3unSnYDcKDNbwPpo124NwkqeTJmoTkWWxjYtyysiOO7PjWhMdJO26WpPxM2/ 5pjg== X-Gm-Message-State: AHYfb5hcEoxU+1hb3lTdDXkxzUjB4QMuGwV6bgBnp66bqOtXBC2UJqaq giDBmASHl0N+ZNl7 X-Received: by 10.200.23.236 with SMTP id r41mr6751021qtk.160.1504179161414; Thu, 31 Aug 2017 04:32:41 -0700 (PDT) Received: from cavall.w50.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id j185sm5124884qkf.62.2017.08.31.04.32.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 04:32:40 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4D9348B0-ACB1-4351-B8C8-BFFCDCF39413" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 31 Aug 2017 07:32:38 -0400 In-Reply-To: <20170831074920.EFC3B83DAC59@rock.dv.isc.org> Cc: Daniel Migault , HOMENET , secdir@ietf.org To: Mark Andrews References: <150307463977.14156.2178189421671973906@ietfa.amsl.com> <5C378A81-AB6B-4F2F-8D97-CDED30D788AE@fugue.com> <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com> <20170831074920.EFC3B83DAC59@rock.dv.isc.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Secdir last call review of draft-ietf-homenet-dot-12 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:32:45 -0000 --Apple-Mail=_4D9348B0-ACB1-4351-B8C8-BFFCDCF39413 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Aug 31, 2017, at 3:49 AM, Mark Andrews wrote: > as it is a over specification. Just let IANA manage it. This makes sense--thanks! --Apple-Mail=_4D9348B0-ACB1-4351-B8C8-BFFCDCF39413 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 31, 2017, at 3:49 AM, Mark Andrews <marka@isc.org> = wrote:
as it is a over = specification.  Just let IANA manage it.

This = makes sense--thanks!

= --Apple-Mail=_4D9348B0-ACB1-4351-B8C8-BFFCDCF39413-- From nobody Thu Aug 31 06:52:40 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C36A4132D87; Thu, 31 Aug 2017 06:52:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-homenet-dot@ietf.org, Ray Bellis , homenet-chairs@ietf.org, ray@bellis.me.uk, homenet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150418755679.16776.2244408640678371841.idtracker@ietfa.amsl.com> Date: Thu, 31 Aug 2017 06:52:36 -0700 Archived-At: Subject: [homenet] Benoit Claise's No Objection on draft-ietf-homenet-dot-13: (with COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 13:52:37 -0000 Benoit Claise has entered the following ballot position for draft-ietf-homenet-dot-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "As a result, the use of '.home' is deprecated." I had to double-checked that .home was NOT in https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml .home was specified/requested in RFC7788 but never requested to IANA according to RFC6761. If mentioned in the draft, this info might help others... From nobody Thu Aug 31 07:11:54 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301CF132D8F for ; Thu, 31 Aug 2017 07:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 sUURRVtR2Tdp for ; Thu, 31 Aug 2017 07:11:49 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 B45E0132DF9 for ; Thu, 31 Aug 2017 07:11:49 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id u11so3432261qtu.1 for ; Thu, 31 Aug 2017 07:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vuNek2amyfDCG3dO850LPaa5vs7QAS3M00JE9Q9H8Ts=; b=p8bKgOjjIPF9TqajBeGCyi57YuV1gK7IlH0WFAiWojEbOXOAtLBSSR5nY3Gv9RfF50 c/wgxm4IO9gZqahriJpWB1TsBGrcMapix9lOqxJnZunQg+S8XURJfhfeS78ei4vGbwUZ tVG4BowDl3ZwBrPZXwYcgKQexx7fyuhUzNVsN6A7aDw989J8dnzqTyUg8mV05tmXLmcW ciO9fI0RZDN1hhrV3HR/wNB6V7QSlP5vc5pkPnHkdTT16nk6H07lLBBJ7VuA0WGTVNiW lU38CvYqh1vYN16bKwfZ15KnbT1wWCO9LKF0d4gkIXv3+nm5M1HAvlfluGmLa6Yj4OaZ BjaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vuNek2amyfDCG3dO850LPaa5vs7QAS3M00JE9Q9H8Ts=; b=uliPvik1/zh30GpUl0XvPqOUKdtD04iqHVpVMm/mQOu/eziuOQ1tMzxJXhORmP82Eu keTGBDxb9okWZNo9b4ZbnWjZ9e8ESHxsMHxcBkjJbc0WguGD3R46hZ54QmbLLsk8aYOd g/DphA0cUyutRwXcNTO8Ks5gB9GavUrPsK9ojGthqepNVCP/s6qRvgwjCLFk4r29Tm9L x5u6my9r9P235z4qKc5N/ozC6B1vQm2U+m1pQqzmwElHXo7CI/HEmf8X+mgf2pjKxDnu tCBsiP29QpO1yeZRkwh8fvI+p6PMtcOmRu17HpHB+dtCe5bMIOFIfQEhtchx0SlDzESg 7hAg== X-Gm-Message-State: AHPjjUheb/7D8ePf/yG2uTvzxYU4/2E5R7Imv79tgFiPWad/I+i2DxzZ R4oMdhMMAvkvI+QEF2Rang== X-Google-Smtp-Source: ADKCNb6zWT1RkSmweMgbKqRYpyGT31LZOsCaju/tgqKbaYvt31TetJe0rE9ISOqaHfwpoTjS6K/AhA== X-Received: by 10.200.38.183 with SMTP id 52mr7010932qto.237.1504188708817; Thu, 31 Aug 2017 07:11:48 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id n90sm2163712qkl.78.2017.08.31.07.11.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 07:11:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <150418755679.16776.2244408640678371841.idtracker@ietfa.amsl.com> Date: Thu, 31 Aug 2017 10:11:46 -0400 Cc: The IESG , draft-ietf-homenet-dot@ietf.org, homenet-chairs@ietf.org, HOMENET , ray@bellis.me.uk Content-Transfer-Encoding: quoted-printable Message-Id: References: <150418755679.16776.2244408640678371841.idtracker@ietfa.amsl.com> To: Benoit Claise X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Benoit Claise's No Objection on draft-ietf-homenet-dot-13: (with COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 14:11:52 -0000 I can update the text as follows: As a result, the use of '.home.', both as specified in RFC7788, and for other = uses is deprecated. This should not be taken to mean that an explicit allocation by = ICANN is superseded; this deprecation refers to uses of '.home.' as practiced at the = time of publication of this document. As you can see, though, this is somewhat problematic, which is why we = took out similar text previously. I think this new text is less = problematic than the old text, but personally I still prefer to just let = people wonder what "deprecated" means. I would actually rather leave = it ambiguous, in the sense that this would also discourage ICANN = allocating '.home.' as a GTLD. However, I suspect that there are = people on the IESG who understand this issue better than I do, and so I = would appreciate it if you would discuss this during the telechat, if = you read this in time, and see if you can get a consensus from the IESG = on what to write here. I am happy to make this change or not make it, = as you all decide. > On Aug 31, 2017, at 9:52 AM, Benoit Claise wrote: >=20 > Benoit Claise has entered the following ballot position for > draft-ietf-homenet-dot-13: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > "As a result, the use of '.home' is deprecated." > I had to double-checked that .home was NOT in > = https://www.iana.org/assignments/special-use-domain-names/special-use-doma= in-names.xhtml > .home was specified/requested in RFC7788 but never requested to IANA = according > to RFC6761. If mentioned in the draft, this info might help others... >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Thu Aug 31 08:39:55 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5839C13219E; Thu, 31 Aug 2017 08:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ZP2tSE7gn1RO; Thu, 31 Aug 2017 08:39:42 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11B113236D; Thu, 31 Aug 2017 08:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2929; q=dns/txt; s=iport; t=1504193982; x=1505403582; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=wKFclM3+CltCIVw5gfy+/75Uk3r3/noW1xoUhFwqwfM=; b=fzW+w+sHqr6EATugUuWUw9dsrcqQOuPESlRHt7YttDnPRbCDIlgeETUZ Kx9QB+bZOgQlo/iv85RXBtiL07AZNzAsDVGGzkjrAaDOdKgAek5LdwsDZ mASq1ghDHufninD6NEE7l0Sf5AsY4Nc+DRfvHLEkd/FdrR5Hjn/fPnnxP U=; X-IronPort-AV: E=Sophos;i="5.41,453,1498521600"; d="scan'208";a="696879114" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2017 15:39:39 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7VFdc8f013407; Thu, 31 Aug 2017 15:39:39 GMT To: Ted Lemon Cc: The IESG , draft-ietf-homenet-dot@ietf.org, homenet-chairs@ietf.org, HOMENET , ray@bellis.me.uk, Benoit Claise References: <150418755679.16776.2244408640678371841.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <77037f81-4d1a-a810-6924-17065a7f733e@cisco.com> Date: Thu, 31 Aug 2017 17:39:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [homenet] Benoit Claise's No Objection on draft-ietf-homenet-dot-13: (with COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 15:39:48 -0000 Hi Ted, > I can update the text as follows: > > As a result, > the use of '.home.', both as specified in RFC7788, and for other uses is deprecated. > This should not be taken to mean that an explicit allocation by ICANN is superseded; > this deprecation refers to uses of '.home.' as practiced at the time of publication > of this document. I'm surprised by "for the other uses". I was thinking something such as: As a result, the use of '.home.', as specified in RFC7788, is deprecated. Since '.home.' was not requested to IANA according to RFC6761, no IANA action is required. I'm probably over simplifying this, which probably makes it more complex. A little bit too late for this quick telechat today, so let me discuss with Terry and come back to you. Regards, Benoit > > As you can see, though, this is somewhat problematic, which is why we took out similar text previously. I think this new text is less problematic than the old text, but personally I still prefer to just let people wonder what "deprecated" means. I would actually rather leave it ambiguous, in the sense that this would also discourage ICANN allocating '.home.' as a GTLD. However, I suspect that there are people on the IESG who understand this issue better than I do, and so I would appreciate it if you would discuss this during the telechat, if you read this in time, and see if you can get a consensus from the IESG on what to write here. I am happy to make this change or not make it, as you all decide. > >> On Aug 31, 2017, at 9:52 AM, Benoit Claise wrote: >> >> Benoit Claise has entered the following ballot position for >> draft-ietf-homenet-dot-13: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> "As a result, the use of '.home' is deprecated." >> I had to double-checked that .home was NOT in >> https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml >> .home was specified/requested in RFC7788 but never requested to IANA according >> to RFC6761. If mentioned in the draft, this info might help others... >> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > . > From nobody Thu Aug 31 08:42:19 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9796713219E for ; Thu, 31 Aug 2017 08:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 lWcGi5tXSGEb for ; Thu, 31 Aug 2017 08:42:16 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 4C11F132715 for ; Thu, 31 Aug 2017 08:42:16 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id h15so4632738qta.4 for ; Thu, 31 Aug 2017 08:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gTF562DmhYBie9unSwRRjLPi2vQKP8eay0xeas4t5wA=; b=rfbo3BkEjRGqFH8R0uelVI2CwcUEqz/wC3hXgnwmVQx7ccjUycowdTsD0gX2Tl4X38 dnMCs8d56KzIIino/ktd5IIy2U5A0CE5dR2vYjCb3M56oUdUBZ12rho/Aq+R95ITo8DI 5EAFOK0pB4Kq00cuOqM3orLHTugqjlM0Tt1Dj22vAr/0dbEgs0C6Lzqzv+UOQMJAljPY vuR5VsXRxwN765kY5rUAJHA02UgLvTHq3E0vX8XyMXESEYj7B+vybwKmlFUy8ZrWZ53n f2kS04fAMJTodztO/qz0hVayDbqT8x52V//Xon33Xya15LXu5x/t46LM7QStLtY9RO+T 2wZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gTF562DmhYBie9unSwRRjLPi2vQKP8eay0xeas4t5wA=; b=VtA37nANo0RKNU8lECUzYZJoozNOSaZICgqFqrg8WA4g/p8IwTDj7zR39by7Qev/vi 18sRQEaPSL8jm38gEWVCDu2xBzZZkz5lJRDrtnkaaCOQqnUFjzFGgyaFTIjr3bKfrxSn EYIgPvcJDtgFjF1vmLnBSl0FKWHaQKXcHMVRQq5OFwgnM7ib1eYhNnUH/q8xFmEJAcg3 FntUvvqLnCSein3xEdUig4JfDHocn6P6ee8Al9k1phQCW0aTGW23HwSa15es0szSkExA 0eJ+M4ri5jB9MTNOPol1ID/Dh7pv39fnCNG+rW35tXTwUk91etLIha9Dfv36wW0aguxq eyyg== X-Gm-Message-State: AHPjjUhqXXUG1rWVSgAvIW4JUbIMHtYwygtjOYpklHgOqA4ZPbPleTfN XuxTeli+qierFqZx X-Google-Smtp-Source: ADKCNb4jzjWCCkHdg7fZpV3q5X5kFkrITb6qamiqd/Wv9A7iPjY6JZ1ox6k64fLBndCuOddYK+U5rA== X-Received: by 10.237.38.164 with SMTP id q33mr7569399qtd.238.1504194135463; Thu, 31 Aug 2017 08:42:15 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id d1sm5491671qkf.6.2017.08.31.08.42.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 08:42:14 -0700 (PDT) From: Ted Lemon Message-Id: <012AA5E3-C07B-473F-9438-E2DDAE22071B@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DF76D6CD-A6E5-4E67-9DB2-E62FC8F8EE7E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 31 Aug 2017 11:42:13 -0400 In-Reply-To: <77037f81-4d1a-a810-6924-17065a7f733e@cisco.com> Cc: The IESG , draft-ietf-homenet-dot@ietf.org, homenet-chairs@ietf.org, HOMENET , ray@bellis.me.uk To: Benoit Claise References: <150418755679.16776.2244408640678371841.idtracker@ietfa.amsl.com> <77037f81-4d1a-a810-6924-17065a7f733e@cisco.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] Benoit Claise's No Objection on draft-ietf-homenet-dot-13: (with COMMENT) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 15:42:18 -0000 --Apple-Mail=_DF76D6CD-A6E5-4E67-9DB2-E62FC8F8EE7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 31, 2017, at 11:39 AM, Benoit Claise wrote: > I'm probably over simplifying this, which probably makes it more = complex. > A little bit too late for this quick telechat today, so let me discuss = with Terry and come back to you. OK. Other uses are ad-hoc uses of the name: e.g., Sky TV in the UK, = IIRC, just used this domain in all their routers without ever getting = permission or trying to claim it officially. I believe that other such = uses exist. This is discussed in = https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ = , which is = in the RFC editor queue. --Apple-Mail=_DF76D6CD-A6E5-4E67-9DB2-E62FC8F8EE7E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 31, 2017, at 11:39 AM, Benoit Claise <bclaise@cisco.com> = wrote:
I'm probably over = simplifying this, which probably makes it more complex.
A little bit too late for this quick telechat = today, so let me discuss with Terry and come back to = you.

OK. =   Other uses are ad-hoc uses of the name: e.g., Sky TV in the UK, = IIRC, just used this domain in all their routers without ever getting = permission or trying to claim it officially.   I believe that other = such uses exist.   This is discussed in https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/= , which is in the RFC editor queue.

= --Apple-Mail=_DF76D6CD-A6E5-4E67-9DB2-E62FC8F8EE7E-- From nobody Thu Aug 31 12:57:16 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88F0132DFA; Thu, 31 Aug 2017 12:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham 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 4TjFHUYB99IE; Thu, 31 Aug 2017 12:56:21 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35DF1329BD; Thu, 31 Aug 2017 12:56:20 -0700 (PDT) Received: from [169.254.114.42] (50-1-98-42.dsl.dynamic.fusionbroadband.com [50.1.98.42]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v7VJtFvh099562 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 Aug 2017 12:55:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-42.dsl.dynamic.fusionbroadband.com [50.1.98.42] claimed to be [169.254.114.42] From: "Paul Hoffman" To: "Mark Andrews" Cc: HOMENET , secdir@ietf.org Date: Thu, 31 Aug 2017 12:56:17 -0700 Message-ID: <81929571-D70C-45D3-9A67-38EF54DF0DA9@vpnc.org> In-Reply-To: <20170831074920.EFC3B83DAC59@rock.dv.isc.org> References: <150307463977.14156.2178189421671973906@ietfa.amsl.com> <5C378A81-AB6B-4F2F-8D97-CDED30D788AE@fugue.com> <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com> <20170831074920.EFC3B83DAC59@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [homenet] [secdir] Secdir last call review of draft-ietf-homenet-dot-12 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 19:56:32 -0000 On 31 Aug 2017, at 0:49, Mark Andrews wrote: > In message <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com>, Ted Lemon > writes: >> >> On Aug 29, 2017, at 10:03 PM, Ted Lemon wrote: >>> Yes. As far as I know the text gives IANA the information they >>> need >>> to do; I do not know how they operate their black hole servers, so I >>> am >>> trusting that these instructions are sufficient. They have been >>> reviewed by people who understand this problem better than I do, >>> like >>> Andrew Sullivan, Paul Hoffman and Mark Andrews. I was specifically >>> advised not to overspecify this. I would rather take their word on >>> this >>> than yours, if you will forgive my saying so. :) >> >> Argh. Warren made me look more closely, and you were right. Sorry >> for >> doubting. :] Here is the new text for the IANA considerations >> section: >> >> IANA is further requested to create a new subregistry within the >> "Locally-Served DNS Zones" registry , titled >> "Transport-Independent Locally-Served DNS Zones", with the same >> format as the other subregistries. IANA is requested to add an >> entry in this new registry for 'home.arpa.' with the description >> "Homenet Special-Use Domain", listing this document as the >> reference. > > It is up to IANA as to how they implement the delegation. I could be wrong, but I think it is up to the IAB how they implement the delegations in .arpa. The sentences above are just about the registry, not about the DNS. --Paul Hoffman From nobody Thu Aug 31 19:39:17 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84802133145; Thu, 31 Aug 2017 19:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 iX6SKa944Ppk; Thu, 31 Aug 2017 19:39:14 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0C2A133141; Thu, 31 Aug 2017 19:39:14 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 85D2134B3D0; Fri, 1 Sep 2017 02:39:11 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3463D160044; Fri, 1 Sep 2017 02:39:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 11456160050; Fri, 1 Sep 2017 02:39:11 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sOhweI5d4xqm; Fri, 1 Sep 2017 02:39:10 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B5C14160044; Fri, 1 Sep 2017 02:39:10 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E7C0F83ED0E3; Fri, 1 Sep 2017 12:39:08 +1000 (AEST) To: Eric Rescorla Cc: "The IESG" , draft-ietf-homenet-dot@ietf.org, homenet-chairs@ietf.org, homenet@ietf.org, ray@bellis.me.uk From: Mark Andrews References: <150413520708.16860.14531912464478386147.idtracker@ietfa.amsl.com> In-reply-to: Your message of "Wed, 30 Aug 2017 16:20:07 -0700." <150413520708.16860.14531912464478386147.idtracker@ietfa.amsl.com> Date: Fri, 01 Sep 2017 12:39:08 +1000 Message-Id: <20170901023908.E7C0F83ED0E3@rock.dv.isc.org> Archived-At: Subject: Re: [homenet] Eric Rescorla's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 02:39:16 -0000 In message <150413520708.16860.14531912464478386147.idtracker@ietfa.amsl.com>, Eric Rescorla writes: > Eric Rescorla has entered the following ballot position for > draft-ietf-homenet-dot-13: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > A. Recursive resolvers at sites using 'home.arpa.' MUST > transparently support DNSSEC queries: queries for DNSSEC > records and queries with the DO bit set ([RFC4035] section > 3.2.1). While validation is not required, it is strongly > encouraged: a caching recursive resolver that does not > validate answers that can be validated may cache invalid > data. This in turn will prevent validating stub resolvers > from successfully validating answers. > > I don't understand the rationale for this requirement. As I understand it > from this document, stuff ending in home.arpa cannot be DNSSEC validated, > so what's it the business of this document to levy the requirement on > sites which support home.arpa that they do anything with DNSSEC at all. Wrong the responses can be validated. The output of the validation step is one of secure, insecure, or bogus. With the exception of home.arpa/DS and without private trust anchors being installed the output of that validation should be insecure for all answers from home.arpa. home.arpa/DS should validate as secure NODATA. In particular validation of the home.arpa/DS is important as it prevents the cache being poisoned with answers which prevent the stub proving that the home.arpa is supposed to exist and that it doesn't have a chain of trust from the root. Mark > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org