From nobody Fri Mar 3 15:59:35 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 1A3561299F6; Fri, 3 Mar 2017 15:55:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858533010.15846.2732422304428854129.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:30 -0800 Archived-At: Cc: homenet@ietf.org, terry.manderson@icann.org Subject: [homenet] homenet - Requested session has been scheduled for IETF 98 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:30 -0000 Dear Ray Bellis, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. homenet Session 1 (1:30:00) Monday, Morning Session I 0900-1130 Room Name: Zurich D size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Home Networking Area Name: Internet Area Session Requester: Ray Bellis 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 sunset4 pcp bier anima softwire dhc mptcp babel Second Priority: roll dprive isis opsec rtgarea rtgwg dane spring dbound Third Priority: manet nfvrg People who must be present: Mark Townsley Terry Manderson Ray Bellis Resources Requested: Projector in room Special Requests: --------------------------------------------------------- From nobody Thu Mar 9 05:17: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 055921295AE for ; Thu, 9 Mar 2017 05:17:03 -0800 (PST) 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 fZmmZq8o_f7M for ; Thu, 9 Mar 2017 05:17:01 -0800 (PST) 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 4D5A2129461 for ; Thu, 9 Mar 2017 05:17:00 -0800 (PST) Received: from [46.227.151.81] (port=58128 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 1clxw9-0007Dp-FD (Exim 4.72) for homenet@ietf.org (return-path ); Thu, 09 Mar 2017 13:16:57 +0000 To: HOMENET From: Ray Bellis Message-ID: <3d3ad88f-4b36-b397-5bb7-197589b06c1f@bellis.me.uk> Date: Thu, 9 Mar 2017 13:16:58 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [homenet] Chicago meeting logistics X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 13:17:03 -0000 IETF 98 is nearly upon us! The draft submission deadline is 23:59 UTC next Monday 13th, so please ensure that any new or updated drafts are submitted before then. The Homenet WG session has been scheduled for 09:00 on Monday 27th. We have been allocated a 2.5 hour slot, although we only requested 1.5 hours. We've therefore got plenty of time to fill, so if you have items that you would like to present (and that you haven't already discussed with the Chairs) please let us know ASAP. Advance volunteers for jabber relay and note taker would, of course, be much appreciated. With the meeting so early in the week it's also crucial that we get slides early (i.e. Sunday night at the latest) and not just before the session starts! Please don't forget slide numbers, to assist remote participants. thanks, Ray and Mark From nobody Fri Mar 10 09:55: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 BE0231294CF for ; Fri, 10 Mar 2017 09:55:27 -0800 (PST) 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 JawRhxcoi8bl for ; Fri, 10 Mar 2017 09:55:26 -0800 (PST) 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 F377B129417 for ; Fri, 10 Mar 2017 09:55:25 -0800 (PST) Received: from [46.227.151.81] (port=65330 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 1cmOl7-0007he-WB (Exim 4.72) for homenet@ietf.org (return-path ); Fri, 10 Mar 2017 17:55:22 +0000 To: HOMENET From: Ray Bellis Message-ID: <38e9722d-dd79-7325-c363-d2a3285b4bcc@bellis.me.uk> Date: Fri, 10 Mar 2017 17:55:24 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [homenet] Status update on -redact and -dothome X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:55:28 -0000 I thought the list had gotten automatic notification of this, but it seems not. Following the WGLC, and then our own reviews and write ups, Mark and I last week requested publication of draft-ietf-homenet-redact and draft-ietf-homenet-dot, so these documents are now out of the Working Group. They're currently in AD Review, following which they should go to IETF Last Call and thence to the IESG. Ray From nobody Sun Mar 12 05:17: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 37B87128824 for ; Sun, 12 Mar 2017 05:17:34 -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, RP_MATCHES_RCVD=-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 F_FCm02iOOj3 for ; Sun, 12 Mar 2017 05:17:32 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF5A12711D for ; Sun, 12 Mar 2017 05:17:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D63ED2CFD8 for ; Sun, 12 Mar 2017 14:17:29 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuEbsVH4D-lK for ; Sun, 12 Mar 2017 14:17:29 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3A5A12CCC1 for ; Sun, 12 Mar 2017 14:17:29 +0200 (EET) (envelope-from jari.arkko@piuha.net) From: Jari Arkko X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_DAD25F92-0B42-4FC1-A6A7-BF9BC23CE692"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Sun, 12 Mar 2017 13:17:28 +0100 Message-Id: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> To: homenet@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 12:17:34 -0000 --Apple-Mail=_DAD25F92-0B42-4FC1-A6A7-BF9BC23CE692 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have reviewed these two documents today, and had some comments: redact: Seems fine. But on: RFC7788 did not follow the process defined in Special Use Domain Names [1]. I would like to add that the issue is not just a process issue; the questions one would have to answer (like how other entities in the Internet should deal with the newly allocated name) went unanswered. Maybe: RFC7788 did not follow the process defined in Special Use Domain Names [1], or specify how other software should deal with the allocated name. dot: I=92m fine overall in requesting the allocation of .homenet for this purpose. However, there are first of all some unclear details, but more importantly, I fear that the class of name being requested is wrong. I say this with the understanding that I=92m not an DNS expert, but despite efforts I have failed to understand the logic, and I can see some issues in doing it the way that you=92re crafting the request. Such queries MUST NOT be recursively forwarded to servers outside the logical boundaries of the home network. I=92m not clear how to implement this MUST NOT. Is there a requirement here that any recursive resolver either knows about the logical boundaries of a home network, or does not forward .homenet queries? 2. Applications SHOULD treat domain names ending with '.homenet.' just like any other FQDN, and MUST NOT make any assumption on the level of additional security implied by its presence. This is fine, but that should probably be =91=85 any assumption about the security properties based on the use of this special name.=92 (It is not clear to me that there=92d be additional security level, could also be reduced security, e.g., if DNSSEC was not locally available.) 5. Only a DNS server that is authoritative for the root ('.') or is configured to be authoritative for '.homenet' or a subdomain of '.homenet' will ever answer a query about '.homenet.' In both of these cases, the server should simply answer as configured: no special handling is required. =85 IANA is requested to set up insecure delegation for '.homenet' in the root zone pointing to the AS112 service [RFC7535], to break the DNSSEC chain of trust. This is the concern about the type of a name being requested that I mentioned above. It is not clear to me why these are a requirement. Also, the insecure delegation in the root zone puts us into a place where we have not been before, process-wise, because this is a special use domain name and a proper TLD at the same time, causing us to run both the ICANN and the IETF process, and I think this might also imply things at least at the moment that we don=92t like, such as a requirement to sign the TLD, which would be contrary to our stated goals here. Furthermore, I don=92t understand the technical motivation, despite having read plenty of email on this topic and having asked friends. But maybe I=92m being dense today. Probably. But, here=92s my thinking. If we categorise .homenet as special, I don=92t understand why we need an insecure delegation. Software (e.g., local resolver) would *know* this is a special name and it would never be the case that .homenet suddenly turns into a delegated secure regular domain which needs the chain of trust from the root. What gives? To prevent this from happening, it may be useful for the resolver to identify different home networks on which it has resolved names, but this is out of scope for this document. Even if this is outside the scope, it is not clear to me how this is doable, given existing APIs. Jari --Apple-Mail=_DAD25F92-0B42-4FC1-A6A7-BF9BC23CE692 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYxTxYAAoJEM80gCTQU46q/8IP/jrlBtxTavHxwFOx4WNGCF6m 62xtyiII/2XcMwNlPQpKS8MfUxmFYlfhohMgcJAQFj5W3kZ7BkvCtmuf5yTQhKlp D73wBVfOwqRWpnxZazBpNOvx8fYyA7o+aodfFZ9YiokNDhH4PDZlY9VHPcuLWEII rYPCTwkwQn+xZjzXNMI1ij0sh0FC5th1ltBcwMq+acUjN8xOVwgAZrEOYxePlpq7 fyNUbj4Wu/gKeIwItghQeRElTccaBjBBrxQnkF0sZOVS0j+dwZFkvYvVRcyb9+GH 6kCPv6dbQmDIv7zW/Uzo0j2qHY6TzVC33/UMSn+HzWbt7zurJbTrVeQMhH01e7ET ZYB80NX914snzjTco96jwUy9yiG6OPuPMzlcVPMWRiuWjsn2FexEqfhl7TM4d2VL CKjt8XH/sGiCnKYXhyTVhFEq99t7q725WxLQCetFn02mkpwkMfogNpKMn8vLgEjb y/OLp2x258Q3GQCsyxEXQHEez1OmCl60TZvCyW97ATCvHB+ZygbxUgPULUHN5SKD oQ/b4jCZj4jPMJGdaWpLm0NV2HfD7znj2q9BzMLG6Maiheq/V1RITazFN26J8AX1 YdbjmORtQi+XEd3jFCCvrFPn4PpYasCBjTRCZQzI13PzLMYBTEBqyVc36FiOyLuO 14RiUEAkCkpnUZ/GlCjf =GVWM -----END PGP SIGNATURE----- --Apple-Mail=_DAD25F92-0B42-4FC1-A6A7-BF9BC23CE692-- From nobody Sun Mar 12 05:41: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 C12B41204D9 for ; Sun, 12 Mar 2017 05:41:44 -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 Bpw25s1fL66e for ; Sun, 12 Mar 2017 05:41:43 -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 DC70112944A for ; Sun, 12 Mar 2017 05:41:41 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id i34so16284218qtc.0 for ; Sun, 12 Mar 2017 05:41:41 -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=E1apS8VuNYKwD3cehTse6wgnWHV4HyyXbCE3IlWRHv4=; b=iZIe0lJVUJ+EP9nXFP8XLT+CqWe4hYfM4lyWlR0Y6+o2mW7Vb9T+UvSdu+wVb6uBf2 uDT5728wQ8GUPAl+KiZiFRqwDAn1Jxfa3YerK2fSIKbW7nKAegr2W4JNMl7ef62RFO4K 3Okf/Q8bM+uN/I53AN4UL/bgZlwgQ6vKyg64TmaKUlsNPjBa0bAJll9WkPw2IXTtbeDX o8pElY0N2WNR5pPWl0rakXSyucBL3GrCquWHPUosxwRCYs7b507Y9J8oYhOWB8sNUIoA 2Lm6z+jlFxO58DyH91GdsJYKUOLFDzQ+gc4fl9NP1KTaG94J1g47maK5RM9bxhWOyNy3 NUFA== 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=E1apS8VuNYKwD3cehTse6wgnWHV4HyyXbCE3IlWRHv4=; b=EE5CwgiINz9sGWY7PEw7s5qqp3tuAI+5BGrf0Er53sH1Wz1Xi1xN+IAhrOrdBL2BOg 5Ke30/o3JeZmkVflJ3unHjNvDgoYV90EbdUYIGmYpuVpn2H3y6XzKuMnuuyZKvqNHIbV gkHXN+7ZiYguSqcPaZDTLhmlZZY3HlpuDtCx1nRw+QwaerUy1ZbJ534z46CFZy7UbldO hnRKvN23tSoBSQHO/lqPaob8yip5Sw/zzt6HCVaK3tNQEcf2Ux2UDcd1UVbIPJJB7DYS Yq0EhjxsbioJgcPPL7VNARmSeVvsp4OtZCT+msVfaRvSVGSh9zo/EqsjGv95rc0P2V+R Xukw== X-Gm-Message-State: AMke39kLCXksZYhR+G9gHr+VorY5fjEKQn6g4w3Etv4dVGmAbR1WedOfb7UmqWn17CDS8g== X-Received: by 10.237.32.34 with SMTP id 31mr27909878qta.174.1489322500946; Sun, 12 Mar 2017 05:41:40 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id t43sm10138247qtc.64.2017.03.12.05.41.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Mar 2017 05:41:40 -0700 (PDT) From: Ted Lemon Message-Id: <43E15F33-EFE4-4690-88FD-76977C930055@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5D4AAE1D-2465-440F-8097-C1C9DE1C39C0" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 12 Mar 2017 08:41:38 -0400 In-Reply-To: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> To: Jari Arkko References: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 12:41:45 -0000 --Apple-Mail=_5D4AAE1D-2465-440F-8097-C1C9DE1C39C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 12, 2017, at 8:17 AM, Jari Arkko wrote: > I would like to add that the issue is not just a process issue; > the questions one would have to answer (like how other > entities in the Internet should deal with the newly allocated > name) went unanswered. Maybe: While this is true, it is not why we are doing the redact. We actually = do the enumeration in homenet-dot. I think changing the text would = confuse the issue by leading the reader to believe something that isn't = true. Am I missing something? > However, there are first of all some unclear > details, but more importantly, I fear that the class of > name being requested is wrong. I say this with the > understanding that I=E2=80=99m not an DNS expert, but despite > efforts I have failed to understand the logic, and I can > see some issues in doing it the way that you=E2=80=99re crafting > the request. You use the word type later on, not class, so my initial reaction to = this text was wrong. To be clear, I assume you are not proposing that = we use a different CLASS value. > I=E2=80=99m not clear how to implement this MUST NOT. Is there > a requirement here that any recursive resolver either > knows about the logical boundaries of a home network, > or does not forward .homenet queries? This is addressed in points 4 and 5 of section 3. Your objection to = the normative language in section 2 makes sense, though. > This is fine, but that should probably be =E2=80=98=E2=80=A6 any = assumption > about the security properties based on the use of this special > name.=E2=80=99 (It is not clear to me that there=E2=80=99d be = additional security > level, could also be reduced security, e.g., if DNSSEC was not > locally available.) That makes sense. > If we categorise .homenet as special, I don=E2=80=99t understand > why we need an insecure delegation. Software (e.g., > local resolver) would *know* this is a special name > and it would never be the case that .homenet suddenly > turns into a delegated secure regular domain which needs > the chain of trust from the root. What gives? A validating stub will treat an un-signed RR in the zone as bogus if = there is no un-signed delegation, because the absence of an un-signed = delegation constitutes a secure denial of existence. The working group = is well aware of the process issue=E2=80=94we've discussed it at length. = We know that it's terra incognita, and may not go our way, but we want = to try. Given that we're in last call, I suppose perhaps you are = saying that you as a participant wish to see the consensus change; I = would prefer not to have that discussion again. Is this what you are = proposing, or are you just pointing this out in case the working group = missed it? > To > prevent this from happening, it may be useful for the resolver to > identify different home networks on which it has resolved names, but > this is out of scope for this document. >=20 > Even if this is outside the scope, it is not clear to me how this is > doable, given existing APIs. You can establish a process for establishing a trust anchor for any = given homenet using trust-on-first-use of that zone's KSK. When you = encounter a zone signed with a different KSK, this is by definition not = the same zone, but is not treated as invalid: instead, you can cache = multiple trust anchors (or be configured to treat other homenets as = untrusted, or as invalid). This requires modifications to the stub = resolver, obviously. There may be other issues with this solution as = well, which is why it's out of scope for the current discussion, but you = asked. :) --Apple-Mail=_5D4AAE1D-2465-440F-8097-C1C9DE1C39C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 12, 2017, at 8:17 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
I would like to add = that the issue is not just a process issue;
the questions one would have to answer (like how = other
entities in the Internet should deal with the = newly allocated
name) went unanswered. = Maybe:

While= this is true, it is not why we are doing the redact.   We actually = do the enumeration in homenet-dot.   I think changing the text = would confuse the issue by leading the reader to believe something that = isn't true.   Am I missing something?

However,= there are first of all some unclear
details, but more importantly, I fear that the class = of
name being requested is = wrong. I say this with the
understanding that I=E2=80=99m not an DNS expert, but = despite
efforts I have failed = to understand the logic, and I can
see some issues in doing it the way that you=E2=80=99re = crafting
the = request.

You use = the word type later on, not class, so my initial reaction to this text = was wrong.   To be clear, I assume you are not proposing that we = use a different CLASS value.

I=E2=80=99= m not clear how to implement this MUST NOT. Is there
a requirement here that = any recursive resolver either
knows about the logical boundaries of a home = network,
or does not forward = .homenet queries?

This is addressed in points 4 and 5 of section 3.   Your = objection to the normative language in section 2 makes sense, = though.

This is fine, but that = should probably be =E2=80=98=E2=80=A6 any assumption
about the security = properties based on the use of this special
name.=E2=80=99 (It is = not clear to me that there=E2=80=99d be additional security
level, could also be = reduced security, e.g., if DNSSEC was not
locally available.)

That makes sense.

If we = categorise .homenet as special, I don=E2=80=99t understand
why we need an insecure = delegation. Software (e.g.,
local resolver) would *know* this is a special name
and it would never be = the case that .homenet suddenly
turns into a delegated secure regular domain which = needs
the chain of trust from = the root. What gives?

A validating stub will treat an un-signed RR in the zone as = bogus if there is no un-signed delegation, because the absence of an = un-signed delegation constitutes a secure denial of existence.   = The working group is well aware of the process issue=E2=80=94we've = discussed it at length.   We know that it's terra incognita, and = may not go our way, but we want to try.   Given that we're in last = call, I suppose perhaps you are saying that you as a participant wish to = see the consensus change; I would prefer not to have that discussion = again.   Is this what you are proposing, or are you just pointing = this out in case the working group missed it?

  = To
  prevent = this from happening, it may be useful for the resolver to
  identify = different home networks on which it has resolved names, but
  this is out = of scope for this document.

Even = if this is outside the scope, it is not clear to me how this = is
doable, given existing = APIs.

You can = establish a process for establishing a trust anchor for any given = homenet using trust-on-first-use of that zone's KSK.   When you = encounter a zone signed with a different KSK, this is by definition not = the same zone, but is not treated as invalid: instead, you can cache = multiple trust anchors (or be configured to treat other homenets as = untrusted, or as invalid).   This requires modifications to the = stub resolver, obviously.   There may be other issues with this = solution as well, which is why it's out of scope for the current = discussion, but you asked.   :)

= --Apple-Mail=_5D4AAE1D-2465-440F-8097-C1C9DE1C39C0-- From nobody Sun Mar 12 05:45: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 260DF1293EB for ; Sun, 12 Mar 2017 05:45:05 -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, RP_MATCHES_RCVD=-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 pij7yul907hs for ; Sun, 12 Mar 2017 05:45:03 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id C8C00128DF6 for ; Sun, 12 Mar 2017 05:45:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1E6D32CFD8; Sun, 12 Mar 2017 14:45:02 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcMrGWYtQpMn; Sun, 12 Mar 2017 14:45:01 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 78F6E2CCC1; Sun, 12 Mar 2017 14:45:01 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_363526B9-2FB4-4478-B2A0-6879B6AC88A1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <43E15F33-EFE4-4690-88FD-76977C930055@fugue.com> Date: Sun, 12 Mar 2017 13:45:01 +0100 Message-Id: References: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> <43E15F33-EFE4-4690-88FD-76977C930055@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 12:45:05 -0000 --Apple-Mail=_363526B9-2FB4-4478-B2A0-6879B6AC88A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> I would like to add that the issue is not just a process issue; >> the questions one would have to answer (like how other >> entities in the Internet should deal with the newly allocated >> name) went unanswered. Maybe: >=20 > While this is true, it is not why we are doing the redact. We = actually do the enumeration in homenet-dot. I think changing the text = would confuse the issue by leading the reader to believe something that = isn't true. Perhaps, but I wanted to be accurate as to why the original thing wasn=92t satisfactory. Your point about confusing with regards to the current thing is of course valid. Presumably that could be addressed by explicitly saying that there=92s ongoing work that intends to not make the same mistakes :-) >> However, there are first of all some unclear >> details, but more importantly, I fear that the class of >> name being requested is wrong. I say this with the >> understanding that I=92m not an DNS expert, but despite >> efforts I have failed to understand the logic, and I can >> see some issues in doing it the way that you=92re crafting >> the request. >=20 > You use the word type later on, not class, so my initial reaction to = this text was wrong. To be clear, I assume you are not proposing that = we use a different CLASS value. Right. Sorry. You can tell that I=92m not a DNS expert=85 :) >=20 >> I=92m not clear how to implement this MUST NOT. Is there >> a requirement here that any recursive resolver either >> knows about the logical boundaries of a home network, >> or does not forward .homenet queries? >=20 > This is addressed in points 4 and 5 of section 3. Your objection to = the normative language in section 2 makes sense, though. >=20 >> This is fine, but that should probably be =91=85 any assumption >> about the security properties based on the use of this special >> name.=92 (It is not clear to me that there=92d be additional security >> level, could also be reduced security, e.g., if DNSSEC was not >> locally available.) >=20 > That makes sense. Ok. More later, gotta run. Thanks for the quick response! Jari --Apple-Mail=_363526B9-2FB4-4478-B2A0-6879B6AC88A1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYxULNAAoJEM80gCTQU46qswgP/2t1+oMhun01MxGuiDS4TXGB It+sgnKF3nOce5gxPWBfmjpvtf3sU+LyR9r74+zv99qT3PhJPrPKJp2QDQOZShNP hBop1RRqXowA2NA7Jmmr9FFtikuYJxhIdmArT2yLiMJs0VaoUlRTuhm9ya0p4vFI BYM6IbAMYpz7hhgtNxGuBPxD8f2o4BHErPowhWijS1caegv7Vl6F8rgTWAXuK1Tv msqNLI3K8lghLoYYNAxOlB15UaiqVFW/BmrncAQT1QP2EzD+PSffH5HPEMV5c+ks xwN4SaaXL6RaLILZgi6UjpANsyD98w5eTtSDwqKCy1K9lhLsZpuOw8CJa199lgrk A+Zc8nCT1Nqev9QuiBNEGr97E86S3thkv5pL0kdDIw2NB7hfg2Z7ksWIjOCf2vQ8 NM/CN4RuA3FkcBjsTrjvQ29xUB5xU9IM1y0qGM3zXX3dnO3b8mgEy0DgfxYF2Kqa vEQq3lblfPL/1hC8pYbBtZO0Tlh0XIKxB6zZAm/Sk4AqvbMOP8lEzRHjOBc+am+a OMbgQBs51IYPTuMHYlzTBbl4BdmbAlFFgZX8dmVcIM4zt5b4WuodJ3WRPv7akhVD lla/xG0vNsg/6XGVIweKs6+laBmqeu04UIiwoJCm0twSoG8u6gsHiwSb46NqphrL 82uAk2qnXrOAkGjwRF6i =ldhC -----END PGP SIGNATURE----- --Apple-Mail=_363526B9-2FB4-4478-B2A0-6879B6AC88A1-- From nobody Sun Mar 12 06: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 C77B312955A for ; Sun, 12 Mar 2017 06:59: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, 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=dR/D8qOE; dkim=pass (1024-bit key) header.d=yitter.info header.b=KFqoEnyq 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 Cs9qp-89DYhP for ; Sun, 12 Mar 2017 06:59:37 -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 5861F12943F for ; Sun, 12 Mar 2017 06:59:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 55CA6BEEDC for ; Sun, 12 Mar 2017 13:59:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1489327176; bh=GwSFRkMpPj/dLc3RVCPI/ZhpC4nb34DONWxkxSp93qA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=dR/D8qOEms17ZJnUlfKeB4tDTynih9UDKQU36rzGrORYkkc5TFA3OPa7kGHgq5b4W Ohl9sv7a03DR6c5+5JstZ4/ys5sO1EYzV+Oll/ew9quUPgSzNOkexh6pR4C4967XKF 8k4srMy6Mkx7kE2bJgpm67mpSLMHpMIJOMqE+/bg= 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 G_mTnHnh2fl9 for ; Sun, 12 Mar 2017 13:59:34 +0000 (UTC) Date: Sun, 12 Mar 2017 09:59:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1489327174; bh=GwSFRkMpPj/dLc3RVCPI/ZhpC4nb34DONWxkxSp93qA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=KFqoEnyqlTp4+WB2PN7X/GvPKDEjcnurgg5k7/rjg8FRv9wnjub189lJG7f0iPyuI ArIASf+otUjqqhW1i6RC0INPVeHVLeX418Aiqu6HXX+TyRTn9C4v0VwNgU4PFmlYNl xCrOz12kQp+6PA2oLLlEB/TUWe0Z+YHElNDovP8E= From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20170312135930.GF13811@mx4.yitter.info> References: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> Archived-At: Subject: Re: [homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 13:59:39 -0000 Hi, On Sun, Mar 12, 2017 at 01:17:28PM +0100, Jari Arkko wrote: > I’m fine overall in requesting the allocation of .homenet for > this purpose. As I've already argued in this list, I think it's a mistake, but I'll try not to rehash that argument in what follows. (So if you detect such rehashing, please don't misunderstand it as what I've intended. I'm imperfect.) > Such queries MUST NOT be recursively > forwarded to servers outside the logical boundaries of the home > network. > > I’m not clear how to implement this MUST NOT. Is there > a requirement here that any recursive resolver either > knows about the logical boundaries of a home network, > or does not forward .homenet queries? It would seem that's an implicit requirement, but note that the requirement will never be met by anyone who doesn't implement this specification. Since basically every shipped home network box has some sort of forwarding or recursive DNS system in it, and they know nothing about homenet now, so they will just send the query out to the Internet. (This will be true of every domain name we pick for this.) > 2. Applications SHOULD treat domain names ending with '.homenet.' > just like any other FQDN, and MUST NOT make any assumption on the > level of additional security implied by its presence. > > This is fine, but that should probably be ‘… any assumption > about the security properties based on the use of this special > name.’ (It is not clear to me that there’d be additional security > level, could also be reduced security, e.g., if DNSSEC was not > locally available.) I don't think I understand this comment. But my understanding of the goal of homenet use cases was that most of the deployment needed to work without upgrading everything. So you should be able to use the homenet features with your unupgraded laptop, because it's supposed to Just Work like any other network context. So, > It is not clear to me why these are a requirement. it's because of the "Just Works" requirement. If you are validating on your laptop, your validator does not know about homenet, and so it won't know that when it gets the proof of non-existence of homenet. that it is supposed to ignore that proof. So it will treat any name beneath homenet as a bogus entry. > Also, the insecure delegation in the root zone puts us into a > place where we have not been before, process-wise, because > this is a special use domain name and a proper TLD at the same > time, causing us to run both the ICANN and the IETF process, As long as we understand "run the ICANN process" as including "getting ICANN to invent such a process", I agree with the above. > If we categorise .homenet as special, I don’t understand > why we need an insecure delegation. Software (e.g., > local resolver) would *know* this is a special name > and it would never be the case that .homenet suddenly > turns into a delegated secure regular domain which needs > the chain of trust from the root. What gives? Which "local resolver" do you mean? There could be more than one, and it's not only resolvers. You could do validation without doing resolution. Basically, to get homenet without the provably insecure delegation, you need to give up on validation or you have to accept that homenet techniques won't work until everything has been upgraded. (I suppose that, since we're assuming v6, we might be waiting for that anyway ;-) ) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Mar 13 05:11: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 3EE9712958A for ; Mon, 13 Mar 2017 05:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 hruzRvCBJMyY for ; Mon, 13 Mar 2017 05:11:16 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 62FD612957C for ; Mon, 13 Mar 2017 05:11:16 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id 1so219732523qkl.3 for ; Mon, 13 Mar 2017 05:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=k4JE/j7a4p4Z7F7tTP3rxnaDAEiB0HJxh9WxfeJfz9k=; b=UIjYJoylFxQTBH0vv9HYxHzEMrMLw7MqOWOF0ERFVBkVUf86WBhyBMkF3EATaezoAQ JrjowL+WEo+1D0QKkuS50MCauIIt6Et+Wf7z7mumCDhrXdDW+Tdbgp5rET4Me823wVnV xCr9FNXNB92fMbeRldqM+i0wTO2jPoUj7a3b1aZ7t1C0cn5p0PUt2OjUEjmCb71+6g65 ru2OZRGyQU8b0XjysLVPCHGDlAv2Z0kJqcWATIHx44LL5+2FSCcNMdOGA7s6DVQGgZGg kZUQo+WyzPdbLo2Gt17PZ+e0Ic2sL4Lsv+BexmEGcz7T4+7gABqV/jbrmD2KTuYoOBBo sMPQ== 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=k4JE/j7a4p4Z7F7tTP3rxnaDAEiB0HJxh9WxfeJfz9k=; b=W5fPPcfGjBE4J9hPV8PMUNmr1wpUEyho7QRRbEOMl/iZrEd0O/nSKRZfzRIHop7dO3 D9V88fbXcHB9XeMKXGzahWgpZM+/EZGBidKmTwp5rUnDyWW1s0O6RtEuDIay08a9xE7S WILbGoFunYl94MwA/hvcBDTfSF4MXHQFexOA015Eyi8l4+rg65gpoiNCkzIXvwGNhO1w pjkbdw9K9xI78LSQ7hHAPr9dDkXvRUnuJF5m069Rvp2LgHR1cAZeMRY7cmRRJB8xYdW3 dvBDcBjYX8LRBnA5rKk6MK5yUKQA0QyWlfa0MShwXMsYkRLPwUQnqO9IwGtee1L+Pz8N IFZw== X-Gm-Message-State: AFeK/H1hKJB7YROZS4ucMPBDrxoVdrKH6uq9dz1QZawoSFzUsmqSFiP5RPbJOV59qQP+sA== X-Received: by 10.55.9.3 with SMTP id 3mr29047094qkj.199.1489407075485; Mon, 13 Mar 2017 05:11:15 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:907f:7393:27af:19ab? ([2601:18f:801:600:907f:7393:27af:19ab]) by smtp.gmail.com with ESMTPSA id t30sm12029985qtt.56.2017.03.13.05.11.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 05:11:15 -0700 (PDT) From: Ralph Droms Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0EC73E2A-97BA-4499-AB09-F539C76498E7" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Mar 2017 08:11:13 -0400 In-Reply-To: <20170312135930.GF13811@mx4.yitter.info> To: Jari Arkko References: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> <20170312135930.GF13811@mx4.yitter.info> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: HOMENET Subject: Re: [homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 12:11:18 -0000 --Apple-Mail=_0EC73E2A-97BA-4499-AB09-F539C76498E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 12, 2017, at 9:59 AM, Andrew Sullivan = wrote: >=20 > Hi, >=20 > On Sun, Mar 12, 2017 at 01:17:28PM +0100, Jari Arkko wrote: >=20 > [...] >> Also, the insecure delegation in the root zone puts us into a >> place where we have not been before, process-wise, because >> this is a special use domain name and a proper TLD at the same >> time, causing us to run both the ICANN and the IETF process, >=20 > As long as we understand "run the ICANN process" as including "getting > ICANN to invent such a process", I agree with the above. I agree with Andrew and think we need to consider this step quite = carefully. This text in the IANA considerations section: IANA is requested to set up insecure delegation for '.homenet' in the root zone pointing to the AS112 service [RFC7535], to break the DNSSEC chain of trust. does not explain that there is no process through which IANA can set up = that delegation. It may not even be an IANA process. If this text were = to be published in an RFC, I don't think IANA can carry out that = instruction today, and I don't think IANA has the authority to negotiate = a process through which it can carry out the instruction in the future. I think this text should be modified in some way, before the document is = published, to recognize explicitly that no such process exists today and = that such a process is requested as part of the implementation of the = published document. The homenet WG is, I believe, aware of the need for a process for = instantiating an insecure delegation as requested in the -dot document. = In my opinion, the implicit request for such a process should be made = explicit in some way. - Ralph >=20 >> If we categorise .homenet as special, I don=E2=80=99t understand >> why we need an insecure delegation. Software (e.g., >> local resolver) would *know* this is a special name >> and it would never be the case that .homenet suddenly >> turns into a delegated secure regular domain which needs >> the chain of trust from the root. What gives? >=20 > Which "local resolver" do you mean? There could be more than one, and > it's not only resolvers. You could do validation without doing > resolution. Basically, to get homenet without the provably insecure > delegation, you need to give up on validation or you have to accept > that homenet techniques won't work until everything has been upgraded. > (I suppose that, since we're assuming v6, we might be waiting for that > anyway ;-) ) >=20 > Best regards, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_0EC73E2A-97BA-4499-AB09-F539C76498E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 12, 2017, at 9:59 AM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:

Hi,
On Sun, Mar 12, 2017 at 01:17:28PM +0100, = Jari Arkko wrote:

[...]
Also, the insecure delegation in the root zone puts us into = a
place where we have not been before, process-wise, = because
this is a special use domain name and a proper TLD = at the same
time, causing us to run both the ICANN and the = IETF process,

As long as we = understand "run the ICANN process" as including "getting
ICANN to invent such a process", I agree with the above.

I agree = with Andrew and think we need to consider this step quite carefully. =  This text in the IANA considerations section:

   IANA is requested to set up = insecure delegation for '.homenet' in the
   root = zone pointing to the AS112 service [RFC7535], to break = the
   DNSSEC chain of trust.

does not explain that there is no process through = which IANA can set up that delegation.  It may not even be an IANA = process.  If this text were to be published in an RFC, I don't = think IANA can carry out that instruction today, and I don't think IANA = has the authority to negotiate a process through which it can carry out = the instruction in the future.

I = think this text should be modified in some way, before the document is = published, to recognize explicitly that no such process exists today and = that such a process is requested as part of the implementation of the = published document.

The homenet WG = is, I believe, aware of the need for a process for instantiating an = insecure delegation as requested in the -dot document.  In my = opinion, the implicit request for such a process should be made explicit = in some way.

- Ralph


If we = categorise .homenet as special, I don=E2=80=99t understand
why we need an insecure delegation. Software (e.g.,
local resolver) would *know* this is a special name
and it would never be the case that .homenet suddenly
turns into a delegated secure regular domain which needs
the chain of trust from the root. What gives?

Which "local resolver" do you = mean?  There could be more than one, and
it's not = only resolvers.  You could do validation without doing
resolution.  Basically, to get homenet without the = provably insecure
delegation, you need to give up on = validation or you have to accept
that homenet techniques = won't work until everything has been upgraded.
(I suppose = that, since we're assuming v6, we might be waiting for that
anyway ;-) )

Best regards,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

= --Apple-Mail=_0EC73E2A-97BA-4499-AB09-F539C76498E7-- From nobody Mon Mar 13 06:11: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 29E3F1295F4 for ; Mon, 13 Mar 2017 06:11:41 -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, RP_MATCHES_RCVD=-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 4IFI_Welr00H for ; Mon, 13 Mar 2017 06:11:40 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id CC6631295F0 for ; Mon, 13 Mar 2017 06:11:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2A9E02CCC1; Mon, 13 Mar 2017 15:11:39 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvewJP4v0LZE; Mon, 13 Mar 2017 15:11:38 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B46382CC5E; Mon, 13 Mar 2017 15:11:38 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_66644FA6-C309-4430-ADCC-CCFF934C727E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: Date: Mon, 13 Mar 2017 15:11:38 +0200 Message-Id: References: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> <20170312135930.GF13811@mx4.yitter.info> To: Ralph Droms X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: HOMENET Subject: Re: [homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 13:11:41 -0000 --Apple-Mail=_66644FA6-C309-4430-ADCC-CCFF934C727E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>> Also, the insecure delegation in the root zone puts us into a >>> place where we have not been before, process-wise, because >>> this is a special use domain name and a proper TLD at the same >>> time, causing us to run both the ICANN and the IETF process, >>=20 >> As long as we understand "run the ICANN process" as including = "getting >> ICANN to invent such a process", I agree with the above. This is my understanding as well. > I agree with Andrew and think we need to consider this step quite = carefully. This text in the IANA considerations section: >=20 > IANA is requested to set up insecure delegation for '.homenet' in = the > root zone pointing to the AS112 service [RFC7535], to break the > DNSSEC chain of trust. >=20 > does not explain that there is no process through which IANA can set = up that delegation. It may not even be an IANA process. If this text = were to be published in an RFC, I don't think IANA can carry out that = instruction today, and I don't think IANA has the authority to negotiate = a process through which it can carry out the instruction in the future. >=20 > I think this text should be modified in some way, before the document = is published, to recognize explicitly that no such process exists today = and that such a process is requested as part of the implementation of = the published document. >=20 > The homenet WG is, I believe, aware of the need for a process for = instantiating an insecure delegation as requested in the -dot document. = In my opinion, the implicit request for such a process should be made = explicit in some way. Good advice. Thanks. Jari --Apple-Mail=_66644FA6-C309-4430-ADCC-CCFF934C727E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYxpqKAAoJEM80gCTQU46q0fQP/2jLExPt4bx80VXbp/vNELlc itwQp7e5Mg6KzpP24U4ZlyPYjvG8gYBshbLXBYvOQF7vVGINB59xH5ryuo7bG0Bq DzqoQ/Qe3Yx4kWoQD3bLfSI/Ac7+J3dn16ao4heCggNxUeXAPlnuu/ABh6xONQOc sGQwKADrEdUqchORqCtW3PEOIkF6OiXv/jQEZZdgT98J970+5gRom4r9U9TRNylX 5ny+z6ndG3PdYORh9NuaeM8dracgD2/IHHcEDlA6Ln4dYVcnD1CroczzyqEGJZqx I/JryjzK1SsYbUz1RM5PosY9lr+N3SXbqzs8Rbk1DGNhfevNffJU+ejvGJRr7VWC YzO3ObulsHY72Ogrp+cJrgkMa0FpZ15eRoYWIzBYwx7wPZnzikHM6fM5RIDsmN4F AdTRGXJi1ZwmaXSxa9YV86TyHzEfyz8+iHGCiLGRv6bjRPiQz6yWjLL0aVXCYv/M T0TJxheNfG+I8QOJFtLzBn3vO0cDAOsdMn1ZXFX+6Zg0d5zrEsnOt/N2w9xlHaFs lX+EQ2UTiMKQAJFVMzrb8ufrbwQkuyT8lC5TFMgGQYAF/JRxigZZSOrgxUYMn/dO OzLojUqSX6ZUct0kr64zM0zy7nE00L4pNvIafPYZt38VhB0VJyxAm/iHcPbTTlzO 1Rb4UhcX49cNVcIm0YuR =wFxC -----END PGP SIGNATURE----- --Apple-Mail=_66644FA6-C309-4430-ADCC-CCFF934C727E-- From nobody Mon Mar 13 12:10:20 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 110A412945C; Mon, 13 Mar 2017 12:10:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943221802.20389.9700867499747159709@ietfa.amsl.com> Date: Mon, 13 Mar 2017 12:10:18 -0700 Archived-At: Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-dot-03.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:10:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking of the IETF. Title : Special Use Top Level Domain '.homenet' Authors : Pierre Pfister Ted Lemon Filename : draft-ietf-homenet-dot-03.txt Pages : 7 Date : 2017-03-13 Abstract: This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.homenet.', and designates this top-level domain as a special-use domain name. The '.homenet' top-level domain replaces '.home' as the default domain used by the Home Networking Control Protocol (HNCP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-homenet-dot-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dot-03 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 Mon Mar 13 12:21:37 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 152D7129AC3; Mon, 13 Mar 2017 12:21:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943289206.20268.548283699839842692@ietfa.amsl.com> Date: Mon, 13 Mar 2017 12:21:32 -0700 Archived-At: Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-redact-03.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:21:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking of the IETF. Title : Redacting .home from HNCP Author : Ted Lemon Filename : draft-ietf-homenet-redact-03.txt Pages : 3 Date : 2017-03-13 Abstract: This document updates the Home Networking Control Protocol, eliminating the recommendation for a default top-level name for local name resolution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-homenet-redact-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-redact-03 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 Mon Mar 13 12:23: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 D3573129A92 for ; Mon, 13 Mar 2017 12:23:01 -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 fKubhjE0HZsx for ; Mon, 13 Mar 2017 12:23:00 -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 06C4012949E for ; Mon, 13 Mar 2017 12:23:00 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id 1so230527747qkl.3 for ; Mon, 13 Mar 2017 12:22:59 -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=Jx0EdsVsY/PGuS4ffn3olE+DGjtsf48t8C720qjj+Ko=; b=wAZxFV6p0/yKHvfXxioBdbY0U3sq1Zvo9XZwdBwav4w2S7V0a05hj3TbkSvxjFk5rh rED1am+h76Yj3fYB5hisvpoUvR6RrPW+GRhuWrmNuP8g7621udFQH9Ydey8LvXrMBzwF YRR0rAwg6sOivP+xut75o+rMQz/UqQmSUw1fY0ap1ShMQ4ZL90/cASJv/fPeEehfiWCC iNyiaq2zlHWYo9EO155pEyhRNc7Wv/jBvPQqzbbCW4XIwVpyZ+r1hB//FIVuDRY9mQTh EMa7/trppL99OyprgzOU636aOM92jWneJCLdV6nnSzyYfM/9fuWw/Tw0zZDWRRBlmR57 js5Q== 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=Jx0EdsVsY/PGuS4ffn3olE+DGjtsf48t8C720qjj+Ko=; b=LuHOgfCimglxY52S733fQWceXx+QwdIsIeXrWQ6+CIgnGmVieb4g2zXM8VwgDmlvga ZrTHdn5hpsvzFtZgURoEgWwhSYExAcZVigmXylHtOLQ6ODu9bcmL9YLY1eEmsNM2MKnB YdRi20UIlPJ6LbnTAyiH5jA/PREBqrXEVL1NF/MycLTN2bnGZrS8J/uRHM8ncuveVYpF yOpuRWum1zx5WeQra8ZC9/FXsfVdFzUIQp66tBueuoqNTVGIdU3ng3N93fXcMIN8SfiC cKfkTmisgAKzEorvPatRPp8sEwmdd/AEALzDTJgT8vdZ8Q8I8y5zhnlFgTSJ0G+V7t9S UzMQ== X-Gm-Message-State: AFeK/H21tg36C1vKA6zUKC0XGWcjGBzboysMtgofIijvXIBW4Q0uheaLr5EBMzAX7TOsXw== X-Received: by 10.55.78.1 with SMTP id c1mr34611879qkb.251.1489432979177; Mon, 13 Mar 2017 12:22:59 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id k62sm12833250qkd.21.2017.03.13.12.22.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 12:22:58 -0700 (PDT) From: Ted Lemon Message-Id: <9448A617-124A-40C3-B5B1-ABA57F54E816@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0EA391A4-6E9A-41C5-AB58-0C4F88353E70" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Mar 2017 15:22:57 -0400 In-Reply-To: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> To: Jari Arkko References: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:23:02 -0000 --Apple-Mail=_0EA391A4-6E9A-41C5-AB58-0C4F88353E70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 12, 2017, at 8:17 AM, Jari Arkko wrote: > Seems fine. But on: >=20 > RFC7788 > did not follow the process defined in Special Use Domain > Names [1]. >=20 > I would like to add that the issue is not just a process issue; > the questions one would have to answer (like how other > entities in the Internet should deal with the newly allocated > name) went unanswered. Maybe: >=20 > RFC7788 > did not follow the process defined in Special Use Domain > Names [1], or specify how other software should deal with > the allocated name. I just uploaded a new version of the doc with your proposed text. Diff = here: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-redact-03 = I also updated the homenet-dot document, and you should have received a = link to the diff under a separate cover, and of course the announcement = also went to the mailing list, where I'm sure it was completely buried = in all today's other timely submissions. --Apple-Mail=_0EA391A4-6E9A-41C5-AB58-0C4F88353E70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Mar 12, 2017, at 8:17 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
Seems fine. But = on:

 RFC7788
 did not follow the process = defined in Special Use Domain
 Names [1].

I would like to add that the = issue is not just a process issue;
the questions one would have to = answer (like how other
entities in the Internet should deal with = the newly allocated
name) went unanswered. Maybe:

 RFC7788
 did not follow the process defined in = Special Use Domain
 Names [1], or specify how other = software should deal with
 the allocated = name.

I = just uploaded a new version of the doc with your proposed text.   = Diff here:

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-redact-0= 3

I also = updated the homenet-dot document, and you should have received a link to = the diff under a separate cover, and of course the announcement also = went to the mailing list, where I'm sure it was completely buried in all = today's other timely submissions.

= --Apple-Mail=_0EA391A4-6E9A-41C5-AB58-0C4F88353E70-- From nobody Mon Mar 13 12:48: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 0F34B1298AC for ; Mon, 13 Mar 2017 12:48:38 -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, RP_MATCHES_RCVD=-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 DRdX3xgfmyRR for ; Mon, 13 Mar 2017 12:48:37 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB43129ADE for ; Mon, 13 Mar 2017 12:48:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5E14D2CCC1; Mon, 13 Mar 2017 21:48:12 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awkq8qoY8icq; Mon, 13 Mar 2017 21:48:12 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id F3D272CC5E; Mon, 13 Mar 2017 21:48:11 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7793B262-F8EC-4508-85F8-F71A1741573E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <9448A617-124A-40C3-B5B1-ABA57F54E816@fugue.com> Date: Mon, 13 Mar 2017 21:48:11 +0200 Message-Id: <164A4F84-F34C-4F45-8240-55A2B703A11C@piuha.net> References: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> <9448A617-124A-40C3-B5B1-ABA57F54E816@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:48:38 -0000 --Apple-Mail=_7793B262-F8EC-4508-85F8-F71A1741573E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks. I won=92t have time to review it today though. Jari --Apple-Mail=_7793B262-F8EC-4508-85F8-F71A1741573E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYxvd7AAoJEM80gCTQU46qSUMP/Rt3xDqdjB4z48Htijniyq7E UzM8ybxq4AfMO+ZfoYrTu8ZvwAFr8W4UM4uJ6WxBK93tmZC1O52Jf2SKbz9Ehb7r zz1VeiTcWMGZKz+0i+TrtLDz+VjC/4olDcBjYlP5lhh9xIoxKKSLUKvUe4z8oyhO 1J1P06HVCxoyli/xlW2lG0SFu5xW4P4cRBiA53DEaBgq3KZH85sbY7SB+tdVVf4B 0WMyy6oYFBZQF5WZsCdZ9ZtUT0GC6IHAr2xAINUT8d3GgoVpY/SfIpViBL+MQmwD 2V9AuFIggYvrs4LYCxY7MwGMIKWW2aCnHw8yvtPh5ugHgOeYYsdoRromFUoI4jz1 4TZ/0KhEVZN0zic/fQo+Np+AoOOvMwy75tOb2KFPZ6hojPlJuSzjkFXRDIhEy2Zi 9mfvVosdhQ5wRd93z7TofmoI+xPLui8X23d+Gqn9uMIVMi7112zbVhkIErgcZX6K h5iRx6k1SWZTtEvOzQjInRO89Uu79BRd8RTM9dF4ZuPaT0pN07x6GBmSL8tyc0RI XW1hq0v0qZvJCnV1bQFk6cdOFA/2cRKpPIQmtx9oU6KHU/P3RS22fLD5XTCmCxOK tHgWcjQF/fU2qH5RZkrS+AwsF2sq5CgodwSuqFjVTO7TEBuM+Y8ueTgwtz7mdvns DLBOGSNL9RW79ZxtnSaJ =tnXB -----END PGP SIGNATURE----- --Apple-Mail=_7793B262-F8EC-4508-85F8-F71A1741573E-- From nobody Mon Mar 13 12:52: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 280E6129453 for ; Mon, 13 Mar 2017 12:52:38 -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 lGlynFdzgKsx for ; Mon, 13 Mar 2017 12:52:37 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 D664D129430 for ; Mon, 13 Mar 2017 12:52:36 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id p64so231970438qke.1 for ; Mon, 13 Mar 2017 12:52: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=oQnc4X+/YG/BT9QE/Wd4VYtYhknNiiwkoqu7LmQTRAk=; b=sYBp73PYjXMXnteVHnh/kmLgJOyWYQcawCpCD/lnitay8MBc7J0VSWKvEnGgVmUI4d yllrrQZenDaF1krwQ0Fe0yPg5i6+mTGGw7XjogQcqiffzca3HSaEEM//Qxb9jHAtaZN3 +II54lG6IkwzG2pmZhqup+UR6Hv+JmOXmVf5MZriTB/TEWRNQaN2WjfA08OyZXK/CfVP uNfZmspkZIAS9caVzOyGj76fqh3Ibbc38QPnF1SIn+3Zen0fr+x+w7F632h5NctE/UpM hOjoHCHLzPRp8r8tJZtA7cdajN8wYwGqzTbm2QOmtgMErcpumsAwUVXGBteAJjlGbI3L 9Jgw== 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=oQnc4X+/YG/BT9QE/Wd4VYtYhknNiiwkoqu7LmQTRAk=; b=X5cKsX0gWahv01NxdDaOl9+66Jb60BDQrJgNHI6HRcHixYZOE/3Ph6Ji2+T6qTvHcI T19knZJTiO+Wjyp0Wu64huI7NzgJfyWX4azfXb/U7JIU7OAm+intOUhu4dvUwZCrsElp 4sWecNQooNeVi92tg9Owx+6cZj4n1lUjb9L9v+NxU20spx6TDE8KFV5qnUFHAq0fjLAd dM+YluAns0MEXJ1gfnIoCUwAZiGUvJQMB2LQ9W1Ihu7OLj8zesgPqVyvDLpB5c3AMwBG OhI5d5upgV2K9ZK/ta6Myeud28dFTfcHjCWzZRM2SuauxzzU9zevo4A6DdoyJvlOqc9b F+uQ== X-Gm-Message-State: AFeK/H3qjk1g76Vo94n8bpJkxQsbTl0TAFwoeZ6bKhPbLiMb8hM6GVysoSZHfAwqx7mcEQ== X-Received: by 10.55.212.8 with SMTP id l8mr36182263qki.52.1489434756038; Mon, 13 Mar 2017 12:52:36 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id e19sm12864651qta.68.2017.03.13.12.52.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 12:52:35 -0700 (PDT) From: Ted Lemon Message-Id: <69E09A09-77A3-49CB-896A-7974D577E422@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E38E7F08-C444-4AFC-A21D-E6B59589DCB7" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Mar 2017 15:52:34 -0400 In-Reply-To: <164A4F84-F34C-4F45-8240-55A2B703A11C@piuha.net> To: Jari Arkko References: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> <9448A617-124A-40C3-B5B1-ABA57F54E816@fugue.com> <164A4F84-F34C-4F45-8240-55A2B703A11C@piuha.net> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:52:38 -0000 --Apple-Mail=_E38E7F08-C444-4AFC-A21D-E6B59589DCB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 13, 2017, at 3:48 PM, Jari Arkko wrote: > Thanks. I won=E2=80=99t have time to review it today though. Whyever not? :) --Apple-Mail=_E38E7F08-C444-4AFC-A21D-E6B59589DCB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 13, 2017, at 3:48 PM, Jari Arkko <jari.arkko@piuha.net> wrote:
Thanks. I won=E2=80=99= t have time to review it today though.

Whyever not?   :)

= --Apple-Mail=_E38E7F08-C444-4AFC-A21D-E6B59589DCB7-- From nobody Mon Mar 13 14:58: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 F3E28129B7A for ; Mon, 13 Mar 2017 14:58:53 -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 RRPP24NYEN1Z for ; Mon, 13 Mar 2017 14:58:52 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 E5318129415 for ; Mon, 13 Mar 2017 14:58:51 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id n21so43070590qta.1 for ; Mon, 13 Mar 2017 14:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:references:to:date; bh=RVy88l0hjP0tmPWwAoS9C/z5YSUwMOeelEdKNTmMOnY=; b=PknBGZrXMUoDio7zkVQRxvuI7NnTbH9bPr04F9Wt1bFg9Ik7rWYcpPGQOfHp9neJ2F HzmIS1CHtuLg5pA1GM6Qke9WQId9uN7cEFuG6k1ssNaPTceZI7ZDrVXC2XqcvtI54xOk +jU5VR7ff+J1PS6GzPdjfaGd2driebVLEzxvF/+hGIXnr916J71RpC7DqssFQ4DEMmcX ueGHz+wXRzDIuiLjhKwC/0VO4lXnSRWZ1VwLSv/CtmEQ1XMz+t1/xkkT18xWs16wcliX mQzgkGvPRJUX/+uwyYUMrt3Gbv97VEAZTDp7ZDu0L1MTbb+YOLnQew2/6NOzCY8WpWbo pluQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=RVy88l0hjP0tmPWwAoS9C/z5YSUwMOeelEdKNTmMOnY=; b=Cf43OjaIMhzDSvuLxvWZ5DE5qbD0v7Y2VZO/F1DLoTraQzd9r5LgbXWllJcKeD3b/p j6dH4XJuyGAPt+bVRkTUeDCICePUcyjErU1jjufEfCcT7YrJTR2GeqsV9TfQ3jsKa/3d c3Z2MmfJYgtX0Vr3h/BJMPVObkVMK5yOyZ6Q6KhzGCcXNgus900SO+iRDz5EtJu/V56c OUdYRMg0xNiBTqf5QpdXnh88rMvEtPPINGRKa7+GzqE9gI/p11drs3MSAOcKAxVJwILG HMuYcAe7pQ5sQgcpDFWmbUx4M5cgrIgIBJJ0byEpNrrGUn8FTRoJYbOFS6sa0Yr3LCvi MWsQ== X-Gm-Message-State: AMke39nB0c5vBmc+gGxmZXKnt94B6MHE0i9GYmiPdaHdFgqu32lejG94VifhwnPNVF6mnA== X-Received: by 10.237.34.150 with SMTP id p22mr33391037qtc.66.1489442330934; Mon, 13 Mar 2017 14:58:50 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id n11sm13071789qke.28.2017.03.13.14.58.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 14:58:50 -0700 (PDT) From: Ted Lemon Content-Type: multipart/alternative; boundary="Apple-Mail=_8DCBBB24-B1F9-4E82-BE83-27B389361682" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: References: <148944217975.20370.12525433504127407949@ietfa.amsl.com> To: HOMENET Date: Mon, 13 Mar 2017 17:58:49 -0400 X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [homenet] Simple Homenet Naming Architecture... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:58:54 -0000 --Apple-Mail=_8DCBBB24-B1F9-4E82-BE83-27B389361682 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Daniel Migault and I have been working on the Simple Homenet Naming = Architecture. I've posted a -00 that I hope we can discuss in Chicago. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-tldm-simple-homenet-naming-00.txt > Date: March 13, 2017 at 5:56:19 PM EDT > To: > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Simple Homenet Naming and Service Discovery = Architecture > Authors : Ted Lemon > Daniel Migault > Filename : draft-tldm-simple-homenet-naming-00.txt > Pages : 9 > Date : 2017-03-13 >=20 > Abstract: > This document describes a simple name resolution and service > discovery architecture for homenets. This architecture covers local > publication of names, as well as name resolution for local and = global > names. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-tldm-simple-homenet-naming/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-tldm-simple-homenet-naming-00 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_8DCBBB24-B1F9-4E82-BE83-27B389361682 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Daniel Migault and I have been working on the Simple Homenet = Naming Architecture.   I've posted a -00 that I hope we can discuss = in Chicago.

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = I-D Action: = draft-tldm-simple-homenet-naming-00.txt
Date: = March 13, 2017 at 5:56:19 PM = EDT
To: = <i-d-announce@ietf.org>
Reply-To: = internet-drafts@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.


=        Title =           : Simple = Homenet Naming and Service Discovery Architecture
=        Authors =         : Ted Lemon
= =             &n= bsp;           &nbs= p;Daniel Migault
Filename =        : = draft-tldm-simple-homenet-naming-00.txt
Pages =           : 9
= Date =            : = 2017-03-13

Abstract:
=   This document describes a simple name resolution and = service
  discovery architecture for homenets. =  This architecture covers local
=   publication of names, as well as name resolution for local = and global
  names.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-tldm-simple-homenet-nami= ng/

There's also a htmlized version = available at:
https://tools.ietf.org/html/draft-tldm-simple-homenet-naming-00=


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

= --Apple-Mail=_8DCBBB24-B1F9-4E82-BE83-27B389361682-- From nobody Mon Mar 13 15:04: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 06A61129BD8 for ; Mon, 13 Mar 2017 15:04:12 -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 ighPHQsOibwT for ; Mon, 13 Mar 2017 15:04:10 -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 946DD1293FB for ; Mon, 13 Mar 2017 15:04:10 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id n21so43159685qta.1 for ; Mon, 13 Mar 2017 15:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=ZjXysfZftdvONaU/IEf7vwt1tHg2xmdf0KhL4nm14ck=; b=d0wwwd9BA00saJljx266WiCyWdzC/akJu1vRbHhbS/qZSwiaEnyRmY1/W0sjOtUFis NCbT9yndFKSfZbDS8Pl925toGVIBTHiRliY/tUiw1WqXMbOOqkqr19Wv4yE6QKqdEx0V A4D+v8lIKCFzkkxisH75FBx/yNpvD7fKgrrWXWN88Iwny+pCRov965U6BrcW5JsGxpK3 pcMZeFnxLSPqVMMmn9HnuoDelK0DXm0NTB8HO8yGjks+WA21Dx1m92bQWOVM52qeKeOt Eosae4tkXSe6tYaOUZnyXUrWvHdppGMS9MthLgvAEEC/JTw08tS1TeOA+cR6LaKxuOfa 0hhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=ZjXysfZftdvONaU/IEf7vwt1tHg2xmdf0KhL4nm14ck=; b=jusfe7Pqw0oDkHaYmw0TL6QZKAKpLMJ/xWGKVJrlzZlsvArI6WWHnzmbyGFOMxLHSn PqtV3lRG7d4NEkZEFRzZVuFCp7EwoMvDHCOifqihQmoFI4Zvfwlr5fH2ZZ95NbPcGeFd kmJvZjISKOwHHtEo5p1CDnxxu0MIbbX252SUqiIyk5LHTUjU9kKWyfznUJ/W3T8ayBKy YVe2ZLnvn2HNp6MjbYz4FlY38suGXk9I/LM0JyDMo/cQ41vT3D3TLoYzxbirVFXKL6xh V0H+ZqI4e0Qo8w2VvCxZ/0Z+eO2oUgSHcNwxvgakOCJ0ia4nRLNwHWJAJIHS0eqKzpI6 qNoA== X-Gm-Message-State: AMke39lO5melZn8HTfuRQjDbixPO7BfhH+P2u+dJhs1ufOqFnsIM+MALZYk29Yy3aGdZIg== X-Received: by 10.237.54.162 with SMTP id f31mr34210288qtb.2.1489442649442; Mon, 13 Mar 2017 15:04:09 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id z4sm9152463qkc.22.2017.03.13.15.04.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 15:04:08 -0700 (PDT) From: Ted Lemon Content-Type: multipart/alternative; boundary="Apple-Mail=_D4F41442-8003-48EB-89E4-FE793A1D532D" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Mar 2017 18:04:07 -0400 References: <148944217975.20370.12525433504127407949@ietfa.amsl.com> To: HOMENET In-Reply-To: Message-Id: <3CF9BA31-1620-472C-9197-581C338FD222@fugue.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [homenet] Simple Homenet Naming Architecture... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:04:12 -0000 --Apple-Mail=_D4F41442-8003-48EB-89E4-FE793A1D532D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 13, 2017, at 5:58 PM, Ted Lemon wrote: > Daniel Migault and I have been working on the Simple Homenet Naming = Architecture. I've posted a -00 that I hope we can discuss in Chicago. To amplify on that slightly, the idea with this document is to provide a = naming architecture that gets naming done on the homenet, and nothing = else. There is no support for DNSSEC or PKI, or for publishing names = in the global DNS. However, in principle all of these things _can_ be = done on the homenet using this architecture=E2=80=94they will simply = require an additional functional box which is not specified in this = architecture, but fits into it. --Apple-Mail=_D4F41442-8003-48EB-89E4-FE793A1D532D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 13, 2017, at 5:58 PM, Ted Lemon <mellon@fugue.com> = wrote:
Daniel Migault and I have been working on the = Simple Homenet Naming Architecture.   I've posted a -00 that I hope = we can discuss in Chicago.

To amplify on that slightly, the idea with this = document is to provide a naming architecture that gets naming done on = the homenet, and nothing else.   There is no support for DNSSEC or = PKI, or for publishing names in the global DNS.   However, in = principle all of these things _can_ be done on the homenet using this = architecture=E2=80=94they will simply require an additional functional = box which is not specified in this architecture, but fits into = it.


= --Apple-Mail=_D4F41442-8003-48EB-89E4-FE793A1D532D-- From nobody Tue Mar 14 01: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 5CA21129482 for ; Tue, 14 Mar 2017 01:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_NEUTRAL=0.779] 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 vBEuR4P7qKOK for ; Tue, 14 Mar 2017 01:49:23 -0700 (PDT) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.229]) by ietfa.amsl.com (Postfix) with ESMTP id 5B564129469 for ; Tue, 14 Mar 2017 01:49:23 -0700 (PDT) Received: from poro.lan (80.220.131.63) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 58A591F8008E0B1F; Tue, 14 Mar 2017 10:49:21 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Markus Stenberg In-Reply-To: Date: Tue, 14 Mar 2017 10:49:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <80BCEE0D-BF31-45F1-A21C-0FE3A24CB492@iki.fi> References: <148944217975.20370.12525433504127407949@ietfa.amsl.com> To: Ted Lemon X-Mailer: Apple Mail (2.3259) Archived-At: Cc: HOMENET Subject: Re: [homenet] Simple Homenet Naming Architecture... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 08:49:25 -0000 On 13 Mar 2017, at 23.58, Ted Lemon wrote: > Daniel Migault and I have been working on the Simple Homenet Naming = Architecture. I=E2=80=99ve posted a -00 that I hope we can discuss in = Chicago. S1.1: The assumption in UI is false. The visible services (at least in = the legacy browse mode, e.g. =E2=80=98flat list=E2=80=99, do not need to = have topology information visible to the user; in browse mode, full = domain is usually shown). S3.3: Why MUST filter out globals? I do not see the reason, and if I do = not, casual reader might not either. If it is just an opinion, it could = be SHOULD perhaps. The subsection lists 3 functions (querying, aggregating, relaying) but = says there are only two types of proxies. I am slightly confused. My reading (which you do not state explicitly) is that you advocate a = solution where you have =E2=80=98aggregating proxy=E2=80=99 which asks = for results from multiple links, and combines them, handling uniqueness = of responses; however, the devices themselves will not even know they = are =E2=80=98computer 72=E2=80=99 and not =E2=80=98computer.local=E2=80=99= which they advertise on the link. This gets quite awkward as devices = come and go if they do not locally know their name, unless the = aggregating function is fully stateful and robust (=3D mappings stay = constant until end of time) and it can somehow determine that moved node = (computer.local which moved from link A to link B to new name = computer-2.local as there was computer.local already on the link B) is = still same. In my experimentation in 2013, somewhat better working design seemed to = be forcing the aggregated name mappings to stay unique by essentially = forcing devices to rename themselves until the computer.local thinks it = is actually computer 72.local (or whatever) which is network-wide unique = and then when it moves its node name part stays same. Anyway, it looks like a good start, at least no mention of dnssec or = crazy delegation to random third party by default.=20 Cheers, -Markus= From nobody Tue Mar 14 08:25: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 07F95129590 for ; Tue, 14 Mar 2017 08:25: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 PbREDPpefZNz for ; Tue, 14 Mar 2017 08:24:59 -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 9AFE9128DF6 for ; Tue, 14 Mar 2017 08:24:59 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id 1so249844081qkl.3 for ; Tue, 14 Mar 2017 08:24:59 -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=MzBbAxMD+KouOWxNeKcZl6B4lbyQMOJv+GaryFr9dCQ=; b=SYuZ9FlqQS0HkqvaynIllsvVCFNdu4Wdx5REkjl22jhntmeQ0pdmhiU8mg1Caea/se T8lQWOTfG2xAHwJ1Cf8fwz6r7RVYV/zSONayJo95+/VrSzHSFAFnQ5eSXk1Df+hB9N0c dvjcaWhrPfmWQq0KyV79R/9m4ma3CaFl99zQlRE7cpp6US9juPBGVlDNxWeJhDq2GcHX bFGAAVIL1v6F0oclcjwJYWWzndYhvQiRU+dr9zt+iSA9Wv8bcrpBrlyBeO/vX1ezC66X U9PRT00bssrm5jR8ICGIzlwhP435MbpzTwNzXw1uByWhdBDeLzkLtR/SJ0i4i4luDZTu Li9w== 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=MzBbAxMD+KouOWxNeKcZl6B4lbyQMOJv+GaryFr9dCQ=; b=KomTsOUVWLTnn7gSK0VvhWGNBBCTtaurVBz49DMn0Lt7SjYTKS45iP7zrmJt8PgelV 8XTFIIApjvMoY2oW1/xXh7pvEcroQcrS0JdJYtrHHXTlprY0xFpS8vCjHY3wCHSKoDJR 7y2AnWSqAGXa+PEu5blQ7VwNOooLLOp+DfCp0LtqN091JgTYa6VVxSo4+L+K53QAOpUX UjNB0DFMsU8KMMmCA/mSs5jsFBIMntoBfvxZf2p2y7q+4K7Cs+ko1w9vP96g8nKU/2OG qtsIcqjuIDLPbq+muDjzPdJS1VqVUbjJTBbh2AdjYnlOCanYiE5/O5JTIH7GSP/Cb5II 25kg== X-Gm-Message-State: AMke39m8HRCTO+A05gFlLFwwZvKam2jwN+w6N9MmqPgU4/a+6BeqA+vvIb4OZFuki2clZw== X-Received: by 10.55.146.4 with SMTP id u4mr35581167qkd.37.1489505098719; Tue, 14 Mar 2017 08:24:58 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 44sm14599195qts.15.2017.03.14.08.24.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 08:24:58 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_25A4F294-A75C-446E-ADC8-234DCB849B1D" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 14 Mar 2017 11:24:56 -0400 In-Reply-To: <80BCEE0D-BF31-45F1-A21C-0FE3A24CB492@iki.fi> Cc: HOMENET To: Markus Stenberg References: <148944217975.20370.12525433504127407949@ietfa.amsl.com> <80BCEE0D-BF31-45F1-A21C-0FE3A24CB492@iki.fi> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [homenet] Simple Homenet Naming Architecture... X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 15:25:02 -0000 --Apple-Mail=_25A4F294-A75C-446E-ADC8-234DCB849B1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 14, 2017, at 4:49 AM, Markus Stenberg = wrote: > S3.3: Why MUST filter out globals? I do not see the reason, and if I = do not, casual reader might not either. If it is just an opinion, it = could be SHOULD perhaps. Are you talking about this text? Local names appear as subdomains of [TBD1]. These names can only be resolved within the homenet; not only is [TBD1] not a globally unique name, but queries from outside of the homenet for any name, on or off the homenet, must be rejected with a REFUSED response. This text is actually wrong. The correct behavior is specified in RFC = 5625, section 6.2. The point is to avoid being an amplifier for DDoS = attacks. > The subsection lists 3 functions (querying, aggregating, relaying) but = says there are only two types of proxies. I am slightly confused. The confusion here is twofold. First, I used the term "relaying proxy" = in the first sentence, and then started using the term "querying proxy" = to mean the same thing in later sentences, but didn't notice until you = pointed it out that I had done this. The other issue is that there are actually three functions here, and I = only really talk in detail about two. Bear in mind that we talked = about a two-layer architecture, and this is the easy layer, but it has = to support the other layer. In order to support the other layer, it's = (maybe) necessary to have a DNS proxy on every link that can assert that = a DNS query was received on-link, in order to support stateful DNSSD. = We didn't really go into any detail about that in this version of the = architecture. The other two functions are the hybrid that asks questions using mDNS in = response to queries over DNS, and the hybrid that asks questions using = DNS to proxies that do mDNS. So the first of these is the querying = proxy, and the second is the aggregating proxy. I'm not actually convinced that we want to do stateful hybrid DNSSD = using DNS update; if we don't, then the third function goes away. > My reading (which you do not state explicitly) is that you advocate a = solution where you have =E2=80=98aggregating proxy=E2=80=99 which asks = for results from multiple links, and combines them, handling uniqueness = of responses; however, the devices themselves will not even know they = are =E2=80=98computer 72=E2=80=99 and not =E2=80=98computer.local=E2=80=99= which they advertise on the link. This gets quite awkward as devices = come and go if they do not locally know their name, unless the = aggregating function is fully stateful and robust (=3D mappings stay = constant until end of time) and it can somehow determine that moved node = (computer.local which moved from link A to link B to new name = computer-2.local as there was computer.local already on the link B) is = still same. I am not sure, but I think you are alluding here to the problem that if = you have a computer that connects to one link sometimes and another link = at other times, it will present the same name on both links and this = will create a conflict. Otherwise naming conflicts of this type are = quite rare. But it sounds like you've encountered them enough to be = concerned about it. In the case I'm talking about, defending the name = doesn't work, because the device always presents the same name, and so = the number keeps creeping up, which is not desirable. In any case, given that you've done some hacking in this space, it would = be helpful if we could have a more detailed conversation about it at = IETF, so that I can understand your experiences. > Anyway, it looks like a good start, at least no mention of dnssec or = crazy delegation to random third party by default.=20 That's the second layer. I don't think it's crazy or random, but yes, = it's not present in the simple architecture, since there was clearly = demand for an architecture that was easier to implement than the = DNSSEC/delegation architecture. Personally, I think that we need a = real security model, and so proposing this as a separate architecture is = somewhat harmful, but I admit that the real security model is hard [tm].= --Apple-Mail=_25A4F294-A75C-446E-ADC8-234DCB849B1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 14, 2017, at 4:49 AM, Markus Stenberg <markus.stenberg@iki.fi> wrote:
S3.3: Why MUST = filter out globals? I do not see the reason, and if I do not, casual = reader might not either. If it is just an opinion, it could be SHOULD = perhaps.

Are = you talking about this text?

   Local names appear as subdomains of [TBD1].  These names can only =
be
   resolved within the homenet; not only is [TBD1] not a globally unique
   name, but queries from outside of the homenet for any name, on or off
   the homenet, must be rejected with a REFUSED response.

This text is = actually wrong.   The correct behavior is specified in RFC 5625, = section 6.2.   The point is to avoid being an amplifier for DDoS = attacks.

The subsection lists 3 = functions (querying, aggregating, relaying) but says there are only two = types of proxies. I am slightly confused.

The confusion here is twofold.   First, I used the term = "relaying proxy" in the first sentence, and then started using the term = "querying proxy" to mean the same thing in later sentences, but didn't = notice until you pointed it out that I had done this.

The other issue is that = there are actually three functions here, and I only really talk in = detail about two.   Bear in mind that we talked about a two-layer = architecture, and this is the easy layer, but it has to support the = other layer.   In order to support the other layer, it's (maybe) = necessary to have a DNS proxy on every link that can assert that a DNS = query was received on-link, in order to support stateful DNSSD.   = We didn't really go into any detail about that in this version of the = architecture.

The other two functions are the hybrid that asks questions = using mDNS in response to queries over DNS, and the hybrid that asks = questions using DNS to proxies that do mDNS.   So the first of = these is the querying proxy, and the second is the aggregating = proxy.

I'm not = actually convinced that we want to do stateful hybrid DNSSD using DNS = update; if we don't, then the third function goes away.

My = reading (which you do not state explicitly) is that you advocate a = solution where you have =E2=80=98aggregating proxy=E2=80=99 which asks = for results from multiple links, and combines them, handling uniqueness = of responses; however, the devices themselves will not even know they = are =E2=80=98computer 72=E2=80=99 and not =E2=80=98computer.local=E2=80=99= which they advertise on the link. This gets quite awkward as devices = come and go if they do not locally know their name, unless the = aggregating function is fully stateful and robust (=3D mappings stay = constant until end of time) and it can somehow determine that moved node = (computer.local which moved from link A to link B to new name = computer-2.local as there was computer.local already on the link B) is = still same.

I am = not sure, but I think you are alluding here to the problem that if you = have a computer that connects to one link sometimes and another link at = other times, it will present the same name on both links and this will = create a conflict.   Otherwise naming conflicts of this type are = quite rare.   But it sounds like you've encountered them enough to = be concerned about it.   In the case I'm talking about, defending = the name doesn't work, because the device always presents the same name, = and so the number keeps creeping up, which is not desirable.

In any case, given that = you've done some hacking in this space, it would be helpful if we could = have a more detailed conversation about it at IETF, so that I can = understand your experiences.

Anyway, = it looks like a good start, at least no mention of dnssec or crazy = delegation to random third party by default. 

That's the second layer.   I don't = think it's crazy or random, but yes, it's not present in the simple = architecture, since there was clearly demand for an architecture that = was easier to implement than the DNSSEC/delegation architecture.   = Personally, I think that we need a real security model, and so proposing = this as a separate architecture is somewhat harmful, but I admit that = the real security model is hard [tm].
= --Apple-Mail=_25A4F294-A75C-446E-ADC8-234DCB849B1D-- From nobody Sat Mar 18 21:29:42 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 76B69129477; Sat, 18 Mar 2017 21:29:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jon Mitchell To: Cc: draft-ietf-homenet-dot.all@ietf.org, homenet@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148989778041.21449.11458841609929936240@ietfa.amsl.com> Date: Sat, 18 Mar 2017 21:29:40 -0700 Archived-At: Subject: [homenet] Review of draft-ietf-homenet-dot-03 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, 19 Mar 2017 04:29:40 -0000 Reviewer: Jon Mitchell Review result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Overall - document has issues, could likely benefit from further reviews. This document was asked for early review by with a specific request instructions to look at in context of RFC6761 definition of special use domain names as well as from the operational implications of having an unsigned root zone. Having read the document and a number of related works that I found useful in understanding further the implications of this document (such as those laid out by draft-ietf-dnsop-sutld-ps-03), I think it would be useful for this document to go through an additional further early review by dnsop working group directly, however here is my non-DNS expert feedback: This document does spell out handling for .homenet as required by RFC6761, specifically in Section 3 of the draft, and does seem to adequately fit under the definition of a special used domain name, primarily only based on the difference of user experience with the domain (criteria #1). That said, I have several concerns with the wording in this draft regarding criteria in this section, here they are in the same numbered list as in the draft (and as required by RFC6761). 1. This does not adequately identify that users should not treat .homenet like any other domain name in the sense that entries in this top level domain are pretty much guaranteed to be non-unique, and likely this will pose general confusion, service reachability, as well as security concerns that are somewhat glossed over as well in the security considerations section of the draft. 2. All though this states that applications should not consider .homenet domain has having an elevation of security, user facing applications may want to actually notify users of the special behavior of this domain and the fact that it is more insecure as the names are not globally unique and using them outside of the local networking environment will likely have unexpected results. Further applications are pretty much guaranteed to not be able to have certificate based trust of the hosts at this domain since they are not globally unique. 3. No issues with section wording which basically prescribes no difference from normal DNS behavior, although this section is a bit verbose about how a host gets it's nameservers, which seems unnecessary. 4. This section is a bit confusing as it says that .homenet is effectively a locally served zone as described by RFC6303, but then there is no request for IANA to add this to the locally served zones registry which was established by that RFC, not to mention that registry does not currently contain any non reverse zones today. My reading is that homenet's desired behavior for this and section 5 are similar to the description of the .test domain handling in RFC6761, and I'm curious (not familiar with history or timing of the two documents) that none of the domain handling in RFC6761 defer to RFC6303 for specification handling like .homenet tries to do here. 5 and 6. Similar concern as above, wonder why same wording as prescribed for .test domain in RFC6761 is not used for .homenet 7. No concerns. Concerns with security considerations - user surprise (and threat) is something that is basically being designed into this use case, as well as is the need to disable DNSSEC and some of the ability to use certain types of certificate based application security that relies on CA trust based on names. This doesn't feel adequately called out. IANA considerations - as described below section doesn't mention locally served zone registry, although it's unclear as described above whether or not that's really the behavior desired. From nobody Thu Mar 23 11:21: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 C91F2129B9D for ; Thu, 23 Mar 2017 11:21:32 -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, FREEMAIL_FROM=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 Jqsnn6pOSzki for ; Thu, 23 Mar 2017 11:21:31 -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 2E1D9129BB6 for ; Thu, 23 Mar 2017 11:21:31 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id p64so187784742qke.1 for ; Thu, 23 Mar 2017 11:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=6oUdvi3KwvpM0F7/vKdtnSVCLdXGBtSBPLNnWucYq5A=; b=CYN07RoVf+1zz3RNEwlCWw3wzTS0a63bY7Scph3DzEO7uPQmyn0NumprcHgau1NVLu 1utVGZzWuBvQVa9QYHeAFn8Dd9ENHgVCJnE+ei1XGXcnMMhLv+OgOoqwPkZYSSnIr5Hz yraP5A7NnOji9gftRz3rNv47PRnXLIQLtb11KKsnywtHfl7YWN2M7u2lXfQPt38+oqYD iWkqYMidONX6aVde8cWFtOqhnthpyE6fp4UJy20ZShsA0K2cxO/onOtGEV3g8KeS1XRz gl8KF35Gt4OX9s5qrZ3Jm74IzaLk7/LJ+UQIVLi89vtxfj5vM89hYqKl8VA74oVXioCv Jj2A== 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=6oUdvi3KwvpM0F7/vKdtnSVCLdXGBtSBPLNnWucYq5A=; b=S6Z72mXqD1+R0K3FXWN6ujI7kJBffB5BA5C7DlsrPcDNx1ltZlCsAIF3gb6nlXjSbf 8pNbuqZZbkemPl6CbyKYr82Wm0+5vMvzQ/rFobxkWNHOWaDk8HYZMsMN+fUBI2YA9a1H xxvwrCKBhhgudqc0wN0mPw1a1LywC/0jc/ThPDMJINGa0DxTBPx6Qm7x0TFJnIC+bP8p +T7nvUtKZlsREnudNINIg2X61mkh37Sot9hKLnquCMYmoDIoHh6yS18X+IQSJCTeDhXT qPlmEKXJ44twuc5jv5MTdA9+MyePH4/pxZniyXWkAUCVpCSyVN47GqdqEhkMZdtzcg5g XLKw== X-Gm-Message-State: AFeK/H3QET1UrpE/E07outtdbm2D96WRBSAJYqte3Amm2FRNJCjqGRdHBDEaYks/7ZRGWg== X-Received: by 10.55.37.142 with SMTP id l14mr3367014qkl.188.1490293290215; Thu, 23 Mar 2017 11:21:30 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:65d4:518c:a8e7:5d72? ([2601:18f:801:600:65d4:518c:a8e7:5d72]) by smtp.gmail.com with ESMTPSA id l6sm3740057qkd.66.2017.03.23.11.21.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 11:21:29 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 23 Mar 2017 14:21:26 -0400 References: <1E14B142-680B-4E30-809B-68E03EB6E326@gmail.com> <61FD3EE3-3043-4AB1-9823-6A9D61B1438C@vigilsec.com> <21C8F856-FE3F-42A6-A8ED-888D0797B68B@vigilsec.com> <60C85486-E351-4C42-ADEB-FCBB56F4EA27@fugue.com> <734EC35A-4B1F-43EB-BE37-C34CA46BDA26@fugue.com> <203D2BEA-1008-48A0-9CE2-1FD621C6117F@shinkuro.com> <3134EDC2-FB00-41EA-8338-6E6B196137F1@fugue.com> <572B4EBA-F37F-4E92-A252-44BAF5DE7FF5@shinkuro.com> <95935A30-9B77-4B7A-A0CE-4409134B6163@fugue.com> To: HOMENET In-Reply-To: Message-Id: <9768C77F-1993-4012-83B5-A077DF0C53A5@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [homenet] [DNSOP] WG review of draft-ietf-homenet-dot-03 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, 23 Mar 2017 18:21:33 -0000 I asked this question on the dnsop WG mailing list; asking again here: > On Mar 21, 2017, at 9:39 AM, Ralph Droms = wrote: >=20 > Ted - has the operation of .homenet, as described in = draft-ietf-homenet-dot-03, been demonstrated? >=20 > - Ralph >=20 Specifically, has the ability to validate queries to .homenet been = demonstrated with a simulated root zone including the entry for = .homenet, properly configured recursive resolvers and properly = configured clients (having received a list of the local recursive = resolvers through DHCP or ND)? - Ralph From nobody Fri Mar 24 12:04: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 2361312956A for ; Fri, 24 Mar 2017 12:04:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 5wzl-JjHWn7F for ; Fri, 24 Mar 2017 12:04:48 -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 0CEF51296D7 for ; Fri, 24 Mar 2017 12:04:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7FB6F2009E; Fri, 24 Mar 2017 15:28:25 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5C4C3636E0; Fri, 24 Mar 2017 15:04:47 -0400 (EDT) From: Michael Richardson To: Ralph Droms cc: HOMENET In-Reply-To: <9768C77F-1993-4012-83B5-A077DF0C53A5@gmail.com> References: <1E14B142-680B-4E30-809B-68E03EB6E326@gmail.com> <61FD3EE3-3043-4AB1-9823-6A9D61B1438C@vigilsec.com> <21C8F856-FE3F-42A6-A8ED-888D0797B68B@vigilsec.com> <60C85486-E351-4C42-ADEB-FCBB56F4EA27@fugue.com> <734EC35A-4B1F-43EB-BE37-C34CA46BDA26@fugue.com> <203D2BEA-1008-48A0-9CE2-1FD621C6117F@shinkuro.com> <3134EDC2-FB00-41EA-8338-6E6B196137F1@fugue.com> <572B4EBA-F37F-4E92-A252-44BAF5DE7FF5@shinkuro.com> <95935A30-9B77-4B7A-A0CE-4409134B6163@fugue.com> <9768C77F-1993-4012-83B5-A077DF0C53A5@gmail.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] [DNSOP] WG review of draft-ietf-homenet-dot-03 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, 24 Mar 2017 19:04:50 -0000 --=-=-= Content-Type: text/plain Ralph Droms wrote: >> Ted - has the operation of .homenet, as described in >> draft-ietf-homenet-dot-03, been demonstrated? > Specifically, has the ability to validate queries to .homenet been > demonstrated with a simulated root zone including the entry for > .homenet, properly configured recursive resolvers and properly > configured clients (having received a list of the local recursive > resolvers through DHCP or ND)? Are you asking this is in the context of a recursive resolver that speaks homenet (mDNS, etc.), or one that has no knowledge of .homenet.? I note in the IANA considerations that the root will have an insecure delegation to a blackhole server. So I think the simulation above would need to do that as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljVbc8ACgkQgItw+93Q 3WXPMgf/S6MBbtHOnYhprDapjzQJbj6T9h6uZOauHA+2AdkdRHcdZfu/p2UhsiIz 4EsuEOlU4uRsEhaVvrebKKm8f6QvxlvLXeGEvN8v+6MzoJBFvlnjN6Yf7asdBXAS F/oBhBsrAp00ikv/I/EuRs1gjw7rUAwdl8tRNiBid7o1Z/23BfU9DfAOLKk5VpeC Pp01dEWdOP+bAlpUrbcPUOBmLLXTcYRl/SkD1AkQxspqHU0LuorlPNqJzVX2hbGl OxrTSWyFgpxoHaU62Y5Wmi/gkuIqUU06hCAkdCxqHWGuolw+UA/hqRD7ly8DpiBN 6LC+W+lnj+5x3MTlfzetEyPnd3EZhg== =7bau -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 25 04:40: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 4289612741D for ; Sat, 25 Mar 2017 04:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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=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 0YM7ipoawvfk for ; Sat, 25 Mar 2017 04:40:33 -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 7DB6F128656 for ; Sat, 25 Mar 2017 04:40:33 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id f11so9377800qkb.0 for ; Sat, 25 Mar 2017 04:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kQsDLZaAae6wNU3yxaXFBRxCjH/gQ+0uRO/PUGsmbCs=; b=QWxjiwB735LdmEmh1O0wHGVklUhoZn8w0ZKCxEy6FLiMMAhYGnmpMAp0t8JWCPYqaG z6q3omboVWPdyN5o9CArYyrp/IAyE8Tb19IYposSu8+JGCZhM7hK5L8NwjmDM9qa7wnh rocWzz+ZuyHcT9nvMu1cr+6ZWxPEXrvHfruJ5RDASkQ48QfZBZvsvyAmBqxc3VLvj9HF 5oVaJBpftZeOuu4z7HrvrI0w4AJFKUvGc4F17vB1rC+umV44rsMgC6MdPod1FX223PIo Nt9xWpU3BYSmZMK1RSvAzMi0+yaPuGHgANW2q4uL7cTkNEzz3Mj42pYjFPDw7bluojq6 OGzA== 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=kQsDLZaAae6wNU3yxaXFBRxCjH/gQ+0uRO/PUGsmbCs=; b=e1MsmP9/ZAGxhftHGrr+w8kVUEAt6TmDzkpQykevXaeJ5YFL+eIluC7htzNq7aZZih 2JWzu2W2gFggeXdUpMzVOGESpM/2IYFyE0AnHzP8VrX+ioPS8U/kQPZkVLgfbbq8Z0Zj ML+jFhw4klp4YKzPIEdb/wged7oOoGCoH9UN8z0WOrrSFJ6H2wUp7ZZzbPjucOpBJeQ+ y504MhTrAv2xTb18wjmC3V0XqSmRv5QIbhFwoq6OgbCk9iFiBrt5IDR5MRZ2mbQnJIIu 296HUKq68AJtlf89grJDW0Ty5y/tQmeCoLon97Lj6S1T4oa75yyvpS+a4rENAMU5lQ7+ TMZA== X-Gm-Message-State: AFeK/H0/vQDKhAHItk3HSqaoakP7w/P5INMSCeLjrzqwfGJBwxsfuhe2n1i4ICHRc0b7fg== X-Received: by 10.55.151.3 with SMTP id z3mr11899575qkd.79.1490442032651; Sat, 25 Mar 2017 04:40:32 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:5121:50f3:95c6:b3af? ([2601:18f:801:600:5121:50f3:95c6:b3af]) by smtp.gmail.com with ESMTPSA id q145sm3492583qke.39.2017.03.25.04.40.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Mar 2017 04:40:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ralph Droms In-Reply-To: <23193.1490382287@obiwan.sandelman.ca> Date: Sat, 25 Mar 2017 07:40:27 -0400 Cc: HOMENET Content-Transfer-Encoding: quoted-printable Message-Id: <5FA3E58B-A81B-42BB-8A38-9FAC886A0767@gmail.com> References: <1E14B142-680B-4E30-809B-68E03EB6E326@gmail.com> <61FD3EE3-3043-4AB1-9823-6A9D61B1438C@vigilsec.com> <21C8F856-FE3F-42A6-A8ED-888D0797B68B@vigilsec.com> <60C85486-E351-4C42-ADEB-FCBB56F4EA27@fugue.com> <734EC35A-4B1F-43EB-BE37-C34CA46BDA26@fugue.com> <203D2BEA-1008-48A0-9CE2-1FD621C6117F@shinkuro.com> <3134EDC2-FB00-41EA-8338-6E6B196137F1@fugue.com> <572B4EBA-F37F-4E92-A252-44BAF5DE7FF5@shinkuro.com> <95935A30-9B77-4B7A-A0CE-4409134B6163@fugue.com> <9768C77F-1993-4012-83B5-A077DF0C53A5@gmail.com> <23193.1490382287@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [homenet] [DNSOP] WG review of draft-ietf-homenet-dot-03 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, 25 Mar 2017 11:40:35 -0000 > On Mar 24, 2017, at 3:04 PM, Michael Richardson = wrote: >=20 >=20 > Ralph Droms wrote: >>> Ted - has the operation of .homenet, as described in >>> draft-ietf-homenet-dot-03, been demonstrated? >=20 >> Specifically, has the ability to validate queries to .homenet been >> demonstrated with a simulated root zone including the entry for >> .homenet, properly configured recursive resolvers and properly >> configured clients (having received a list of the local recursive >> resolvers through DHCP or ND)? >=20 > Are you asking this is in the context of a recursive resolver that = speaks > homenet (mDNS, etc.), or one that has no knowledge of .homenet.? It would be interesting to test both scenarios - the former scenario = will test whether the mechanism in homenet-dot works in practice and the = latter will give some indication of how queries in the .homenet zone = will be handled (e.g., leakage to root servers) in non-homenet networks. > I note in the IANA considerations that the root will have an insecure > delegation to a blackhole server. So I think the simulation above = would > need to do that as well. Yes. - Ralph >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Tue Mar 28 10:32:47 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 6BD7E129704; Tue, 28 Mar 2017 10:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 czHkeWf7ULtR; Tue, 28 Mar 2017 10:32:35 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C1612944B; Tue, 28 Mar 2017 10:32:35 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Mar 2017 10:32:32 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 28 Mar 2017 10:32:32 -0700 From: Terry Manderson To: HOMENET CC: "dnsop@ietf.org" Thread-Topic: My assessment of .homenet as described during the WG session yesterday. Thread-Index: AQHSp+lHBXnknGGzd0m0I5wpP+R/Qw== Date: Tue, 28 Mar 2017 17:32:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3573603150_1408478111" MIME-Version: 1.0 Archived-At: Subject: [homenet] My assessment of .homenet as described during the WG session yesterday. 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, 28 Mar 2017 17:32:40 -0000 --B_3573603150_1408478111 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Dear HOMENET and DNSOP WG(s), Wearing the INT AD hat. Firstly, thank you to the DNSOP WG for the deep review, thoughts, and considered responses to my request for review. Secondly, my apologies for not sharing my throughs before the HOMENET session. It would have been impractical to do so as this is a very (VERY) fluid situation with IETF leadership also engaged in discussions. This is simply an iteration of my description of the current situation as delivered yesterday. Do be aware that conversations are continuing and you should NOT take this as a declarative statement. During the HOMENET WG session I specified that for this topic I am comfortable answering _ clarifying _ questions. The same applies here. My answers may or may not change due to the fluid nature of the concern and I hope you appreciate that. My summary of the situation is this. 1) .homenet _COULD_ be added to the special use domain registry based on RFC6761 2) The expected future operation of HOMENET resolution for DNSSEC validating stub resolvers requires a break in the DNSSEC chain of trust. 3) To achieve "2", the document _additionally_ asks IANA to insert an insecure delegation into the root zone 4) The ask for "3" is not covered in IETF policy terms, in fact it tries to put an entry into someone else's registry (the root zone), and will require a set of collaborative discussions with the ICANN community and a new process that handles this situation. There are no expectations that this process will be defined in a reasonable time for the uses of HOMENET. Options, possibly not an exhaustive list A) seek a .homenet special use domain with the request for an insecure delegation in the root zone. (This is what the document asks for NOW, and here we are) B) seek a .homenet special use domain WITHOUT the delegation request AND ask the IETF/IESG/IAB to commence the discussion with the ICANN community to achieve an insecure delegation c) seek a .arpa insecure special use delegation d) go for "B" and if that doesn't work shift to "C" Each of these have different positive and negatives in a raw technical sense, UI design desires, and policy and political frames. Again, this situation is fluid and as discussions evolve I will provide more information when it is appropriate. In the mean-time I would very much like everyone to take a calming breath and understand that I am taking a very pragmatic view of this concern. Cheers, Terry INT AD --B_3573603150_1408478111 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFFLX sKZsujj++k14jIIGdSiy5LBnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE3MDMyODE3MzIzMFowDQYJKoZIhvcNAQEBBQAEggEAseXG3LFeXso1n5K4Yo2Q kobUxyDoyrQCmfXvPusMvsv4xxrbCukI4meg9OP6uIDGaA7yMjqr6iq/hffcV5BbZ7MLtVXF 7T9j9XOjK1dfB7ueZloNC3CGnSGcH4wg9V+uuDN2/7VRYj6vDq1pLPdCiRi8tbfI4IHPFYlK 1lZ1JSzeD8ubGy0CwNfQuykJsDV8j9eFOaID+0xKqb+YXCjVG1f0sR6dZuhKYCgwgzmSnUEv 7HJ6cBGaTs7kyD+DHCAd3wCLfEVs72fmrvGG2xDixHFV/GQhr55+cSH37L4tHz2lASneLBWs giwAtt04qcjSf009F+uNo4aXxh8XzOG9CQ== --B_3573603150_1408478111-- From nobody Wed Mar 29 07:48: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 D5648129411 for ; Wed, 29 Mar 2017 07:48:47 -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, RP_MATCHES_RCVD=-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=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 MPF_9wOsK7-o for ; Wed, 29 Mar 2017 07:48:45 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 B456E128ACA for ; Wed, 29 Mar 2017 07:48:45 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id l7so235123ioe.3 for ; Wed, 29 Mar 2017 07:48:45 -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=rrFFn/bIW62jfAjjAcLPhkRJ+ExX3JrvspIBkTxvn8I=; b=exch29fQB2YX7GsOBpvH1YXlgzX78chz9qig91NTEd1LK7WGT14/C8Lh8YCj4HMhhE E2HVhM2cmOPhrVIRIgTQ+S1chYtW5tVvmIvp3a7WYrW1d0OHzGhJLh5CfnhUT56Mt1pK Bw2POCkgrut4N45TmmGnFcqDPABAVgEDonunHjFbj5Ca6Akn26ldlnCDtTwFjPOhuXHt 9OT47oqyvt3FhP2xxYEvaghAIaiyCHoOq8qLk4vLgJc/YkIGYoOvgcpBwNZu4n3v/+la qSCV9i6UUTClAkXC0p66J50R29P4agiPw9KmhuLBZoUPbwfSdsrTaBXr1vwOWYUOZYFh oU8g== 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=rrFFn/bIW62jfAjjAcLPhkRJ+ExX3JrvspIBkTxvn8I=; b=GAaZT0V8/KPZGpB8vqLsF93zQoCpxJdRkXERNKeVEz1O5Hqw/H60HLz6ZMp54B4cZ0 OonpCWX0lTYVzoOmZPys8W/0G3kWRKo18VpV9tYCfaVzcLsA+XTzEJOYMjRoIJT09BGY iyA9DfctkxhM+KyJXPUj6oby0FgQKfBb6MBHreD3IcPsxw3Tkzk+oIpzbPpsQEgPT0Vh T3fnbgaYLKAeq4wDhuxmtsf82ZZ/+eKnzOl6nuMJISxiFDZ1bx3/fisyru1yCkambmF8 JXeh/eWiwpYRGMvKMKbiVM0u+1WNVEABDuv892o9wvGjeYa2DzvIyYtMAES1aoihR0OD 63XA== X-Gm-Message-State: AFeK/H1q1muxh4X+V4jiY6ZFRsTYANx1ShtnIt+7BgISvmnA758YlNR3lElmPaojh/9U7Ldv X-Received: by 10.107.28.73 with SMTP id c70mr1189811ioc.198.1490798924913; Wed, 29 Mar 2017 07:48:44 -0700 (PDT) Received: from t2001067c0370199845020a80e0eed59e.v6.meeting.ietf.org (t2001067c0370199845020a80e0eed59e.v6.meeting.ietf.org. [2001:67c:370:1998:4502:a80:e0ee:d59e]) by smtp.gmail.com with ESMTPSA id v185sm3413279itf.11.2017.03.29.07.48.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 07:48:44 -0700 (PDT) From: james woodyatt Message-Id: <0BF0317B-6411-4D84-BFBE-8011D0BE27D2@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4AA293F1-D937-44F5-BA15-556A4F7ED997" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 29 Mar 2017 09:48:43 -0500 In-Reply-To: Cc: HOMENET , "dnsop@ietf.org" To: Terry Manderson References: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [homenet] My assessment of .homenet as described during the WG session yesterday. 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, 29 Mar 2017 14:48:48 -0000 --Apple-Mail=_4AA293F1-D937-44F5-BA15-556A4F7ED997 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Terry, Clarifying questions here... On Mar 28, 2017, at 12:32, Terry Manderson = wrote: >=20 > My summary of the situation is this. >=20 > 1) .homenet _COULD_ be added to the special use domain registry based = on RFC6761=20 >=20 > 2) The expected future operation of HOMENET resolution for DNSSEC = validating stub resolvers requires a break in the DNSSEC chain of trust. >=20 > 3) To achieve "2", the document _additionally_ asks IANA to insert an = insecure delegation into the root zone >=20 > 4) The ask for "3" is not covered in IETF policy terms, in fact it = tries to put an entry into someone else's registry (the root zone), and = will require a set of collaborative discussions with the ICANN community = and a new process that handles this situation. There are no expectations = that this process will be defined in a reasonable time for the uses of = HOMENET. q1. What precisely about =E2=80=9C3=E2=80=9D is not covered in IETF = policy terms? That the document directs IANA to request a delegation in = the root zone? Or that the document directs IANA to request an = *insecure* delegation in the root zone, whereas a secure delegation = *would* be adequately covered? Or both of these? q2. If the answer to q1 is that both aspects of =E2=80=9C3=E2=80=9D are = not covered in IETF policy terms, and that each one will require a set = of collaborative discussions with the ICANN community and new processes = that handle each of these situations, are there any expectations about = which of the two processes, if there are two and not just one, can be = defined in a workable period of time for HOMENET? --james woodyatt > --Apple-Mail=_4AA293F1-D937-44F5-BA15-556A4F7ED997 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Terry,

Clarifying questions here...

On Mar 28, 2017, at 12:32, Terry = Manderson <terry.manderson@icann.org> wrote:

My = summary of the situation is this.

1) = .homenet _COULD_ be added to the special use domain registry based on = RFC6761

2) The expected future operation = of HOMENET resolution for DNSSEC validating stub resolvers requires a = break in the DNSSEC chain of trust.

3) To = achieve "2", the document _additionally_ asks IANA to insert an insecure = delegation into the root zone

4) The ask for = "3" is not covered in IETF policy terms, in fact it tries to put an = entry into someone else's registry (the root zone), and will require a = set of collaborative discussions with the ICANN community and a new = process that handles this situation. There are no expectations that this = process will be defined in a reasonable time for the uses of HOMENET.

q1. = What precisely about =E2=80=9C3=E2=80=9D is not covered in IETF policy = terms? That the document directs IANA to request a delegation in the = root zone? Or that the document directs IANA to request an *insecure* = delegation in the root zone, whereas a secure delegation *would* be = adequately covered? Or both of these?

q2. If the answer to q1 is that both aspects of = =E2=80=9C3=E2=80=9D are not covered in IETF policy terms, and that each = one will require a set of collaborative discussions with the ICANN = community and new processes that handle each of these situations, are = there any expectations about which of the two processes, if there are = two and not just one, can be defined in a workable period of time for = HOMENET?

--james woodyatt <jhw@google.com>



= --Apple-Mail=_4AA293F1-D937-44F5-BA15-556A4F7ED997-- From nobody Wed Mar 29 07:51:43 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 6E2A6128656 for ; Wed, 29 Mar 2017 07:51:36 -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, 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=algebras-org.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 upgO3Rk88zPp for ; Wed, 29 Mar 2017 07:51:34 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 0B13C128DF3 for ; Wed, 29 Mar 2017 07:51:34 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id z204so20498085vkd.1 for ; Wed, 29 Mar 2017 07:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MD5FkufWFYicQUVrhKa3TlMAaYawfdUO8KgSyg2Yeqo=; b=OBPwfCG7b+yynQBBYsHS5apYsMoyVbMVEgl9mVeUr/k05f2p6cay3t5qOaUnMCYR+Y fZgtcuiA6boWS9gfKSAHJXMPt1biSk4R9axYJeXmehBguVqxaztJZuLuV3GUH6oXdPAk T7ZR/cVmCWCHCctzQM33drQ8DslpjWmkoQm9OqfHz/Ivln4ddr1vAv1WdB6xWrosSgup yppZC8IMAeoHGXyVHHNaYUYPNEKOl1ewPi/NOMko5jZw0vlaQhI09x+sqUxWzPU13Qbq 5c+3vpW+ta36VwE443TUPRAuAVCvFwCFnkLKtOj5jHSDX2AuLQm4DJnVIIpT+1AYtTHF kFBA== 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=MD5FkufWFYicQUVrhKa3TlMAaYawfdUO8KgSyg2Yeqo=; b=nX5wUkO8l1QnTbxo6DKHuQb2sQgubF7E5UKxRcB+vomalazHgBlTop3+/aSnVHFrOw 5kq8XWuo1mNuV1hy2c80vR8zfGPM2z1vdnUzXJixZInXjjB1aP1TLz0UafRqFukVrQ2H +ozSGhI2etIDBs0MHhPDyiWMNZZNqrVoUB87TFOI8wQYYWEN50vs7QGqXGWsPm5jeM3F N9IVjcxXb4Te1T7SiDXtTkWgLWjA7TYdV6f8WffdPUQTX8ZtvQZ69g5lwSgKf3iIAjIs fM6zOzgKAXe3LFIp263zc/1hj2nGXLwKIrJ3V2I3yzuuajYHrfmq/pe/kylyCBAFeNW3 ykAQ== X-Gm-Message-State: AFeK/H2RkzggP6fWbztnIkSXI0qpwVv7GPWjqsDMiwWx4J7YyiEsMBWP1aL/mfh0B1ac9u0X2uxKJDsK1ACXGA== X-Received: by 10.159.48.20 with SMTP id h20mr393455uab.49.1490799092939; Wed, 29 Mar 2017 07:51:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.20 with HTTP; Wed, 29 Mar 2017 07:51:32 -0700 (PDT) X-Originating-IP: [2001:67c:370:128:f4d9:ba6:ceb5:82fb] In-Reply-To: <0BF0317B-6411-4D84-BFBE-8011D0BE27D2@google.com> References: <0BF0317B-6411-4D84-BFBE-8011D0BE27D2@google.com> From: George Michaelson Date: Wed, 29 Mar 2017 09:51:32 -0500 Message-ID: To: james woodyatt Cc: Terry Manderson , HOMENET , "dnsop@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 29 Mar 2017 14:51:36 -0000 sign it with a bad key or bad DS. this goes to SERVFAIL and its NXDOMAIN. -G On Wed, Mar 29, 2017 at 9:48 AM, james woodyatt wrote: > Hi Terry, > > Clarifying questions here... > > On Mar 28, 2017, at 12:32, Terry Manderson > wrote: > > > My summary of the situation is this. > > 1) .homenet _COULD_ be added to the special use domain registry based on > RFC6761 > > 2) The expected future operation of HOMENET resolution for DNSSEC validat= ing > stub resolvers requires a break in the DNSSEC chain of trust. > > 3) To achieve "2", the document _additionally_ asks IANA to insert an > insecure delegation into the root zone > > > 4) The ask for "3" is not covered in IETF policy terms, in fact it tries = to > put an entry into someone else's registry (the root zone), and will requi= re > a set of collaborative discussions with the ICANN community and a new > process that handles this situation. There are no expectations that this > process will be defined in a reasonable time for the uses of HOMENET. > > > q1. What precisely about =E2=80=9C3=E2=80=9D is not covered in IETF polic= y terms? That the > document directs IANA to request a delegation in the root zone? Or that t= he > document directs IANA to request an *insecure* delegation in the root zon= e, > whereas a secure delegation *would* be adequately covered? Or both of the= se? > > q2. If the answer to q1 is that both aspects of =E2=80=9C3=E2=80=9D are n= ot covered in IETF > policy terms, and that each one will require a set of collaborative > discussions with the ICANN community and new processes that handle each o= f > these situations, are there any expectations about which of the two > processes, if there are two and not just one, can be defined in a workabl= e > period of time for HOMENET? > > --james woodyatt > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Wed Mar 29 08:04: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 7DDF5126DD9; Wed, 29 Mar 2017 08:04:12 -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 tQYj2VUu4ADE; Wed, 29 Mar 2017 08:04:10 -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 E3634127599; Wed, 29 Mar 2017 08:04:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 938BB200A3; Wed, 29 Mar 2017 11:28:03 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BBB12636E0; Wed, 29 Mar 2017 11:04:08 -0400 (EDT) From: Michael Richardson To: casm@ietf.org, anima@ietf.org cc: Brian E Carpenter , Mark Townsley , homenet@ietf.org In-Reply-To: <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.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] prefix assignment 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, 29 Mar 2017 15:04:13 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable This discussion started in a private thread, so I'll try to bring people up-to-date by repeating and moving around text. The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is to do distributed prefix allocation. This is very much in the space of *coordinated* address management. (My take, BTW, is that CASM should be considered the first spin-off WG From=20ANIMA...) Mark and Brian discussed how HNCP does prefix distribution within Homenet. Brian then suggests: brian> But if the CE includes a little autonomic service agent (ASA) which brian> is in the ISP's security domain (not the SOHO domain), it can act = for brian> HNCP to solicit address space from the ISP. That's the southern si= de brian> of the CASM model and the northern side of HNCP. I asked a simple question: don't we have DHCPv6 for this? I also then asked: > a) the CPE device is now part of the ISP's ACP. > That's okay if the CPE device is owned by the ISP and/or the CPE devi= ce > includes some kind of trusted computation environment. > {But a CPE owned by the ISP, might not be trusted by the home owner, > so another router in between would be needed, Brian answered: > Really? Why not? I don't think that the ISP can trust to have code controlled by end users running in their ACP domain. I also think that many end-users will be quite reasonably upset that their ISPs can snoop on their internal traffic. This may in fact violate many work-at-home agreements; which is often the case of why you see multiple routers/firewalls in documents like https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router. (Fred had more interesting diagrams in presentations, which I could dig up) >> b) DHCPv6 PD is already the protocol that solves prefix allocation a= cross >> trust boundaries. > Indeed. That's why we have "PD supported" as a Boolean property of t= he > PrefixManager objective. There's no intention to undermine PD. Why do I need to run a protocol in order to find if I can run a protocol, when DHCP has the same mechanism already. And use of DHCPv6 itself is well defined in cable and DSL connections already. >> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that d= eals with >> prefixes. It would speak DHCPv6-PD to the south, and GRASP/ASA to t= he north. > Yes, the DSLAM is definitely a good place to put one. >> North of the ISP's device would be the ISP's (distributed) IPAM. >> GRASP/ASA-Prefix would be the protocol between. > Anyway, my point is that these approaches (ANIMA, HNCP and PD) are > complementary not competitors. I don't see you saying that. I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and HN= CP in the home) such that they interact directly, rather than using PD. You say this right here: brian> But if the CE includes a little autonomic service agent (ASA) which =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljbzOgACgkQgItw+93Q 3WWBcgf8CcE79ZLXXvDgkBd6u1TuXKIzWofyjbAJIC/ogOvh9QeCwsOi/WP89BNC EDxd6YytkRgHXyebOK7+L6PA3dQfUJBkcUUcAmJVJHfJT2lU0505TfAXIuQ6jPuU oWFjyzs/dG43v2wMd5nkMN+IcXIh5ceVeDagRkRW5GagItfbfqq4HHflSzrSHaRI +I4/tAd5P+KCBoX7N7hvI5TJ1W+xp1mBIVA0U/G673VeGFCyz1VQTnu+M+nRoY/l BBrxZrB8iZnC0jCSZjNp1Ki/5drlsQxAiT2XENrkNw5YFi6cEj+zLQSysgbuezmw 4iRD/nfxfrrLFv9dJUa5PkVn5vNMZA== =mM8R -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 29 08:08: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 8056D127599; Wed, 29 Mar 2017 08:07:57 -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 wIlGeVozT-OI; Wed, 29 Mar 2017 08:07:55 -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 BE8051293FB; Wed, 29 Mar 2017 08:07:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DFF75200A3; Wed, 29 Mar 2017 11:31:49 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0D772636E0; Wed, 29 Mar 2017 11:07:55 -0400 (EDT) From: Michael Richardson To: Terry Manderson cc: HOMENET , "dnsop\@ietf.org" In-Reply-To: References: 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] My assessment of .homenet as described during the WG session yesterday. 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, 29 Mar 2017 15:07:58 -0000 --=-=-= Content-Type: text/plain Terry Manderson wrote: > B) seek a .homenet special use domain WITHOUT the delegation request > AND ask the IETF/IESG/IAB to commence the discussion with the ICANN > community to achieve an insecure delegation > c) seek a .arpa insecure special use delegation > d) go for "B" and if that doesn't work shift to "C" Is there some reason we can not proceed with "C", concurrently with (B). This might cause stub resolvers to have to have two cases (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy and attempt interop with SOMETHING.arpa NOW, and it would more clearly permit "home." to be removed from code. > Again, this situation is fluid and as discussions evolve I will provide > more information when it is appropriate. In the mean-time I would very > much like everyone to take a calming breath and understand that I am > taking a very pragmatic view of this concern. Thank you! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljbzcoACgkQgItw+93Q 3WXFZQf9FBGW7E4sBt6/3t9LSXQzTyku3C1fTPvtRyc7fgGSDILAHTfU9y3x8Utr DPPZwybycIlS9IO7XTUq3NU2LNMkkh1qwGmVRTzYQSR0rM2i/TU18O5VFP9hAwDl E1pT+LvTo8YlVuz/c7gWKsZw7t4ixmgUZwCGCB1DeTeBX3mfJxzUgXMWtmeqkF7s zM8JsO2OFTo1l7P3SdX3JoVxodxyooZwMK174+Zvc+sU3guUYR78kSnYzsf4KtUn dovRJ1F2bqMQsmr6QXVaLhMWojl5mClhtZ9E8G0xXxccYMe0cE8C5LZnu4ONlHf4 6QDAbXNrBv44u0WxEoWyUo2qzkUEtA== =z9yj -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 29 08:37: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 0A0A1129540; Wed, 29 Mar 2017 08:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 h5N5CYR3Qu3y; Wed, 29 Mar 2017 08:37:14 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB2B128D19; Wed, 29 Mar 2017 08:37:12 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 29 Mar 2017 08:37:10 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 29 Mar 2017 08:37:10 -0700 From: Terry Manderson To: james woodyatt CC: HOMENET , "dnsop@ietf.org" Thread-Topic: [homenet] My assessment of .homenet as described during the WG session yesterday. Thread-Index: AQHSp+lHBXnknGGzd0m0I5wpP+R/Q6GsXKWAgAC1KgA= Date: Wed, 29 Mar 2017 15:37:09 +0000 Message-ID: <380F7E71-AC41-4F8D-A048-DC732CF92086@icann.org> References: <0BF0317B-6411-4D84-BFBE-8011D0BE27D2@google.com> In-Reply-To: <0BF0317B-6411-4D84-BFBE-8011D0BE27D2@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3573682628_169053644" MIME-Version: 1.0 Archived-At: Subject: Re: [homenet] My assessment of .homenet as described during the WG session yesterday. 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, 29 Mar 2017 15:37:17 -0000 --B_3573682628_169053644 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi James, Q1. Both. The root zone, as a registry, is not an IETF registry. Q2. My guess, and I am really guessing here, that if a process were to be c= reated by the ICANN community to accept such requests from the IETF, it woul= d be encompassing of both. Cheers Terry=20 On 30/03/2017, 12:48 AM, "homenet on behalf of james woodyatt" wrote: =20 q1. What precisely about =E2=80=9C3=E2=80=9D is not covered in IETF policy terms? T= hat the document directs IANA to request a delegation in the root zone? Or t= hat the document directs IANA to request an *insecure* delegation in the roo= t zone, whereas a secure delegation *would* be adequately covered? Or both of these? =20 =20 q2. If the answer to q1 is that both aspects of =E2=80=9C3=E2=80=9D are not covered= in IETF policy terms, and that each one will require a set of collaborative= discussions with the ICANN community and new processes that handle each of = these situations, are there any expectations about which of the two processes, if there are two and not just one, c= an be defined in a workable period of time for HOMENET? =20 =20 =20 --james woodyatt =20 =20 =20 =20 =20 =20 --B_3573682628_169053644 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFIk0 /bq3tU7JjpvK/ls2e2DeE8GkMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE3MDMyOTE1MzcwOFowDQYJKoZIhvcNAQEBBQAEggEAQYZCe5rBNpjgMcCOziS8 IOxNxgRmF/lFcXSCtKQFWVw5aQvSA1P6HPVKfeRCvjwQJU0ojGBoE6AUMnrXzI/PmICr1DQG J0cv0G+LfVM21wU9GPJjGm1sFzClPg+1+RqkOffj2wVOzsJ+koegXUSkMra6pYiQW91c4kZL IidX9R129qx1AAdRb/8qCzyQvYhCuSD5//zrNFfLBK019QNTTFJPJd5ZRg7d6BrTKjA8EDug qNOx94DB68PrJ7AXV/HlpQ6A+3Y6Oky+RM0GSZ+RIaWRfKSBz3T2X5jhEMfkVa4qWCjOGTjS sRSkaER/MSwIYtQUlvgv5NN5Uy+l0CzLpg== --B_3573682628_169053644-- From nobody Wed Mar 29 08:41: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 A70EE126557; Wed, 29 Mar 2017 08:41:43 -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, 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 PTu2Jrn0nSkK; Wed, 29 Mar 2017 08:41:41 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCBE1297C3; Wed, 29 Mar 2017 08:41:39 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 29 Mar 2017 08:41:37 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 29 Mar 2017 08:41:37 -0700 From: Terry Manderson To: Michael Richardson CC: HOMENET , "dnsop@ietf.org" Thread-Topic: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday. Thread-Index: AQHSp+lHBXnknGGzd0m0I5wpP+R/Q6GsYgKAgACxDQA= Date: Wed, 29 Mar 2017 15:41:36 +0000 Message-ID: References: <29150.1490800075@obiwan.sandelman.ca> In-Reply-To: <29150.1490800075@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3573682896_1803442087" MIME-Version: 1.0 Archived-At: Subject: Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 29 Mar 2017 15:41:43 -0000 --B_3573682896_1803442087 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Hi Michael, There is no policy or technical barrier to proceeding with SOMETHING.arpa. Procedurally that, of course, would necessitate some WG discussion and consensus. Cheers Terry On 30/03/2017, 1:07 AM, "DNSOP on behalf of Michael Richardson" wrote: Terry Manderson wrote: > B) seek a .homenet special use domain WITHOUT the delegation request > AND ask the IETF/IESG/IAB to commence the discussion with the ICANN > community to achieve an insecure delegation > c) seek a .arpa insecure special use delegation > d) go for "B" and if that doesn't work shift to "C" Is there some reason we can not proceed with "C", concurrently with (B). This might cause stub resolvers to have to have two cases (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy and attempt interop with SOMETHING.arpa NOW, and it would more clearly permit "home." to be removed from code. > Again, this situation is fluid and as discussions evolve I will provide > more information when it is appropriate. In the mean-time I would very > much like everyone to take a calming breath and understand that I am > taking a very pragmatic view of this concern. Thank you! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --B_3573682896_1803442087 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFLSR s2CqS31wZMKx50rA4bSOgHaPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE3MDMyOTE1NDEzNlowDQYJKoZIhvcNAQEBBQAEggEARhUNW10Y081xIRKGqfUP ORjuicdtMwB8SnC4MFFe39o4RAcqQciIGbezIcgFHpTXnhw4kP8tZFSgnUA+dw/jDNmNDy8h 9WBbP4rps7r/BAHAwrJua5ZeKro2gAZ355EWcKe8lxB8Hln3xuvHmFvViK7gvTRsmVsIty54 mN6CZutWM7lg+Ph7I22fEVXjA+K0uA65hqpfqaVvbUEuFlicq5S1l/+6ARsBYNZxywzHmtdC KKwRDieOMg4Iu4sfoU36/s4kT/upeb9InjBNYyHGcxGIjz+efI1a+huiX+MDK7Z+JBPgRkNs rXHRzzbMhIaS/EUF/3K7B5MAGhMQYE+SmQ== --B_3573682896_1803442087-- From nobody Wed Mar 29 09:13: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 3563012943D; Wed, 29 Mar 2017 09:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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=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 sqhOfUkWceSO; Wed, 29 Mar 2017 09:13:46 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 7470F129876; Wed, 29 Mar 2017 09:13:39 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id f84so278811ioj.0; Wed, 29 Mar 2017 09:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DGYijWLnAJNW+R5cgLp4KNibgxvBxyPBwdlW20qNAWc=; b=JNRKI2yDcdhEGe8fn7YYL0ufmT1iuvACNDaov8lBqJchxjnkSWoBEI7kpDzPP0V69Z UeNSyyCxsLMue4oWF34pA2qWUnW7B4Ajw9eyr3Z3a6l6pOR+jec3Q3e4A91eGnPvKwP5 B/v25xwVhingtAO08iHw0AhfkNFU9RM4EQ7n9gVK7gejEYNhStu8mQG4HbX6W44gWtBX 6uld7afMKWlZfPpJEqfujywOXQG3xyJMpE1wDOstJMGLGmqMdRjKN5ARR1qqZnugoPoH yoj44qM2F008lq4dxol8VhtYeG/dJZ/WflIK/+oByAWY4XhFZUvH/B4IXhtcmZRcGEBD S/vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=DGYijWLnAJNW+R5cgLp4KNibgxvBxyPBwdlW20qNAWc=; b=rew6F+OhFn/US34F9UbNRVB0nQcOhJ7RasBRnMeVAx7p9Id8NUSYGN7+fQrL+HPfvc qDoGMuYLGyGWzAHej2I/2nTbAaejbHOdp59PqZvwso9gfqykWO0l9hG0dcp12K7+2JK+ RpCiba4YwMH6UA8eFqCW/gbhXZH3vrtmIzbKs+GWrqhtQLQZsoQJ6YLOywRnaVMOUZys U/KsWv29fYl+fD8G6Fo+qWsW8jrQq7IAEtBLbcko8n4TprBtfjQX8i2GZYFwSsSIsVqS SC/NMvSjPT7BQltATbm0JqhNvBgCK/Y1babCBEy/nZkae+yho5c4jc7rUuW8+vtCMsvs hDCg== X-Gm-Message-State: AFeK/H1qP5aViKzEQrR+f1iuX1rgjI5JcAe7G51gqnKlWuSZEF/9BWCxRg178JlgzqFq6w== X-Received: by 10.107.47.130 with SMTP id v2mr1507287iov.201.1490804018715; Wed, 29 Mar 2017 09:13:38 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o97sm1760077ioi.53.2017.03.29.09.13.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 09:13:38 -0700 (PDT) To: Michael Richardson , casm@ietf.org, anima@ietf.org References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> Cc: Mark Townsley , homenet@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 30 Mar 2017 05:13:43 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <28218.1490799848@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [homenet] prefix assignment 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, 29 Mar 2017 16:13:49 -0000 OK, I'll front-post. Where you want to plug in an ASA (autonomic service agent) is anywhere you want plug in some intelligence to govern an automatic process. Intelligence, for example, to figure out what to do if the user side asks for a /48 and the ISP offers a /60. So the ASA might negotiate a compromise at /56 and then PD does its thing. But we didn't want to exclude a scenario where PD isn't available, hence a flag is included. About the domain boundary: > I don't think that the ISP can trust to have code controlled by end users > running in their ACP domain. Right. But in ISP-provided CEs this could presumably be fixed, because that code would be locked down. In a store-bought CE, isn't this exactly where BRSKI will help us? There is certainly an issue for home-made CE images, but they will be a tiny minority of users. Brian On 30/03/2017 04:04, Michael Richardson wrote: > > This discussion started in a private thread, so I'll try to bring people > up-to-date by repeating and moving around text. > > The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is > to do distributed prefix allocation. This is very much in the space of > *coordinated* address management. > > (My take, BTW, is that CASM should be considered the first spin-off WG > From ANIMA...) > > Mark and Brian discussed how HNCP does prefix distribution within Homenet. > > Brian then suggests: > > brian> But if the CE includes a little autonomic service agent (ASA) which > brian> is in the ISP's security domain (not the SOHO domain), it can act for > brian> HNCP to solicit address space from the ISP. That's the southern side > brian> of the CASM model and the northern side of HNCP. > > I asked a simple question: don't we have DHCPv6 for this? > > I also then asked: > > > a) the CPE device is now part of the ISP's ACP. > > That's okay if the CPE device is owned by the ISP and/or the CPE device > > includes some kind of trusted computation environment. > > {But a CPE owned by the ISP, might not be trusted by the home owner, > > so another router in between would be needed, > > Brian answered: > > Really? Why not? > > I don't think that the ISP can trust to have code controlled by end users > running in their ACP domain. > > I also think that many end-users will be quite reasonably upset that their > ISPs can snoop on their internal traffic. This may in fact violate many > work-at-home agreements; which is often the case of why you see multiple > routers/firewalls in documents like > https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router. > > (Fred had more interesting diagrams in presentations, which I could dig up) > > >> b) DHCPv6 PD is already the protocol that solves prefix allocation across > >> trust boundaries. > > > Indeed. That's why we have "PD supported" as a Boolean property of the > > PrefixManager objective. There's no intention to undermine PD. > > Why do I need to run a protocol in order to find if I can run a protocol, > when DHCP has the same mechanism already. And use of DHCPv6 itself is well > defined in cable and DSL connections already. > > >> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that deals with > >> prefixes. It would speak DHCPv6-PD to the south, and GRASP/ASA to the north. > > > Yes, the DSLAM is definitely a good place to put one. > > > >> North of the ISP's device would be the ISP's (distributed) IPAM. > >> GRASP/ASA-Prefix would be the protocol between. > > > Anyway, my point is that these approaches (ANIMA, HNCP and PD) are > > complementary not competitors. > > I don't see you saying that. > > I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and HNCP > in the home) such that they interact directly, rather than using PD. You > say this right here: > > brian> But if the CE includes a little autonomic service agent (ASA) which > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Wed Mar 29 13:11: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 8AE841293E3 for ; Wed, 29 Mar 2017 13:11:02 -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 46MDuf7XkaDV for ; Wed, 29 Mar 2017 13:11:00 -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 8A3D81298AF for ; Wed, 29 Mar 2017 13:10:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DBDDF203B7 for ; Wed, 29 Mar 2017 16:34:52 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 483B1636E0 for ; Wed, 29 Mar 2017 16:10:57 -0400 (EDT) From: Michael Richardson To: HOMENET In-Reply-To: References: <29150.1490800075@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: [homenet] ask for .arpa 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, 29 Mar 2017 20:11:02 -0000 --=-=-= Content-Type: text/plain Terry Manderson wrote: Terry> There is no policy or technical barrier to proceeding with Terry> SOMETHING.arpa. Procedurally that, of course, would necessitate some WG terry> discussion and consensus. ... Terry> c) seek a .arpa insecure special use delegation mcr> This might cause stub resolvers to have to have two cases mcr> (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy mcr> and attempt interop with SOMETHING.arpa NOW, and it would more clearly mcr> permit "home." to be removed from code. I believe that HOMENET should proceed immediately with asking the IAB for .arpa. I think that getting "home." removed from implementation is pretty important. let's do this ask concurrently with deciding what is. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljcFNAACgkQgItw+93Q 3WXVPQf/bLnNvl3oFEUAKph1NqMbFfcASkar5xgxUAtOBSxbSP83rk2I3ha+UUHd h/Rn1Ve36hWbSejV9Ty3ZbcNYMgW8FSbYWI+l1RrgNHG9ru4ucIEIFwGFzv/nZOR HHQwVgmMvcnDj67YmKVMZU8ylUFATT1sBE6Ky06jm3qMHGcQwL/g2pnLe/aPqQoA uXvqBOaBlwRMAE6NukHCRg3nClfiK3za3mLXRS2rxGEE5YKZv23d/LFhuV9+6jRB ZRO98l4HDCeuJ3KK0inp6M+25cx6kAxLKIyCg4Ika/iOFg938Q12+CZ3Sf2CILlD DHRsA5R0MEovf6lOYLj0PSub5oKnpA== =/7Qk -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 29 13:16: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 7A8ED127BA3; Wed, 29 Mar 2017 13:16:31 -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 IsKGJZS7LrWD; Wed, 29 Mar 2017 13:16:29 -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 C07D812704B; Wed, 29 Mar 2017 13:16:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F60C203B7; Wed, 29 Mar 2017 16:40:24 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 029BD636E0; Wed, 29 Mar 2017 16:16:29 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: casm@ietf.org, anima@ietf.org, Mark Townsley , homenet@ietf.org In-Reply-To: References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@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] prefix assignment 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, 29 Mar 2017 20:16:32 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Where you want to plug in an ASA (autonomic service agent) is anywhere > you want plug in some intelligence to govern an automatic process. > Intelligence, for example, to figure out what to do if the user side > asks for a /48 and the ISP offers a /60. So the ASA might negotiate > a compromise at /56 and then PD does its thing. But we didn't want > to exclude a scenario where PD isn't available, hence a flag is > included. To put this is pseudo-(monty)pythonesq: Customer: Hi, I'd like to buy a parrot. Store: Would you like a Blue Parrot or a Red Parrot? Customer: I'd like a Blue Parrot. Store: I'm sorry, but we don't sell Parrots. I just don't see the point of the ASA here. If DHCPv6-PD isn't available, then it's not a compliant ISP connection (RFC7204) and it's outside of the scope of homenet to begin with. > About the domain boundary: >> I don't think that the ISP can trust to have code controlled by end users >> running in their ACP domain. > Right. But in ISP-provided CEs this could presumably be fixed, because > that code would be locked down. In a store-bought CE, isn't this exactly > where BRSKI will help us? There is certainly an issue for home-made CE > images, but they will be a tiny minority of users. No, BRSKI doesn't help the ISP feel safe that the code I am running on my store-bought CE won't attempt to mess with their network. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljcFhwACgkQgItw+93Q 3WUQYwf+I+RwnzYZOAh/cem16Dlxq+EA+qcmCY740lGwg6RmzXYYTy2qWVvvwYOH U2Op4ngX0x1aL6YVGiqJ2Du6KkeMV5InbUMMHksIh11l9szmexGAgQ605/Go8Uri /YHdR32safjVpEiS57VbAR+FLFZooQ9m3UQb617RWL1TMZHvV9X3Ud87KwqikziR A5SEruGC0jWIXZeIcNjCC/vYUcF6LeCwaoGHBHYyhkce0U19jAfVTxY+2xe1su+U l2yhWaG//XGuP2XtI/pS9bbt1aH/cDFekb6tj3BN8viIMqEU4t22yE6SxMK917tC MhSKAMlOR9UcVr5vuQoWG6KRnAwDRw== =LfbD -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 29 13:47: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 0728D12785F; Wed, 29 Mar 2017 13:46:53 -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, FREEMAIL_FROM=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 9FhHh5gQwgGt; Wed, 29 Mar 2017 13:46:51 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 0A6A912956C; Wed, 29 Mar 2017 13:46:51 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id w11so3643529itb.0; Wed, 29 Mar 2017 13:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=F60E85dKcF87/QWxtPhnnfRjuZXf/80TvUSMYICj9KM=; b=JAkNKRsUcHo8rNy1i27TOoSdw6rSe2R2mXtSTF4pvLMp+ZyfWgSRKFudHkfsWIdV5r JjJAItJ4D+yQWn1KE1Pyaph25j7yxPU3l5AaN6C3zDnm/iMGxIzMbV2LpwgLoUQ30ggz ltZJ4duHOQaZl8FH4/fpPO9rJ6WNTWXaCwk1hiNkhbic67sxtw/1c04EFviwG4lsF/Yt xWMlO9koZ6lyKf0Yic6A72YdEOjRrH3fFadi1FkOd6t2wrGlj6ucWtImN9D9HI71QDxS fWIosHx6bmAvn+orvkqJHRQiZTrj75BMMAP8N3Qk8WjroPb90QImOuSGFycasgxZeDoX HyGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=F60E85dKcF87/QWxtPhnnfRjuZXf/80TvUSMYICj9KM=; b=kHLLRAIhmXVNPlJoZZa52m/U5XxjWKVg1gp8f8mr+J5AZs/vs/KOU0ccTFP7EvaZVd cy6gg1PR5xaFONJtavQUsY+3FApb43kzzqLAhfzLllUj3fR14jn/PbK0vQixm6MB9JW7 HtC2ftGiXfNe6fNrIRlZgaHDIWLtgrbhIpy7RlrRk9rXTbV3PC7hLDEbFI4U5Xt1tXmU jS637QvietE7JWpq9k/csPjsaezRAxEd5ATk+RR9CIhmmUUO/hyiSBRGHvMxGmladNtW YJAf+vxR18NirAvht85RkQSp4MQOa66dyW4PKfSo3Xe7qlll6zYYzNW6auU3tzK8iLEL sCNA== X-Gm-Message-State: AFeK/H1ln8V7TJidnqP+7Kbp/nwvlH0VQ4tU3224Qb/F/OTw5dvCrGOLRFJVCrIGFNh+aQ== X-Received: by 10.36.28.130 with SMTP id c124mr409142itc.17.1490820410424; Wed, 29 Mar 2017 13:46:50 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q185sm3893461itc.22.2017.03.29.13.46.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 13:46:49 -0700 (PDT) To: Michael Richardson References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> Cc: casm@ietf.org, anima@ietf.org, Mark Townsley , homenet@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> Date: Thu, 30 Mar 2017 09:46:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <14579.1490818588@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [homenet] prefix assignment 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, 29 Mar 2017 20:46:53 -0000 On 30/03/2017 09:16, Michael Richardson wrote: > > Brian E Carpenter wrote: > > Where you want to plug in an ASA (autonomic service agent) is anywhere > > you want plug in some intelligence to govern an automatic process. > > Intelligence, for example, to figure out what to do if the user side > > asks for a /48 and the ISP offers a /60. So the ASA might negotiate > > a compromise at /56 and then PD does its thing. But we didn't want > > to exclude a scenario where PD isn't available, hence a flag is > > included. > > To put this is pseudo-(monty)pythonesq: > > Customer: Hi, I'd like to buy a parrot. > Store: Would you like a Blue Parrot or a Red Parrot? > Customer: I'd like a Blue Parrot. > Store: I'm sorry, but we don't sell Parrots. No, it's not really Pythonesque but negotiation is allowed to fail. > I just don't see the point of the ASA here. There's already a thing called an HNCP agent. Why couldn't it be enhanced to negotiate with an upstream ASA for resources? > If DHCPv6-PD isn't available, then it's not a compliant ISP connection > (RFC7204) and it's outside of the scope of homenet to begin with. No disagreement; the idea was simply to ensure that the GRASP objective can communicate that PD is or isn't available. If PD is required in a particular scenario then that parameter will always be set True. > > About the domain boundary: > > >> I don't think that the ISP can trust to have code controlled by end users > >> running in their ACP domain. > > > Right. But in ISP-provided CEs this could presumably be fixed, because > > that code would be locked down. In a store-bought CE, isn't this exactly > > where BRSKI will help us? There is certainly an issue for home-made CE > > images, but they will be a tiny minority of users. > > No, BRSKI doesn't help the ISP feel safe that the code I am running > on my store-bought CE won't attempt to mess with their network. Yes, I see that. (Unless of course we get into much more complex validation and authorization stuff, which seems unlikely to fly.) Brian From nobody Wed Mar 29 13:56: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 4569412945D; Wed, 29 Mar 2017 13:56: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 HP2lVjp_IezK; Wed, 29 Mar 2017 13:56:26 -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 64909129891; Wed, 29 Mar 2017 13:56:25 -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/56228) with ESMTP id v2TKuNUF013675; Wed, 29 Mar 2017 22:56:23 +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 ADB7AD78B7; Wed, 29 Mar 2017 22:56:23 +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 arPhDVrfdgX9; Wed, 29 Mar 2017 22:56:22 +0200 (CEST) Received: from ijon.irif.fr (dhcp-8558.meeting.ietf.org [31.133.133.88]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D7242D78F6; Wed, 29 Mar 2017 22:56:18 +0200 (CEST) Date: Wed, 29 Mar 2017 15:56:22 -0500 Message-ID: <87shlvhkeh.wl-jch@irif.fr> From: Juliusz Chroboczek To: Michael Richardson Cc: casm@ietf.org, anima@ietf.org, homenet@ietf.org In-Reply-To: <28218.1490799848@obiwan.sandelman.ca> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> 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]); Wed, 29 Mar 2017 22:56:23 +0200 (CEST) X-Miltered: at korolev with ID 58DC1F77.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58DC1F77.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 : 58DC1F77.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] prefix assignment 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, 29 Mar 2017 20:56:28 -0000 brian> But if the CE includes a little autonomic service agent (ASA) which brian> is in the ISP's security domain (not the SOHO domain), it can act for brian> HNCP to solicit address space from the ISP. That's the southern side brian> of the CASM model and the northern side of HNCP. HNCP just doesn't care. HNCP has a notion of "External Connection", and an External Connection may provide one or more External Prefixes. HNCP will assign to each link in the HNCP one /64 from each External Prefix. HNCP doesn't care where these External Connection TLVs come from, but it is my understanding that there is WG consensus that DHCPv6-PD is the default mechanism. I don't think there's anything in any of our RFCs that would prevent an implementation from obtaining External Prefixes using a different protocol, e.g. manual configuration, a proprietary provisioning protocol or even algorithmically derived from an IPv4 address (as with 6rd). Both implementations of HNCP are easy to extend with a different mechanism for obtaining External Prefixes, should you wish to experiment. -- Juliusz From nobody Wed Mar 29 14:05: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 0F8C6126DDF; Wed, 29 Mar 2017 14:05:03 -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 METRaPwEtr4c; Wed, 29 Mar 2017 14:05:01 -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 2BFF9124217; Wed, 29 Mar 2017 14:05:01 -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/56228) with ESMTP id v2TL4uiB016063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Mar 2017 23:04:56 +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/56228) with ESMTP id v2TL4uUb006204; Wed, 29 Mar 2017 23:04:56 +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 2813ED78F6; Wed, 29 Mar 2017 23:04:56 +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 wBxGdJggd7pu; Wed, 29 Mar 2017 23:04:55 +0200 (CEST) Received: from ijon.irif.fr (dhcp-8558.meeting.ietf.org [31.133.133.88]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C64B5D78C3; Wed, 29 Mar 2017 23:04:46 +0200 (CEST) Date: Wed, 29 Mar 2017 16:04:50 -0500 Message-ID: <87r31fhk0d.wl-jch@irif.fr> From: Juliusz Chroboczek To: Brian E Carpenter Cc: Michael Richardson , Mark Townsley , homenet@ietf.org, casm@ietf.org, anima@ietf.org In-Reply-To: <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.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, 29 Mar 2017 23:04:56 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 29 Mar 2017 23:04:56 +0200 (CEST) X-Miltered: at korolev with ID 58DC2178.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58DC2178.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58DC2178.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58DC2178.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 : 58DC2178.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58DC2178.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] prefix assignment 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, 29 Mar 2017 21:05:03 -0000 > There's already a thing called an HNCP agent. Why couldn't > it be enhanced to negotiate with an upstream ASA for resources? Could you please clarify what you mean by "negotiate"? Current HNCP implementations are provided with a bunch of External Prefixes, which they then carve into /64, one per prefix. Are you envisioning a scenario where the HNCP implementation actually performs active negotiation on its external interfaces? -- Juliusz From nobody Wed Mar 29 14:39: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 76FE91293EE; Wed, 29 Mar 2017 14:38:58 -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, 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 pKoT4lbMrvUk; Wed, 29 Mar 2017 14:38:56 -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 B8BB71250B8; Wed, 29 Mar 2017 14:38:56 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C9D6203B0; Wed, 29 Mar 2017 18:02:51 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B6D69636E0; Wed, 29 Mar 2017 17:38:55 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: casm@ietf.org, anima@ietf.org, Mark Townsley , homenet@ietf.org In-Reply-To: <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.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] prefix assignment 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, 29 Mar 2017 21:38:58 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> I just don't see the point of the ASA here. > There's already a thing called an HNCP agent. Why couldn't > it be enhanced to negotiate with an upstream ASA for resources? Because it's already done. It's called DHCPv6. It already has extensive running code :-) It's not even that complex. I would love to request address space via ASA from the DHCPv6 server. That would all happen within the ISP's ACP though. Right now (on DSL lines), the address space mostly comes via radius. Which is to say that the problem has been centralized by MBS builders into being someone else's problem. Advertising the address space is often done by OSPFv3, but there are additional things that would be easier for the DHCPv6 server to do, such as the DNS delegations that homenet is working on finishing. I think that CASM could very nicely define/extend the prefix ASA to deal with DNS reverse names, and as the RIRs (George) said, better link the delegated prefix to clear ownership records. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljcKW8ACgkQgItw+93Q 3WU72wf+PPC8ZFrnt9lHQqsaBLizGmYzqdllAEWch6TnQETLwAJjiMk644oPUN+2 GmC8AtgW6PzffL/1zsZHYlMLBn5uM2sZunQBufsW5da9yXkThUeHAsRUQ85n3uGC HI1xFQaCAkrelussMo9OKofLWMLv1repOQURuiKGNdP0OpD1fn/D+ZsCBhEvPx0l 2b8z/V2K0Oed2KCtDwCtYE8mcG9uiK1FCCPa64VLayD4Mw+uIjXrjrDXDX9RhC9V H5AKNiyeS6NXOmMJs/8TdPlzzceXAY7ek5Bp1c/LzJrqiDR0pozQMMOivuXiCRxQ Sc2lpo8VdcT4sC1RiUa4wVD70t4EgA== =D0pq -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 29 14:41: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 529F9129465; Wed, 29 Mar 2017 14:41:49 -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 dOb4eZtLl9LF; Wed, 29 Mar 2017 14:41:47 -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 5D5CB12948C; Wed, 29 Mar 2017 14:41:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6CA89203B0; Wed, 29 Mar 2017 18:05:41 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 92365636E0; Wed, 29 Mar 2017 17:41:45 -0400 (EDT) From: Michael Richardson To: Juliusz Chroboczek cc: Brian E Carpenter , Mark Townsley , homenet@ietf.org, casm@ietf.org, anima@ietf.org In-Reply-To: <87r31fhk0d.wl-jch@irif.fr> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <87r31fhk0d.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] prefix assignment 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, 29 Mar 2017 21:41:49 -0000 --=-=-= Content-Type: text/plain Juliusz Chroboczek wrote: >> There's already a thing called an HNCP agent. Why couldn't >> it be enhanced to negotiate with an upstream ASA for resources? > Could you please clarify what you mean by "negotiate"? Current HNCP > implementations are provided with a bunch of External Prefixes, which they > then carve into /64, one per prefix. Are you envisioning a scenario where > the HNCP implementation actually performs active negotiation on its > external interfaces? Yes, that's what Brian is suggesting. The HNCP daemon would speak GRASP ASA on the "northbound" interface. It wouldn't necessarily speak HNCP. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljcKhkACgkQgItw+93Q 3WX4fAf+P+vJtXc7W3n+tF1e1K8/0EH+L8dyzjmR4yCg6hLICqscAIm/vT6tveB6 4P0Qzmi1TDgYDRZl64aGQ8e044qoURoyh10kj5EHcor5CY+oSA1QKzFseWGzXDCG RLGUbHgrU6Xz/5br+Mf7ACsSyCybCwi/WjRgH6duaIsmM25uQxsuxWukAVeeU4RQ +OAfrTR3MSdiYv/4whiDxCXo1BuGFNqT09zfstcgqTdEA9/9mKL8ZkDNCIsr3pSr deofhFijyNBk/Z8/fUWGjde7Y6UEgffdEB3pLBxZXZdMA7A/SBQP3E22WWTtNC7E 7dlfB2g8faEjPeKtzn7bKf71KGGa9Q== =Ou1x -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 29 14:59: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 0A367126C23; Wed, 29 Mar 2017 14:59: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, 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 utFF5lWxX5mc; Wed, 29 Mar 2017 14:59: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 373C312949E; Wed, 29 Mar 2017 14:59:27 -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/56228) with ESMTP id v2TLxMFl029474; Wed, 29 Mar 2017 23:59:22 +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 91D84D79D6; Wed, 29 Mar 2017 23:59:22 +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 Zk5S5GjTzP9n; Wed, 29 Mar 2017 23:59:21 +0200 (CEST) Received: from ijon.irif.fr (dhcp-8558.meeting.ietf.org [31.133.133.88]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2FC51D79B8; Wed, 29 Mar 2017 23:59:20 +0200 (CEST) Date: Wed, 29 Mar 2017 16:59:22 -0500 Message-ID: <87h92bhhhh.wl-jch@irif.fr> From: Juliusz Chroboczek To: Michael Richardson Cc: Brian E Carpenter , Mark Townsley , homenet@ietf.org, casm@ietf.org, anima@ietf.org In-Reply-To: <1636.1490823705@obiwan.sandelman.ca> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <87r31fhk0d.wl-jch@irif.fr> <1636.1490823705@obiwan.sandelman.ca> 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]); Wed, 29 Mar 2017 23:59:22 +0200 (CEST) X-Miltered: at korolev with ID 58DC2E3A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58DC2E3A.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 : 58DC2E3A.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] prefix assignment 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, 29 Mar 2017 21:59:29 -0000 >> Could you please clarify what you mean by "negotiate"? Current HNCP >> implementations are provided with a bunch of External Prefixes, which they >> then carve into /64, one per prefix. Are you envisioning a scenario where >> the HNCP implementation actually performs active negotiation on its >> external interfaces? > Yes, that's what Brian is suggesting. > The HNCP daemon would speak GRASP ASA on the "northbound" interface. Sorry if I wasn't clear. Would it merely request address space and handle it out using HNCP, or would it actively renegotiate address space in response to HNCP events? If the latter -- why? From nobody Wed Mar 29 14:59: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 A418412964B for ; Wed, 29 Mar 2017 14:59:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=townsley-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 aq0-N8qXh9qx for ; Wed, 29 Mar 2017 14:59:37 -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 58C50129664 for ; Wed, 29 Mar 2017 14:59:36 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id g2so19203866pge.3 for ; Wed, 29 Mar 2017 14:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=townsley-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jdy30LkPv7+/k4RFzav2oaglD/DKg3IeLuwh+qXaS2g=; b=hb3u67wNoDmHZQWuf6bhWg63DgRL3oT8ICryQtagvGzpUEoo6AxAzZblKRq4It6yj0 QvVMswHu8rJQdiQhHiah9g+YQTztArM644MEqiJSPK6fdGtsflNCH4sNx4vmAfz2Tz0Y UhBTOcKhOfPw4AimgYpe7jYpcAQxOuSQuboNWRLOqWZV8cjMYgj4+pbqnFyyBW6YbvoE 5Mota2xb7U1iS0P7EzjQOuwmjC9cCXfKPdjp5GHgOLHLHI9LvGCZgqTo92VdrB2k8Ab7 upJTgNp5E0uChVvW0Fc4UmSxKVyZSlN688L/4pWqJZR4SGppC2OPUmRhkGGTVnq48+7I FYvg== 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=Jdy30LkPv7+/k4RFzav2oaglD/DKg3IeLuwh+qXaS2g=; b=OZUJcY74vnxmLV/OY4e4NEPZ5YEO4+dDEITj0II6obngrvEfo8VmkmSQwGJab9buM3 snHfwJsgnAXALKtGdB5vIPEGmLcHvEPlNcjSw8sWcCbuZyq9w3+7qjxySiZMYO0XnOk8 QJ7IkKGbixI5CXL2hi1IDTX3B1qGF3VmhbgqxuQf3f8slUIaEG9tRnLSg3bO4XC4ljc3 osYsJWNGDUV8pLJcYTnLGuByF7BqLrpwVJ7F18T38n4ygEcAJWpwz5ZqYA2sGFME1N2s bQW5vVTd2ZLZhD9kT2AVS4vuqiurx5m9ae8x6MLD6L5RfEm4GppsUMhfO9zXwQplw5kc zImw== X-Gm-Message-State: AFeK/H12YXYtSPo441zTYwrw5vEuiRO38urIAqR/WJZChQr/7cFID0LEXYrPh6D7r7kcDA== X-Received: by 10.84.218.138 with SMTP id r10mr3101254pli.165.1490824775898; Wed, 29 Mar 2017 14:59:35 -0700 (PDT) Received: from ?IPv6:2001:420:c0cc:1006::cf? ([2001:420:c0cc:1006::cf]) by smtp.gmail.com with ESMTPSA id j188sm187941pfg.27.2017.03.29.14.59.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 14:59:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Mark Townsley In-Reply-To: Date: Wed, 29 Mar 2017 16:59:27 -0500 Cc: HOMENET Content-Transfer-Encoding: quoted-printable Message-Id: <4D7D6FEF-5CEB-4404-8A7B-A98D4EF7389E@townsley.net> References: To: Terry Manderson X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [homenet] My assessment of .homenet as described during the WG session yesterday. 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, 29 Mar 2017 21:59:42 -0000 Many Thanks for posting this, Terry. Homenet, As Terry said, these options are still very fluid and may come or go. = That said, Ray and I talked this over and believe Option B fits well = within the spirit of the consensus call made at IETF 97 to redact and = replace .home with .homenet (understanding at the time that it could be = more difficult process-wise than if we requested .homenet.arpa).=20 - Mark > On Mar 28, 2017, at 12:32 PM, Terry Manderson = wrote: >=20 > Dear HOMENET and DNSOP WG(s), >=20 > Wearing the INT AD hat. >=20 > Firstly, thank you to the DNSOP WG for the deep review, thoughts, and = considered responses to my request for review. >=20 > Secondly, my apologies for not sharing my throughs before the HOMENET = session. It would have been impractical to do so as this is a very = (VERY) fluid situation with IETF leadership also engaged in discussions. >=20 > This is simply an iteration of my description of the current situation = as delivered yesterday. Do be aware that conversations are continuing = and you should NOT take this as a declarative statement. During the = HOMENET WG session I specified that for this topic I am comfortable = answering _ clarifying _ questions. The same applies here. My answers = may or may not change due to the fluid nature of the concern and I hope = you appreciate that. >=20 > My summary of the situation is this. >=20 > 1) .homenet _COULD_ be added to the special use domain registry based = on RFC6761=20 >=20 > 2) The expected future operation of HOMENET resolution for DNSSEC = validating stub resolvers requires a break in the DNSSEC chain of trust. >=20 > 3) To achieve "2", the document _additionally_ asks IANA to insert an = insecure delegation into the root zone >=20 > 4) The ask for "3" is not covered in IETF policy terms, in fact it = tries to put an entry into someone else's registry (the root zone), and = will require a set of collaborative discussions with the ICANN community = and a new process that handles this situation. There are no expectations = that this process will be defined in a reasonable time for the uses of = HOMENET. >=20 >=20 > Options, possibly not an exhaustive list >=20 > A) seek a .homenet special use domain with the request for an insecure = delegation in the root zone. (This is what the document asks for NOW, = and here we are) >=20 > B) seek a .homenet special use domain WITHOUT the delegation request = AND ask the IETF/IESG/IAB to commence the discussion with the ICANN = community to achieve an insecure delegation >=20 > c) seek a .arpa insecure special use delegation >=20 > d) go for "B" and if that doesn't work shift to "C" >=20 >=20 > Each of these have different positive and negatives in a raw technical = sense, UI design desires, and policy and political frames. >=20 > Again, this situation is fluid and as discussions evolve I will = provide more information when it is appropriate. In the mean-time I = would very much like everyone to take a calming breath and understand = that I am taking a very pragmatic view of this concern. >=20 > Cheers, > Terry > INT AD > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Wed Mar 29 15: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 D13B61294F9 for ; Wed, 29 Mar 2017 15:07:26 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=townsley-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 ehkXqPl-iJxD for ; Wed, 29 Mar 2017 15:07:25 -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 172051295D0 for ; Wed, 29 Mar 2017 15:07:24 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id 81so19628115pgh.2 for ; Wed, 29 Mar 2017 15:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=townsley-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pecWafBs4689stiQ6yMyIiVt4BBbB0rboHNc/GAxmGA=; b=Wpu4ULlPJoFp1WZTYXtEXqHtx202UkZL+HhUq5hch8q7EB7zy5F3sVGGfXBkAXQLfQ tvTm9ZM7S71ycq+dGqDCMOQ12tOdfRL1CyyEAYRKeBiyfivWl/TUUkYCXzOXtl3FURV9 Po49Ov/A0yWTtEU3F8ANly5XjIz6HoUlXZBwSzbx6Vm5QQr/GjotrDGHio6ho3FG+X5Q R+jNPOjHUqWpeg6a29ModQuA+LPMkKDIaqd0Kdba8CNRpnIvNSDgvjnHuFGg09StE+pc o8oxDDn3/EWf+k1OvHauX+rqbXzkPWd1WSlrjVd0XrsZUS4HeFcYy0Tq1ngnovsDmiPS Xzdg== 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=pecWafBs4689stiQ6yMyIiVt4BBbB0rboHNc/GAxmGA=; b=YEjoPP3IxTrTatyWqTmo9YwhzfOPvEWWPYIa0ujLK030kLyZjwnRZJacYWVI8j5zBh wsdeXQwwivIxqpN4XDPVlR49dFBJo3lmzz1c2E5wHZS327deA4PB3HaId9SXgWFZk3cu syXlB8l+eox9/yTmwqIIpTtO4CjHOYk/NEEAfoZe/NPkoLGWkSNX9NM0g9+z6m7sTT43 ZeOlg4cujvGMlw3pHhlb6x6vR/yRFFlvPcRuw2TF5racQrPXCfOr2bAgAt2n6TKSgXHC ZIh1tDPniGfUOZbpMYWDaQGwEnzwT3EcPBS8OlrWRGMUb+rLL85zmP2lzF4gxbCRZs6p 8Ijg== X-Gm-Message-State: AFeK/H3W5yEOjwdbLflLHMUVq5LQAhW/WhutNwfNTd/Y4QF03BURtGMhixJ2w4BFmUlGWg== X-Received: by 10.98.200.136 with SMTP id i8mr2823186pfk.120.1490825243662; Wed, 29 Mar 2017 15:07:23 -0700 (PDT) Received: from ?IPv6:2001:420:c0cc:1006::cf? ([2001:420:c0cc:1006::cf]) by smtp.gmail.com with ESMTPSA id s11sm172482pgc.61.2017.03.29.15.07.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 15:07:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Mark Townsley In-Reply-To: <29150.1490800075@obiwan.sandelman.ca> Date: Wed, 29 Mar 2017 17:07:15 -0500 Cc: Terry Manderson , HOMENET , "dnsop@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <29150.1490800075@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [homenet] My assessment of .homenet as described during the WG session yesterday. 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, 29 Mar 2017 22:07:27 -0000 > On Mar 29, 2017, at 10:07 AM, Michael Richardson = wrote: >=20 >=20 > Terry Manderson wrote: >> B) seek a .homenet special use domain WITHOUT the delegation request >> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN >> community to achieve an insecure delegation >=20 >> c) seek a .arpa insecure special use delegation >=20 >> d) go for "B" and if that doesn't work shift to "C" >=20 > Is there some reason we can not proceed with "C", concurrently with = (B). I think that would require a new consensus call. There was a lot of work = done to get to the point of agreeing on a path forward at the last IETF, = and this path would be rather different than that. > This might cause stub resolvers to have to have two cases > (SOMETHING.arpa, and .homenet) eventually, but at least we could = deploy > and attempt interop with SOMETHING.arpa NOW, and it would more clearly > permit "home." to be removed from code. >=20 /chair-hat-off I don=E2=80=99t think we want to have two defaults in our specs. It=E2=80=99= s bad enough that we are already going to end up with .home and .homenet = depending on the version of code used or forked from, I really don=E2=80=99= t want to do anything that could lead to a third if we can avoid it. - Mark >> Again, this situation is fluid and as discussions evolve I will = provide >> more information when it is appropriate. In the mean-time I would = very >> much like everyone to take a calming breath and understand that I am >> taking a very pragmatic view of this concern. >=20 > Thank you! >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Wed Mar 29 15: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 585D6126C23; Wed, 29 Mar 2017 15:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 67qQ_J0_fXwM; Wed, 29 Mar 2017 15:15:05 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A5F1279E5; Wed, 29 Mar 2017 15:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3799; q=dns/txt; s=iport; t=1490825705; x=1492035305; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DFCqdQxT9B/m0+ZuK1XWA7a7oR1wzfDZFc5xltaGbDE=; b=BTd/yzJtWdhMUZt/zi7s+slMkv9O7BrA/y6MYDsQSgyzi7i0hLlNH9g0 UqHo7CwQ4W+XkH6664pNCwJzQvYRLzeRBarosSEGLLip+DLa3WHyI5Sxx 5xa5wY9XlPUHnS4dDRkzzjf3tUOBb/wPtZF4Pqr39pNV4VIUKLy786fGM M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQCCMdxY/4UNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VhgQsHjWyRMh+VToIOHwuCQoJsSgKDQz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECAQEBODQLBQsCAQgYHhAnCyUCBA4FigIIDrAmilkBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYhTCIJihFSDNIIxBZxgAYZ8gyqIKZEzk2kBHziBBFkVQRE?= =?us-ascii?q?BhkZ1iCmBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,243,1486425600"; d="scan'208";a="229445798" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2017 22:14:38 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2TMEc11001665 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 22:14:38 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 17:14:37 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Wed, 29 Mar 2017 17:14:37 -0500 From: "Mark Townsley (townsley)" To: Michael Richardson CC: "casm@ietf.org" , "anima@ietf.org" , "homenet@ietf.org" Thread-Topic: [homenet] prefix assignment Thread-Index: AQHSp9vjxu1NLCXsxk6FBlrX+TkYTqGqzpsAgAFw7ACAAHhGAA== Date: Wed, 29 Mar 2017 22:14:37 +0000 Message-ID: <4C898133-C860-4369-8BDC-E5868CA70EB9@cisco.com> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> In-Reply-To: <28218.1490799848@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.184.139] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [homenet] prefix assignment 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, 29 Mar 2017 22:15:07 -0000 > On Mar 29, 2017, at 10:04 AM, Michael Richardson = wrote: >=20 >=20 > This discussion started in a private thread, so I'll try to bring people > up-to-date by repeating and moving around text. >=20 > The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is > to do distributed prefix allocation. This is very much in the space of > *coordinated* address management. >=20 > (My take, BTW, is that CASM should be considered the first spin-off WG > From ANIMA...) >=20 > Mark and Brian discussed how HNCP does prefix distribution within Homenet= . I was really pointing out that RFC 7695 could be used independent of HNCP.= =20 HNCP is just one protocol that uses the RFC 7695 distributed prefix assignm= ent algorithm (which actually began as extensions to OSPF before HNCP even = existed).=20 - Mark >=20 > Brian then suggests: >=20 > brian> But if the CE includes a little autonomic service agent (ASA) whi= ch > brian> is in the ISP's security domain (not the SOHO domain), it can act= for > brian> HNCP to solicit address space from the ISP. That's the southern s= ide > brian> of the CASM model and the northern side of HNCP. >=20 > I asked a simple question: don't we have DHCPv6 for this? >=20 > I also then asked: >=20 >> a) the CPE device is now part of the ISP's ACP. >> That's okay if the CPE device is owned by the ISP and/or the CPE device >> includes some kind of trusted computation environment. >> {But a CPE owned by the ISP, might not be trusted by the home owner, >> so another router in between would be needed, >=20 > Brian answered: >> Really? Why not? >=20 > I don't think that the ISP can trust to have code controlled by end users > running in their ACP domain. >=20 > I also think that many end-users will be quite reasonably upset that thei= r > ISPs can snoop on their internal traffic. This may in fact violate many > work-at-home agreements; which is often the case of why you see multiple > routers/firewalls in documents like > https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-route= r. >=20 > (Fred had more interesting diagrams in presentations, which I could dig u= p) >=20 >>> b) DHCPv6 PD is already the protocol that solves prefix allocation acro= ss >>> trust boundaries. >=20 >> Indeed. That's why we have "PD supported" as a Boolean property of the >> PrefixManager objective. There's no intention to undermine PD. >=20 > Why do I need to run a protocol in order to find if I can run a protocol, > when DHCP has the same mechanism already. And use of DHCPv6 itself is we= ll > defined in cable and DSL connections already. >=20 >>> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that deal= s with >>> prefixes. It would speak DHCPv6-PD to the south, and GRASP/ASA to the = north. >=20 >> Yes, the DSLAM is definitely a good place to put one. >=20 >=20 >>> North of the ISP's device would be the ISP's (distributed) IPAM. >>> GRASP/ASA-Prefix would be the protocol between. >=20 >> Anyway, my point is that these approaches (ANIMA, HNCP and PD) are >> complementary not competitors. >=20 > I don't see you saying that. >=20 > I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and = HNCP > in the home) such that they interact directly, rather than using PD. You > say this right here: >=20 > brian> But if the CE includes a little autonomic service agent (ASA) whi= ch >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Wed Mar 29 16:01: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 8E7FD129631; Wed, 29 Mar 2017 16:01:32 -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, FREEMAIL_FROM=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=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 apNzLDl67z0U; Wed, 29 Mar 2017 16:01:30 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D702712967E; Wed, 29 Mar 2017 16:01:21 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id y18so11430703itc.2; Wed, 29 Mar 2017 16:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=z3NQr6PmrxvynVU1cLKKReWc5O/wpv8YszuQDLz7kmQ=; b=GQHvN0s6ezlw2quvyGoBOEt8xjEzC5MyZGItnXpMxJNr6e+W/dbzfR/ym7cfX6Dygp 8ynaPdeHMX4tB00ySamWAHHqt3KLjDdnxGmg56BA4kf6fb7Fqg55p9KQ8R4eg+m1tITR Hg2uFaX/7Lpiqb8HchrqlWRORE2hniqE3s27XyWTCaaKWeodkbM1kxYKB+/Jff1EZ3Cs Ed1vi9A7HRWA/6W7FV0XjunnpqAt7poqc8+YFO4Lfza9vQn10bpR3dQuLBnh3NHYcjt5 y5SdruibIPkM4T8FRCPmvjDwAJSq4IwgdhDDT59bZDKA3FnaCWCTRbc8nWAfLusOydtE p1fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=z3NQr6PmrxvynVU1cLKKReWc5O/wpv8YszuQDLz7kmQ=; b=KVErrBcmNZGqildmnv1e0PXqqhCj2gjbrrfR8+WB7Yk0MQSFKQtHYPSAWmaGpnCpoe FA1toHXWlx3F87AFqGPEjOTF5SoyIrIS8kfqphNkJMjyVxf3KzU76HdAXzw+92KnSENF WcavZv9jT51DOEszbbiG/+X5LlyxiszowGlDvSpS1GX8o2idr/xZ7iQ7cxCzGkPzW52P QVeiCLnvFstC+EmoyQ+QMB97LqLSx2quRv185piJHrMIty7RbE5BQkT9BsdXmtPPD1Ul kEg96ZUR3hcies22xOuVuYoMh01D5BNzw2CvIem1bUY7hWng/5IPKjvkDfD+qqRQIZmx WJsA== X-Gm-Message-State: AFeK/H2t/tcnlanqGhU4a6iq8Sn/EWiCzjF2j2h4DL8R8zKJX5mrFpPcv5vjmMlsuvHCFQ== X-Received: by 10.36.87.136 with SMTP id u130mr1080438ita.100.1490828481039; Wed, 29 Mar 2017 16:01:21 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p6sm424258iof.12.2017.03.29.16.01.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 16:01:20 -0700 (PDT) To: Juliusz Chroboczek References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <87r31fhk0d.wl-jch@irif.fr> Cc: Michael Richardson , Mark Townsley , homenet@ietf.org, casm@ietf.org, anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 30 Mar 2017 12:01:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87r31fhk0d.wl-jch@irif.fr> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [homenet] prefix assignment 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, 29 Mar 2017 23:01:33 -0000 On 30/03/2017 10:04, Juliusz Chroboczek wrote: >> There's already a thing called an HNCP agent. Why couldn't >> it be enhanced to negotiate with an upstream ASA for resources? > > Could you please clarify what you mean by "negotiate"? Current HNCP > implementations are provided with a bunch of External Prefixes, which they > then carve into /64, one per prefix. Are you envisioning a scenario where > the HNCP implementation actually performs active negotiation on its > external interfaces? Yes. But if it's a useless use case, that's fine. I was motivated to point out that there *really* is no conflict between the homenet work and Anima, and that they could be complementary if we want. Brian From nobody Wed Mar 29 16:04: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 73564129631; Wed, 29 Mar 2017 16:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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=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 xq7zwxoZaaKl; Wed, 29 Mar 2017 16:04:50 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 64F7F129572; Wed, 29 Mar 2017 16:04:50 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id 190so11422060itm.3; Wed, 29 Mar 2017 16:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cTFHsouxE3/yMR/FXksA1Btsf0Q1oZje3k8oykMT7x4=; b=gEtx2tnxJtPuzaRKjRYNT25gm+dgypFrn7KBO2sOl5yn/dIRX36L4j5vHqOTwkmAJV P5/609heesE913NhtOmXCAvW081CEqdauQM8eC5Vm2w73cwyhc7GrD5owFzlE+ifq07+ 9DEgYmbnKuanhFp4ZtO/eEdbzjCwx2M3OwIorFHNJCcLK8y8ZXtbueUF0Kid4NsaLGdf Zslw8mD3ZaVaQdYWilx8Tt+1vnW5FrlJKC5CDqiz/jM+ohFs2rP3rfiwyL7oUWBHv3/T LsbHhJFaJ7Qxu2RWgJhDekmtAL8t10afXPj9XFdNHY+ciDpzlaCO4ilvxMcJgJSl4jPk fT+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=cTFHsouxE3/yMR/FXksA1Btsf0Q1oZje3k8oykMT7x4=; b=WeeUppyXueSkeN+z8lmFmQywwCZ4l9wYKzG009lw+6V7dQ9Clw3EC+Eb+g7iquUMKY O8EdgTqy5XjF2y/IUNMMyM5FcfW072f8EqpR+tPhRwC8NXUq8XeA/loUSD1+BGuiqZPA utVel1RFN5hNQWGi42FSfFvIaAsPmaSDNtjB8fML5qv2/yRcMCIMhQhHtqgv/V7vGkra PK6NsMbdCQfHWzoYP0HwQhgXNBtnWX3SRuGuR4Dw8kvNtyJxYUpkyzb3MrIn0XcdBCav 40PdOIoV4z0EhgtebWsUWqkukZe/5d8gD74rHEkYeWEmlFRb4zME7ArzrpJYIE0r451Y 0xRA== X-Gm-Message-State: AFeK/H2bIBnMFYff0+cj/rDBxCBAc+Wca+KImhkw/HQQVRDOFHJoCosmpegxrRil6MqG6Q== X-Received: by 10.36.87.15 with SMTP id u15mr1091888ita.58.1490828689611; Wed, 29 Mar 2017 16:04:49 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b126sm410720ioa.55.2017.03.29.16.04.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 16:04:48 -0700 (PDT) To: "Mark Townsley (townsley)" , Michael Richardson References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <4C898133-C860-4369-8BDC-E5868CA70EB9@cisco.com> Cc: "homenet@ietf.org" , "casm@ietf.org" , "anima@ietf.org" From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 30 Mar 2017 12:04:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4C898133-C860-4369-8BDC-E5868CA70EB9@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [homenet] [Anima] prefix assignment 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, 29 Mar 2017 23:04:52 -0000 On 30/03/2017 11:14, Mark Townsley (townsley) wrote: > >> On Mar 29, 2017, at 10:04 AM, Michael Richardson wrote: >> >> >> This discussion started in a private thread, so I'll try to bring people >> up-to-date by repeating and moving around text. >> >> The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is >> to do distributed prefix allocation. This is very much in the space of >> *coordinated* address management. >> >> (My take, BTW, is that CASM should be considered the first spin-off WG >> From ANIMA...) >> >> Mark and Brian discussed how HNCP does prefix distribution within Homenet. > > I was really pointing out that RFC 7695 could be used independent of HNCP. > > HNCP is just one protocol that uses the RFC 7695 distributed prefix assignment algorithm (which actually began as extensions to OSPF before HNCP even existed). True. And I don't see any reason why a CASM system including autonomic service agents shouldn't be used to supply prefixes for use by an RFC7695 implementation. So the various tools can fit together. Brian > > - Mark > >> >> Brian then suggests: >> >> brian> But if the CE includes a little autonomic service agent (ASA) which >> brian> is in the ISP's security domain (not the SOHO domain), it can act for >> brian> HNCP to solicit address space from the ISP. That's the southern side >> brian> of the CASM model and the northern side of HNCP. >> >> I asked a simple question: don't we have DHCPv6 for this? >> >> I also then asked: >> >>> a) the CPE device is now part of the ISP's ACP. >>> That's okay if the CPE device is owned by the ISP and/or the CPE device >>> includes some kind of trusted computation environment. >>> {But a CPE owned by the ISP, might not be trusted by the home owner, >>> so another router in between would be needed, >> >> Brian answered: >>> Really? Why not? >> >> I don't think that the ISP can trust to have code controlled by end users >> running in their ACP domain. >> >> I also think that many end-users will be quite reasonably upset that their >> ISPs can snoop on their internal traffic. This may in fact violate many >> work-at-home agreements; which is often the case of why you see multiple >> routers/firewalls in documents like >> https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router. >> >> (Fred had more interesting diagrams in presentations, which I could dig up) >> >>>> b) DHCPv6 PD is already the protocol that solves prefix allocation across >>>> trust boundaries. >> >>> Indeed. That's why we have "PD supported" as a Boolean property of the >>> PrefixManager objective. There's no intention to undermine PD. >> >> Why do I need to run a protocol in order to find if I can run a protocol, >> when DHCP has the same mechanism already. And use of DHCPv6 itself is well >> defined in cable and DSL connections already. >> >>>> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that deals with >>>> prefixes. It would speak DHCPv6-PD to the south, and GRASP/ASA to the north. >> >>> Yes, the DSLAM is definitely a good place to put one. >> >> >>>> North of the ISP's device would be the ISP's (distributed) IPAM. >>>> GRASP/ASA-Prefix would be the protocol between. >> >>> Anyway, my point is that these approaches (ANIMA, HNCP and PD) are >>> complementary not competitors. >> >> I don't see you saying that. >> >> I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and HNCP >> in the home) such that they interact directly, rather than using PD. You >> say this right here: >> >> brian> But if the CE includes a little autonomic service agent (ASA) which >> >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Mar 29 16:12: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 A01EB1296BF; Wed, 29 Mar 2017 16:12:48 -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, FREEMAIL_FROM=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 j4-15ZYqhCar; Wed, 29 Mar 2017 16:12:46 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 56D7012969C; Wed, 29 Mar 2017 16:12:42 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id 190so11437448itm.3; Wed, 29 Mar 2017 16:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=8CGAL/RuUywWYk2fEbxCeGAyc+X0KJBT/AlqCrec1Mc=; b=QI+SpNfF8UzkJiBoPsDp1NzqBvVyhawTPqHJj0z27tRy0dg/r4vsgChIfMGY4HNk0B IVu91fMRHZBZGtsu4gT33u0dFJUs2dN0dvh4gQxPkFGbKR1zoQ+h8RwFcFSaZFeXYnlF O65EY3pGfA7fEkvJQ1HD6dAb5LsSz9xjR8rlWz+XTkhIh65tutJQLfRl6iUd8L9NbvST uRql75OBB4fIdF1xFWyLHkFXcCOYLmuayfu4+YGNOnafok5TTZjRcs5QmS8k4qMQLzqN LfXzHZZ1HjjzFOkVwPb0JtM1Ovr1HDiJY3ZfQIO9cBYYB+nR1o9ZWb/WdmW7LEEpyZHA ZHFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=8CGAL/RuUywWYk2fEbxCeGAyc+X0KJBT/AlqCrec1Mc=; b=Dk/9QCBK7xZqSmiZOA/HC+B7j8O2WfHJBqXDAlmSvRafqaY68dnX1LRps6jbyXgkiZ WiS9xvPAEEui/eWsYqzdlzorXqRNGpDjOUDBlq+H3nucvoyhB+F0944Tnzq4l0Rjgt9Y gVAhSC2vzp7dw1xk3xAU0s7lw1iZOB4GQItA9HvsmixHVQMqym6uLD8vgA5Owek5Fj75 PcA9agXsJX8S38gjiKZVsXWNTmJ2qFPjIZEemo9qZWeXH1FGuOVcg0ix6DBowAxw5K1E y+ial8w6CwiQa+XqbVJ2TaoRNhxPFgOoLK79eSjwBzjNvZMKzMLtUQLgfScMDpTD7SOl jwzQ== X-Gm-Message-State: AFeK/H22XYpG5UA0lhKOKrFLpG7b4h7fHbp1j97RasDf8fPhstD6qMdecbWZvz/tMj4qTg== X-Received: by 10.36.111.9 with SMTP id x9mr1160426itb.102.1490829161628; Wed, 29 Mar 2017 16:12:41 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b25sm433380iod.32.2017.03.29.16.12.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 16:12:41 -0700 (PDT) To: Michael Richardson References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <916.1490823535@obiwan.sandelman.ca> Cc: casm@ietf.org, anima@ietf.org, Mark Townsley , homenet@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 30 Mar 2017 12:12:41 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <916.1490823535@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [homenet] prefix assignment 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, 29 Mar 2017 23:12:49 -0000 On 30/03/2017 10:38, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> I just don't see the point of the ASA here. > > > There's already a thing called an HNCP agent. Why couldn't > > it be enhanced to negotiate with an upstream ASA for resources? > > Because it's already done. It's called DHCPv6. > It already has extensive running code :-) > It's not even that complex. All true. But it isn't designed for negotiation as far as I know, just a request/response. > I would love to request address space via ASA from the DHCPv6 server. > That would all happen within the ISP's ACP though. Agreed, that is a little higher up the food chain. Maybe that is as close to the user as an ASA will get. I don't really care; I just wanted to explore the way we might fit our various tools together. > Right now (on DSL lines), the address space mostly comes via radius. > Which is to say that the problem has been centralized by MBS builders into > being someone else's problem. Advertising the address space is often done by > OSPFv3, but there are additional things that would be easier for the DHCPv6 > server to do, such as the DNS delegations that homenet is working on > finishing. Yes, indeed, and then we could discuss how the radius server gets new address space when it runs out. > I think that CASM could very nicely define/extend the prefix ASA to deal with > DNS reverse names, and as the RIRs (George) said, better link the delegated > prefix to clear ownership records. Yes, by defining a full set of relevant objectives. Brian From nobody Wed Mar 29 16:23: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 60CF31287A0; Wed, 29 Mar 2017 16:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 U4On6zk8OT_y; Wed, 29 Mar 2017 16:23:44 -0700 (PDT) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B30A12773A; Wed, 29 Mar 2017 16:16:51 -0700 (PDT) Received: from [10.61.228.52] (unknown [173.38.220.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 2B52A564797; Thu, 30 Mar 2017 01:16:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Pierre Pfister In-Reply-To: Date: Wed, 29 Mar 2017 18:16:43 -0500 Cc: Mark Townsley , Michael Richardson , "homenet@ietf.org" , "casm@ietf.org" , "anima@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <4C898133-C860-4369-8BDC-E5868CA70EB9@cisco.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3259) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Thu Mar 30 01:16:47 2017 +0200 (CEST)) Archived-At: Subject: Re: [homenet] [Anima] prefix assignment 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, 29 Mar 2017 23:23:47 -0000 > Le 29 mars 2017 =C3=A0 18:04, Brian E Carpenter = a =C3=A9crit : >=20 > On 30/03/2017 11:14, Mark Townsley (townsley) wrote: >>=20 >>> On Mar 29, 2017, at 10:04 AM, Michael Richardson = wrote: >>>=20 >>>=20 >>> This discussion started in a private thread, so I'll try to bring = people >>> up-to-date by repeating and moving around text. >>>=20 >>> The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is >>> to do distributed prefix allocation. This is very much in the space = of >>> *coordinated* address management. >>>=20 >>> (My take, BTW, is that CASM should be considered the first spin-off = WG >>> =46rom ANIMA...) >>>=20 >>> Mark and Brian discussed how HNCP does prefix distribution within = Homenet. >>=20 >> I was really pointing out that RFC 7695 could be used independent of = HNCP.=20 >>=20 >> HNCP is just one protocol that uses the RFC 7695 distributed prefix = assignment algorithm (which actually began as extensions to OSPF before = HNCP even existed). >=20 > True. And I don't see any reason why a CASM system including autonomic = service > agents shouldn't be used to supply prefixes for use by an RFC7695 = implementation. > So the various tools can fit together. Absolutely. RFC7695 Applicability Statement (Section 3.) explains that = the algorithm can be used as long as participating nodes gets configured with an eventually = consistent set of non-overlaping prefixes, which are then used to carve-out sub-prefixes that are assigned to = link/nodes/objects/toasters. - If ANIMA provides a protocol capable of configuring nodes with such a = set of delegated prefixes, RFC7695 can be used.=20 - CASM can also be used, as discussed earlier, in order to provision = HNCP (by the mean of a border router), and hence be used as a = provisioning mechanism to Homenet border routers. - If CASM intends to adopt a distributed architecture, and assuming the = existence of a reliable flooding protocol (AFAIK, grasp would be capable = of such a thing), RFC7695 could be used in order to reliably carve and = assign prefixes out of available addressing space. =20 - Pierre >=20 > Brian >>=20 >> - Mark >>=20 >>>=20 >>> Brian then suggests: >>>=20 >>> brian> But if the CE includes a little autonomic service agent (ASA) = which >>> brian> is in the ISP's security domain (not the SOHO domain), it can = act for >>> brian> HNCP to solicit address space from the ISP. That's the = southern side >>> brian> of the CASM model and the northern side of HNCP. >>>=20 >>> I asked a simple question: don't we have DHCPv6 for this? >>>=20 >>> I also then asked: >>>=20 >>>> a) the CPE device is now part of the ISP's ACP. >>>> That's okay if the CPE device is owned by the ISP and/or the CPE = device >>>> includes some kind of trusted computation environment. >>>> {But a CPE owned by the ISP, might not be trusted by the home = owner, >>>> so another router in between would be needed, >>>=20 >>> Brian answered: >>>> Really? Why not? >>>=20 >>> I don't think that the ISP can trust to have code controlled by end = users >>> running in their ACP domain. >>>=20 >>> I also think that many end-users will be quite reasonably upset that = their >>> ISPs can snoop on their internal traffic. This may in fact violate = many >>> work-at-home agreements; which is often the case of why you see = multiple >>> routers/firewalls in documents like >>> = https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router. >>>=20 >>> (Fred had more interesting diagrams in presentations, which I could = dig up) >>>=20 >>>>> b) DHCPv6 PD is already the protocol that solves prefix allocation = across >>>>> trust boundaries. >>>=20 >>>> Indeed. That's why we have "PD supported" as a Boolean property of = the >>>> PrefixManager objective. There's no intention to undermine PD. >>>=20 >>> Why do I need to run a protocol in order to find if I can run a = protocol, >>> when DHCP has the same mechanism already. And use of DHCPv6 itself = is well >>> defined in cable and DSL connections already. >>>=20 >>>>> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that = deals with >>>>> prefixes. It would speak DHCPv6-PD to the south, and GRASP/ASA to = the north. >>>=20 >>>> Yes, the DSLAM is definitely a good place to put one. >>>=20 >>>=20 >>>>> North of the ISP's device would be the ISP's (distributed) IPAM. >>>>> GRASP/ASA-Prefix would be the protocol between. >>>=20 >>>> Anyway, my point is that these approaches (ANIMA, HNCP and PD) are >>>> complementary not competitors. >>>=20 >>> I don't see you saying that. >>>=20 >>> I see ou trying to extend two internal mechanisms (ANIMA in the ISP, = and HNCP >>> in the home) such that they interact directly, rather than using PD. = You >>> say this right here: >>>=20 >>> brian> But if the CE includes a little autonomic service agent (ASA) = which >>>=20 >>>=20 >>> -- >>> Michael Richardson , Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >>=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Wed Mar 29 21:41: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 B017F129572; Wed, 29 Mar 2017 21:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 qgTBRyWxYCfJ; Wed, 29 Mar 2017 21:41:01 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 6B885129445; Wed, 29 Mar 2017 21:41:01 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id b140so12080865iof.1; Wed, 29 Mar 2017 21:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3/Yv0uEFj/rCgItYGiY1hdPHWI3qRb+vRR/dgng5Mik=; b=qqahZI/qlRLiozgqXOzyRy5NCpqYLW0YKwTG5yLucB9D+3402sK4zRSbgMY406dcj3 oi+ksHRlc36rZ2tsNfV+tHYnMZlJU18ETjuLgcof+KxUo70GpsXy5Usrrhp4DvaiVIWQ xYcnuD3SBFj7349Hl1TcAU2E+ITMGw5Y1xq9/LTfo/8EYcIfTAns3Bo2XhLDmvhwoj2O Is1mKpE3Zm8kmb2ktYraBxTL2tsSsEmPzOHUgKYbiQpB5ECrvhdKn9Zk40s1hsnk6IuQ P7iPgfdEjyLTLde+q04T2tWz4Bl6dnpLU35hwBzGonzzypQgXrSoxEYvL789qWvvnwQh OyGw== 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=3/Yv0uEFj/rCgItYGiY1hdPHWI3qRb+vRR/dgng5Mik=; b=L+aa0kHn8FFaRZX0yRrgqQyocBYx4DK9bFCmjcEv6qmZ3ROcBQiAkLY5ZD+FTte/E9 WtO2U8HlNFLXpoNpI17MFrQZ3n/0aJTFBXkYAeCMzcyrNN+L7U7t0gyfcXYufnj+2iPW TbWyqWNK4Fb4MBEvQv8SkxklPkN3/0j9J6xwUgeD0LuIw0Vr+lZYdjcY1WG324ueswMq N9UN3O4e24bqhIe7y5NRxVDxP9CPOjCMO9K9LoBxZTTmNZRuj+FOP9leUIMU1M94RrUB GSfw31GlKs8h7riGOZqG35VxmuUmz0PR/RCJ6n5I8lbFOVVHYH2s9A1gywcu2/wBOOPT UpTA== X-Gm-Message-State: AFeK/H2WgeoXr/Po1XL70wAU1q6hbRkvHOn0HyQXFw5iA5Ps691Nrys0MY8CW4GCoKLQfZpHQFcChJvzbfHygA== X-Received: by 10.107.136.41 with SMTP id k41mr5326826iod.160.1490848860719; Wed, 29 Mar 2017 21:41:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.46.151 with HTTP; Wed, 29 Mar 2017 21:41:00 -0700 (PDT) In-Reply-To: References: <29150.1490800075@obiwan.sandelman.ca> From: Brian Dickson Date: Wed, 29 Mar 2017 23:41:00 -0500 Message-ID: To: Mark Townsley Cc: Michael Richardson , HOMENET , "dnsop@ietf.org" , Terry Manderson Content-Type: multipart/alternative; boundary=001a113ec618c1d412054beb4ce3 Archived-At: Subject: Re: [homenet] My assessment of .homenet as described during the WG session yesterday. 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, 30 Mar 2017 04:41:04 -0000 --001a113ec618c1d412054beb4ce3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley wrote: > > > On Mar 29, 2017, at 10:07 AM, Michael Richardson > wrote: > > > > > > Terry Manderson wrote: > >> B) seek a .homenet special use domain WITHOUT the delegation request > >> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN > >> community to achieve an insecure delegation > > > >> c) seek a .arpa insecure special use delegation > > > >> d) go for "B" and if that doesn't work shift to "C" > > > > Is there some reason we can not proceed with "C", concurrently with (B)= . > > I think that would require a new consensus call. There was a lot of work > done to get to the point of agreeing on a path forward at the last IETF, > and this path would be rather different than that. > > > This might cause stub resolvers to have to have two cases > > (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy > > and attempt interop with SOMETHING.arpa NOW, and it would more clearly > > permit "home." to be removed from code. > > > > /chair-hat-off > > I don=E2=80=99t think we want to have two defaults in our specs. It=E2=80= =99s bad enough > that we are already going to end up with .home and .homenet depending on > the version of code used or forked from, I really don=E2=80=99t want to d= o anything > that could lead to a third if we can avoid it. > > - Mark > Taking a STRICTLY devil's advocate position here: Isn't it the case that the thing that knows what the label is, should be able to masquerade on behalf of anything that isn't aware of the divergence of the three possible values for ? If you end up with some boxes thinking it is ".home", some ".homenet", and some ".homenet.arpa", as long as one of them knows about all three, it should be possible to resolve the differences. The scope of the namespace is "the home network", and never reaches the real DNS (roots), so at worst it would be folding the three fake namespaces into a unified (three-headed) fake namespace. I.e. avoid it if you can, but if you can't, I think the issues are solvable, even if they get a little funky/ugly under the hood. None of that should be visible to users, I don't think. Brian P.S. Guide to implementers - never expose multiple handles for the same object; over-exuberant users may be tempted to try to "clean up" the duplicates. --001a113ec618c1d412054beb4ce3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley <mark@townsley.net&= gt; wrote:

> On Mar 29, 2017, at 10:07 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>
>
> Terry Manderson <terry= .manderson@icann.org> wrote:
>> B) seek a .homenet special use domain WITHOUT the delegation reque= st
>> AND ask the IETF/IESG/IAB to commence the discussion with the ICAN= N
>> community to achieve an insecure delegation
>
>> c) seek a <SOMETHING>.arpa insecure special use delegation >
>> d) go for "B" and if that doesn't work shift to &quo= t;C"
>
> Is there some reason we can not proceed with "C", concurrent= ly with (B).

I think that would require a new consensus call. There was a lot of = work done to get to the point of agreeing on a path forward at the last IET= F, and this path would be rather different than that.

> This might cause stub resolvers to have to have two cases
> (SOMETHING.arpa, and .homenet) eventually, but at least we could deplo= y
> and attempt interop with SOMETHING.arpa NOW, and it would more clearly=
> permit "home." to be removed from code.
>

/chair-hat-off

I don=E2=80=99t think we want to have two defaults in our specs. It=E2=80= =99s bad enough that we are already going to end up with .home and .homenet= depending on the version of code used or forked from, I really don=E2=80= =99t want to do anything that could lead to a third if we can avoid it.

- Mark

Taking a STRICTLY = devil's advocate position here:

Isn't it t= he case that the thing that knows what the <homenet> label is, should= be able to masquerade on behalf of anything that isn't aware of the di= vergence of the three possible values for <homenet>? If you end up wi= th some boxes thinking it is ".home", some ".homenet", = and some ".homenet.arpa", as long as one of them knows about all = three, it should be possible to resolve the differences.

The scope of the namespace is "the home network", and neve= r reaches the real DNS (roots), so at worst it would be folding the three f= ake namespaces into a unified (three-headed) fake namespace.

=
I.e. avoid it if you can, but if you can't, I think the issu= es are solvable, even if they get a little funky/ugly under the hood.
=

None of that should be visible to users, I don't th= ink.=C2=A0

Brian=C2=A0

P.= S. Guide to implementers - never expose multiple handles for the same objec= t; over-exuberant users may be tempted to try to "clean up" the d= uplicates.
--001a113ec618c1d412054beb4ce3-- From nobody Wed Mar 29 22:20: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 6878B129522; Wed, 29 Mar 2017 22:20:14 -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, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_HI=-5, 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 I6IrfwjqTSVG; Wed, 29 Mar 2017 22:20:12 -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 7276E12948D; Wed, 29 Mar 2017 22:20:12 -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 73E8D24AE08; Thu, 30 Mar 2017 05:20:07 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5B20A16003A; Thu, 30 Mar 2017 05:20:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4541816004F; Thu, 30 Mar 2017 05:20:07 +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 TLRklVDkJlmu; Thu, 30 Mar 2017 05:20:07 +0000 (UTC) Received: from rock.dv.isc.org (107-1-12-170-ip-static.hfc.comcastbusiness.net [107.1.12.170]) by zmx1.isc.org (Postfix) with ESMTPSA id E413616003A; Thu, 30 Mar 2017 05:20:06 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 008D66A4B0BE; Thu, 30 Mar 2017 16:20:05 +1100 (AEDT) To: Brian Dickson Cc: Mark Townsley , Michael Richardson , HOMENET , "dnsop@ietf.org" , Terry Manderson From: Mark Andrews References: <29150.1490800075@obiwan.sandelman.ca> In-reply-to: Your message of "Wed, 29 Mar 2017 23:41:00 -0500." Date: Thu, 30 Mar 2017 16:20:05 +1100 Message-Id: <20170330052006.008D66A4B0BE@rock.dv.isc.org> Archived-At: Subject: Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 30 Mar 2017 05:20:14 -0000 In message , Brian Dickson writes: > On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley wrote: > > > > > > On Mar 29, 2017, at 10:07 AM, Michael Richardson > > > wrote: > > > > > > > > > Terry Manderson wrote: > > >> B) seek a .homenet special use domain WITHOUT the delegation request > > >> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN > > >> community to achieve an insecure delegation > > > > > >> c) seek a .arpa insecure special use delegation > > > > > >> d) go for "B" and if that doesn't work shift to "C" > > > > > > Is there some reason we can not proceed with "C", concurrently with (B). > > > > I think that would require a new consensus call. There was a lot of work > > done to get to the point of agreeing on a path forward at the last IETF, > > and this path would be rather different than that. > > > > > This might cause stub resolvers to have to have two cases > > > (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy > > > and attempt interop with SOMETHING.arpa NOW, and it would more clearly > > > permit "home." to be removed from code. > > > > > > > /chair-hat-off > > > > I don’t think we want to have two defaults in our specs. It’s bad enough > > that we are already going to end up with .home and .homenet depending on > > the version of code used or forked from, I really don’t want to do anything > > that could lead to a third if we can avoid it. > > > > - Mark > > > > Taking a STRICTLY devil's advocate position here: > > Isn't it the case that the thing that knows what the label is, > should be able to masquerade on behalf of anything that isn't aware of the > divergence of the three possible values for ? If you end up with > some boxes thinking it is ".home", some ".homenet", and some > ".homenet.arpa", as long as one of them knows about all three, it should > be possible to resolve the differences. > > The scope of the namespace is "the home network", and never reaches the > real DNS (roots), so at worst it would be folding the three fake > namespaces into a unified (three-headed) fake namespace. Can we please stop with this "and never reaches the real DNS (roots)" garbage. Queries for homenet/DS *will* reach the roots. That is how DNSSEC validation is designed to work. They *need* to be answered with a signed NOERROR NODATA response. Lots of Linux distributions ship with DNSSEC validation enabled for on machine clients and they are also configured to forward to the nameservers that are returned by DHCP. These machines behave *exactly* like a validating stub resolver from the DNSSEC perspective. This isn't something that will be in the future. It is the PRESENT. > I.e. avoid it if you can, but if you can't, I think the issues are > solvable, even if they get a little funky/ugly under the hood. > > None of that should be visible to users, I don't think. > > Brian > > P.S. Guide to implementers - never expose multiple handles for the same > object; over-exuberant users may be tempted to try to "clean up" the > duplicates. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Mar 30 07:46: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 CDB4012922E; Thu, 30 Mar 2017 07:46:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Dmig_WhXRgpE; Thu, 30 Mar 2017 07:46:01 -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 DFE6712706D; Thu, 30 Mar 2017 07:46:00 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 146A4203AD; Thu, 30 Mar 2017 11:09:58 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BB607636BB; Thu, 30 Mar 2017 10:45:59 -0400 (EDT) From: Michael Richardson To: Juliusz Chroboczek cc: Brian E Carpenter , Mark Townsley , homenet@ietf.org, casm@ietf.org, anima@ietf.org In-Reply-To: <87h92bhhhh.wl-jch@irif.fr> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <87r31fhk0d.wl-jch@irif.fr> <1636.1490823705@obiwan.sandelman.ca> <87h92bhhhh.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] prefix assignment 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, 30 Mar 2017 14:46:04 -0000 --=-=-= Content-Type: text/plain Juliusz Chroboczek wrote: >>> Could you please clarify what you mean by "negotiate"? Current HNCP >>> implementations are provided with a bunch of External Prefixes, which they >>> then carve into /64, one per prefix. Are you envisioning a scenario where >>> the HNCP implementation actually performs active negotiation on its >>> external interfaces? >> Yes, that's what Brian is suggesting. >> The HNCP daemon would speak GRASP ASA on the "northbound" interface. > Sorry if I wasn't clear. Would it merely request address space and handle > it out using HNCP, or would it actively renegotiate address space in > response to HNCP events? > If the latter -- why? It would hand out space via HNCP, and if it ran out of space, get more. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljdGicACgkQgItw+93Q 3WWMlwgAl2WAbqmbiT8TAGHIMHZ1Annwj1stda9GhqGU6bxJkOC77GcKFHK34h5E eoxYV/0g4HAg8ZFn6dP2Pfli9uIFQ3TCJCpOw/3aQbYgK0J+5a0K5lPA+lwGopB+ goLAMyjU7Tewzo0K6aSvmKNcxfeJkxcqJLaxURXs0Xc/n5F0Gtp2NfntH9ljjuI6 XvLRk2jkc7HZWLnpwaQd3KmjuNCcObQjXWcopuMwsB1Kz/OvTuLIcq1R7QrehFr4 BON17dnTBC8rVyCQ+ZETsjFafTlRTnaen0vgxmqv0TvPnPoNNWkMSGUZ/C02UQan NoLcrprgqlWTCn5XbGNtmQro8N2vrA== =XGT1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 30 07:50:47 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 73FD2120726 for ; Thu, 30 Mar 2017 07:50:42 -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 Qm2eq9X9fVcM for ; Thu, 30 Mar 2017 07:50:41 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 7634F1294DF for ; Thu, 30 Mar 2017 07:50:39 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id b140so20687051iof.1 for ; Thu, 30 Mar 2017 07:50:39 -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=Yi/kzougTnU3ZgNQxjBPkBPsMVDd+mswulKoBxMqF1M=; b=P1WraYwOvE/GMDRw9AucHuHGl7ZnDrATdAdw0rHuohkDTkZBeLGNCyCSLFAoA1k3Hq btcOPvk0Bgya2rlMRG20foYNlNX9I//WghEkk/0dusQBDlucq5S712HAhjWMfXpCLVWm mLiXA2ZW50LzUG9lvEIiSLXh7FGpydxw6zRHt5cUuEpanKGoGSNIE0jptQy9GP5XsM0+ sMV+BiDNasEvJUyERrLnbNHkwz75RvUsCY5n2zR3B6DPd6mu8uW2xzOUAev8A4MSwdpy VWxgvEi7PVAbLoQTaO0PpySg/HqnZLJF9HUWgmNJJ0drRgcfEW9QwnvP/wTdxKnh8Fw2 vryQ== 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=Yi/kzougTnU3ZgNQxjBPkBPsMVDd+mswulKoBxMqF1M=; b=XMX+05iZmVs7nwVC/ExIXGihcLJArPp6kT16gbm/1Qa29r4ErxZscjAXpYbC40F3ps 5C8u+f79MYC5/eIIz8KWgR1QrA8JAPbKGBI/AGcdslmFm4fsa+ahLqJna57SueI+YwfZ /4YKhP7S5mRokaDRGeVp44PKKfpOgHok3BTTEVM2A6dx+y/fyhrg8edG+dk2DuBw7EvS iOOS0291vxKutqSJ7cuFPod3+VIpltKZUQjvpPJUXJ2uBEhw2p8mFM/ARFf06PV+f0YK e2Qo2jjupKAdhOvO6gewgZlAK/gDvsh3rn9R9MWlFV/wQx4y7VPhmBcPtuUen5GiY+jf 8UrA== X-Gm-Message-State: AFeK/H3RRvdQk3gYm7e0DQWclvo1WF+i4XQutNzEXNwK63/p+a8Bay/h3JD144jq5yJ16A== X-Received: by 10.107.35.198 with SMTP id j189mr868764ioj.76.1490885438787; Thu, 30 Mar 2017 07:50:38 -0700 (PDT) Received: from t2001067c0370199861d1a9fa7f011c21.v6.meeting.ietf.org (t2001067c0370199861d1a9fa7f011c21.v6.meeting.ietf.org. [2001:67c:370:1998:61d1:a9fa:7f01:1c21]) by smtp.gmail.com with ESMTPSA id q185sm5120992itc.22.2017.03.30.07.50.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 07:50:37 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B248B620-BC86-4DF1-BDA7-EE4F86932942" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 30 Mar 2017 09:50:36 -0500 In-Reply-To: <969.1490885159@obiwan.sandelman.ca> Cc: Juliusz Chroboczek , Mark Townsley , HOMENET , anima@ietf.org, casm@ietf.org To: Michael Richardson References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <87r31fhk0d.wl-jch@irif.fr> <1636.1490823705@obiwan.sandelman.ca> <87h92bhhhh.wl-jch@irif.fr> <969.1490885159@obiwan.sandelman.ca> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] prefix assignment 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, 30 Mar 2017 14:50:42 -0000 --Apple-Mail=_B248B620-BC86-4DF1-BDA7-EE4F86932942 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 30, 2017, at 9:45 AM, Michael Richardson = wrote: > It would hand out space via HNCP, and if it ran out of space, get = more. This can also be done with DHCP. --Apple-Mail=_B248B620-BC86-4DF1-BDA7-EE4F86932942 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Mar 30, 2017, at 9:45 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
It would hand out space via HNCP, and if = it ran out of space, get more.

This = can also be done with DHCP.

= --Apple-Mail=_B248B620-BC86-4DF1-BDA7-EE4F86932942-- From nobody Thu Mar 30 07:52: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 3A26D12950E; Thu, 30 Mar 2017 07:51:54 -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 DkMp-I1Wqxg0; Thu, 30 Mar 2017 07:51: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 00F39120726; Thu, 30 Mar 2017 07:51:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5966F203AD; Thu, 30 Mar 2017 11:15:49 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 122CA636BB; Thu, 30 Mar 2017 10:51:51 -0400 (EDT) From: Michael Richardson To: "homenet\@ietf.org" , "casm\@ietf.org" , "anima\@ietf.org" CC: Pierre Pfister , Brian E Carpenter , Mark Townsley In-Reply-To: References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <4C898133-C860-4369-8BDC-E5868CA70EB9@cisco.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] [Anima] prefix assignment 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, 30 Mar 2017 14:51:54 -0000 --=-=-= Content-Type: text/plain Pierre Pfister wrote: > Absolutely. RFC7695 Applicability Statement (Section 3.) explains that > the algorithm can be used as > long as participating nodes gets configured with an eventually > consistent set of non-overlaping prefixes, > which are then used to carve-out sub-prefixes that are assigned to > link/nodes/objects/toasters. I think that I can envision a situation where a largish distributed enterprise could use auto-configuring Homenet technology in a "Small Office" configuration, and would use a CASM/ANIMA mechanism at the edge to ask for more address space from HQ. (That could well be occuring via a VPN, or some dark fiber, doesn't matter) In that case, the HNCP and ANIMA parts would be in a common trust environment. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljdG4YACgkQgItw+93Q 3WUbwwf/ZiCAABSrUsDqCI8zjLTV3Cz+VsFLSstl7cQyBOJx8qac3FlmiuD1UaO0 PptytK/0ttqbm6h0Pzn6aSUri9p0F7gyxu6ou95NuyEni1bOSNad0DDrbKPjdiKV CIRxi6WTNzi3GcjtDhLp9BCIY4Xs7HZUkga5RXzWjoFMO9uOorh/fZF+trImegGt ymKSK4tA8DPLPZ6m8qB2V3sc6sOhDtXsHekMU4y+iHWKHjQZmHEtGCYisoDLnlm0 8iMRqZnX0PU5wT3rc3YopS8g5f0rarCoyHJyJvHQQYhtc+MNWunJDvyPIDjzoqB2 FfZpQ+FGGIwqbJ04awCJCR9OZ7FXbQ== =/lkD -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 30 08:26: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 835EF1296CD; Thu, 30 Mar 2017 08:26:53 -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, FREEMAIL_FROM=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 e7IRGCtUj_tU; Thu, 30 Mar 2017 08:26:51 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 2BDD912952F; Thu, 30 Mar 2017 08:26:51 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id n76so3216199ioe.1; Thu, 30 Mar 2017 08:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GgB26uphbGPvc5jOBtWTx/6FP8vWqNeVvu9tzTlcc/4=; b=b6yBTqKuG/yM6mxinQa5pESkrT0lQaEKj4H/V73yc0EmKvY0CKlC8eOFfKqgFdgElT RTXpKnXxq5Rpbt0j4BDynuBR0WuRxlgcXzF7c06qC6O+EIuEOCC8ZVy2QRhYxIurgLCw EOsDaJ+1PnDnwxehCstuCjzsQDb53pZ9Y6kQnY4sL/WwyiEZracjmsoYZ7DHJCu9F+jJ r8ALFGCDNkwmFbu3f5iYgQeX/lZU642wIP+3DqlQFSnZyFDHJQydly5WvcLTKswQqI3k K/8CgOj9+GM90XhA2csQbGHaAyIKn7dpW6GMuYHdxDs2ReZK35y6kg9tBELcX7HA+moQ rwPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=GgB26uphbGPvc5jOBtWTx/6FP8vWqNeVvu9tzTlcc/4=; b=ngg7gi5w2KMh3LU5hLhtlU8Li7YdeuJSzCx3i0cgd3QR7dFNjhwvqTIZZZ02HHTW4h juGC/wrCF4c/6PX7zMZzP0QQFeHbcfbgCM7uSw+GyQPNWej0Gw64CV902X/OoS3W4lH1 bmjga89Di/U2gCD4DhS65HUVbZ7q10urX5CaU2sTzQ7SVG2OGN6J6IjhaDrlchipHSVz +8VJsO951hoDw+csks7Iy/KPbS/dMQdSqCi+WJTEOcb4tnMMxnXqsh1a0ttwlg7jNBOp X0JLRCXrjyTxG2THbotLcgnqNr07rjedcDztE8OcS6ZheJo9GGXvVpYTWHvWAdtUUeZ7 rTuQ== X-Gm-Message-State: AFeK/H1P3Cw3SwXu6gBT0pX2yDJ1CDOXeobgU0nk5BdKSB0pJhHmTxacRLpVp1/VOaYrpQ== X-Received: by 10.107.35.211 with SMTP id j202mr1091444ioj.158.1490887610461; Thu, 30 Mar 2017 08:26:50 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f196sm1178412itc.2.2017.03.30.08.26.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 08:26:49 -0700 (PDT) To: Ted Lemon , Michael Richardson References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <87r31fhk0d.wl-jch@irif.fr> <1636.1490823705@obiwan.sandelman.ca> <87h92bhhhh.wl-jch@irif.fr> <969.1490885159@obiwan.sandelman.ca> Cc: Mark Townsley , HOMENET , anima@ietf.org, Juliusz Chroboczek , casm@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <1aab4a0c-24bc-1b4b-0c0d-8ab7ba38726f@gmail.com> Date: Fri, 31 Mar 2017 04:26:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [homenet] [Anima] prefix assignment 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, 30 Mar 2017 15:26:54 -0000 On 31/03/2017 03:50, Ted Lemon wrote: > On Mar 30, 2017, at 9:45 AM, Michael Richardson wrote: >> It would hand out space via HNCP, and if it ran out of space, get more. > > This can also be done with DHCP. Indeed. I'm not trying to force the Anima approach, just pointing out that it will be available in contexts where more than a simple PD operation might be appropriate. Brian From nobody Thu Mar 30 10:54: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 057B612952F; Thu, 30 Mar 2017 10:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 Dna2d0N-T3ot; Thu, 30 Mar 2017 10:54:52 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 EBE15128D19; Thu, 30 Mar 2017 10:54:51 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id b140so24487209iof.1; Thu, 30 Mar 2017 10:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z7GNuBzKawqmBMhUX04y/xRfhnlcG6aZcfJ5Kh+A09A=; b=uVoVW/T5BWFX8t4fZSNp4k8VwkfAc01ozfqYcFftRB2VfSHKH4N4sG6nAO2SaqL8ar 0DT5/t1jd7KQYLM/cUH0FTO/GA9YQZdMiI2P9FXFiUpgNYDbkCfG31QI21NOm0oPgMTj x2+zaYrRfsEtnA5g0CENkjP5Rs3XR4pmAKR8QWrbnR8JLQwSjPS0ToMwKJz5go2+CxtY rQ6mJlwhdFlFmX59Bof4ZwEE/hfCwZ1EjAYBMyocdHC/dNZrc7sYnMLT5MNFZD2D27+1 +Vc4yZdb/wnV+d4X2kTUY7SIyKwRBOJHfN30ls/Khx27zo3Pt7DN5G6K/tPmI4Ulb8QH k0ag== 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=z7GNuBzKawqmBMhUX04y/xRfhnlcG6aZcfJ5Kh+A09A=; b=d+SOK2XSUUKNrbaikzJYaznmDSev6cS/Myr+bfMoZtSIA4bPGHvVm6ZSGOa5YRYoN2 dNMlRtqgt7DJQJ2KM56mqFsks8G5oAdQf3xo08hI0NLL8/b+R3cbppUDzH4ggEP/3tSN LZqTkGLw56wqZ+QVknqCJNJ58IARSDWUHDTBHKvBKjkUOGvN8lew0uVMR5OLRyvU6tVE h1aKspGoc0wltnT0AdVCRqcx0NdkcA2Doff2fRiX94zvisgoKjKDqw63qIcJb/bGUvww cmyXNtO5YF5k5jmFbJ6UfQFHlIPiAs2H3QLBuroEmOgLS/k3n1jQzeZvdFzgw/Kb0+nl XUsg== X-Gm-Message-State: AFeK/H3bMbHP6a81T56tkaQ+cS1UrlnRR3irqVXJRvWJCeMmRhKFTNG18WiX6wo6Z6CHRApa/kPOTRRTe/6QSw== X-Received: by 10.107.136.41 with SMTP id k41mr2124251iod.160.1490896491177; Thu, 30 Mar 2017 10:54:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.46.151 with HTTP; Thu, 30 Mar 2017 10:54:50 -0700 (PDT) In-Reply-To: <20170330052006.008D66A4B0BE@rock.dv.isc.org> References: <29150.1490800075@obiwan.sandelman.ca> <20170330052006.008D66A4B0BE@rock.dv.isc.org> From: Brian Dickson Date: Thu, 30 Mar 2017 12:54:50 -0500 Message-ID: To: Mark Andrews Cc: Mark Townsley , Michael Richardson , HOMENET , "dnsop@ietf.org" , Terry Manderson Content-Type: multipart/alternative; boundary=001a113ec618c0ed6c054bf663af Archived-At: Subject: Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 30 Mar 2017 17:54:55 -0000 --001a113ec618c0ed6c054bf663af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mark, When I say, "never reaches the roots", this is what I mean: Resolution of "example." is, by design, intercepted by homenet resolvers, and never reaches the outside world. Do you concur with this statement? Please stop conflating the issue of "the homenet namespace is local" (and thus not resolvable from outside starting at the DNS root) from the issue of the need for an insecure delegation IF homenet end systems do their own DNSSEC validation AND those same end systems don't special-case homenet from validation AND IF homenet is not signed with a separate trust anchor. Yes, IF validating stubs need to confirm the unsigned nature of homenet, THEN there is a need for retrieving the appropriate DNSSEC proof showing that there is a delegation out of the chain of trust anchored at the DNS root. What that proof looks like is dependent on the issue under discussion, which is what the domain name for homenet should be, and why. If the domain for homenet is "homenet." anchored in the root zone, then yes, "homenet/DS" will need to be obtained (or more correctly, "homenet/NSEC" proving no DS exists), signed by the ZSK of the root, along with the signed DNSKEY set (signed by the KSK of the root, i.e. the ICANN root trust anchor). If the domain for homenet is something else, such as "homenet.arpa.", then the proof contains more elements, such as the DS for arpa, and the NSEC for homenet.arpa (proving no homenet.arpa/DS exists). Brian On Thu, Mar 30, 2017 at 12:20 AM, Mark Andrews wrote: > > In message gmail.com>, Brian Dickson writes: > > On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley > wrote: > > > > > > > > > On Mar 29, 2017, at 10:07 AM, Michael Richardson > > > > > wrote: > > > > > > > > > > > > Terry Manderson wrote: > > > >> B) seek a .homenet special use domain WITHOUT the delegation reque= st > > > >> AND ask the IETF/IESG/IAB to commence the discussion with the ICAN= N > > > >> community to achieve an insecure delegation > > > > > > > >> c) seek a .arpa insecure special use delegation > > > > > > > >> d) go for "B" and if that doesn't work shift to "C" > > > > > > > > Is there some reason we can not proceed with "C", concurrently with > (B). > > > > > > I think that would require a new consensus call. There was a lot of > work > > > done to get to the point of agreeing on a path forward at the last > IETF, > > > and this path would be rather different than that. > > > > > > > This might cause stub resolvers to have to have two cases > > > > (SOMETHING.arpa, and .homenet) eventually, but at least we could > deploy > > > > and attempt interop with SOMETHING.arpa NOW, and it would more > clearly > > > > permit "home." to be removed from code. > > > > > > > > > > /chair-hat-off > > > > > > I don=E2=80=99t think we want to have two defaults in our specs. It= =E2=80=99s bad > enough > > > that we are already going to end up with .home and .homenet depending > on > > > the version of code used or forked from, I really don=E2=80=99t want = to do > anything > > > that could lead to a third if we can avoid it. > > > > > > - Mark > > > > > > > Taking a STRICTLY devil's advocate position here: > > > > Isn't it the case that the thing that knows what the label is= , > > should be able to masquerade on behalf of anything that isn't aware of > the > > divergence of the three possible values for ? If you end up wi= th > > some boxes thinking it is ".home", some ".homenet", and some > > ".homenet.arpa", as long as one of them knows about all three, it shoul= d > > be possible to resolve the differences. > > > > The scope of the namespace is "the home network", and never reaches the > > real DNS (roots), so at worst it would be folding the three fake > > namespaces into a unified (three-headed) fake namespace. > > Can we please stop with this "and never reaches the real DNS (roots)" > garbage. Queries for homenet/DS *will* reach the roots. That is > how DNSSEC validation is designed to work. They *need* to be > answered with a signed NOERROR NODATA response. Lots of Linux > distributions ship with DNSSEC validation enabled for on machine > clients and they are also configured to forward to the nameservers > that are returned by DHCP. > > These machines behave *exactly* like a validating stub resolver from > the DNSSEC perspective. This isn't something that will be in the > future. It is the PRESENT. > > > I.e. avoid it if you can, but if you can't, I think the issues are > > solvable, even if they get a little funky/ugly under the hood. > > > > None of that should be visible to users, I don't think. > > > > Brian > > > > P.S. Guide to implementers - never expose multiple handles for the same > > object; over-exuberant users may be tempted to try to "clean up" the > > duplicates. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --001a113ec618c0ed6c054bf663af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mark,

When I say, "never reaches th= e roots", this is what I mean:
Resolution of "example.&= lt;homenet-label>" is, by design, intercepted by homenet resolvers,= and never reaches the outside world.=C2=A0
Do you concur with th= is statement?

Please stop conflating the iss= ue of "the homenet namespace is local" (and thus not resolvable f= rom outside starting at the DNS root) from the issue of the need for an ins= ecure delegation IF homenet end systems do their own DNSSEC validation AND = those same end systems don't special-case homenet from validation AND I= F homenet is not signed with a separate trust anchor.

<= div>Yes, IF validating stubs need to confirm the unsigned nature of homenet= , THEN there is a need for retrieving the appropriate DNSSEC proof showing = that there is a delegation out of the chain of trust anchored at the DNS ro= ot.

What that proof looks like is dependent on the= issue under discussion, which is what the domain name for homenet should b= e, and why.

If the domain for homenet is "hom= enet." anchored in the root zone, then yes, "homenet/DS" wil= l need to be obtained (or more correctly, "homenet/NSEC" proving = no DS exists), signed by the ZSK of the root, along with the signed DNSKEY = set (signed by the KSK of the root, i.e. the ICANN root trust anchor).

If the domain for homenet is something else, such as &= quot;homenet.arpa.", then the proof contains more elements, such as th= e DS for arpa, and the NSEC for homenet.arpa (proving no homenet.arpa/DS ex= ists).

Brian

On Thu, Mar 30, 2017 at 12:20 AM, Mar= k Andrews <marka@isc.org> wrote:

In message <CAH1iCiozhJ3CxRDXh8R1kfv40SZvA2MqPmsstx__+= 34BRowwUw@mail.gmail.com>, Brian Dickson writes:
> On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley <mark@townsley.net> wrote:
>
> >
> > > On Mar 29, 2017, at 10:07 AM, Michael Richardson
> <mcr+ietf@sandelman.ca>
> > wrote:
> > >
> > >
> > > Terry Manderson <terry.manderson@icann.org> wrote:
> > >> B) seek a .homenet special use domain WITHOUT the delega= tion request
> > >> AND ask the IETF/IESG/IAB to commence the discussion wit= h the ICANN
> > >> community to achieve an insecure delegation
> > >
> > >> c) seek a <SOMETHING>.arpa insecure special use de= legation
> > >
> > >> d) go for "B" and if that doesn't work shi= ft to "C"
> > >
> > > Is there some reason we can not proceed with "C", = concurrently with (B).
> >
> > I think that would require a new consensus call. There was a lot = of work
> > done to get to the point of agreeing on a path forward at the las= t IETF,
> > and this path would be rather different than that.
> >
> > > This might cause stub resolvers to have to have two cases > > > (SOMETHING.arpa, and .homenet) eventually, but at least we c= ould deploy
> > > and attempt interop with SOMETHING.arpa NOW, and it would mo= re clearly
> > > permit "home." to be removed from code.
> > >
> >
> > /chair-hat-off
> >
> > I don=E2=80=99t think we want to have two defaults in our specs. = It=E2=80=99s bad enough
> > that we are already going to end up with .home and .homenet depen= ding on
> > the version of code used or forked from, I really don=E2=80=99t w= ant to do anything
> > that could lead to a third if we can avoid it.
> >
> > - Mark
> >
>
> Taking a STRICTLY devil's advocate position here:
>
> Isn't it the case that the thing that knows what the <homenet&g= t; label is,
> should be able to masquerade on behalf of anything that isn't awar= e of the
> divergence of the three possible values for <homenet>? If you en= d up with
> some boxes thinking it is ".home", some ".homenet"= , and some
> ".homenet.arpa", as long as one of them knows about all thre= e, it should
> be possible to resolve the differences.
>
> The scope of the namespace is "the home network", and never = reaches the
> real DNS (roots), so at worst it would be folding the three fake
> namespaces into a unified (three-headed) fake namespace.

Can we please stop with this "and never reaches the real D= NS (roots)"
garbage.=C2=A0 Queries for homenet/DS *will* reach the roots.=C2=A0 That is=
how DNSSEC validation is designed to work.=C2=A0 They *need* to be
answered with a signed NOERROR NODATA response.=C2=A0 Lots of Linux
distributions ship with DNSSEC validation enabled for on machine
clients and they are also configured to forward to the nameservers
that are returned by DHCP.

These machines behave *exactly* like a validating stub resolver from
the DNSSEC perspective.=C2=A0 This isn't something that will be in the<= br> future.=C2=A0 It is the PRESENT.

> I.e. avoid it if you can, but if you can't, I think the issues are=
> solvable, even if they get a little funky/ugly under the hood.
>
> None of that should be visible to users, I don't think.
>
> Brian
>
> P.S. Guide to implementers - never expose multiple handles for the sam= e
> object; over-exuberant users may be tempted to try to "clean up&q= uot; the
> duplicates.

--
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

--001a113ec618c0ed6c054bf663af-- From nobody Thu Mar 30 11:05: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 B94931296CF; Thu, 30 Mar 2017 11:05: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 x-iiyKR85m0S; Thu, 30 Mar 2017 11:05:15 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBBE129447; Thu, 30 Mar 2017 11:05:15 -0700 (PDT) Received: from linux-hs2j.localnet (dhcp-148.access.lah1.vix.su [24.104.150.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id D864F61F9C; Thu, 30 Mar 2017 18:05:14 +0000 (UTC) From: Paul Vixie To: dnsop@ietf.org Cc: Brian Dickson , Mark Andrews , Michael Richardson , HOMENET , Mark Townsley , Terry Manderson Date: Thu, 30 Mar 2017 18:05:14 +0000 Message-ID: <4075745.jMg8SJvaMW@linux-hs2j> Organization: Vixie Freehold In-Reply-To: References: <20170330052006.008D66A4B0BE@rock.dv.isc.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 30 Mar 2017 18:05:25 -0000 On Thursday, March 30, 2017 5:54:50 PM GMT Brian Dickson wrote: > Mark, > > When I say, "never reaches the roots", this is what I mean: > Resolution of "example." is, by design, intercepted by > homenet resolvers, and never reaches the outside world. > Do you concur with this statement? > > ... i'm not mark, but i'd like to speak on a related topic. by design, queries that result in RFC 1918 addresses, and queries for RFC 1918 PTR names, were to be intercepted by local resolvers. let me know if you can't access DNS-OARC's DITL archives, which will show you how prominent both kinds those queries loom in actual root name service load. i predict that foo.bar. will do likewise, whatever its design. this is the one saving grace in asking for a real root zone delegation: we can add an NS pointing to localhost, and try to get subsequent queries to go to heck rather than to the root servers. vixie From nobody Thu Mar 30 11:11: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 95EA11299CF; Thu, 30 Mar 2017 11:11: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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=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 nw6vyeyotx5e; Thu, 30 Mar 2017 11:11:03 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFDE128D3E; Thu, 30 Mar 2017 11:11:03 -0700 (PDT) Received: from dummy.name; Thu, 30 Mar 2017 18:11:02 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Steve Crocker In-Reply-To: <4075745.jMg8SJvaMW@linux-hs2j> Date: Thu, 30 Mar 2017 14:11:00 -0400 Cc: "Stephen D. Crocker" , "dnsop@ietf.org WG" , Brian Dickson , Michael Richardson , Mark Townsley , HOMENET , Terry Manderson Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170330052006.008D66A4B0BE@rock.dv.isc.org> <4075745.jMg8SJvaMW@linux-hs2j> To: Paul Vixie X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 30 Mar 2017 18:11:15 -0000 On the other hand, might there be value in seeing how much errant = traffic goes to the root so it can be reported and used to inform = vendors, network architects, network administrators, et al? Given the amount of bogus traffic already goes to the root, I=E2=80=99m = not immediately worried this will increase the traffic level to a point = of concern. And I remain puzzled as to why a simple NXDOMAIN response from the root = isn=E2=80=99t exactly the right thing and why it matters whether it=E2=80=99= s signed or not. Steve > On Mar 30, 2017, at 2:05 PM, Paul Vixie wrote: >=20 > On Thursday, March 30, 2017 5:54:50 PM GMT Brian Dickson wrote: >> Mark, >>=20 >> When I say, "never reaches the roots", this is what I mean: >> Resolution of "example." is, by design, intercepted by >> homenet resolvers, and never reaches the outside world. >> Do you concur with this statement? >>=20 >> ... >=20 > i'm not mark, but i'd like to speak on a related topic. >=20 > by design, queries that result in RFC 1918 addresses, and queries for = RFC 1918=20 > PTR names, were to be intercepted by local resolvers. >=20 > let me know if you can't access DNS-OARC's DITL archives, which will = show you=20 > how prominent both kinds those queries loom in actual root name = service load. >=20 > i predict that foo.bar. will do likewise, whatever its = design.=20 > this is the one saving grace in asking for a real root zone = delegation: we can=20 > add an NS pointing to localhost, and try to get subsequent queries to = go to=20 > heck rather than to the root servers. >=20 > vixie >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu Mar 30 11:21: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 EB17C127B60; Thu, 30 Mar 2017 11:21:36 -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 G-z9r4oLaeg8; Thu, 30 Mar 2017 11:21:35 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705561279EB; Thu, 30 Mar 2017 11:21:35 -0700 (PDT) Received: from linux-hs2j.localnet (dhcp-148.access.lah1.vix.su [24.104.150.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4079261F9C; Thu, 30 Mar 2017 18:21:35 +0000 (UTC) From: Paul Vixie To: Steve Crocker Cc: "dnsop@ietf.org WG" , Brian Dickson , Michael Richardson , Mark Townsley , HOMENET , Terry Manderson Date: Thu, 30 Mar 2017 18:21:34 +0000 Message-ID: <6266533.Fy4lafrYmC@linux-hs2j> Organization: Vixie Freehold In-Reply-To: References: <4075745.jMg8SJvaMW@linux-hs2j> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 30 Mar 2017 18:21:37 -0000 On Thursday, March 30, 2017 6:11:00 PM GMT Steve Crocker wrote: > On the other hand, might there be value in seeing how much errant traffic > goes to the root so it can be reported and used to inform vendors, network > architects, network administrators, et al? it seems unlikely to me that any of them would care. they didn't for RFC 19= 18,=20 and i did try, for years, before DNS-OARC existed, using f-root trace data. > Given the amount of bogus traffic already goes to the root, I=E2=80=99m n= ot > immediately worried this will increase the traffic level to a point of > concern. that's what we've said about every other incremental increase. some day we= =20 will reach a tipping point and be wrong. i think if we know that dreck is=20 coming, we should prepare for it, perhaps with an NS RR pointing to the AS1= 12=20 project, whose operators are ready to share data with researchers on reques= t. perversely, the ~90+% garbage we receive helps motivate overprovisioning, a= nd=20 helps ensure that when some server is down, its impact (less than 10% of lo= ad=20 that should be answered) is statistically spread out across a large amount = of=20 dreck. if only good queries made it to the roots, then the statisticaly=20 likelihood of not being able to answer one that mattered, would be higher.= =20 it's a congestion-based form of forward error correction, i suppose. > And I remain puzzled as to why a simple NXDOMAIN response from the root > isn=E2=80=99t exactly the right thing and why it matters whether it=E2=80= =99s signed or > not. nxdomain isn't cached by everyone who should, and of those who cache it,=20 nxdomain doesn't stop downward cache traversal everywhere (which it should)= ,=20 and in any case nxdomain covers the full qname and so would only stop=20 traversals through a full (foo.bar.) qname, which is why we n= eed=20 query-minimization (which would permit queries for just or=20 perhaps .) whose cached nxdomains would have a broa= der=20 impact (if they stopped traversal and if they are cached at all.) executive summary: the dns works at all, and we love that, but it's not hap= py=20 and it's not healthy and it's never going to be. vixie From nobody Thu Mar 30 11:22: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 89667129A0B; Thu, 30 Mar 2017 11:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ZemPpEHFkE4w; Thu, 30 Mar 2017 11:22:41 -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 D37C51298C7; Thu, 30 Mar 2017 11:22:40 -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 9230824AE09; Thu, 30 Mar 2017 18:21:20 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7E61A160047; Thu, 30 Mar 2017 18:21:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6C28F16008F; Thu, 30 Mar 2017 18:21:20 +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 yXH0_Eq2G33f; Thu, 30 Mar 2017 18:21:20 +0000 (UTC) Received: from rock.dv.isc.org (dhcp-8754.meeting.ietf.org [31.133.135.84]) by zmx1.isc.org (Postfix) with ESMTPSA id 3A4BC160047; Thu, 30 Mar 2017 18:21:20 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 60AE66A52C15; Fri, 31 Mar 2017 05:21:19 +1100 (AEDT) To: Brian Dickson Cc: Mark Townsley , Michael Richardson , HOMENET , "dnsop@ietf.org" , Terry Manderson From: Mark Andrews References: <29150.1490800075@obiwan.sandelman.ca> <20170330052006.008D66A4B0BE@rock.dv.isc.org> In-reply-to: Your message of "Thu, 30 Mar 2017 12:54:50 -0500." Date: Fri, 31 Mar 2017 05:21:19 +1100 Message-Id: <20170330182119.60AE66A52C15@rock.dv.isc.org> Archived-At: Subject: Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 30 Mar 2017 18:22:45 -0000 In message , Brian Di ckson writes: > > Mark, > > When I say, "never reaches the roots", this is what I mean: > Resolution of "example." is, by design, intercepted by > homenet resolvers, and never reaches the outside world. > Do you concur with this statement? Yes, but that isn't the complete picture. "never" doesn't mean "most of the time". "never" means "never". > Please stop conflating the issue of "the homenet namespace is local" (and > thus not resolvable from outside starting at the DNS root) from the issue > of the need for an insecure delegation IF homenet end systems do their own > DNSSEC validation AND those same end systems don't special-case homenet > from validation AND IF homenet is not signed with a separate trust anchor. I want RFC 4035 compliant validating systems to be able to resolve local names with the default homenet domain name when they are connected to a homenet. That cannot happen without there being a insecure delegation in the global namespace that breaks the DNSSEC chain of trust. Additionally the chosen name MUST exist in the global namespace to avoid QNAME minimisation issues. > Yes, IF validating stubs need to confirm the unsigned nature of homenet, > THEN there is a need for retrieving the appropriate DNSSEC proof showing > that there is a delegation out of the chain of trust anchored at the DNS > root. > > What that proof looks like is dependent on the issue under discussion, > which is what the domain name for homenet should be, and why. RFC 4035 states what that proof needs to look like. That proof needs to exist at whatever name is chosen. > If the domain for homenet is "homenet." anchored in the root zone, then > yes, "homenet/DS" will need to be obtained (or more correctly, > "homenet/NSEC" proving no DS exists), signed by the ZSK of the root, along > with the signed DNSKEY set (signed by the KSK of the root, i.e. the ICANN > root trust anchor). > > If the domain for homenet is something else, such as "homenet.arpa.", then > the proof contains more elements, such as the DS for arpa, and the NSEC for > homenet.arpa (proving no homenet.arpa/DS exists). > > Brian > > On Thu, Mar 30, 2017 at 12:20 AM, Mark Andrews wrote: > > > > > In message > gmail.com>, Brian Dickson writes: > > > On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley > > wrote: > > > > > > > > > > > > On Mar 29, 2017, at 10:07 AM, Michael Richardson > > > > > > > wrote: > > > > > > > > > > > > > > > Terry Manderson wrote: > > > > >> B) seek a .homenet special use domain WITHOUT the delegation reque= > st > > > > >> AND ask the IETF/IESG/IAB to commence the discussion with the ICAN= > N > > > > >> community to achieve an insecure delegation > > > > > > > > > >> c) seek a .arpa insecure special use delegation > > > > > > > > > >> d) go for "B" and if that doesn't work shift to "C" > > > > > > > > > > Is there some reason we can not proceed with "C", concurrently with > > (B). > > > > > > > > I think that would require a new consensus call. There was a lot of > > work > > > > done to get to the point of agreeing on a path forward at the last > > IETF, > > > > and this path would be rather different than that. > > > > > > > > > This might cause stub resolvers to have to have two cases > > > > > (SOMETHING.arpa, and .homenet) eventually, but at least we could > > deploy > > > > > and attempt interop with SOMETHING.arpa NOW, and it would more > > clearly > > > > > permit "home." to be removed from code. > > > > > > > > > > > > > /chair-hat-off > > > > > > > > I don=E2=80=99t think we want to have two defaults in our specs. It= > =E2=80=99s bad > > enough > > > > that we are already going to end up with .home and .homenet depending > > on > > > > the version of code used or forked from, I really don=E2=80=99t want = > to do > > anything > > > > that could lead to a third if we can avoid it. > > > > > > > > - Mark > > > > > > > > > > Taking a STRICTLY devil's advocate position here: > > > > > > Isn't it the case that the thing that knows what the label is= > , > > > should be able to masquerade on behalf of anything that isn't aware of > > the > > > divergence of the three possible values for ? If you end up wi= > th > > > some boxes thinking it is ".home", some ".homenet", and some > > > ".homenet.arpa", as long as one of them knows about all three, it shoul= > d > > > be possible to resolve the differences. > > > > > > The scope of the namespace is "the home network", and never reaches the > > > real DNS (roots), so at worst it would be folding the three fake > > > namespaces into a unified (three-headed) fake namespace. > > > > Can we please stop with this "and never reaches the real DNS (roots)" > > garbage. Queries for homenet/DS *will* reach the roots. That is > > how DNSSEC validation is designed to work. They *need* to be > > answered with a signed NOERROR NODATA response. Lots of Linux > > distributions ship with DNSSEC validation enabled for on machine > > clients and they are also configured to forward to the nameservers > > that are returned by DHCP. > > > > These machines behave *exactly* like a validating stub resolver from > > the DNSSEC perspective. This isn't something that will be in the > > future. It is the PRESENT. > > > > > I.e. avoid it if you can, but if you can't, I think the issues are > > > solvable, even if they get a little funky/ugly under the hood. > > > > > > None of that should be visible to users, I don't think. > > > > > > Brian > > > > > > P.S. Guide to implementers - never expose multiple handles for the same > > > object; over-exuberant users may be tempted to try to "clean up" the > > > duplicates. > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > --001a113ec618c0ed6c054bf663af > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > >
Mark,

When I say, "never reaches th= > e roots", this is what I mean:
Resolution of "example.&= > lt;homenet-label>" is, by design, intercepted by homenet resolvers,= > and never reaches the outside world.=C2=A0
Do you concur with th= > is statement?

Please stop conflating the iss= > ue of "the homenet namespace is local" (and thus not resolvable f= > rom outside starting at the DNS root) from the issue of the need for an ins= > ecure delegation IF homenet end systems do their own DNSSEC validation AND = > those same end systems don't special-case homenet from validation AND I= > F homenet is not signed with a separate trust anchor.

<= > div>Yes, IF validating stubs need to confirm the unsigned nature of homenet= > , THEN there is a need for retrieving the appropriate DNSSEC proof showing = > that there is a delegation out of the chain of trust anchored at the DNS ro= > ot.

What that proof looks like is dependent on the= > issue under discussion, which is what the domain name for homenet should b= > e, and why.

If the domain for homenet is "hom= > enet." anchored in the root zone, then yes, "homenet/DS" wil= > l need to be obtained (or more correctly, "homenet/NSEC" proving = > no DS exists), signed by the ZSK of the root, along with the signed DNSKEY = > set (signed by the KSK of the root, i.e. the ICANN root trust anchor). >

If the domain for homenet is something else, such as &= > quot;homenet.arpa.", then the proof contains more elements, such as th= > e DS for arpa, and the NSEC for homenet.arpa (proving no homenet.arpa/DS ex= > ists).

Brian
extra">
On Thu, Mar 30, 2017 at 12:20 AM, Mar= > k Andrews < _blank">marka@isc.org> wrote:
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= > x">

> In message < 2B34BRowwUw@mail.gmail.com">CAH1iCiozhJ3CxRDXh8R1kfv40SZvA2MqPmsstx__+= > 34BRowwUw@mail.gmail.com>, Brian Dickson writes:
> > On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley < ark@townsley.net">mark@townsley.net> wrote:
> >
> > >
> > > > On Mar 29, 2017, at 10:07 AM, Michael Richardson
> > <mcr+ietf@sandelman.ca a>>
> > > wrote:
> > > >
> > > >
> > > > Terry Manderson < org">terry.manderson@icann.org> wrote:
> > > >> B) seek a .homenet special use domain WITHOUT the delega= > tion request
> > > >> AND ask the IETF/IESG/IAB to commence the discussion wit= > h the ICANN
> > > >> community to achieve an insecure delegation
> > > >
> > > >> c) seek a <SOMETHING>.arpa insecure special use de= > legation
> > > >
> > > >> d) go for "B" and if that doesn't work shi= > ft to "C"
> > > >
> > > > Is there some reason we can not proceed with "C", = > concurrently with (B).
> > >
> > > I think that would require a new consensus call. There was a lot = > of work
> > > done to get to the point of agreeing on a path forward at the las= > t IETF,
> > > and this path would be rather different than that.
> > >
> > > > This might cause stub resolvers to have to have two cases > > > > > (SOMETHING.arpa, and .homenet) eventually, but at least we c= > ould deploy
> > > > and attempt interop with SOMETHING.arpa NOW, and it would mo= > re clearly
> > > > permit "home." to be removed from code.
> > > >
> > >
> > > /chair-hat-off
> > >
> > > I don=E2=80=99t think we want to have two defaults in our specs. = > It=E2=80=99s bad enough
> > > that we are already going to end up with .home and .homenet depen= > ding on
> > > the version of code used or forked from, I really don=E2=80=99t w= > ant to do anything
> > > that could lead to a third if we can avoid it.
> > >
> > > - Mark
> > >
> >
> > Taking a STRICTLY devil's advocate position here:
> >
> > Isn't it the case that the thing that knows what the <homenet&g= > t; label is,
> > should be able to masquerade on behalf of anything that isn't awar= > e of the
> > divergence of the three possible values for <homenet>? If you en= > d up with
> > some boxes thinking it is ".home", some ".homenet"= > , and some
> > ".homenet.arpa", as long as one of them knows about all thre= > e, it should
> > be possible to resolve the differences.
> >
> > The scope of the namespace is "the home network", and never = > reaches the
> > real DNS (roots), so at worst it would be folding the three fake
> > namespaces into a unified (three-headed) fake namespace.
>
>
Can we please stop with this "and never reaches the real D= > NS (roots)"
> garbage.=C2=A0 Queries for homenet/DS *will* reach the roots.=C2=A0 That is= >
> how DNSSEC validation is designed to work.=C2=A0 They *need* to be
> answered with a signed NOERROR NODATA response.=C2=A0 Lots of Linux
> distributions ship with DNSSEC validation enabled for on machine
> clients and they are also configured to forward to the nameservers
> that are returned by DHCP.
>
> These machines behave *exactly* like a validating stub resolver from
> the DNSSEC perspective.=C2=A0 This isn't something that will be in the<= > br> > future.=C2=A0 It is the PRESENT.
>

> > I.e. avoid it if you can, but if you can't, I think the issues are= >
> > solvable, even if they get a little funky/ugly under the hood.
> >
> > None of that should be visible to users, I don't think.
> >
> > Brian
> >
> > P.S. Guide to implementers - never expose multiple handles for the sam= > e
> > object; over-exuberant users may be tempted to try to "clean up&q= > uot; the
> > duplicates.
>
>
--
> 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
>

> > --001a113ec618c0ed6c054bf663af-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Mar 30 12:52: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 ACEEE12894A for ; Thu, 30 Mar 2017 12:52: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=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 1NzMVXF3L2Gr for ; Thu, 30 Mar 2017 12:52:25 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 5626712778D for ; Thu, 30 Mar 2017 12:52:25 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id l7so26781813ioe.3 for ; Thu, 30 Mar 2017 12:52: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=ClCIukjRA5BSBbCCtg9XSzQAm2vx4WEGcbbIl8Nq7mo=; b=PQidZLilK2pB3wggTJW6i6MbFas7uGuzI6KobNGryt6LSrDqtrLv3XZhL+Eamukatj /DJGamqILDRTjNqp7fp0AmVIy7RGD4VDM6iYkQlZWqWEK9rIvbcTxhJkbR9y5XuYM3Fx yyhUansHwQg+xNRi/ujROA1NuHxO86jXzupXOhsLAT+/rjOk3nzZse6AWwKt19IyKgI1 J+rZlkLWcJIw8adpAv7NKsrLmE9wSpS12wbR56IzI/ev7KPqYTy6PBePKd5IqA7+fLlB AuELOIkwleupjiNkLBMUJspx6dsEhY4Lmyt8zUmeB2VSVLOdQr63xYAcYVSL/0vTMXDH /zJQ== 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=ClCIukjRA5BSBbCCtg9XSzQAm2vx4WEGcbbIl8Nq7mo=; b=YbjTkdwHh4wWFee370aRKQhyrZMfo0iAc9Lau1dnaG2afBuzBCtHWuGm+OwSYZnSWN daHIo5HIJ2GUqSUCE1yByutc9ChpD0AXE7Jy/p38hvYcTKwi0FzvigtzFBdug5x/dmoa MsK+4m4u4tNQUDEiC7TKplS5pr9dNdv7naTO2TiIm8Alrcxcu2KdVbJ/QoXJEuORat2I ykC0tvf9z9GY3vGd63MSpQ/RWc2y/AghBM5QAeZ44jOXDG3UAC3A9jbAq3mEeIoLHhUP szpdtI6a/y7m4dHutp9nVUZpsB1rv4rHwjModbygnlx5MkEcdQNta+NF3tJLAYd9a3SM b4sw== X-Gm-Message-State: AFeK/H3SOvZDtTUuwG7xtZaaJWWVa3dnz4iKXTT+M2s6Ydr6MDLLtK8pr7M1SxJm+hl4qw== X-Received: by 10.107.27.204 with SMTP id b195mr2685770iob.26.1490903544598; Thu, 30 Mar 2017 12:52:24 -0700 (PDT) Received: from dhcp-91f6.meeting.ietf.org (dhcp-91f6.meeting.ietf.org. [31.133.145.246]) by smtp.gmail.com with ESMTPSA id c3sm57374ith.24.2017.03.30.12.52.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 12:52:23 -0700 (PDT) From: Ted Lemon Message-Id: <8C25D5ED-B9C5-4D46-94E0-C15A4538A9A8@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FE909100-B2E7-47D4-BA60-34A0C1FB8E66" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 30 Mar 2017 14:52:22 -0500 In-Reply-To: Cc: Paul Vixie , Brian Dickson , Michael Richardson , "dnsop@ietf.org WG" , Mark Townsley , HOMENET , Terry Manderson To: Steve Crocker References: <20170330052006.008D66A4B0BE@rock.dv.isc.org> <4075745.jMg8SJvaMW@linux-hs2j> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 30 Mar 2017 19:52:28 -0000 --Apple-Mail=_FE909100-B2E7-47D4-BA60-34A0C1FB8E66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 30, 2017, at 1:11 PM, Steve Crocker wrote: > And I remain puzzled as to why a simple NXDOMAIN response from the = root isn=E2=80=99t exactly the right thing and why it matters whether = it=E2=80=99s signed or not. Because DNSSEC. A validating stub will see a proof of nonexistence and = ignore anything the local recursive resolver offers.= --Apple-Mail=_FE909100-B2E7-47D4-BA60-34A0C1FB8E66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 30, 2017, at 1:11 PM, Steve Crocker <steve@shinkuro.com> = wrote:
And I remain = puzzled as to why a simple NXDOMAIN response from the root isn=E2=80=99t = exactly the right thing and why it matters whether it=E2=80=99s signed = or not.

Because DNSSEC.   A validating stub will = see a proof of nonexistence and ignore anything the local recursive = resolver offers.
= --Apple-Mail=_FE909100-B2E7-47D4-BA60-34A0C1FB8E66-- From nobody Thu Mar 30 13: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 9480512943C; Thu, 30 Mar 2017 13:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 7Bfs57mp61AI; Thu, 30 Mar 2017 13:46:42 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8201294F8; Thu, 30 Mar 2017 13:46:42 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 30 Mar 2017 13:46:39 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 30 Mar 2017 13:46:39 -0700 From: Terry Manderson To: HOMENET CC: "dnsop@ietf.org" Thread-Topic: [DNSOP] My assessment of .homenet as described during the WG session yesterday. Thread-Index: AQHSqZa6BXnknGGzd0m0I5wpP+R/Qw== Date: Thu, 30 Mar 2017 20:46:39 +0000 Message-ID: <07190227-DC82-4B1A-93CE-DF66AEB5111D@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3573787598_212650162" MIME-Version: 1.0 Archived-At: Subject: Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 30 Mar 2017 20:46:45 -0000 --B_3573787598_212650162 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Dear WGs (HOMENET and DNSOP) Based on the reviews from many folk, the discussions in DNSOP and HOMENET, the clarifying questions and responses during the HOMENET session at IETF98, a number of other DNS expert level discussions I have had, and the IAB statement [1] my final assessment on the HOMENET domain is as follows. A TLD request is not the ideal architectural direction that would encompass the goals of the greater Internet along with the ethos and scope of the IETF. I shall be returning the document (draft-ietf-homenet-dot) to the WG to consider and find consensus on a domain under .ARPA The already stated technical assessment is a .ARPA subdomain can satisfy the requirement for a special use domain, in addition to being resolvable in the DNS with the requested characteristics. The WG should consider the situations where the name of the device is escalated to the user, not that I believe the WG should engage in UI/UX design, but to ensure that if it is desired by the WG that the name be suitably obfuscated, HOMENET features should exist to ensure that. Thanks Terry [1] https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/ On 29/03/2017, 3:32 AM, "DNSOP on behalf of Terry Manderson" wrote: Dear HOMENET and DNSOP WG(s), Wearing the INT AD hat. Firstly, thank you to the DNSOP WG for the deep review, thoughts, and considered responses to my request for review. Secondly, my apologies for not sharing my throughs before the HOMENET session. It would have been impractical to do so as this is a very (VERY) fluid situation with IETF leadership also engaged in discussions. This is simply an iteration of my description of the current situation as delivered yesterday. Do be aware that conversations are continuing and you should NOT take this as a declarative statement. During the HOMENET WG session I specified that for this topic I am comfortable answering _ clarifying _ questions. The same applies here. My answers may or may not change due to the fluid nature of the concern and I hope you appreciate that. My summary of the situation is this. 1) .homenet _COULD_ be added to the special use domain registry based on RFC6761 2) The expected future operation of HOMENET resolution for DNSSEC validating stub resolvers requires a break in the DNSSEC chain of trust. 3) To achieve "2", the document _additionally_ asks IANA to insert an insecure delegation into the root zone 4) The ask for "3" is not covered in IETF policy terms, in fact it tries to put an entry into someone else's registry (the root zone), and will require a set of collaborative discussions with the ICANN community and a new process that handles this situation. There are no expectations that this process will be defined in a reasonable time for the uses of HOMENET. Options, possibly not an exhaustive list A) seek a .homenet special use domain with the request for an insecure delegation in the root zone. (This is what the document asks for NOW, and here we are) B) seek a .homenet special use domain WITHOUT the delegation request AND ask the IETF/IESG/IAB to commence the discussion with the ICANN community to achieve an insecure delegation c) seek a .arpa insecure special use delegation d) go for "B" and if that doesn't work shift to "C" Each of these have different positive and negatives in a raw technical sense, UI design desires, and policy and political frames. Again, this situation is fluid and as discussions evolve I will provide more information when it is appropriate. In the mean-time I would very much like everyone to take a calming breath and understand that I am taking a very pragmatic view of this concern. Cheers, Terry INT AD --B_3573787598_212650162 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFEbv WCjYV1veM9UGcgKNL3IFjg72MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE3MDMzMDIwNDYzOFowDQYJKoZIhvcNAQEBBQAEggEAIQvzp+INWAei1NvUn8uL uEYk7aWf3hNQFEsgNICDXSYA8o1GRzYC6A//fX57Wu2BefgLyagCYJrGfIYLiuGueeUMuvAs 68ftHjqGhwO+So/JiTccsh+7PtPAMJfhqtQnvVJXs1lQy2dF2ODpprtx9IjRFQV1Ud2XH//w b0EWFNPqX8uZYgQjQjBMgjX9wEP2+O5iaXS7tzOJHpZ0zgpocxlfuE8QqIVQQ80B4h5z1bV/ YivZt20XfGn5dFe8iUt0LMSNiK7SQf2iCC/oGq8g66GQrDbCqbhJyxVZJDBLIiDlYfbRwsoz NQqIFWMxgX9MjIjyrq7eoXWZgzdvawyM4A== --B_3573787598_212650162-- From nobody Thu Mar 30 13:54:32 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 3BEAF1294A2 for ; Thu, 30 Mar 2017 13:54: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, 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 RiX157FTV-_l for ; Thu, 30 Mar 2017 13:54:24 -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 9F1FB1294A4 for ; Thu, 30 Mar 2017 13:54:22 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id x125so50068393pgb.0 for ; Thu, 30 Mar 2017 13:54:22 -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=f29ic3tr+v5AQcuuOLqC+uq6CsJK934F8K+pIx45bGM=; b=en4FbKv/+RHlkSuElzoI/dKCjuF3IUKbrfzTMuwqyPRGapyuTf7cPgcuKX9tBi2waH RNaLN+RszbiPztTzvXYij9QzZ2E2B/sS0wX9fSguYuSQ6oxAeFrtxLj8193c1FmIBr6p +jQxa+lHLDgGROsyCGivkMCgeY4/QaUcafL22HIDJTx9rn07PTa8WpBtNuVQxSnIrBaX IujVvDD0xikPFKFX1Ul3qfHs7nJlQTwm49D9V6Rh++fTvkRtYiRMuGQsc7+GE0Yue+ox Qu71nsrbYwNYHI/PTuYKNKr0b5MPYGXKUQOHiQB1j+nGsyq3FpQ4CsQ7xTqJR+cQ6KjF 3+Ww== 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=f29ic3tr+v5AQcuuOLqC+uq6CsJK934F8K+pIx45bGM=; b=rAPK+DXfaMHyzQtVOF6wBlfnCJNRBobKH++a9MNe8FR660/U30v+8iaDCXpVQwQoBu 4Gtjfo2qKaVH0/neNmXe1C5D+HZlsYlu5MsZKOC2mxHd2xoYG/69ZSNTtnshtQS1DWj7 fVKkZAFr97CwKeFB5+tQ1qZY7kNGH/FaGEuUgrGo3j6ClA9ji6F3qpMB3RZ3AbBqa6eg WMeu8wm859L4iQwC5HvMmN5Uc5W/LUfrw8SgXh5IOyVPx/F/ixX80OvIFQWHK13Q+VYt 1wQuw/p06biQKgcPtiHYlB19dKyVLZ27Yek/4KAsBothhKnhllpMPeP6UlIc/9DPfAKb VRJQ== X-Gm-Message-State: AFeK/H2eIdf83UMsXJtnmkCrTv8GgOgHHHiMqhYi0DGVIIqAJTAbZ5i8bLLJksIGiIOUlGmi7H9YWzupA4NdWw== X-Received: by 10.98.210.133 with SMTP id c127mr1115872pfg.83.1490907262131; Thu, 30 Mar 2017 13:54:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.203 with HTTP; Thu, 30 Mar 2017 13:54:21 -0700 (PDT) Received: by 10.100.179.203 with HTTP; Thu, 30 Mar 2017 13:54:21 -0700 (PDT) In-Reply-To: <07190227-DC82-4B1A-93CE-DF66AEB5111D@icann.org> References: <07190227-DC82-4B1A-93CE-DF66AEB5111D@icann.org> From: Ted Lemon Date: Thu, 30 Mar 2017 15:54:21 -0500 Message-ID: To: Terry Manderson Cc: dnsop WG , HOMENET Content-Type: multipart/alternative; boundary=001a11468cd2c0b642054bf8e57d Archived-At: Subject: Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 30 Mar 2017 20:54:27 -0000 --001a11468cd2c0b642054bf8e57d Content-Type: text/plain; charset=UTF-8 Thanks, Terry! I know this wasn't a fun discussion, but it is good to get a clear answer that sets or expectations, so thanks for that! --001a11468cd2c0b642054bf8e57d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Terry!=C2=A0 I know this wasn't a fun di= scussion, but it is good to get a clear answer that sets or expectations, s= o thanks for that!
--001a11468cd2c0b642054bf8e57d-- From nobody Thu Mar 30 13:59: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 5A3C61294F8 for ; Thu, 30 Mar 2017 13:58:59 -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 E4wF6QD0PwOn for ; Thu, 30 Mar 2017 13:58:57 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::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 A68DE12704B for ; Thu, 30 Mar 2017 13:58:57 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id 81so50188980pgh.2 for ; Thu, 30 Mar 2017 13:58:57 -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=S+PzD1GyMdojrMUrmXtjKUxKSndO0xp8yZ8Ka+L4Uik=; b=TnoHSgRSkKF3jhM3TFLDj55xVpOfSHB4YxCRltetHLYaLumQmWYrEg8ouB9HUh5ajn iwDSIG5Vt0O8gb6ZebEjUWLBMqM+1sH4SSRO/gXGBNOvQTY6GYJ/HvT58Lp7NBd9GvOL fh0hQBYLI9LCTYOUFR1tITuQpvCRyc/PkkBoiyY6S2zZHlNW/atqGFvHXnNbeYEcYsnq Xo3k8te/clOEkrkI7lj95mO8e0qRKL8PtoCrPWc/KgLPdMZMwXP93S95GSYk3kqb0Kez P1bfSWM2IEg6hYesY1vk5Z0bpsZz/gPaWgXmMQ/Xeo8CMdBqpR7sKLGBpx+Wpd6D6fpW 0erw== 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=S+PzD1GyMdojrMUrmXtjKUxKSndO0xp8yZ8Ka+L4Uik=; b=bxlEk9IyXUgNUjMEBlKD6sVodyWt7tdjiK0KvW9/RHuglO/jW2Zkz+WzbUFIMa6KBJ FHW94TjO0DFsc9GrsByijESBQjcEjqF2oxcGgU0Aus0xQCMgeFLsw5t/46rtGh1ibQaJ baMFwphJbfdvzs2mvzISIrGO6hnvkYxxsxxgcjkfH66mINCaAV7U3Md6igm12o6+8xWH 76gbEyfu52fQLR60Y/JWouimro9wTU/ZL04j3deZTyKxdSp+Yde1yx7pLIEf7XHSrrNG U3v/CqHqpmW2sRw6TZ93E6peXmdcl1vjr8EADvK4hcYx80Zm+Loj0ntGMdZ9Eg2yRCWi Ie3A== X-Gm-Message-State: AFeK/H2Vxh2v6LHKORnaJwznx5amrtd7WGeb2CtQrLUPg+hddOjmL7Jgn7QHFgXi/Fcj8TLT2kGb2JOaSMNBtg== X-Received: by 10.99.110.6 with SMTP id j6mr1170169pgc.64.1490907537305; Thu, 30 Mar 2017 13:58:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.203 with HTTP; Thu, 30 Mar 2017 13:58:56 -0700 (PDT) Received: by 10.100.179.203 with HTTP; Thu, 30 Mar 2017 13:58:56 -0700 (PDT) In-Reply-To: References: <07190227-DC82-4B1A-93CE-DF66AEB5111D@icann.org> From: Ted Lemon Date: Thu, 30 Mar 2017 15:58:56 -0500 Message-ID: To: Terry Manderson Cc: HOMENET Content-Type: multipart/alternative; boundary=94eb2c19e278279784054bf8f6a7 Archived-At: Subject: Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 30 Mar 2017 20:58:59 -0000 --94eb2c19e278279784054bf8f6a7 Content-Type: text/plain; charset=UTF-8 Leaving dnsop of the cc list, I would like to propose that we cut to the chase and choose hm.arpa. If some vendor with deep pockets wants to find a good application, we could talk about that, but I don't expect that, and even if it were to happen, it wouldn't happen soon since there is no schedule for the next gtld fiasco. I think demanding that validating resolvers be specially modified doesn't scale, so my personal preference is to not go down that road. But I think that is the only option of we want to keep .homenet. On Mar 30, 2017 3:54 PM, "Ted Lemon" wrote: > Thanks, Terry! I know this wasn't a fun discussion, but it is good to get > a clear answer that sets or expectations, so thanks for that! > --94eb2c19e278279784054bf8f6a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Leaving dnsop of the cc list, I would like to propose tha= t we cut to the chase and choose hm.arpa. If some vendor with deep pockets = wants to find a good application, we could talk about that, but I don't= expect that, and even if it were to happen, it wouldn't happen soon si= nce there is no schedule for the next gtld fiasco.=C2=A0
<= br>
I think demanding that validating resolvers be s= pecially modified doesn't scale, so my personal preference is to not go= down that road. But I think that is the only option of we want to keep .ho= menet.=C2=A0

On Mar 30, 2017 3:54 PM, "Ted Lemon" <mellon@fugue.com> wrote:
=
Thanks, Terry!=C2=A0 = I know this wasn't a fun discussion, but it is good to get a clear answ= er that sets or expectations, so thanks for that!
--94eb2c19e278279784054bf8f6a7-- From nobody Thu Mar 30 15:39:47 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 A2D1112948E for ; Thu, 30 Mar 2017 15:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, 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=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 F2G4jCt75iLh for ; Thu, 30 Mar 2017 15:39:43 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 BFB571294D0 for ; Thu, 30 Mar 2017 15:39:42 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id y18so2871535itc.1 for ; Thu, 30 Mar 2017 15:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=NOUsU/6LiwIV/7IrsMTN996hV0y1wQ096MuenFOZ4AA=; b=nxpyWn3/faGem5i5P2xlDU+JbAHk306VME5arRr/WqoGhb4cpl+C0E0j3PKCbLmMoj V8J/ZRr42Nl5DOmoXkKbiXJQt/BzHMJv2Hf64nb5gBiBDITBh1pgr+rD4veLx2rwRHiW +TOAZzZtD9gQqbiDgcofeuSkB1i+GJttpsOqSNUDlIcTub8W6cYagm9rgD//G07efOIx VFzPm/CJa93dlDU2/0DBjrp8C1Ulns/CMYoyLRa/8AWke9ENwifhCH7ti60qsMKMBEdG oX+pfNUXS9Tl5U7ESPFAPtyjXQbUjJm/0xSeKMUkLx4u+wUpCCgxI4N638aWhkskf0OH pIGA== 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=NOUsU/6LiwIV/7IrsMTN996hV0y1wQ096MuenFOZ4AA=; b=F4fKObjV3o0+s7fg/0Ad0sSLV5axfClc/GQ4oc9O9TgS2VcDtk7xQP0ZYVR/a67UP6 Wg2Us8dNiffLSuO9oOdot/ayRPIQM+ufCLr83zRv9zUb/JdP1kpbD7hqQ0glouSJ6Z6Q AKeAsEWq+kMS+yG/2UGSNEaVNuefXzhZiUrCl+MQ8H+kcJoK1xIvgLrrY4lFdoXdMrEg eaWXDR8NvJ90UrxF1EQUkl7Py/58llNVY999lCZboFymAYNVZHHoGtP+SlgwcSVviRJp N5CkdZ6NF7C3+aq3LbnINFCmrwy08Qsx6le0IhbM8kBwGOyFloeOZ3TvoCjvf9ldCjqb PpHg== X-Gm-Message-State: AFeK/H2u55/0CJ02tYI4WnUmxOGUKbeZkYLd7NOiK5kBNVch3m0pYWW7zEEjHrKUsW0svU7t X-Received: by 10.36.103.215 with SMTP id u206mr754008itc.6.1490913581711; Thu, 30 Mar 2017 15:39:41 -0700 (PDT) Received: from t2001067c037019981908a58861a506dc.v6.meeting.ietf.org (t2001067c037019981908a58861a506dc.v6.meeting.ietf.org. [2001:67c:370:1998:1908:a588:61a5:6dc]) by smtp.gmail.com with ESMTPSA id k66sm290008itg.8.2017.03.30.15.39.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 15:39:41 -0700 (PDT) From: james woodyatt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 30 Mar 2017 17:39:40 -0500 References: <07190227-DC82-4B1A-93CE-DF66AEB5111D@icann.org> To: HOMENET In-Reply-To: Message-Id: <08629A7A-B302-48B9-BA51-F4B445B36FF0@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [homenet] I-D.ietf-homenet-dot 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, 30 Mar 2017 22:39:45 -0000 On Mar 30, 2017, at 15:58, Ted Lemon wrote: >=20 > Leaving dnsop of the cc list, I would like to propose that we cut to = the chase and choose hm.arpa. [=E2=80=A6] If we=E2=80=99re going to reopen the naming discussion, then I have an = opinion. I prefer hab.arpa. My reasoning follows. p1. The word =E2=80=9Chab=E2=80=9D has a reasonably obvious = pronunciation, even for people who speak languages more closely related = to Latin, where a solitary =E2=80=98h=E2=80=99 doesn=E2=80=99t have a = sound, and even when they drop the =E2=80=98h=E2=80=99 English speakers = are still going to hear it. p2. While it=E2=80=99s not as short as =E2=80=9Chm.arpa=E2=80=9D but = it=E2=80=99s only one letter longer, and =E2=80=9Chab.arpa" has the = additional feature of using a word that has a reasonable connection to = the concept for which we are using it. See further reasoning below. p3. Yes, the word =E2=80=9Chab=E2=80=9D is jargon. It's an abbreviation = of =E2=80=9Chabitat,=E2=80=9D which in its most general sense means = =E2=80=9Cthe environment where someone or something lives,=E2=80=9D but = the abbreviated word =E2=80=9Chab" is more commonly used to signify the = more specialized concept of =E2=80=9Ca controlled physical environment = suitable for human habitation.=E2=80=9D (Here is a good example of that = usage, from NASA: ) p4. My contention is that this is a more precise term than =E2=80=9Chome=E2= =80=9D for the context in which we are working. The Oxford English = Dictionary has three different senses in which the word =E2=80=9Chome=E2=80= =9D can be used as a noun, and it=E2=80=99s also an adjective, a verb = *and* an adverb. In the noun case, Oxford has the word =E2=80=9Chome=E2=80= =9D loaded with a lot unnecessary signifiers: =E2=80=9C1. the place = where one lives permanently, especially as a member of a family or = household,=E2=80=9D whereas, Oxford=E2=80=99s informal definition of = =E2=80=9Chabitat,=E2=80=9D in the one sense where it has any definition = at all, is short and to the point: "a person=E2=80=99s usual or = preferred surroundings.=E2=80=9D Much closer to the mark. I think this is in keeping with the observation that the protocols we = are developing here are more about the environment in which we expect = people to be using them and what those people are doing there, and less = about a) who is living there, b) how they are related to one another, = and c) how often they come and go. The environment in question is the = human habitat, i.e =E2=80=9Cplaces where people live,=E2=80=9D in = contrast to places like offices and schools (where people work and = study) and industrial environments like data centers (where people are = basically an alien hostile threat). p5. Yes, I admit it: I read science fiction, lots of authors in that = genre use the =E2=80=9Chab=E2=80=9D abbreviation in the sense that NASA = is using in the link I mentioned above, and I think it sounds cool. = Guilty as charged. Not ashamed. --james woodyatt From nobody Thu Mar 30 15:54: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 C3055128D40 for ; Thu, 30 Mar 2017 15:54:52 -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 REwANykXSVXj for ; Thu, 30 Mar 2017 15:54:51 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 4012412949E for ; Thu, 30 Mar 2017 15:54:51 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id y18so3019019itc.1 for ; Thu, 30 Mar 2017 15:54:51 -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=SnDrLG2u94A0vxd3rkPwmsRhV/Gej8zhslK0Pu6SdQQ=; b=Y93xhZtEpPnbV07KfysizID7C6mWekkkICQ1ZIjldRf6c9UZGWrlP1/VGo2gYpb84d TS/UEzy29moMC3iet5HR/Ghz+NsnIia6LEY4z7AgSjlSvBDe8jLXrzUnqjDKFjUUx1AE ksL6Ws7fDAXMRxvf6t1NIXCDr5chIQgO00tqhOT8LPyEWH4D2pFUzpaJXeU5vO5TJuAC gUpgky9qJyjAVrtdW33aIeOxE1lddab8exIsAL2JIHWER6Dm+A3xIsPF3Z88IN5UdexL 3Ma6s0JrmNB58cAlWFEOl2bbEhpyM52R9DLny8Dpb2HOeOWuWMUim7SCJ7HTHfl5d83M A4Og== 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=SnDrLG2u94A0vxd3rkPwmsRhV/Gej8zhslK0Pu6SdQQ=; b=oZSQDXEV/sWqowVr5paR6AyJudHbNQWGIumPO6m6eoPXQKQJB69lSJTGAwehyGnNYJ ibCu5KJn9+rbW/TrP3dcow1QlMtzYgMVi4Cv6zAUPjh9uiSdPAMVR7ujNuN25+TU3gNp 5turzgSmZtksV1KOZgZSdFjLhg8jO0nME78guUDlp2op3lhgGJj85sfRekrhG5heH+fi 9j7A7y1aRt708n8daYt1QQKc+xWJA86dRnJzSdxHW+Y8Ja/IGQ0d6K0V3NG5IRMMIBQH UcqM4oC4KHa07GzyYSJcUav9o34jMeMXYHlBPvJcCL7sQzdykWt5jXZtl/oGXtwfnwN0 DlGA== X-Gm-Message-State: AFeK/H3uNiwXaYlUR21AanNltohGRGqE6m01rCkRgZ2VvhZpOcVlZZBn66u77LkMIRimeA== X-Received: by 10.36.82.204 with SMTP id d195mr705393itb.29.1490914490639; Thu, 30 Mar 2017 15:54:50 -0700 (PDT) Received: from t2001067c0370012884779be50fc0bb3a.v6.meeting.ietf.org (t2001067c0370012884779be50fc0bb3a.v6.meeting.ietf.org. [2001:67c:370:128:8477:9be5:fc0:bb3a]) by smtp.gmail.com with ESMTPSA id a22sm285125itb.29.2017.03.30.15.54.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 15:54:50 -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: <08629A7A-B302-48B9-BA51-F4B445B36FF0@google.com> Date: Thu, 30 Mar 2017 17:54:48 -0500 Cc: HOMENET Content-Transfer-Encoding: quoted-printable Message-Id: <6701D998-60C8-4EAC-BE4F-1F21BDA3E20B@fugue.com> References: <07190227-DC82-4B1A-93CE-DF66AEB5111D@icann.org> <08629A7A-B302-48B9-BA51-F4B445B36FF0@google.com> To: james woodyatt X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] I-D.ietf-homenet-dot 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, 30 Mar 2017 22:54:53 -0000 I'm okay with either hm or hab. I would very much like for us not to = tube on a beauty contest discussion, though. It would be nice to turn = this draft around quickly. From nobody Thu Mar 30 16:01: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 3F9DD12948C for ; Thu, 30 Mar 2017 16:01:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 YaQ8n0Jddd_F for ; Thu, 30 Mar 2017 16:01:08 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 B74E21279E5 for ; Thu, 30 Mar 2017 16:01:08 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id e75so3304166itd.1 for ; Thu, 30 Mar 2017 16:01:08 -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=a1JYbLP11bwoQBNm9oEWBoiufZbUz/3ns5DsWcCWEXo=; b=j1p2jgqr0QmVdxs4om6yGYpGCH7hFRqzKxokeVkbrgfohcoR8Xt3Q3G79cMJ/1+sYz jW123hpbaHXX/Tr2I3YRFh6C9AWmkOS3jhPl+xygzu79scthlPtpZdPCJ8aiyFFljmpj Hn43W6rWAma/wazjvWSTVKk5L1IBa3irGBxsjny878D/9TLwMa0qdlebyJhZ5mqZeQuo 8agdyKkTayRRW0s+Xo3gxwaaspnb6bvTHZq0x9OhIdG4LxD5yHP56V68Re6pihVSW7Nr OR8STc0pon1uIrmh0WDpUZ36Y5Rtp8GlN3lSZmNI9NcbhSwxX1jjnPpF69SmhC+oLAs0 9u0g== 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=a1JYbLP11bwoQBNm9oEWBoiufZbUz/3ns5DsWcCWEXo=; b=txSv0O7e1ca767eeH0Wz79Q60+uE6FqIC8a0Kh6vIl5LYruSNWTFm+861Qc6fGvm8A EwHLPfCpQutoEtINDZCzWB4wdtyw8sxgExIGQPQGBSE2LMcHj33rc5i8xBt3gDtlW7/S xMqESRjryCec1pJkzNGPQvmG2lu7u2v1TDVf/Ld3RRgmcnPrJ/6Y/p2xAQfd7M5GNK2i kT+jRuDY44g3PDeZO4rMS9AvqYEX555yCfXFhrOYBvySniNhDB5QCQb9GWdVfEyW4r1Z l1P734VnLBpqIultQsovK/F+TC9Woojm33BJ53kvpVK4vzocxr/m5H94EzNIOvHb41h+ HX/g== X-Gm-Message-State: AFeK/H0ol8ZsEPn4PbHdeNj6KnFoEChf2MBgxwzklyNL4RrBA0wZvSrQSYlrt7kW500TsAXX X-Received: by 10.36.115.145 with SMTP id y139mr708200itb.123.1490914867436; Thu, 30 Mar 2017 16:01:07 -0700 (PDT) Received: from t2001067c037019981908a58861a506dc.v6.meeting.ietf.org (t2001067c037019981908a58861a506dc.v6.meeting.ietf.org. [2001:67c:370:1998:1908:a588:61a5:6dc]) by smtp.gmail.com with ESMTPSA id y7sm293857itc.27.2017.03.30.16.01.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 16:01:06 -0700 (PDT) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C8FB4BFA-9FB3-45E5-9AE9-0A70FD607219" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 30 Mar 2017 18:01:06 -0500 In-Reply-To: <6701D998-60C8-4EAC-BE4F-1F21BDA3E20B@fugue.com> Cc: HOMENET To: Ted Lemon References: <07190227-DC82-4B1A-93CE-DF66AEB5111D@icann.org> <08629A7A-B302-48B9-BA51-F4B445B36FF0@google.com> <6701D998-60C8-4EAC-BE4F-1F21BDA3E20B@fugue.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [homenet] I-D.ietf-homenet-dot 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, 30 Mar 2017 23:01:10 -0000 --Apple-Mail=_C8FB4BFA-9FB3-45E5-9AE9-0A70FD607219 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 30, 2017, at 17:54, Ted Lemon wrote: >=20 > I'm okay with either hm or hab. I would very much like for us not to = tube on a beauty contest discussion, though. It would be nice to turn = this draft around quickly. So, it=E2=80=99s settled then. :) --james woodyatt > --Apple-Mail=_C8FB4BFA-9FB3-45E5-9AE9-0A70FD607219 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 30, 2017, at = 17:54, Ted Lemon <mellon@fugue.com> wrote:

I'm okay with either hm or hab.   I would very much = like for us not to tube on a beauty contest discussion, though. =   It would be nice to turn this draft around quickly.

So, it=E2=80= =99s settled then. :)

--james woodyatt <jhw@google.com>



= --Apple-Mail=_C8FB4BFA-9FB3-45E5-9AE9-0A70FD607219-- From nobody Thu Mar 30 16:05: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 B1A671279E5 for ; Thu, 30 Mar 2017 16:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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=apple.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 g0axE_tYz8Vq for ; Thu, 30 Mar 2017 16:05:52 -0700 (PDT) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (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 3618112783A for ; Thu, 30 Mar 2017 16:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1490915151; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Suu3K8plcxj2tQSBYo6zG2TQmgl1yLW1HDfzd0A3NbI=; b=rwHUH7o2VXBfEouOfHOSrAhwyZYzEtbSKjB5ZeHlxfLT07xZ9msLeYTIViylRig3 8vYzTRJPlZme0zF9IQfuzDchsFbca+1TIrg4b4iilx5ys1TymUBS5tJjlBRXeI52 qGcTha5YuVv25KVMMCoexu4L/E2s+ozerdsxzWvPq1joVAiC0xPgDFu2X7Mvcizq KvWFCu/8uIWC8jHuDo0WBpPCWRJlEp57DrlFGdhDE8NuQCTtUyB/IpanHyQxD/vN sckOpbAH1GRfWBRXwqtHKqbt9R9vwKu/Bx8ceVBhwimIsnxwa3TFZXZzV7FAaei/ iq8Du1YY6hHoAeTZ1JgalQ==; Received: from relay27.apple.com (relay27.apple.com [17.171.128.108]) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id 2F.64.24065.F4F8DD85; Thu, 30 Mar 2017 16:05:51 -0700 (PDT) X-AuditID: 11ab0215-9b3ff70000005e01-bc-58dd8f4f28c2 Received: from russet.apple.com (st1-02-mail-lb2-v365-snip.apple.com [17.171.128.5]) by relay27.apple.com (Apple SCV relay) with SMTP id 87.E4.01638.E4F8DD85; Thu, 30 Mar 2017 19:05:51 -0400 (EDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_BOXMb2AF+4ZhqPOyn8anOQ)" Received: from [17.104.114.68] (unknown [17.104.114.68]) by russet.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONN00C91HHOJ620@russet.apple.com>; Thu, 30 Mar 2017 16:05:50 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Thu, 30 Mar 2017 18:05:47 -0500 In-reply-to: Cc: Ted Lemon , james woodyatt To: HOMENET References: <07190227-DC82-4B1A-93CE-DF66AEB5111D@icann.org> <08629A7A-B302-48B9-BA51-F4B445B36FF0@google.com> <6701D998-60C8-4EAC-BE4F-1F21BDA3E20B@fugue.com> X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUiuLohR9e//26EQeNaUYv3iw6xWPxsO8Rs 8WbNESYHZo+mC8vYPRZsKvVYsuQnUwBzFJdNSmpOZllqkb5dAlfG9KMTWQpeSlZ0bzrC2MB4 U6yLkZNDQsBEYmHDGrYuRi4OIYGDjBIzbs1lhkns3jWNESJxjFHi6wSQKk4OXgFBiR+T77GA 2MwCYRI9s1pZIYqamST2fzzOBJIQFpCW6LpwFyjBwcEmoCVxYI0RRK+NRNftw8wQJdoSf3/O ZgSxWQRUJV4//MEIUs4pYCfxYLkKiMks4Cgx/4w0SIWIgJzExg+7waqFBJ4ySXxvN4A4U1bi 0/Of7CAXSAh8ZpN43POGZQKj0Cwkl85CcukssLHqElOm5EKEtSWevLvACmGrSSz8vYgJWXwB I9sqRuHcxMwc3cw8I0O9xIKCnFS95PzcTYzg2GAS3cE4/5XhIUYBDkYlHl4BkbsRQqyJZcWV uYcYpTlYlMR5lbuAQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjVJnPMuSWitepM+/2v+lIb pb8X8U/VOlWSsuet+94qjT8BOodmVIisFeQLZQgQtbic/GbxqmjZL/2xPA9O/Hb6+4PT4/BR jkk3ty5UOhDC3bWnL3uNjv8fK7XZy9wf/p+ryPWw9cp+I7d1CtJym98yBp4//+OGQhjv7udc ZxiLZ1ipmssHTBVUYinOSDTUYi4qTgQAE6odGW4CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUiuLqBVde//26EwYabLBbvFx1isfjZdojZ 4s2aI0wOzB5NF5axeyzYVOqxZMlPpgDmKEObtPyi8sSiFIWi5IISW6XijMSU/PJ4S2MjU4fE goKcVL3k/FwlfTublNSczLLUIn27BMOM6UcnshS8lKzo3nSEsYHxplgXIyeHhICJxO5d0xi7 GLk4hASOMUp8nbCGDSTBKyAo8WPyPRYQm1kgTKJnVisrRFEzk8T+j8eZQBLCAtISXRfuAiU4 ONgEtCQOrDGC6LWR6Lp9mBmiRFvi78/ZjCA2i4CqxOuHPxhByjkF7CQeLFcBMZkFHCXmn5EG qRARkJPY+GE3WLWQwFMmie/tBhBnykp8ev6TfQIj/ywkx81CctwssEnqElOm5EKEtSWevLvA CmGrSSz8vYgJWXwBI9sqRsGi1JzESiNzPXiYbWKEREbODsY7N80OMQpwMCrx8O4QvBshxJpY VlyZe4hRgoNZSYTXqhwoxJuSWFmVWpQfX1Sak1p8iNEH6MWJzFKiyfnAqM0riTc0tjC2NLEw MLCwMDLFIawkzut6+k6EkEB6YklqdmpqQWoRzDgmDk6pBsYAjycMM5Jubbf02mzJXhPyd4mC 4feFVilesZq8nqslr//YmWBtnTR7lTdff//xE+KaAjGr31Z3M1Ud/Of/v7/YTW2y+KO41cGz xaZlJH063Ml8u/7sBQe1/h9zN0r3OYrumRjCe3/ybodJZk4eaqYWcy4FR0y3ZXaQ+u8W4v5n 8brIshkf+JVYgKnLUIu5qDgRAKXhRSO5AgAA Archived-At: Subject: Re: [homenet] I-D.ietf-homenet-dot 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, 30 Mar 2017 23:05:53 -0000 --Boundary_(ID_BOXMb2AF+4ZhqPOyn8anOQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable I support science fiction. However, since this string shouldn't be visible to users, this sounds = like the color of the roof of the bike shed. David > On Mar 30, 2017, at 18:01, james woodyatt wrote: >=20 >=20 > On Mar 30, 2017, at 17:54, Ted Lemon > wrote: >>=20 >> I'm okay with either hm or hab. I would very much like for us not = to tube on a beauty contest discussion, though. It would be nice to = turn this draft around quickly. >=20 > So, it=E2=80=99s settled then. :) >=20 > --james woodyatt > >=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Boundary_(ID_BOXMb2AF+4ZhqPOyn8anOQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable I support science fiction.

However, since this string shouldn't be = visible to users, this sounds like the color of the roof of the bike = shed.

David


On Mar 30, 2017, at 18:01, james woodyatt <jhw@google.com> = wrote:


On Mar 30, 2017, at 17:54, = Ted Lemon <mellon@fugue.com> wrote:

I'm okay with either hm or hab.   I would very much = like for us not to tube on a beauty contest discussion, though. =   It would be nice to turn this draft around quickly.

So, it=E2=80=99s settled then. :)

--james woodyatt <jhw@google.com>



_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

= --Boundary_(ID_BOXMb2AF+4ZhqPOyn8anOQ)-- From nobody Thu Mar 30 16:11:32 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 99C1E128B38 for ; Thu, 30 Mar 2017 16:11:30 -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 f0XSPmoZP0GR for ; Thu, 30 Mar 2017 16:11:29 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 E88D212949E for ; Thu, 30 Mar 2017 16:11:28 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id y18so3455345itc.0 for ; Thu, 30 Mar 2017 16:11:28 -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=WBR22aMoAW3X3SCwGK41PayzXgFumuVxaxJdZw6w2DY=; b=LvHkTi8RFMv7xjJpLsx6MLW8sAXZFtQUtCNCVo/MxKzqPejJLShAAp+mB1222IJXG/ JtU2rjrGqMavwXf3xyOgO6jYaE4JWQMNrIxlcYBOvBvZOnIDVCLyElmal7cxaoiw4KY2 EkZhbb9vR0Tj6X95UyMvoQ/fDHomR9ui4x6f7PTCiFU3hwLraFZ3gwgQiCb64qdmwsXK X9L1FLbyzNCYo7LaUf+XzAPceDJp7QiMU2ujn+VVdsAfkGTXE1zqE7bkBRhKm50CA2OR PoVCkVM9gZYo1V3pYcAOBDw+nX5o/8KlaWJCwwIf//KqHGYovfww7D6aEJWJ4+r5AXbp ajjw== 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=WBR22aMoAW3X3SCwGK41PayzXgFumuVxaxJdZw6w2DY=; b=lT/4+F86ZTob8jbGsb2Qb7V6mveZeucJFwPQQ6km/ZYvVpUw044TiXePCoZKabCR4j KhzMXjkO8Io3gx98CMWrTJeGhYAXamdBtYjwwGPdZFMsShCkz7S0jiXbiJaKgEHwy4fe SE+MyMZlpjc9puVDM+gjKRxP+SlQdIp6A5R+vpen5Xn6PVQ3UX/RiHZrguxjX6ScyILq 1yrE3fextEWZn+CGqQNH0NwNk3w98zQI+QpLrb/w1K4BS8anjPVgOIb9ENUsVZ6suVCa MfpYMmtPactRe2XNd1UNRVsMOU1jxvEovW6kn5GZdYWT6PkubAU5+KFFfpTgNOzudJe9 jAHQ== X-Gm-Message-State: AFeK/H1zSq0T3bKjeyRwKm63Vg6evZbAxX0REAg7kAvdPYsAsolS8D8CExqhJrzBTqklCg== X-Received: by 10.36.34.79 with SMTP id o76mr63333ito.116.1490915488303; Thu, 30 Mar 2017 16:11:28 -0700 (PDT) Received: from t2001067c0370012884779be50fc0bb3a.v6.meeting.ietf.org (t2001067c0370012884779be50fc0bb3a.v6.meeting.ietf.org. [2001:67c:370:128:8477:9be5:fc0:bb3a]) by smtp.gmail.com with ESMTPSA id b132sm2207196iob.6.2017.03.30.16.11.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 16:11:27 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F2236ACF-CC9C-49EE-A297-A45CC3CD72D5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 30 Mar 2017 18:11:26 -0500 In-Reply-To: Cc: HOMENET , james woodyatt To: David Schinazi References: <07190227-DC82-4B1A-93CE-DF66AEB5111D@icann.org> <08629A7A-B302-48B9-BA51-F4B445B36FF0@google.com> <6701D998-60C8-4EAC-BE4F-1F21BDA3E20B@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] I-D.ietf-homenet-dot 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, 30 Mar 2017 23:11:31 -0000 --Apple-Mail=_F2236ACF-CC9C-49EE-A297-A45CC3CD72D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 30, 2017, at 6:05 PM, David Schinazi wrote: > However, since this string shouldn't be visible to users, this sounds = like the color of the roof of the bike shed. David, unless something has changed since the last time we had this = argument, let's set it aside. Certainly there are people participating = in this discussion who believe that users will see names, even if you = don't believe that. I don't see how we could gain consensus on your = position, nor do I see any advantage to trying, since you lose nothing = if the name is human-readable. --Apple-Mail=_F2236ACF-CC9C-49EE-A297-A45CC3CD72D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Mar 30, 2017, at 6:05 PM, David Schinazi <dschinazi@apple.com>= wrote:
However, since this string shouldn't be visible to users, this = sounds like the color of the roof of the bike = shed.

David, unless = something has changed since the last time we had this argument, let's = set it aside.   Certainly there are people participating in this = discussion who believe that users will see names, even if you don't = believe that.   I don't see how we could gain consensus on your = position, nor do I see any advantage to trying, since you lose nothing = if the name is human-readable.

= --Apple-Mail=_F2236ACF-CC9C-49EE-A297-A45CC3CD72D5-- From nobody Thu Mar 30 16:13: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 CC2B51295A0 for ; Thu, 30 Mar 2017 16:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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=apple.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 k4ODsIqbl5Hz for ; Thu, 30 Mar 2017 16:13:13 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 1A4BD12949E for ; Thu, 30 Mar 2017 16:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1490915592; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VC+ur8zes7ifoPuvtv2kVv0Eb0xjhan+q8e3gbqF5ns=; b=znz2Q/Qzo/2ZIaU6r1XVO2pOkeq6bi27qKZM7ipTHMg2XqFWRyFfPBAcMzn8+3+K WWE8X6x5fOxtCmAZIdt96tFo2NwPbKgTXxcCGzIf705P4oB4WG7jL69ogG4Cpdyk s+pJKt+M+Oe5RaVrE3pgm0VIF62SYricvBtYLlBLLy2JkHYHSGZ9Rv7IoiczbS6m teF2o0GN9Ud4P+ojEIHNbdOnfaRK1B0JtsKgv+oTFkQt7RNJNE5LjqFoVXn54TXV YYVB0Oc8wXYAnyCsJVR9fWSbtyE/5j2hznBq8Sz9KIYu1KLgHCVQmIkrgyia6PYt CwqfIE12e/PN+AXQJaKvOg==; Received: from relay21.apple.com (relay21.apple.com [17.171.128.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 62.8A.31709.7019DD85; Thu, 30 Mar 2017 16:13:12 -0700 (PDT) X-AuditID: 11973e13-b49fb70000007bdd-05-58dd9106e87a Received: from russet.apple.com (st1-02-mail-lb2-v365-snip.apple.com [17.171.128.5]) by relay21.apple.com (Apple SCV relay) with SMTP id 36.77.19192.5019DD85; Thu, 30 Mar 2017 19:13:10 -0400 (EDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_LXF7/SzW/EA16CYUHOjQQg)" Received: from t2001067c03701998c45b53a26df2585f.v6.meeting.ietf.org (nat64-5c.meeting.ietf.org [31.130.238.92]) by russet.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONN00CGKHTWJ620@russet.apple.com>; Thu, 30 Mar 2017 16:13:09 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <2B747777-4EB2-40F9-AF9D-0ADBF05D7126@apple.com> Date: Thu, 30 Mar 2017 18:13:08 -0500 In-reply-to: Cc: HOMENET , james woodyatt To: Ted Lemon References: <07190227-DC82-4B1A-93CE-DF66AEB5111D@icann.org> <08629A7A-B302-48B9-BA51-F4B445B36FF0@google.com> <6701D998-60C8-4EAC-BE4F-1F21BDA3E20B@fugue.com> X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUiuLohTZdj4t0Ig/aFlhbvFx1isfjZdojZ 4s2aI0wOzB5NF5axeyzYVOqxZMlPpgDmKC6blNSczLLUIn27BK6MKRuVCi5IVWz+18rcwPhT rIuRg0NCwETi4S+LLkYuDiGBdUwSc+Y9Z+pi5ASLH799jwkicYxRYsW9G+wgCV4BQYkfk++x gDQzC4RJbLwuA1Gzl0niXe8tRpAaYQFpia4Ld1lBatgEtCQOrDGCaLWRWH+rkwmiRFvi78/Z YOUsAqoSq9f8ZQOxOQVsJeYefcwKYjML2Es8n/QUbK2IgILE3DNroO45zSyx6PB2RohDZSU+ Pf/JDpKQEPjNJrFv6mOmCYxCs5DcOgvh1llgc7Ukvj9qhQrLSxw8LwsR1pR4du8TO4StLfHk 3QXWBYxsqxiFchMzc3Qz80z1EgsKclL1kvNzNzGC4mK6nfAOxtOrrA4xCnAwKvHw7hC8GyHE mlhWXJl7iFGag0VJnJe5CygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUXc555THMa1X9Z02 sIY8cw6ckaJ4KFPjp+JRoxl77Rmu3lAtMLf78Jj/rf7CLz9XPpNe8PSo+XfVQFZezjmv3O7e Ltj755mg/FttcU2p6ZbqBzefzf1Zc+n6/l8ngj9ZC3v1FAn84LgVadBuNjNF85mGvVSZZ3HQ tsNfT0mJOLdMivs6g7XmtBJLcUaioRZzUXEiAFT5WuFsAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUiuLqBVZdt4t0Ig2NLNCzeLzrEYvGz7RCz xZs1R5gcmD2aLixj91iwqdRjyZKfTAHMUYY2aflF5YlFKQpFyQUltkrFGYkp+eXxlsZGpg6J BQU5qXrJ+blK+nY2Kak5mWWpRfp2CYYZUzYqFVyQqtj8r5W5gfGnWBcjJ4eEgInE8dv3mLoY uTiEBI4xSqy4d4MdJMErICjxY/I9li5GDg5mgTCJjddlIGr2Mkm8673FCFIjLCAt0XXhLitI DZuAlsSBNUYQrTYS6291MkGUaEv8/TkbrJxFQFVi9Zq/bCA2p4CtxNyjj1lBbGYBe4nnk56C rRURUJCYe2YN1D2nmSUWHd7OCHGorMSn5z/ZJzDyz0Jy3iyE82aBjdKS+P6oFSosL3HwvCxE WFPi2b1P7BC2tsSTdxdYFzCyrWIULErNSaw0MtSDh9kmRkhkpO1g/H/O8BCjAAejEg/vDsG7 EUKsiWXFlbmHGCU4mJVEeK3KgUK8KYmVValF+fFFpTmpxYcYfYCenMgsJZqcD4zavJJ4Q2ML Y0sTCwMDCwsjUxzCSuK8rqfvRAgJpCeWpGanphakFsGMY+LglGpg1JwSk/b95Yw1jWtu1H6Z rG8qxhn+UkfRpUJf/UHIm4z5ejty4tU2GrgF+hTY1QlKqi5dcGqZIN/vyMdaQbrsljEz/5z5 HFesuuTByRChAOebn5ZN8H7utuF+KeMZ4buGQi9MF83++Unjd/aWj9Nfyx73qD90wWbd+kW2 /wX+mfxb2WRdyLk+QIkFmLoMtZiLihMBmzAVn7kCAAA= Archived-At: Subject: Re: [homenet] I-D.ietf-homenet-dot 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, 30 Mar 2017 23:13:16 -0000 --Boundary_(ID_LXF7/SzW/EA16CYUHOjQQg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Ted, Apologies, I did not mean to reopen that debate, I just wanted to say that I was in favor of moving quickly, whatever the chosen name. David > On Mar 30, 2017, at 18:11, Ted Lemon wrote: > > On Mar 30, 2017, at 6:05 PM, David Schinazi > wrote: >> However, since this string shouldn't be visible to users, this sounds like the color of the roof of the bike shed. > > David, unless something has changed since the last time we had this argument, let's set it aside. Certainly there are people participating in this discussion who believe that users will see names, even if you don't believe that. I don't see how we could gain consensus on your position, nor do I see any advantage to trying, since you lose nothing if the name is human-readable. > --Boundary_(ID_LXF7/SzW/EA16CYUHOjQQg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
Ted,

Apologies, I did not mean to reopen that debate,
I just wanted to say that I was in favor of moving quickly, = whatever the chosen name.

David


On = Mar 30, 2017, at 18:11, Ted Lemon <mellon@fugue.com> wrote:

On Mar 30, = 2017, at 6:05 PM, David Schinazi <dschinazi@apple.com>= wrote:
However, since this string shouldn't be = visible to users, this sounds like the color of the roof of the bike = shed.

David, = unless something has changed since the last time we had this argument, = let's set it aside.   Certainly there are people participating in = this discussion who believe that users will see names, even if you don't = believe that.   I don't see how we could gain consensus on your = position, nor do I see any advantage to trying, since you lose nothing = if the name is human-readable.


= --Boundary_(ID_LXF7/SzW/EA16CYUHOjQQg)-- From nobody Thu Mar 30 16:50: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 1E26512960D for ; Thu, 30 Mar 2017 16:50:47 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.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 B8VIDkq-NdwH for ; Thu, 30 Mar 2017 16:50:45 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c: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 6D8E7129618 for ; Thu, 30 Mar 2017 16:50:43 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id d188so73126733vka.0 for ; Thu, 30 Mar 2017 16:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jGBRU0Pt7cdTzpCcT/Bl0osIWaMeFjPN76SRJQA1ZGo=; b=yuk2QASvT1vH06yRSQL6OcDtzE055WJTdYbXG7mJkaNoeRuOd25EkW1IsZVJ2PLu4D p0RU0ZE7ua6F8In/iHjwDWSdTJ1xz1ufX6A7aTnG4YHcXv+I/KJvrVu+eOdRw5xpS/rH XN8VWsz31q1G5htFYnosetfzcLRKtk8KtJj/y+11UBd7Y307RUko/3oi3zUKmyTFaEo0 QlUd0SAmKUw69tz19coIUu9ssxrDXWP0XZ9EZmHeA4Uki5J7EJMNUzl1edYnWMcuuzzm Dii3Bio8aAlXMQVJ4Q3pvRjyrjZLdEWo3BhCiPTQfHXToQR/9cmUpj4U5tzm3A9scMCT dHww== 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=jGBRU0Pt7cdTzpCcT/Bl0osIWaMeFjPN76SRJQA1ZGo=; b=nxVYnnp3k+epqqhRbdzrpKqeegwAwjbNDUwrmucbDVwo5t9i47ePldceQmt3mKxgFp SfDRYNJou+Q92dxPyn5/VJXa7MVIDfY4VzN4p/wDYun6M04FjVr9Lw1WOPSdytFyelG4 7xp2Gmo4lEhWWk6T4jOpzLKCen2fb39FtGgWRskRTnFzdTlT+zHAvkdvZvYR95Jrlh43 VOsArzAUeFcoJIFn/e2b0/vPf1AN2mfY4vsdx3A2Z8CN1u14h4Hcw4ZHc0UaMbT/HdLm 0v5tjupmLPEBBcMg/EXMGLqxz3Mhe/+2l7A8IVxQJXQ2Szic6hz1tgCRg6NWPYGyoxPI 1lmw== X-Gm-Message-State: AFeK/H1+H+ZudHm6r24HGsQd2kMdv5iGJSrNZKYOIi0In7F6b567lfjRQJphY8p3pUAoIiq8bqddXRiLAz50+A== X-Received: by 10.159.33.34 with SMTP id 31mr44922uab.23.1490917842396; Thu, 30 Mar 2017 16:50:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.20 with HTTP; Thu, 30 Mar 2017 16:50:41 -0700 (PDT) X-Originating-IP: [2001:67c:370:128:edd8:8db5:4cda:164] In-Reply-To: References: <07190227-DC82-4B1A-93CE-DF66AEB5111D@icann.org> From: George Michaelson Date: Thu, 30 Mar 2017 18:50:41 -0500 Message-ID: To: Terry Manderson Cc: dnsop WG , HOMENET Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 30 Mar 2017 23:50:47 -0000 Thank you for a quick, informed and above all open decision Terry. -George On Thu, Mar 30, 2017 at 3:54 PM, Ted Lemon wrote: > Thanks, Terry! I know this wasn't a fun discussion, but it is good to get a > clear answer that sets or expectations, so thanks for that! > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Fri Mar 31 05:36: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 2C9F012984A for ; Fri, 31 Mar 2017 05:36:44 -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 PoFLpOF6BdaB for ; Fri, 31 Mar 2017 05:36:39 -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 651BF1297BF for ; Fri, 31 Mar 2017 05:36:33 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9D405E1A0 for ; Fri, 31 Mar 2017 09:00:33 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 32636636BB for ; Fri, 31 Mar 2017 08:36:32 -0400 (EDT) From: Michael Richardson To: HOMENET In-Reply-To: References: <07190227-DC82-4B1A-93CE-DF66AEB5111D@icann.org> 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] [DNSOP] My assessment of .homenet as described during the WG session yesterday. 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, 31 Mar 2017 12:36:44 -0000 --=-=-= Content-Type: text/plain Ted Lemon wrote: > Leaving dnsop of the cc list, I would like to propose that we cut to > the chase and choose hm.arpa. If some vendor with deep pockets wants I'm quite happy with that proposal. [To me, it pronounces something like: "Her Majesty Arya", but maybe I've been reading Game of Thrones too much of late :-) ] -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljeTU8ACgkQgItw+93Q 3WVLNQf7B/Sij6kaFIcD1zEaattnFdh7chic00ucxmd4v28x1P+TgR1/lFAlA47h c0P0tRO1KHM8Nez7yIFJr2KJVJMp1L/dBMZrJVlUnN63OSTkYT+2zzS1Ab4YARSg cYsMH0f+3mluvzuuX7J89EyFcRiy35ujfBk2n7FrSTRqV4uovBXbrX+9bpbc7An5 NEvpHIf22MNo2I1LXQrcqAl+mMF9771QKwkPN7Cce/xTGykVAKkNtNxpqkjHzKbP ZoP09uDz+20FS0cRw1LmOvFtoVGodyuddRqBMFfncx4iJFd2u4WiFdoKeBSY+ZBz up3/Pef45FYWc7RJ6EK7RQsZIwdKUg== =5Mux -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 31 07:46: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 59DEB12998B for ; Fri, 31 Mar 2017 07:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-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=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 EXDAaSEkjR9G for ; Fri, 31 Mar 2017 07:46:01 -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-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3031298CF for ; Fri, 31 Mar 2017 07:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1490971559; bh=xVbRdp/WbYuUEGdlr5nECtYFqzpGYvo37F1e6EjdE14=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:MIME-Version:Content-Type; b=eUfWO20+tgVVuIpt8GGoMf+rDfq/9TfOmIKnYH+kWYlBObr4WrdJ7jOA6jrmsZ5DWzcaR8fk2i8Mrjr5a3Omq+JjZEXZ7RuY1iGxgCJT4YvTLnWwvD5RXHr8ZahslmtEnsxeeDu3f+xJPCnp8E87XZBp+4XWk5rrK+tipjhFHKE= Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0145.outbound.protection.outlook.com [213.199.180.145]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-62-nVyl5PWJMEirxRYR4Ew-yg-1; Fri, 31 Mar 2017 15:45:54 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Fri, 31 Mar 2017 14:45:52 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.009; Fri, 31 Mar 2017 14:45:51 +0000 From: Tim Chown To: james woodyatt CC: Ted Lemon , HOMENET Thread-Topic: [homenet] I-D.ietf-homenet-dot Thread-Index: AQHSqaaPLL/sEH6nQkStHUDDmz4lOaGt/fYAgAABwgCAAQf2gA== Date: Fri, 31 Mar 2017 14:45:51 +0000 Message-ID: <1997580F-1C46-4553-B68A-098712A46BB9@jisc.ac.uk> References: <07190227-DC82-4B1A-93CE-DF66AEB5111D@icann.org> <08629A7A-B302-48B9-BA51-F4B445B36FF0@google.com> <6701D998-60C8-4EAC-BE4F-1F21BDA3E20B@fugue.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:1999:a88e:5bdf:7b5d:1b2f] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:7yuy8iGyDc9IkAfryKwwjZP99SYaYB6kJmn97tDhT+JqsULv/Xb4fNU8Os7m9S0s8aegdL+USM2J8+PGbqOnKM1XP0wEuluzLCS298Ss6iRq2kHhTikUcpOJzl/sXDNLT0XUzKxmPYT6njFR7QABB5zCmXWPvKIsyyuO965qqHb1ZjPWGOC6BNexQfntf7TDnj4EBEU8ybAdnMWvLDd+vHwgo4fkvOc+hvpY1qGHY5sBALiTs1i25yWSndgLEqYXCWMa4f7roMeW/io4tou/vHt8sNksaOlsv+V7ruBdUnLS1ZIG+h45DLP5fq7Bs0X8ePOlE8gBga45Lj1ZBwyPqA==; 20:BSaxWxCNYrj11ujqLwP4/960ZL09xjmsrb9UkiO+fyKBIoz7Ol6gqFrgWG5jhCNUf9S/QcMzXA1z6k9+ZDLZPdFXDPWrauzSoR7QvmnnoPBkjpMtoJKsoYba7kiP+8YpHVzvEhGEK6asNYlT9TGQeVbkYIXswJLB99lqhoV1vyY= x-ms-office365-filtering-correlation-id: c33f0d7c-d99a-4b2e-e846-08d47844a0f8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(24454002)(54906002)(3660700001)(99286003)(53936002)(38730400002)(6512007)(236005)(110136004)(2900100001)(5250100002)(6246003)(54896002)(33656002)(36756003)(76176999)(50986999)(57306001)(83716003)(6116002)(7736002)(229853002)(102836003)(2950100002)(6916009)(42882006)(5660300001)(189998001)(8936002)(53546009)(25786009)(6506006)(50226002)(6436002)(82746002)(3280700002)(4326008)(86362001)(2906002)(74482002)(230783001)(81166006)(6486002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 14:45:51.9389 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139 X-MC-Unique: nVyl5PWJMEirxRYR4Ew-yg-1 Content-Type: multipart/alternative; boundary="_000_1997580F1C464553B68A098712A46BB9jiscacuk_" Archived-At: Subject: Re: [homenet] I-D.ietf-homenet-dot 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, 31 Mar 2017 14:46:03 -0000 --_000_1997580F1C464553B68A098712A46BB9jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T24gMzEgTWFyIDIwMTcsIGF0IDAwOjAxLCBqYW1lcyB3b29keWF0dCA8amh3QGdvb2dsZS5jb208 bWFpbHRvOmpod0Bnb29nbGUuY29tPj4gd3JvdGU6DQoNCk9uIE1hciAzMCwgMjAxNywgYXQgMTc6 NTQsIFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbTxtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbT4+ IHdyb3RlOg0KDQpJJ20gb2theSB3aXRoIGVpdGhlciBobSBvciBoYWIuICAgSSB3b3VsZCB2ZXJ5 IG11Y2ggbGlrZSBmb3IgdXMgbm90IHRvIHR1YmUgb24gYSBiZWF1dHkgY29udGVzdCBkaXNjdXNz aW9uLCB0aG91Z2guICAgSXQgd291bGQgYmUgbmljZSB0byB0dXJuIHRoaXMgZHJhZnQgYXJvdW5k IHF1aWNrbHkuDQoNClNvLCBpdOKAmXMgc2V0dGxlZCB0aGVuLiA6KQ0KDQpTb21ldGhpbmcgdGhh dCBpcyBmYWlybHkgdW5hbWJpZ3VvdXNseSBwcm9ub3VuY2VkLCBhbmQgY29uY2lzZSB0byBzYXks IHdvdWxkIGJlIG5pY2UuIEJ5IHRob3NlIGNyaXRlcmlhLCBoYWIgdHJ1bXBzIGhtLiAgTW9zdCB0 eXBpY2FsIGhvbWUgdXNlcnMgc2hvdWxkIG5ldmVyIG5lZWQgdG8gc2VlIG9yIHNheSBpdCB0aG91 Z2guDQoNCkl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGhlYXIgdmlld3MgZnJvbSBub24tRW5n bGlzaCBsYW5ndWFnZSBwZW9wbGUsIGJ1dCB3ZSBzaG91bGQganVzdCBnZXQgdGhpcyBkb25lIGFz YXAuDQoNClRpbQ0K --_000_1997580F1C464553B68A098712A46BB9jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAzMSBNYXIgMjAxNywgYXQgMDA6 MDEsIGphbWVzIHdvb2R5YXR0ICZsdDs8YSBocmVmPSJtYWlsdG86amh3QGdvb2dsZS5jb20iIGNs YXNzPSIiPmpod0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTog c3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1hciAzMCwg MjAxNywgYXQgMTc6NTQsIFRlZCBMZW1vbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1lbGxvbkBmdWd1 ZS5jb20iIGNsYXNzPSIiPm1lbGxvbkBmdWd1ZS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFu Z2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JJ20gb2theSB3aXRo IGVpdGhlciBobSBvciBoYWIuICZuYnNwOyZuYnNwO0kgd291bGQgdmVyeSBtdWNoIGxpa2UgZm9y IHVzIG5vdCB0byB0dWJlIG9uIGEgYmVhdXR5IGNvbnRlc3QgZGlzY3Vzc2lvbiwgdGhvdWdoLiAm bmJzcDsmbmJzcDtJdCB3b3VsZCBiZSBuaWNlIHRvIHR1cm4gdGhpcyBkcmFmdCBhcm91bmQgcXVp Y2tseS48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNvLCBpdOKAmXMgc2V0dGxlZCB0aGVuLiA6 KTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj5Tb21ldGhpbmcgdGhhdCBpcyBmYWlybHkgdW5hbWJpZ3VvdXNs eSBwcm9ub3VuY2VkLCBhbmQgY29uY2lzZSB0byBzYXksIHdvdWxkIGJlIG5pY2UuIEJ5IHRob3Nl IGNyaXRlcmlhLCBoYWIgdHJ1bXBzIGhtLiAmbmJzcDtNb3N0IHR5cGljYWwgaG9tZSB1c2VycyBz aG91bGQgbmV2ZXIgbmVlZCB0byBzZWUgb3Igc2F5IGl0IHRob3VnaC48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkl0IHdvdWxkIGJlIGlu dGVyZXN0aW5nIHRvIGhlYXIgdmlld3MgZnJvbSBub24tRW5nbGlzaCBsYW5ndWFnZSBwZW9wbGUs IGJ1dCB3ZSBzaG91bGQganVzdCBnZXQgdGhpcyBkb25lIGFzYXAuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaW08L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_1997580F1C464553B68A098712A46BB9jiscacuk_--