From nobody Wed Feb 3 10:56:34 2016 Return-Path: X-Original-To: arcing@ietfa.amsl.com Delivered-To: arcing@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27FB1B2B0C for ; Wed, 3 Feb 2016 10:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 pqVETb_emdSQ for ; Wed, 3 Feb 2016 10:56:31 -0800 (PST) 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 B78A41B2B11 for ; Wed, 3 Feb 2016 10:56:30 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id s5so11718621qkd.0 for ; Wed, 03 Feb 2016 10:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=LMLqI4numzA7hlCtIn3LaHl2Rw/vA5gwIUxdUj/60Mc=; b=RfjnTTd3mJ8YQf+ys6D7Uc76AsaDiqdq5iNzQ3DBeZSKrqckmSKhakCcDn5aVY1jWO 6S2tPONxb5r4kY5faSnJmpQYhZDk9XptIklO0EvsvzGHm3mgVNKuRiJDEJ+YuU67IbG6 QprnsWiJougspGB55X4/pxJMpAy3faLDHqW2nXaBWCLG1TJw9y6wTPNb6yEYBRhbn6uo AlULkb9PtRPoxxj60Rr92ornY4qA+UKxeIOwvUaGe543kV7NOEUTU3iTDQuCls8dzBAp 9ubwE0bNeApLJb58ci+c3cu8ALOfYwu0gQNndefbEap+QvX3tVItFM2zh+lmmneMtIMX jFPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=LMLqI4numzA7hlCtIn3LaHl2Rw/vA5gwIUxdUj/60Mc=; b=QCVlX1tacJOUzri1QwR0imbm22SFXeYqmBulBMOehZuzrXzwB8hBRquyXRFrN9HJJ3 JSG3qdE+PtamXJub/CnZasPFWQEtsX/R1993ZPH3GEPgcUWL/OnozKp8Ext6lSRuTBxZ jxjdSoOPxDG/Mhgef7zezMhAp/RmUYDALkaz5kEyeMdzTW3eLNvxgnlv0Lexi7UDrBjr jXCp/YaFfcbjOqklszf+hgP2rLWLnhbgy6eBADBTNSmEQdSsSk8u71MYH085BiqGZYAC gNi6aB/WTS2rfBtWfwKGPuEVEkg19lcBZtLHEI64j2W8l/FFej6cOgPS3sDdrrpr3ZV+ oajA== X-Gm-Message-State: AG10YOTwHDLzw5ge3AD7uG2KnEBrVSPAUIJaCJ0jON9vBofieNF5Gd3MP/75KoZV0CZkWYpVvor3K2YdlugK7Q== X-Received: by 10.55.192.7 with SMTP id o7mr3524598qki.93.1454525789925; Wed, 03 Feb 2016 10:56:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Wed, 3 Feb 2016 10:56:10 -0800 (PST) From: Ted Hardie Date: Wed, 3 Feb 2016 10:56:10 -0800 Message-ID: To: arcing@ietf.org Content-Type: multipart/alternative; boundary=001a1149e40a0692d4052ae22dda Archived-At: Subject: [Arcing] A bit more on the problem statement X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 18:56:33 -0000 --001a1149e40a0692d4052ae22dda Content-Type: text/plain; charset=UTF-8 In the draft I posted on resolution contexts, I called the overarching set of names "Internet names", following RFC 891. Clearly things have moved on from then no little, but I wanted to get back to that terminology because I wanted to stress the internetworking aspect of the problem. For names or identifiers to be meaningful in multiple contexts (like different networks or administrative domains), those contexts have to see them as part of the same namespace. That doesn't mean that there must be one unitary namespace for every use, but it does mean that each context that uses a name must share the same idea of what the namespace context is. You can resolve that problem by having all names in a single namespace context. You can also resolve that by having context markers. The issue with the first approach is that it is trivial for people to mint new names. If those are presumed to be within a single context, that also means that it is trivial for those new names to conflict either with each other or established names. The only available point of control we have at the moment is in resolution using a specific set of resolution protocols. That is, a policy body may decline to allow a particular name to be resolved with the DNS, but anything that doesn't use that set of resolution protocols can still conflict. I don't personally see any way to create a point of control on the minting of the names themselves without a complete architectural re-write of the entire Internet, so I don't think we can change the point of control. That leaves this approach with a pretty big gap--any name that doesn't use the DNS as a resolution protocol is subject to squatting, collision, or confusion. The second approach, using context markers, is approximately where we are today, but we are using an implicit set of context marker rather than an explicit one. But we're not using it particularly well. As it stands, the context marker (pseudo-gTLDs) requires a priori knowledge to establish resolution context *and it doesn't allow you to mark namespaces that don't share the syntax of the DNS*. If what we want is a single Internet namespace, with a marker for which resolution protocol is meant, this could be refined a bit to work. But every single name delegation in any of the resolution contexts will remain a source of potential collision, squatting or confusion, because we still won't control the ability to mint names. If we shift to an explicit set of markers, we get the following advantages: we can use syntax different from the syntax of the DNS; we can avoid collision at the level of the tuple of namespace, name; we can avoid conflating resolution context and namespace. (Note that resolution context is not a one-to-one mapping with protocol. As David Conrad has been pointing out for years, having a cryptographically signed DNS root (or other zone) means the distribution channel for the information can change; the resolution context does not). The disadvantage is that every protocol that works across namespaces must now be updated to recognize both the explicit markers and the namespaces themselves. That's a lot of work and, as IPv6 taught us, the network effects run against you the whole way. It may, however, be something that is significantly easier to deploy incrementally than the core IP layer is. My first question to this group is: do folks agree with this characterization? If not, what's wrong? If they do agree with the characterization of the problem, does this sketch of solution spaces look right? And, most importantly, which level of the problem do we think we can solve: the multiple namespaces one or the unitary namespace/multiple resolution contexts one? regards, Ted --001a1149e40a0692d4052ae22dda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the draft I posted on resolution contexts, I cal= led the overarching set of names "Internet names", following RFC = 891.=C2=A0 Clearly things have moved on from then no little, but I wanted t= o get back to that terminology because I wanted to stress the internetworki= ng aspect of the problem.=C2=A0

For names or identifiers to be mean= ingful in multiple contexts (like different networks or administrative doma= ins), those contexts have to see them as part of the same namespace.=C2=A0 = That doesn't mean that there must be one unitary namespace for every us= e, but it does mean that each context that uses a name must share the same = idea of what the namespace context is.=C2=A0

You can r= esolve that problem by having all names in a single namespace context.=C2= =A0 You can also resolve that by having context markers.=C2=A0

The issue with the first approach is that it is trivial for people= to mint new names.=C2=A0 If those are presumed to be within a single conte= xt, that also means that it is trivial for those new names to conflict eith= er with each other or established names.=C2=A0 The only available point of = control we have at the moment is in resolution using a specific set of reso= lution protocols.=C2=A0 That is, a policy body may decline to allow a parti= cular name to be resolved with the DNS, but anything that doesn't use t= hat set of resolution protocols can still conflict.=C2=A0 I don't perso= nally see any way to create a point of control on the minting of the names = themselves without a complete architectural re-write of the entire Internet= , so I don't think we can change the point of control.=C2=A0 That leave= s this approach with a pretty big gap--any name that doesn't use the DN= S as a resolution protocol is subject to squatting, collision, or confusion= .

The second approach, using context markers, is approx= imately where we are today, but we are using an implicit set of context mar= ker rather than an explicit one.=C2=A0 But we're not using it particula= rly well.=C2=A0 As it stands, the context marker (pseudo-gTLDs) requires a = priori knowledge to establish resolution context *and it doesn't allow = you to mark namespaces that don't share the syntax of the DNS*.=C2=A0 I= f what we want is a single Internet namespace, with a marker for which reso= lution protocol is meant, this could be refined a bit to work. But every si= ngle name delegation in any of the resolution contexts will remain a source= of potential collision, squatting or confusion, because we still won't= control the ability to mint names.

If we shift to an e= xplicit set of markers, we get the following advantages:=C2=A0 we can use s= yntax different from the syntax of the DNS; we can avoid collision at the l= evel of the tuple of namespace, name; we can avoid conflating resolution co= ntext and namespace.=C2=A0 (Note that resolution context is not a one-to-on= e mapping with protocol.=C2=A0 As David Conrad has been pointing out for ye= ars, having a cryptographically signed DNS root (or other zone) means the d= istribution channel for the information can change; the resolution context = does not).

The disadvantage is that every protocol that= works across namespaces must now be updated to recognize both the explicit= markers and the namespaces themselves.=C2=A0 That's a lot of work and,= as IPv6 taught us, the network effects run against you the whole way.=C2= =A0 It may, however, be something that is significantly easier to deploy in= crementally than the core IP layer is.

My first questio= n to this group is:=C2=A0 do folks agree with this characterization?=C2=A0 = If not, what's wrong?

If they do agree with the c= haracterization of the problem, does this sketch of solution spaces look ri= ght?

And, most importantly, which level of the problem = do we think we can solve:=C2=A0 the multiple namespaces one or the unitary = namespace/multiple resolution contexts one?

regards,
Ted
--001a1149e40a0692d4052ae22dda-- From nobody Wed Feb 3 16:45:02 2016 Return-Path: X-Original-To: arcing@ietfa.amsl.com Delivered-To: arcing@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8091B35B5 for ; Wed, 3 Feb 2016 16:45:02 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 sfjEBazMVzY2 for ; Wed, 3 Feb 2016 16:45:01 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 D983B1B2BF7 for ; Wed, 3 Feb 2016 16:45:00 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id n128so24217597pfn.3 for ; Wed, 03 Feb 2016 16:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=G7oMkpNDNoqE51RLL+jvAD/SvfECCgc0NsHoBRs15LE=; b=Cy2xDhSpPzYfjHQXzmAvRQQHfhmPnHgvi6hfU9Yjkj9kPNccE2qmCILZE9hO/udZP7 z4Z32ddiZhdaaM2/as/eR2lSR1CA1ZKV1fWqtVutV0DKkGT6L6bFRRV7s9IyilqjFYDE mbkZ0jwmNnRjHgh8DKEkU9cdr2cDm/rXHLACnsre9Bbyw7ZjlgU21eu3GM8+HGX+rWbS K6tNiZMAU90IeYbJpCAjJyaoYYB2WNy93bGf3O3Cm2TishknB/+BymTvjgGJ+iZDMkAX gz1jZ4azfGBeWzu+/o7U7IJwA9E8vRXqhcQPyiqakP40k85z81nsqvKFqiJMPpjMywUi Xr+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=G7oMkpNDNoqE51RLL+jvAD/SvfECCgc0NsHoBRs15LE=; b=Kz+gPtw5/OG4wjDqQCNHB2F/Hy284zY7DnKJnOIhrHQGViEhyk7a1E4fWohxRzgGq7 8HCKkjY7iorR6o92YChqorSU+2webfhIr9iEm4tytmsqs7j+K9mYlrwtq92ZbMQXYrh7 umOzruio0D+Jkavt8bEBJ2fPJSMb7ZC4OCVh7cYjmCq2mCUIEKXstPQC9wyM1+ULrJXS BSRgAsO7uwo2qhhRrwhPFf0jSxNw/lcZfVPmMgSDk13OxQEiVyzYb/MOBgG0WP/fs7jw moljQizL7hfDob/Gl51uRf4sgqNOxGAQPX2z8MdSh8D/yHXdy564gyFnuk6rNcy4T6Kh /XsA== X-Gm-Message-State: AG10YOQOuxD/lz94E9xrZawBtSgAh8a24Jy2Jvvt2fZOQtsSu/WUEsoAqKjbey834OvA1A== X-Received: by 10.66.237.66 with SMTP id va2mr6869920pac.87.1454546700601; Wed, 03 Feb 2016 16:45:00 -0800 (PST) Received: from US-DOUGO-MAC.local ([2601:646:8800:9378:709f:899e:df8b:885c]) by smtp.googlemail.com with ESMTPSA id 3sm12382119pfp.96.2016.02.03.16.44.59 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Feb 2016 16:44:59 -0800 (PST) To: arcing@ietf.org References: From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <56B29F7C.2040809@gmail.com> Date: Wed, 3 Feb 2016 16:46:52 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Arcing] A bit more on the problem statement X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 00:45:02 -0000 On 2/3/16 10:56 AM, Ted Hardie wrote: > The only available point of control we have at the > moment is in resolution using a specific set of > resolution protocols. That is, a policy body may decline > to allow a particular name to be resolved with the DNS, > but anything that doesn't use that set of resolution > protocols can still conflict. I don't personally see any > way to create a point of control on the minting of the > names themselves without a complete architectural > re-write of the entire Internet, so I don't think we can > change the point of control. That leaves this approach > with a pretty big gap--any name that doesn't use the DNS > as a resolution protocol is subject to squatting, > collision, or confusion. Dear Ted, A practical approach would carefully consider name overlays carved out using specific “Special Use” TLDs generated locally by resolvers able to access both DNS and local namespace. This avoids creation of subtly different namespaces based on protocol selectors such as :// versus ://. that can make use of differing cryptographic assurances. The latter maps into current security and url practices and only requires pro-active standards bodies to insure available “Special Use” TLDs are made available to fulfill essential needs. Otherwise users would then need to carefully examine hffp:// as opposed to http:// .home is already being usurped and should be excluded from DNS as representing “Special Use” for local non-multicast naming. TLD carve-outs have been working fairly well until debates about whether basically money should determine TLDs use. Regards, Douglas Otis From nobody Wed Feb 3 18:08:27 2016 Return-Path: X-Original-To: arcing@ietfa.amsl.com Delivered-To: arcing@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B687E1B3854 for ; Wed, 3 Feb 2016 18:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 kmLAb7_4qSY3 for ; Wed, 3 Feb 2016 18:08:23 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0605.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:605]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDEF11B380A for ; Wed, 3 Feb 2016 18:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uqnJtxcyMJGZSttbqTyx5MWf6HpdG2oWfkucPt+U/5k=; b=1BYYc5sjmmOgP44MK8+m8udK+URFW2Yc+sVIcE8CLX41zmHd3dFZ7u6x4rGmefI1k8f2AnzvUezUpPO3rdY/R8lvhctHl7ox4vcNPU0YNFO3KUszgTFH0UVovih5qaVkMGuPXWNgqIoG/SRoZzzBbLUv1T/NXi2+QLzFRBNmdWk= Received: from CY1PR0601MB1657.namprd06.prod.outlook.com (10.163.232.19) by CY1PR0601MB1659.namprd06.prod.outlook.com (10.163.232.21) with Microsoft SMTP Server (TLS) id 15.1.396.15; Thu, 4 Feb 2016 02:07:59 +0000 Received: from CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) by CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) with mapi id 15.01.0396.020; Thu, 4 Feb 2016 02:07:59 +0000 From: Dan York To: Ted Hardie Thread-Topic: [Arcing] A bit more on the problem statement Thread-Index: AQHRXrSc5VAnQ03hhUeE6omrlyIJ0w== Date: Thu, 4 Feb 2016 02:07:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [74.69.229.215] x-microsoft-exchange-diagnostics: 1; CY1PR0601MB1659; 5:EpXfrY9EBTvAIIrAunc5kqv2tkq2GTo2tLbVVyrFkzI+mtNLi1VySgSt8QKUtMBQW76KGr8dzQ/QIjydpsBo/p9unqKkJmXyveUQWN78AKZrENO5MBOkLbiMPtt+0nsceZxGjAiBaBlnUZkl4h5Diw==; 24:4BhLfOh8P2qbGMC40TPN37gdSEArPbTPjnUyAk+yUAO/ZdxkOcrdN7vLv57gAs6zZybbKhlAofmtbtq/Nr84bCFZUpxu+cVqjKPZmWeplsU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1659; x-ms-office365-filtering-correlation-id: 5b0a3245-7ac6-4fe7-e45a-08d32d08010e x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0601MB1659; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1659; x-forefront-prvs: 084285FC5C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(377454003)(1096002)(1220700001)(102836003)(2906002)(92566002)(586003)(50986999)(76176999)(36756003)(83716003)(5008740100001)(6116002)(189998001)(19617315012)(3846002)(5004730100002)(54356999)(77096005)(15975445007)(4326007)(87936001)(10400500002)(2950100001)(66066001)(19580395003)(19580405001)(5001960100002)(82746002)(106116001)(99286002)(11100500001)(2900100001)(3660700001)(5002640100001)(3280700002)(33656002)(122556002)(15395725005)(40100003)(86362001)(16236675004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1659; H:CY1PR0601MB1657.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D22DCDE4DB564BEBBC0947B1428E29EBisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2016 02:07:58.6050 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1659 Archived-At: Cc: "arcing@ietf.org" Subject: Re: [Arcing] A bit more on the problem statement X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 02:08:25 -0000 --_000_D22DCDE4DB564BEBBC0947B1428E29EBisocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ted, Hmmm... I wrote the message as a draft and then went looking to finish it u= p... and seem to have sent it! Sorry for filling your inboxes with an inco= mplete message! Picking up where I left off... On Feb 3, 2016, at 1:56 PM, Ted Hardie > wrote: If we shift to an explicit set of markers, we get the following advantages:= we can use syntax different from the syntax of the DNS; we can avoid coll= ision at the level of the tuple of namespace, name; we can avoid conflating= resolution context and namespace. Can you give a more Can you give an example of what you are thinking about with regard to an "e= xplicit set of markers"? I ask because... The disadvantage is that every protocol that works across namespaces must n= ow be updated to recognize both the explicit markers and the namespaces the= mselves. That's a lot of work and, as IPv6 taught us, the network effects = run against you the whole way. It may, however, be something that is signi= ficantly easier to deploy incrementally than the core IP layer is. ... I think deployment of any solutions may be a huge issue, but I'm not cl= ear about what you are thinking about as a solution. I'm guessing you have= *some* idea of how you might like to see it work. If we think of different kinds of namespace identifiers, we have the exampl= e of the URI/URL/URN kind of notation with a protocol first. And certainly= in the earlier days of the Internet that was one mechanism we've had. And= yes, it still works today... BUT... today we're seeing so much of Internet= traffic going over HTTP(S) ... and devices and applications *assuming* tra= ffic will be going over HTTP(S)... that we can't rely as much on the protoc= ol portion of the URI. Thus in a world of HTTP/HTTPS it's not surprising t= hat people are overloading existing systems (TLDs) to identify different na= mespaces (ex. .onion). Another examples that occurs to me is the separate namespaces used in XML w= ith the xmlns attribute and appropriate prefixes before elements. But that= 's obviously within an XML *document* versus a network protocol. And, most importantly, which level of the problem do we think we can solve:= the multiple namespaces one or the unitary namespace/multiple resolution = contexts one? I guess a more basic question is - are you suggesting we try to solve this = problem for ALL protocols? for just a select set of protocols (HTTP, HTTPS= ?)? Or something else? Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/ --_000_D22DCDE4DB564BEBBC0947B1428E29EBisocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <3FEF8CB52BA84D429BD56DC240A288E2@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Ted,

Hmmm... I wrote the message as a draft and then went lookin= g to finish it up... and seem to have sent it!  Sorry for filling your= inboxes with an incomplete message!  Picking up where I left off...


On Feb 3, 2016, at 1:56 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

If we shift to an explicit set of markers, we get the following adva= ntages:  we can use syntax different from the syntax of the DNS; we ca= n avoid collision at the level of the tuple of namespace, name; we can avoid conflating resolution context and namespa= ce. 

Can you give a more 

Can you give an example of what you are thinking about with regard to an &q= uot;explicit set of markers"?  

I ask because... 

The disadvantage is that every protocol that works across namespaces= must now be updated to recognize both the explicit markers and the namespa= ces themselves.  That's a lot of work and, as IPv6 taught us, the network effects run against you the whole way.=   It may, however, be something that is significantly easier to deploy= incrementally than the core IP layer is.

... I think deployment of any solutions may be a huge issue, but I'm not cl= ear about what you are thinking about as a solution.  I'm guessing you= have *some* idea of how you might like to see it work.

If we think of different kinds of namespace identifiers, we have the e= xample of the URI/URL/URN kind of notation with a protocol first.  And= certainly in the earlier days of the Internet that was one mechanism we've= had.  And yes, it still works today... BUT... today we're seeing so much of Internet traffic going over HTTP(S) .= .. and devices and applications *assuming* traffic will be going over HTTP(= S)... that we can't rely as much on the protocol portion of the URI.  = Thus in a world of HTTP/HTTPS it's not surprising that people are overloading existing systems (TLDs) to identify= different namespaces (ex. .onion).

Another examples that occurs to me is the separate namespaces used in = XML with the xmlns attribute and appropriate prefixes before elements. &nbs= p;But that's obviously within an XML *document* versus a network protocol.<= /div>

And, most importantly, which level of the problem do we think we can= solve:  the multiple namespaces one or the unitary namespace/multiple= resolution contexts one?

I guess a more basic question is - are you suggesting we try to solve = this problem for ALL protocols?  for just a select set of protocols (H= TTP, HTTPS?)?  Or something else?

Dan

--
Dan York
Senior Content Strategist, Int= ernet Society
york@isoc.org   +1-802-735-1624
Jabber: york@jabber.isoc.org 
Skype: danyork   http://twitter.com/danyork

http://www.internets= ociety.org/




--_000_D22DCDE4DB564BEBBC0947B1428E29EBisocorg_-- From nobody Wed Feb 3 18:55:48 2016 Return-Path: X-Original-To: arcing@ietfa.amsl.com Delivered-To: arcing@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677221B381B for ; Wed, 3 Feb 2016 18:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 JVLTXcvfCype for ; Wed, 3 Feb 2016 18:55:44 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8861B319A for ; Wed, 3 Feb 2016 18:55:44 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EACFE22E200; Wed, 3 Feb 2016 21:55:39 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: Date: Thu, 4 Feb 2016 13:55:36 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <524E4EBB-DB02-4091-9F5D-14F103A81178@mnot.net> References: To: Ted Hardie X-Mailer: Apple Mail (2.2104) Archived-At: Cc: arcing@ietf.org Subject: Re: [Arcing] A bit more on the problem statement X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 02:55:47 -0000 Hi Ted, Trying to work through this, please be patient with my potentially = limited understanding / context. > On 4 Feb 2016, at 5:56 am, Ted Hardie wrote: >=20 > In the draft I posted on resolution contexts, I called the overarching = set of names "Internet names", following RFC 891. Clearly things have = moved on from then no little, but I wanted to get back to that = terminology because I wanted to stress the internetworking aspect of the = problem. =20 >=20 > For names or identifiers to be meaningful in multiple contexts (like = different networks or administrative domains), those contexts have to = see them as part of the same namespace. That doesn't mean that there = must be one unitary namespace for every use, but it does mean that each = context that uses a name must share the same idea of what the namespace = context is. =20 >=20 > You can resolve that problem by having all names in a single namespace = context. You can also resolve that by having context markers. =20 >=20 > The issue with the first approach is that it is trivial for people to = mint new names. If those are presumed to be within a single context, = that also means that it is trivial for those new names to conflict = either with each other or established names. The only available point = of control we have at the moment is in resolution using a specific set = of resolution protocols. >=20 > That is, a policy body may decline to allow a particular name to be = resolved with the DNS, but anything that doesn't use that set of = resolution protocols can still conflict. I don't personally see any way = to create a point of control on the minting of the names themselves = without a complete architectural re-write of the entire Internet, so I = don't think we can change the point of control. That leaves this = approach with a pretty big gap--any name that doesn't use the DNS as a = resolution protocol is subject to squatting, collision, or confusion. >=20 > The second approach, using context markers, is approximately where we = are today, but we are using an implicit set of context marker rather = than an explicit one. But we're not using it particularly well. As it = stands, the context marker (pseudo-gTLDs) requires a priori knowledge to = establish resolution context If applications don't (somewhere) have the ability to perform resolution = in that context, they're not going to work anyway, and if they do, they = have the a priori knowledge necessary.=20 So, I think the problem here is largely what we saw with .onion -- if = your application / resolver / etc. don't recognise it as a special name, = it falls back to DNS resolution, and that may have various undesirable = side effects (besides not working).=20 Arguably the downsides of those side effects for .onion -- given its use = cases -- are pretty extreme, and so it's very interesting to me that = despite that limitation, its very privacy- and security-sensitive = community still decided to go in that direction. > *and it doesn't allow you to mark namespaces that don't share the = syntax of the DNS*. How big of a problem is this? There are issues with i18n and DNS names, = of course, but I don't hear people in this space saying that a big = driver for them is "names that don't look like hostnames." There's a LOT = of shared understanding behind DNS-style names. > If what we want is a single Internet namespace, with a marker for = which resolution protocol is meant, this could be refined a bit to work. Are you thinking of something like a DNS record on the root zone of = these domains, so that resolvers can check to see if it's meant for = them? > But every single name delegation in any of the resolution contexts = will remain a source of potential collision, squatting or confusion, = because we still won't control the ability to mint names. I'm not sure how you got here, or why our (the IETF's?) control over the = ability to mint names is important here. Each resolution context is = going to need to control its own destiny (assuming it has a distinct = name space of its own, a la .onion .home etc.)... > If we shift to an explicit set of markers, we get the following = advantages: we can use syntax different from the syntax of the DNS; we = can avoid collision at the level of the tuple of namespace, name; we can = avoid conflating resolution context and namespace. (Note that = resolution context is not a one-to-one mapping with protocol. As David = Conrad has been pointing out for years, having a cryptographically = signed DNS root (or other zone) means the distribution channel for the = information can change; the resolution context does not). >=20 > The disadvantage is that every protocol that works across namespaces = must now be updated to recognize both the explicit markers and the = namespaces themselves. That's a lot of work and, as IPv6 taught us, the = network effects run against you the whole way. It may, however, be = something that is significantly easier to deploy incrementally than the = core IP layer is. I'm not really sure what direction you're thinking of going here, but I = am reminded somewhat of previous discussions to define how to transport = DNSSEC-signed records inside HTTP/2 frames, thereby establishing an = independent (albeit syntactically and semantically very similar) = resolution protocol for the same context. That hasn't gone anywhere, but = it's still lurking out there as a possibility, AIUI. > My first question to this group is: do folks agree with this = characterization? If not, what's wrong? >=20 > If they do agree with the characterization of the problem, does this = sketch of solution spaces look right? >=20 > And, most importantly, which level of the problem do we think we can = solve: the multiple namespaces one or the unitary namespace/multiple = resolution contexts one? >=20 > regards, >=20 > Ted Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Feb 4 10:24:26 2016 Return-Path: X-Original-To: arcing@ietfa.amsl.com Delivered-To: arcing@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E90E1AC40D for ; Thu, 4 Feb 2016 10:24:24 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 7nzy91JImRll for ; Thu, 4 Feb 2016 10:24:21 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 5C89F1AC425 for ; Thu, 4 Feb 2016 10:24:21 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id o11so48523551qge.2 for ; Thu, 04 Feb 2016 10:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=c59xc1xGyENoVDZzSaeTpzIVHpI1jH6qigKcmmbcX58=; b=DjmehepqJJm5ewmU/c/ccNck5X30CQRq9tMurCMXNNZB7Tfeft9MTgaJcDD2G1XOHr hcwbDuU7O8aZoNWSPwCVJXpai2BWV8P/vFCGjiN/Tx9obkuhfBw3hdTHeCCgsl1B4LcX iTJxQ/KFafbNEK5+jqJgbctLzVp5H3OCvNauIp1LW8XLx3wxMy6Uhbj2way2w/DOAoG7 kouu2wxTzNN9RpYrvon1t22MQl1Cvc4F199DCJAMroPKHmhws2OaPFfQXz7rep7TmrBm RHMeFzPuFFhE89KWqGoJoUuDAWJB9o79kOzRhFQY5JxMexPKpOb8Iu67tHqteTPWYqYH /Sfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=c59xc1xGyENoVDZzSaeTpzIVHpI1jH6qigKcmmbcX58=; b=mA5p+jA1MHyorQle448R7acOcBjNXX30XVq7lVp/SiZlucvPtBeBKy0Te5Ysy/sryn oo9wzdZDns7PpfehMUNuaoFxQ743f8LLTT4Kp+n1fn0mgjUeaSu4g108dWybn7sgfZYb HGMEvq7IS95NSsft4M/6qfddQVWgw2GRQwWDGwN3m4NLbJ9RF/v4xKsKuJDYN9S/KWPC brLEaDDP5UHxsDN8G1kcANoBgEdgkTcI9SqoHVHNHq+C1xbD07UqulYhCJ4qeC2nO2dL Rf67g6JzVYdFs2y5NkMZXlvDXFh3AvXOmHmGQ+4/YS6HRyqPoPfpk4beMS/6KMtZjsJW HJvA== X-Gm-Message-State: AG10YOTB5PQZo78DJvOonsaNdFfml4iTkSoMasQ1ARZ00S6WqVGF8RM35CenT0ZHg8ci/CvHxIe/3lgzGAco6Q== X-Received: by 10.140.163.6 with SMTP id j6mr11749871qhj.36.1454610260544; Thu, 04 Feb 2016 10:24:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Thu, 4 Feb 2016 10:24:01 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Thu, 4 Feb 2016 10:24:01 -0800 Message-ID: To: Dan York Content-Type: multipart/alternative; boundary=001a1139d3fcddfb1d052af5d729 Archived-At: Cc: "arcing@ietf.org" Subject: Re: [Arcing] A bit more on the problem statement X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 18:24:24 -0000 --001a1139d3fcddfb1d052af5d729 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 3, 2016 at 6:07 PM, Dan York wrote: > Ted, > > Hmmm... I wrote the message as a draft and then went looking to finish it > up... and seem to have sent it! Sorry for filling your inboxes with an > incomplete message! Picking up where I left off... > > > On Feb 3, 2016, at 1:56 PM, Ted Hardie wrote: > > If we shift to an explicit set of markers, we get the following > advantages: we can use syntax different from the syntax of the DNS; we c= an > avoid collision at the level of the tuple of namespace, name; we can avoi= d > conflating resolution context and namespace. > > > Can you give a more > > > Can you give an example of what you are thinking about with regard to an > "explicit set of markers"? > > I ask because... > > The disadvantage is that every protocol that works across namespaces must > now be updated to recognize both the explicit markers and the namespaces > themselves. That's a lot of work and, as IPv6 taught us, the network > effects run against you the whole way. It may, however, be something tha= t > is significantly easier to deploy incrementally than the core IP layer is= . > > > ... I think deployment of any solutions may be a huge issue, but I'm not > clear about what you are thinking about as a solution. I'm guessing you > have *some* idea of how you might like to see it work. > > =E2=80=8BI don't think there is any obvious way forward here; there are a l= ot of trade-offs in adopting specific approaches or syntax. The problem isn't insoluble: both URNs and Handles have multiple disjoint namespaces and a way to disambiguate among them. But getting the markers correct at this point to allow new namespaces in existing, common protocol slots would require a lot of analysis and work.=E2=80=8B > If we think of different kinds of namespace identifiers, we have the > example of the URI/URL/URN kind of notation with a protocol first. And > certainly in the earlier days of the Internet that was one mechanism we'v= e > had. And yes, it still works today... BUT... today we're seeing so much = of > Internet traffic going over HTTP(S) ... and devices and applications > *assuming* traffic will be going over HTTP(S)... that we can't rely as mu= ch > on the protocol portion of the URI. Thus in a world of HTTP/HTTPS it's n= ot > surprising that people are overloading existing systems (TLDs) to identif= y > different namespaces (ex. .onion). > > =E2=80=8B So, I believe we could develop a common URL sysntax that permit a nested URN/handle/other-identified-namespace, as you could stretch a point to assert that those are reg=E2=80=8Bistered names and that any syntax that fe= ll under regname was fair game. RFC 3986 says: This specification does not mandate a particular registered name lookup technology and therefore does not restrict the syntax of reg- name beyond what is necessary for interoperability. Instead, it delegates the issue of registered name syntax conformance to the operating system of each application performing URI resolution, and that operating system decides what it will allow for the purpose of host identification. But most approaches would upend every parser out there at the moment, which is a big, hairy deal. We'd have to be convinced that this was useful, deployable, and the right choice before we did that, and, perhaps more importantly, that the failures that would inevitably occur would be limited to the new namespaces. =E2=80=8B > Another examples that occurs to me is the separate namespaces used in XML > with the xmlns attribute and appropriate prefixes before elements. But > that's obviously within an XML *document* versus a network protocol. > > =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B=E2=80=8B > And, most importantly, which level of the problem do we think we can > solve: the multiple namespaces one or the unitary namespace/multiple > resolution contexts one? > > > I guess a more basic question is - are you suggesting we try to solve thi= s > problem for ALL protocols? for just a select set of protocols (HTTP, > HTTPS?)? Or something else? > > =E2=80=8BI think the nature of these names is that the ones that move from = protocol context to protocol context are the ones that present the real problem. So I'm not sure that the size of the ocean to be boiled can be restricted much by limiting only to "successful, widely deployed protocols". But I'm certainly willing to listen if someone else has another way forward here. regards, Ted=E2=80=8B > Dan > > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org > Skype: danyork http://twitter.com/danyork > > http://www.internetsociety.org/ > > > > > --001a1139d3fcddfb1d052af5d729 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 3, 2016 at 6:07 PM,= Dan York <york@isoc.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Ted,

Hmmm... I wrote the message as a draft and then went looking to finish= it up... and seem to have sent it!=C2=A0 Sorry for filling your inboxes wi= th an incomplete message!=C2=A0 Picking up where I left off...


On Feb 3, 2016, at 1:56 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

If we shift to an= explicit set of markers, we get the following advantages:=C2=A0 we can use= syntax different from the syntax of the DNS; we can avoid collision at the= level of the tuple of namespace, name; we can avoid conflating resolution context and namespa= ce.=C2=A0

Can you give a more=C2=A0

Can you give an example of what you are thinking about with regard to an &q= uot;explicit set of markers"? =C2=A0

I ask because...=C2=A0

The disadvantage = is that every protocol that works across namespaces must now be updated to = recognize both the explicit markers and the namespaces themselves.=C2=A0 Th= at's a lot of work and, as IPv6 taught us, the network effects run against you the whole way.= =C2=A0 It may, however, be something that is significantly easier to deploy= incrementally than the core IP layer is.

 ... I think deployment of any solutions may be a huge issue, but I'm no= t clear about what you are thinking about as a solution.=C2=A0 I'm gues= sing you have *some* idea of how you might like to see it work.


=E2=80=8BI don'= t think there is any obvious way forward here; there are a lot of trade-off= s in adopting specific approaches or syntax.=C2=A0 The problem isn't in= soluble:=C2=A0 both URNs and Handles have multiple disjoint namespaces and = a way to disambiguate among them.=C2=A0 But getting the markers correct at = this point to allow new namespaces in existing, common protocol slots would= require a lot of analysis and work.=E2=80=8B

=C2=A0
If we think of different kinds of namespace identifiers, we have the e= xample of the URI/URL/URN kind of notation with a protocol first.=C2=A0 And= certainly in the earlier days of the Internet that was one mechanism we= 9;ve had.=C2=A0 And yes, it still works today... BUT... today we're seeing so much of Internet traffic going over HTTP(= S) ... and devices and applications *assuming* traffic will be going over H= TTP(S)... that we can't rely as much on the protocol portion of the URI= .=C2=A0 Thus in a world of HTTP/HTTPS it's not surprising that people are overloading existing systems (TLDs) to identify= different namespaces (ex. .onion).

=E2=80=8B
So, I believe we could develop a common URL sysntax that permit a=20 nested URN/handle/other-identified-namespace, as you could stretch a point = to assert=20 that those are reg=E2=80=8Bistered names and that any syntax that fell unde= r regname was fair game.=C2=A0 RFC 3986 says:
 This specification d=
oes not mandate a particular registered name
   lookup technology and therefore does not restrict the syntax of reg-
   name beyond what is necessary for interoperability.  Instead, it
   delegates the issue of registered name syntax conformance to the
   operating system of each application performing URI resolution, and
   that operating system decides what it will allow for the purpose of
   host identification.

But most approaches would upend every pars= er out there at the moment, which is a big, hairy deal.=C2=A0 We'd have= to be convinced that this was useful, deployable, and the right choice bef= ore we did that, and, perhaps more importantly, that the failures that woul= d inevitably occur would be limited to the new namespaces.=C2=A0

= =C2=A0=E2=80=8B
Another examples that occurs to me is the separate namespaces used in = XML with the xmlns attribute and appropriate prefixes before elements.=C2= =A0 But that's obviously within an XML *document* versus a network prot= ocol.

=E2=80=8B=E2=80= =8B
=E2=80=8B=E2=80=8B=E2=80=8B
And, most importa= ntly, which level of the problem do we think we can solve:=C2=A0 the multip= le namespaces one or the unitary namespace/multiple resolution contexts one= ?

I guess a more basic question is - are you suggesting we try to= solve this problem for ALL protocols? =C2=A0for just a select set of proto= cols (HTTP, HTTPS?)?=C2=A0 Or something else?


=E2=80=8BI think th= e nature of these names is that the ones that move from protocol context to= protocol context are the ones that present the real problem.=C2=A0 So I= 9;m not sure that the size of the ocean to be boiled can be restricted much= by limiting only to "successful, widely deployed protocols".=C2= =A0 But I'm certainly willing to listen if someone else has another way= forward here.

regards,

Ted=E2=80= =8B


=C2=A0
Dan

--
Dan York
Senior Content Strategist, Internet Socie= ty
Jabber:=C2=A0york@jabber.isoc.org=C2=A0
Skype: danyork =C2=A0=C2=A0http://twitter.com/danyork






--001a1139d3fcddfb1d052af5d729-- From nobody Thu Feb 4 11:44:47 2016 Return-Path: X-Original-To: arcing@ietfa.amsl.com Delivered-To: arcing@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979391ACE57 for ; Thu, 4 Feb 2016 11:44:45 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 NVkgufSZAx2n for ; Thu, 4 Feb 2016 11:44:42 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 C1B5A1ACE53 for ; Thu, 4 Feb 2016 11:44:41 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id y9so46071593qgd.3 for ; Thu, 04 Feb 2016 11:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9WmwAPuGTFXnGovaTSonbpmQx7SAq0LIv597jWsqbgQ=; b=QUHqoKPOtr9R8Wd3mWyWbsmmhv4agWxc9sJsNFrbYgtgVHUxw0uuqv1P3nUJrTAunY hvopNuikLBf7hmoI138bCud6ZqsrYeAcNySIp2sUJD9T18oJlInHurAGDu7chDoIJX7w f+CYlpPxQyBrINLFlTB9MM8VZ0dMMphhvhygtoU/3gSXWQDbhwbZmD43/55wS6+4u1Qr rbClslSjbRVU31Dw4lC2PvIMXsht3/WxIy6zNZQpsu85OUDnHQAQyU+B8HtbHjQ6rZeG YkBA4LjhNqSwLT8Zo3pPfGVTvjsSIpYZigtV88vQplVUrw1/LYTFEVzWF6RMKq2+ZRPN JSTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9WmwAPuGTFXnGovaTSonbpmQx7SAq0LIv597jWsqbgQ=; b=Y3HYCAyu3leK5zsJu0qwEgucOZb9yLDc+8K7MSEfxgeyApjKNZHuD4sK3ZaoHviTgD yAp5E23F265OqeGHjf+71T9Zst4cMcwMp8myeGQhMvqxQ8ghU5tBN03Qf9iQZl5ESmju AlisGodkGI32uEVd7nnRvIRsxKwN+R+97d4TQX1wZm54Roy4ws6IqGEDCOE4ujEw1Hkc VqZzNP+MOIIOgT8TbkcITdJNJQNMMhA6dL10VEUCItrM++9aWE3yAqaHip63ORqRr0Ca y4GRUL14Lq0qHLAVvpNNlM2VX9PtEkSTENZIiOMxE60tzymVJ5aflvj5NKW3Q9z6XF+B hKtQ== X-Gm-Message-State: AG10YOSZMiSg16gJ6gz6d6s6MFuXqyEH2gtvqnjw8/ErAMgOCtuJ9Y+aPbQf3Eegj5vGsslClSrwpkhBm84eHQ== X-Received: by 10.140.96.84 with SMTP id j78mr7246377qge.93.1454615080899; Thu, 04 Feb 2016 11:44:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Thu, 4 Feb 2016 11:44:20 -0800 (PST) In-Reply-To: <524E4EBB-DB02-4091-9F5D-14F103A81178@mnot.net> References: <524E4EBB-DB02-4091-9F5D-14F103A81178@mnot.net> From: Ted Hardie Date: Thu, 4 Feb 2016 11:44:20 -0800 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a113ab5442e9973052af6f7cd Archived-At: Cc: arcing@ietf.org Subject: Re: [Arcing] A bit more on the problem statement X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 19:44:45 -0000 --001a113ab5442e9973052af6f7cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howdy, Replies, but not necessarily answers, in-line. On Wed, Feb 3, 2016 at 6:55 PM, Mark Nottingham wrote: > Hi Ted, > > Trying to work through this, please be patient with my potentially limite= d > understanding / context. > > > > On 4 Feb 2016, at 5:56 am, Ted Hardie wrote: > > > > In the draft I posted on resolution contexts, I called the overarching > set of names "Internet names", following RFC 891. Clearly things have > moved on from then no little, but I wanted to get back to that terminolog= y > because I wanted to stress the internetworking aspect of the problem. > > > > For names or identifiers to be meaningful in multiple contexts (like > different networks or administrative domains), those contexts have to see > them as part of the same namespace. That doesn't mean that there must be > one unitary namespace for every use, but it does mean that each context > that uses a name must share the same idea of what the namespace context i= s. > > > > You can resolve that problem by having all names in a single namespace > context. You can also resolve that by having context markers. > > > > The issue with the first approach is that it is trivial for people to > mint new names. If those are presumed to be within a single context, tha= t > also means that it is trivial for those new names to conflict either with > each other or established names. The only available point of control we > have at the moment is in resolution using a specific set of resolution > protocols. > > > > That is, a policy body may decline to allow a particular name to be > resolved with the DNS, but anything that doesn't use that set of resoluti= on > protocols can still conflict. I don't personally see any way to create a > point of control on the minting of the names themselves without a complet= e > architectural re-write of the entire Internet, so I don't think we can > change the point of control. That leaves this approach with a pretty big > gap--any name that doesn't use the DNS as a resolution protocol is subjec= t > to squatting, collision, or confusion. > > > > The second approach, using context markers, is approximately where we > are today, but we are using an implicit set of context marker rather than > an explicit one. But we're not using it particularly well. As it stands= , > the context marker (pseudo-gTLDs) requires a priori knowledge to establis= h > resolution context > > If applications don't (somewhere) have the ability to perform resolution > in that context, they're not going to work anyway, and if they do, they > have the a priori knowledge necessary. > > =E2=80=8BSo, it doesn't have to be a priori. If there were a protocol sl= ot for resolution context, they could derive the context from that protocol slot; maybe that fails (without the knock-on effect you list below, since there is no default), maybe it doesn't (if the context given uses a protocol known to the resolution subsystem). Several of the systems have methods for determining how to resolve a name without a priori knowledge; they just haven't scaled to the full Internet scale.=E2=80=8B > So, I think the problem here is largely what we saw with .onion -- if you= r > application / resolver / etc. don't recognise it as a special name, it > falls back to DNS resolution, and that may have various undesirable side > effects (besides not working). > > Arguably the downsides of those side effects for .onion -- given its use > cases -- are pretty extreme, and so it's very interesting to me that > despite that limitation, its very privacy- and security-sensitive communi= ty > still decided to go in that direction. > > > > *and it doesn't allow you to mark namespaces that don't share the synta= x > of the DNS*. > > How big of a problem is this? There are issues with i18n and DNS names, o= f > course, but I don't hear people in this space saying that a big driver fo= r > them is "names that don't look like hostnames." There's a LOT of shared > understanding behind DNS-style names. > > =E2=80=8BThere is a lot of shared understanding behind hostname-style names= , but there are also names that don't work in that context because of label length restrictions or other DNS restrictions (names in ASCII distinguished by case etc.). > > > If what we want is a single Internet namespace, with a marker for which > resolution protocol is meant, this could be refined a bit to work. > > Are you thinking of something like a DNS record on the root zone of these > domains, so that resolvers can check to see if it's meant for them? > > =E2=80=8BWarren Kumari and Andrew Sullivan proposed a pseudo-TLD, alt, whic= h would function this way; names under .alt would indicate the resolution context in the delegations from .alt, and the names under that would use it ( draft-ietf-dnsop-alt-tld )=E2=80=8B. You c= ould also do this other ways (special prefix like the Punycode prefix, etc.). It partitions the single namespace into DNS context resolution and non-DNS context resolution, but it remains a unitary namespace other than that. > > But every single name delegation in any of the resolution contexts will > remain a source of potential collision, squatting or confusion, because w= e > still won't control the ability to mint names. > > I'm not sure how you got here, or why our (the IETF's?) control over the > ability to mint names is important here. Each resolution context is going > to need to control its own destiny (assuming it has a distinct name space > of its own, a la .onion .home etc.)... > > =E2=80=8BIf we get broad agreement to use a particular signal, like .alt, t= hen folks minting new namespaces in .alt can avoid collision with a simple FCFS registry. If everyone plays nice, there is no collision and you have no big issues. But we have no way of making that so, and we have seen in the pseudo-TLD case that people mint these, use them, and then require updates of others to deal with the collisions. Depending on the usage of .alt or a similar signal, that could remain a concern (at least version of the proposal had no registry at all, just the reserved top label). > > If we shift to an explicit set of markers, we get the following > advantages: we can use syntax different from the syntax of the DNS; we c= an > avoid collision at the level of the tuple of namespace, name; we can avoi= d > conflating resolution context and namespace. (Note that resolution conte= xt > is not a one-to-one mapping with protocol. As David Conrad has been > pointing out for years, having a cryptographically signed DNS root (or > other zone) means the distribution channel for the information can change= ; > the resolution context does not). > > > > The disadvantage is that every protocol that works across namespaces > must now be updated to recognize both the explicit markers and the > namespaces themselves. That's a lot of work and, as IPv6 taught us, the > network effects run against you the whole way. It may, however, be > something that is significantly easier to deploy incrementally than the > core IP layer is. > > I'm not really sure what direction you're thinking of going here, but I a= m > reminded somewhat of previous discussions to define how to transport > DNSSEC-signed records inside HTTP/2 frames, thereby establishing an > independent (albeit syntactically and semantically very similar) resoluti= on > protocol for the same context. That hasn't gone anywhere, but it's still > lurking out there as a possibility, AIUI. > > =E2=80=8BThat's a different protocol, but the same resolution context, at l= east in my view. If I sent a web server dns: URLs and it responded with the appropriate records, I am still get DNS resolution (and demonstrably correct resolution, with DNS=E2=80=8BSEC), just not using the DNS protocol.= That's the point I was making when I mentioned David Conrad's long history of comments on this topic. > > My first question to this group is: do folks agree with this > characterization? If not, what's wrong? > > > > If they do agree with the characterization of the problem, does this > sketch of solution spaces look right? > > > > And, most importantly, which level of the problem do we think we can > solve: the multiple namespaces one or the unitary namespace/multiple > resolution contexts one? > > > > regards, > > > > Ted > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > =E2=80=8Bregards, Ted=E2=80=8B --001a113ab5442e9973052af6f7cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

Replies, but not necessa= rily answers, in-line.

On Wed, Feb 3, 2016 at 6:55 PM, Mark Nottingham <mnot@mnot.n= et> wrote:
Hi Ted,

Trying to work through this, please be patient with my potentially limited = understanding / context.


> On 4 Feb 2016, at 5:56 am, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> In the draft I posted on resolution contexts, I called the overarching= set of names "Internet names", following RFC 891.=C2=A0 Clearly = things have moved on from then no little, but I wanted to get back to that = terminology because I wanted to stress the internetworking aspect of the pr= oblem.
>
> For names or identifiers to be meaningful in multiple contexts (like d= ifferent networks or administrative domains), those contexts have to see th= em as part of the same namespace.=C2=A0 That doesn't mean that there mu= st be one unitary namespace for every use, but it does mean that each conte= xt that uses a name must share the same idea of what the namespace context = is.
>
> You can resolve that problem by having all names in a single namespace= context.=C2=A0 You can also resolve that by having context markers.
>
> The issue with the first approach is that it is trivial for people to = mint new names.=C2=A0 If those are presumed to be within a single context, = that also means that it is trivial for those new names to conflict either w= ith each other or established names.=C2=A0 The only available point of cont= rol we have at the moment is in resolution using a specific set of resoluti= on protocols.
>
> That is, a policy body may decline to allow a particular name to be re= solved with the DNS, but anything that doesn't use that set of resoluti= on protocols can still conflict.=C2=A0 I don't personally see any way t= o create a point of control on the minting of the names themselves without = a complete architectural re-write of the entire Internet, so I don't th= ink we can change the point of control.=C2=A0 That leaves this approach wit= h a pretty big gap--any name that doesn't use the DNS as a resolution p= rotocol is subject to squatting, collision, or confusion.
>
> The second approach, using context markers, is approximately where we = are today, but we are using an implicit set of context marker rather than a= n explicit one.=C2=A0 But we're not using it particularly well.=C2=A0 A= s it stands, the context marker (pseudo-gTLDs) requires a priori knowledge = to establish resolution context

If applications don't (somewhere) have the ability to perform re= solution in that context, they're not going to work anyway, and if they= do, they have the a priori knowledge necessary.

=E2=80=8BSo, it doesn't have to be a prior= i.=C2=A0 If there were a protocol slot for resolution context, they could d= erive the context from that protocol slot; maybe that fails (without the kn= ock-on effect you list below, since there is no default), maybe it doesn= 9;t (if the context given uses a protocol known to the resolution subsystem= ).=C2=A0 Several of the systems have methods for determining how to resolve= a name without a priori knowledge; they just haven't scaled to the ful= l Internet scale.=E2=80=8B

=C2=A0
So, I think the problem here is largely what we saw with .onion -- if your = application / resolver / etc. don't recognise it as a special name, it = falls back to DNS resolution, and that may have various undesirable side ef= fects (besides not working).

Arguably the downsides of those side effects for .onion -- given its use ca= ses -- are pretty extreme, and so it's very interesting to me that desp= ite that limitation, its very privacy- and security-sensitive community sti= ll decided to go in that direction.


> *and it doesn't allow you to mark namespaces that don't share = the syntax of the DNS*.

How big of a problem is this? There are issues with i18n and DNS nam= es, of course, but I don't hear people in this space saying that a big = driver for them is "names that don't look like hostnames." Th= ere's a LOT of shared understanding behind DNS-style names.


=E2=80=8BThere is = a lot of shared understanding behind hostname-style names, but there are al= so names that don't work in that context because of label length restri= ctions or other DNS restrictions (names in ASCII distinguished by case etc.= ).

=C2=A0

> If what we want is a single Internet namespace, with a marker for whic= h resolution protocol is meant, this could be refined a bit to work.

Are you thinking of something like a DNS record on the root zone of = these domains, so that resolvers can check to see if it's meant for the= m?


=E2=80=8BWarren Ku= mari and Andrew Sullivan proposed a pseudo-TLD, alt, which would function t= his way; names under .alt would indicate the resolution context in the dele= gations from .alt, and the names under that would use it (draft-ietf-dnsop-alt-tld= )=E2=80=8B.=C2=A0 You could also do this other ways (special prefix lik= e the Punycode prefix, etc.).=C2=A0 It partitions the single namespace into= DNS context resolution and non-DNS context resolution, but it remains a un= itary namespace other than that.


> But every single name delegation in any of the resolution contexts wil= l remain a source of potential collision, squatting or confusion, because w= e still won't control the ability to mint names.

I'm not sure how you got here, or why our (the IETF's?) cont= rol over the ability to mint names is important here. Each resolution conte= xt is going to need to control its own destiny (assuming it has a distinct = name space of its own, a la .onion .home etc.)...


=E2=80=8BIf we get broad agreement to u= se a particular signal, like .alt, then folks minting new namespaces in .al= t can avoid collision with a simple FCFS registry.=C2=A0 If everyone plays = nice, there is no collision and you have no big issues.=C2=A0 But we have n= o way of making that so, and we have seen in the pseudo-TLD case that peopl= e mint these, use them, and then require updates of others to deal with the= collisions.=C2=A0 Depending on the usage of .alt or a similar signal, that= could remain a concern (at least version of the proposal had no registry a= t all, just the reserved top label).

=C2=A0
> If we shift to an explicit set of markers, we get the following advant= ages:=C2=A0 we can use syntax different from the syntax of the DNS; we can = avoid collision at the level of the tuple of namespace, name; we can avoid = conflating resolution context and namespace.=C2=A0 (Note that resolution co= ntext is not a one-to-one mapping with protocol.=C2=A0 As David Conrad has = been pointing out for years, having a cryptographically signed DNS root (or= other zone) means the distribution channel for the information can change;= the resolution context does not).
>
> The disadvantage is that every protocol that works across namespaces m= ust now be updated to recognize both the explicit markers and the namespace= s themselves.=C2=A0 That's a lot of work and, as IPv6 taught us, the ne= twork effects run against you the whole way.=C2=A0 It may, however, be some= thing that is significantly easier to deploy incrementally than the core IP= layer is.

I'm not really sure what direction you're thinking of going = here, but I am reminded somewhat of previous discussions to define how to t= ransport DNSSEC-signed records inside HTTP/2 frames, thereby establishing a= n independent (albeit syntactically and semantically very similar) resoluti= on protocol for the same context. That hasn't gone anywhere, but it'= ;s still lurking out there as a possibility, AIUI.


=E2=80=8BThat'= s a different protocol, but the same resolution context, at least in my vie= w.=C2=A0 If I sent a web server dns: URLs and it responded with the appropr= iate records, I am still get DNS resolution (and demonstrably correct resol= ution, with DNS=E2=80=8BSEC), just not using the DNS protocol.=C2=A0 That&#= 39;s the point I was making when I mentioned David Conrad's long histor= y of comments on this topic.


> My first question to this group is:=C2=A0 do folks agree with this cha= racterization?=C2=A0 If not, what's wrong?
>
> If they do agree with the characterization of the problem, does this s= ketch of solution spaces look right?
>
> And, most importantly, which level of the problem do we think we can s= olve:=C2=A0 the multiple namespaces one or the unitary namespace/multiple r= esolution contexts one?
>
> regards,
>
> Ted

Cheers,

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

=E2=80=8Bregards,

Ted=E2=80= =8B

--001a113ab5442e9973052af6f7cd-- From nobody Thu Feb 4 15:00:09 2016 Return-Path: X-Original-To: arcing@ietfa.amsl.com Delivered-To: arcing@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E491B338D for ; Thu, 4 Feb 2016 15:00:07 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 3EL5dJDe_UiI for ; Thu, 4 Feb 2016 15:00:06 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 EA6901B338B for ; Thu, 4 Feb 2016 15:00:05 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id o185so57292309pfb.1 for ; Thu, 04 Feb 2016 15:00:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=+eN/A0xxr3WPfYEZjoz8gGPTIllpB0+uuvLk8mYy1zQ=; b=hQs8pw/qtzFXXWd1vXEY9djp4BlrPmP8zZygoKWYxjN71gvzOi4ibfS/lfRepU3Pv3 cbSmWH7F6VIu7aIuKeuNLIZm5oahbE/m6eQzN0k8qdW7UPrtu7GdY9ZHyqg4N8Vhb0f7 2/juVgur4j7nsM+7P1irnDIQKPGDvtFhi4heLU4L9iPPz/2VWWCjkY5uM/SmGC7A3ZE0 e8qUoxNvV8OLNKb1HZD85vJ2zz4cncT+a3skkmJIF1ti9SAn5b7U+LZfYp7XRtwWB4wD 7UH7IIBPhkOLQmpHEohOfwk2/brM7HMbVkj7oJX1z6F+SL0NJ6xNbJfG6uV8S/Vg0ij2 hfIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=+eN/A0xxr3WPfYEZjoz8gGPTIllpB0+uuvLk8mYy1zQ=; b=E3LHNfoQ9E7/LPrgxU4ku2/Reh4MkuhwYAdzcPqeMp88G94wXS/JA99+aCDhQKfJzf 2uV4UO6SYUqSB06uHyMO7zgCs8KU+FFRdz9WO8nvYm9y44X0V4dmoNPTL7OWn+fhetGq WXz1vDYDxGtKDEJKHyufalgDsPh7Blig/MWa2kOZYnBKfHg0tVhxoGdNLrldIUZLBUrP p6hUYRDq8EkJqlj/3+XxPpA6YBWwxC5bh/zX13VrZuD+5ZhqNTF3F55IM7MrcrX+kG9n ucPLhODcL8yin+5A7rM1Tyrb5rPJjR+49G7QxnwpifOkN7ekhXJmE8MGhADb3s+OjfjH J+7A== X-Gm-Message-State: AG10YOQ3OWiFP+yZi0FWMBd9LqQIm9dT6qQzzidYOa3vEsfPITQ8HxpOujL5QGrQwvOI4A== X-Received: by 10.98.70.139 with SMTP id o11mr15048183pfi.123.1454626805629; Thu, 04 Feb 2016 15:00:05 -0800 (PST) Received: from US-DOUGO-MAC.local (c-24-6-60-244.hsd1.ca.comcast.net. [24.6.60.244]) by smtp.googlemail.com with ESMTPSA id h89sm15157735pfj.52.2016.02.04.15.00.04 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 15:00:04 -0800 (PST) To: arcing@ietf.org References: <524E4EBB-DB02-4091-9F5D-14F103A81178@mnot.net> From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <56B3D81C.9050609@gmail.com> Date: Thu, 4 Feb 2016 15:00:44 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Arcing] A bit more on the problem statement X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 23:00:08 -0000 On 2/4/16 11:44 AM, Ted Hardie wrote: > If we get broad agreement to use a particular signal, > like .alt, then folks minting new namespaces in .alt can > avoid collision with a simple FCFS registry. If everyone > plays nice, there is no collision and you have no big > issues. But we have no way of making that so, and we > have seen in the pseudo-TLD case that people mint these, > use them, and then require updates of others to deal with > the collisions. Depending on the usage of .alt or a > similar signal, that could remain a concern (at least > version of the proposal had no registry at all, just the > reserved top label). Dear Ted, Why assume .home should be converted to .home.alt? Is this to ensure .alt gains inertia with its namespace containing definitions similar to those found with https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02? Open-ended FCFS registration will encourage an explosion of variant namespaces having any number of resolution methods and context. It seems safer to keep .home as defined by draft-cheshire-homenet-dot-home-02, and let .alt develop independently. In the goodness of time resource assessments and related risks assessments can then be made. Small home CPE devices offer limited storage and need simplistic access methods to limit vulnerabilities and coding complexity. As such, offering a highly extensible resolution structure as a first step seems ill considered. Otherwise, assessing security risks will provide resulting extensibility APIs likely to make Java and Flash defense seem trivial in comparison and will do nothing to limit the leakage of .home. Regards, Douglas Otis From nobody Thu Feb 4 15:12:55 2016 Return-Path: X-Original-To: arcing@ietfa.amsl.com Delivered-To: arcing@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FEF1B339A for ; Thu, 4 Feb 2016 15:12:53 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 uYjK0l53tYwm for ; Thu, 4 Feb 2016 15:12:51 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 9EAA81B3385 for ; Thu, 4 Feb 2016 15:12:51 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id o6so27874916qkc.2 for ; Thu, 04 Feb 2016 15:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=03shqFAtWuM0rdcuQr5G/XgtJsPnTM9tB0JNiN3DtZU=; b=YtJXD3PH0X0qQuZE5RLrWr1GdRMT0w/sThnrj+ioErQ98LLhcB3jT1gdCyh08ZjWPY 8KE/iWrpWmXC6rPRa1JEcPCP0TB+8LHFJncLWZqGKLym6stH62XfHMJnFIwuPGsyQ3GX 4Z/DBolchssjTTZCSwf0YOBkfDyqbvjXoTqhJx6b3jqenZZAe8wfyf0oVHW243cYUQpG Phc01NbeeHff1Pl4spY121QaA6pZIwE+BW6tvE1msqBh5wZkrlZ9y5nk11HRMsTjVv4j qOIvJlP26afKUeyQxrqv7H6LTzKxvCvmImWDUl8vy4djRypHz8JJ/g4ylz1mvXRzfA+z cYaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=03shqFAtWuM0rdcuQr5G/XgtJsPnTM9tB0JNiN3DtZU=; b=cqAqFskMUywzoSVRx/0H71bmG8S9tpqcv+2sApU6HmGxYAclEPUvcWkRGPcQ631g6L BYCWzscNJS5wF/iyYyYkTu6onZvp49GyhmLwo0YmYy+w65PaDzY4MNbuUeTXPX7ARn5Z DX8HiZoU6d0Yg+X2dPFp7La8MZFRR3nTRct5h82oyQtGuudjgJvj6hC7RjCAg2AkB/09 KOmR7KZrP6mkXqmX/NUhMIKwFtICkilsBWFmHmuTGWcDzeMUueNfc9ASY7M7avwOc57s cOJTOVRv3YK4cTV7ajqiByKbhAbqLMIRPUdc0Fj8uoZnSFHkTEHNJx6L+tbDp2Yo3Kz0 dXpA== X-Gm-Message-State: AG10YOR2sVR2kStwLYUq7pJkM92n4t+AMm1YUDlyYLJnvi5MgmuJo9Wck87UEWZ1+IwkJSDfpl8WiYSbf0/0Yg== X-Received: by 10.55.71.66 with SMTP id u63mr12428293qka.67.1454627570837; Thu, 04 Feb 2016 15:12:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Thu, 4 Feb 2016 15:12:31 -0800 (PST) In-Reply-To: <56B3D81C.9050609@gmail.com> References: <524E4EBB-DB02-4091-9F5D-14F103A81178@mnot.net> <56B3D81C.9050609@gmail.com> From: Ted Hardie Date: Thu, 4 Feb 2016 15:12:31 -0800 Message-ID: To: Douglas Otis Content-Type: multipart/alternative; boundary=001a114a7974a3f066052af9dfa8 Archived-At: Cc: arcing@ietf.org Subject: Re: [Arcing] A bit more on the problem statement X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 23:12:54 -0000 --001a114a7974a3f066052af9dfa8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 4, 2016 at 3:00 PM, Douglas Otis wrote: > > On 2/4/16 11:44 AM, Ted Hardie wrote: > > If we get broad agreement to use a particular signal, > > like .alt, then folks minting new namespaces in .alt can > > avoid collision with a simple FCFS registry. If everyone > > plays nice, there is no collision and you have no big > > issues. But we have no way of making that so, and we > > have seen in the pseudo-TLD case that people mint these, > > use them, and then require updates of others to deal with > > the collisions. Depending on the usage of .alt or a > > similar signal, that could remain a concern (at least > > version of the proposal had no registry at all, just the > > reserved top label). > > Dear Ted, > > Why assume .home should be converted to .home.alt? Is this > to ensure .alt gains inertia with its namespace containing > definitions similar to those found with > https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02? > > =E2=80=8BFor what it is worth, I think you missed the fact I was citing someone else's work, not advocating .alt myself. That said, I believe the draft you cite has a method that covers this: =E2=80=8B > Open-ended FCFS registration will encourage an explosion of > variant namespaces having any number of resolution methods > and context. It seems safer to keep .home as defined by > draft-cheshire-homenet-dot-home-02, and let .alt develop > independently. In the goodness of time resource assessments > and related risks assessments can then be made. > > Small home CPE devices offer limited storage and need > simplistic access methods to limit vulnerabilities and > coding complexity. As such, offering a highly extensible > resolution structure as a first step seems ill considered. > Otherwise, assessing security risks will provide resulting > extensibility APIs likely to make Java and Flash defense > seem trivial in comparison and will do nothing to limit the > leakage of .home. > > Regards, > Douglas Otis > > > > _______________________________________________ > Arcing mailing list > Arcing@ietf.org > https://www.ietf.org/mailman/listinfo/arcing > --001a114a7974a3f066052af9dfa8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 4, 2016 at 3:00 PM,= Douglas Otis <doug.mtview@gmail.com> wrote:

On 2/4/16 11:44 AM, Ted Hardie wrote:
> If we get broad agreement to use a particular signal,
> like .alt, then folks minting new namespaces in .alt can
> avoid collision with a simple FCFS registry.=C2=A0 If everyone
> plays nice, there is no collision and you have no big
> issues.=C2=A0 But we have no way of making that so, and we
> have seen in the pseudo-TLD case that people mint these,
> use them, and then require updates of others to deal with
> the collisions.=C2=A0 Depending on the usage of .alt or a
> similar signal, that could remain a concern (at least
> version of the proposal had no registry at all, just the
> reserved top label).

Dear Ted,

Why assume .home should be converted to .home.alt? Is this
to ensure .alt gains inertia with its namespace containing
definitions similar to those found with
https://tools.ietf.org/html/draft-ches= hire-homenet-dot-home-02?


=E2=80=8BFor what it is worth, I think you= missed the fact I was citing
someone else's work, no= t advocating .alt myself.=C2=A0 That said,
I believe the dr= aft you cite has a method that covers this:
=E2=80=8B


=C2= =A0
Open-ended FCFS registration will encourage an explosion of
variant namespaces having any number of resolution methods
and context. It seems safer to keep .home as defined by
draft-cheshire-homenet-dot-home-02, and let .alt develop
independently. In the goodness of time resource assessments
and related risks assessments can then be made.

Small home CPE devices offer limited storage and need
simplistic access methods to limit vulnerabilities and
coding complexity. As such, offering a highly extensible
resolution structure as a first step seems ill considered.
Otherwise, assessing security risks will provide resulting
extensibility APIs likely to make Java and Flash defense
seem trivial in comparison and will do nothing to limit the
leakage of .home.

Regards,
Douglas Otis



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

--001a114a7974a3f066052af9dfa8-- From nobody Thu Feb 4 15:16:04 2016 Return-Path: X-Original-To: arcing@ietfa.amsl.com Delivered-To: arcing@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BC81B33C8 for ; Thu, 4 Feb 2016 15:16:02 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 juhtYt9ppBAW for ; Thu, 4 Feb 2016 15:16:00 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076BD1B33C6 for ; Thu, 4 Feb 2016 15:16:00 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id x1so27763346qkc.1 for ; Thu, 04 Feb 2016 15:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3kaRbnHuiHc/m5wSWylph7iPR/aHlX/JFV0NBUzVyJE=; b=FRFc4hXfiW/FS90koAshrPlwdCr5aM3BBoSPtZTjelFy4AfwXVhVmkrst8bd/RpKpo qbCmes/vv1fcGw4sX/UOdg8sM9tdtVVLDhy19zcGbDeEhyt9gPWInaDbu3fcjgbaPlWw pZflQLk1gwllWK2lbSXaywC9Img5a0xOpO9+x+HjGRLJMnnZvMuoa5EvTyOYWmeRfLkA ZCSuhbR9ChXe/AAF2FfN44l6AwHFtqTE9El0IeVzHu6YWcx+ctXVUKqNc8MiMmgjgfQk TO/l7qe6UBqCTfMs6u25C+khzvYZtIgyPZNLX64SwQEGVBWk2saMJTycOYkUWwqxdBpL 4eDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3kaRbnHuiHc/m5wSWylph7iPR/aHlX/JFV0NBUzVyJE=; b=GO0yvKBRAmjS+Ye8YPE/ZNYHlsChlOO2uSBYVkAsTlxCzyZwGhXrUjIYnK2/We/6Ht v2NSs3ZqHIsUPg+rUX/66EyfacGmoduZdXfIsFIdGhvmh3hxMxLZlllTDEdZHxUS3scs WvLbfRcBgmwrgJAF5/NYXTh2T3FHuYGXlOz7srD7Mq2pdacK6kIeuwdCY//m6U6XxLca Vht/YiV9A5uS2BKB8GazmBTGQXASGzTTk9IrpCKhz9lFO6DoZEC9Wn391ilJ9dGF027q Eeep2YU2q9t+bgATqcO0hlez7t0U7VvJlp7D7zI+MoWqIqravL3Tj+zwhIgDrTneO7nC kqhA== X-Gm-Message-State: AG10YOTnikyPlRIK3P+sTiHNPlI35hilkXvRKUX8SHuxFHbxhq59uRUyWoN2wFsod/AeSJG2Qa2WUXHvzxlMmA== X-Received: by 10.55.71.66 with SMTP id u63mr12444577qka.67.1454627759215; Thu, 04 Feb 2016 15:15:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Thu, 4 Feb 2016 15:15:39 -0800 (PST) In-Reply-To: References: <524E4EBB-DB02-4091-9F5D-14F103A81178@mnot.net> <56B3D81C.9050609@gmail.com> From: Ted Hardie Date: Thu, 4 Feb 2016 15:15:39 -0800 Message-ID: To: Douglas Otis Content-Type: multipart/alternative; boundary=001a114a7974de5b45052af9ea20 Archived-At: Cc: arcing@ietf.org Subject: Re: [Arcing] A bit more on the problem statement X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 23:16:02 -0000 --001a114a7974de5b45052af9ea20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, I mis-licked and this went out early. On Thu, Feb 4, 2016 at 3:12 PM, Ted Hardie wrote: > On Thu, Feb 4, 2016 at 3:00 PM, Douglas Otis > wrote: > >> >> On 2/4/16 11:44 AM, Ted Hardie wrote: >> > If we get broad agreement to use a particular signal, >> > like .alt, then folks minting new namespaces in .alt can >> > avoid collision with a simple FCFS registry. If everyone >> > plays nice, there is no collision and you have no big >> > issues. But we have no way of making that so, and we >> > have seen in the pseudo-TLD case that people mint these, >> > use them, and then require updates of others to deal with >> > the collisions. Depending on the usage of .alt or a >> > similar signal, that could remain a concern (at least >> > version of the proposal had no registry at all, just the >> > reserved top label). >> >> Dear Ted, >> >> Why assume .home should be converted to .home.alt? Is this >> to ensure .alt gains inertia with its namespace containing >> definitions similar to those found with >> https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02? >> >> > =E2=80=8BFor what it is worth, I think you missed the fact I was citing > someone else's work, not advocating .alt myself. That said, > I believe the draft you cite has a method that covers this: > =E2=80=8B For residential home networks, Zero Configuration [ZC ] operation is desirable, without requiring any manual configuration from the user. A client device learns about its network environment in a variety of ways. It builds a list of network-recommended DNS search domains using DHCP options 15 (Domain Name option [RFC2132 ]) and 119 (Domain Search option [RFC3397 ]). It builds a list of network-recommended DNS-SD browsing domains by sending domain enumeration queries [RFC6763 ]. =E2=80=8B > > Open-ended FCFS registration will encourage an explosion of >> variant namespaces having any number of resolution methods >> and context. > > =E2=80=8BThis is possible, but unless these are deemed a valuable commodity= , it seems somewhat unlikely. Registry policy can certainly be tweaked to "expert review" or something so that a dictionary attack on .alt fails. But that's a good bit further along than we are. regards, Ted=E2=80=8B > It seems safer to keep .home as defined by >> draft-cheshire-homenet-dot-home-02, and let .alt develop >> independently. In the goodness of time resource assessments >> and related risks assessments can then be made. >> >> > Small home CPE devices offer limited storage and need >> simplistic access methods to limit vulnerabilities and >> coding complexity. As such, offering a highly extensible >> resolution structure as a first step seems ill considered. >> Otherwise, assessing security risks will provide resulting >> extensibility APIs likely to make Java and Flash defense >> seem trivial in comparison and will do nothing to limit the >> leakage of .home. >> >> Regards, >> Douglas Otis >> >> >> >> _______________________________________________ >> Arcing mailing list >> Arcing@ietf.org >> https://www.ietf.org/mailman/listinfo/arcing >> > > --001a114a7974de5b45052af9ea20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, I mis-licked and this went out early.

On Thu, Feb 4,= 2016 at 3:12 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Thu, Feb 4, 2016 at 3:00 PM, Dougla= s Otis <doug.mtview@gmail.com> wrote:

On 2/4/16 11:44 AM, Ted Hardie wrote:
> If we get broad agreement to use a particular signal,
> like .alt, then folks minting new namespaces in .alt can
> avoid collision with a simple FCFS registry.=C2=A0 If everyone
> plays nice, there is no collision and you have no big
> issues.=C2=A0 But we have no way of making that so, and we
> have seen in the pseudo-TLD case that people mint these,
> use them, and then require updates of others to deal with
> the collisions.=C2=A0 Depending on the usage of .alt or a
> similar signal, that could remain a concern (at least
> version of the proposal had no registry at all, just the
> reserved top label).

Dear Ted,

Why assume .home should be converted to .home.alt? Is this
to ensure .alt gains inertia with its namespace containing
definitions similar to those found with
https://tools.ietf.org/html/draft-ches= hire-homenet-dot-home-02?


=E2=80=8BFor what it is worth, I think you missed the fact = I was citing
someone else's work, not advocating .alt myself.=C2=A0 That said,<= br>
I believ= e the draft you cite has a method that covers this:
=E2=80=8B
   For residential h=
ome networks, Zero Configuration [ZC] operation is
   desirable, without requiring any manual configuration from the user.
   A client device learns about its network environment in a variety of
   ways.  It builds a list of network-recommended DNS search domains
   using DHCP options 15 (Domain Name option [RFC2132]) and 119 (Domain
   Search option [RFC6763].
=E2=80=8B

Open-ended FCFS registration will encourage an explosion of
variant namespaces having any number of resolution methods
and context.

=E2=80=8BThis is possible, but unless these are deemed a valuable comm= odity,
it seems somewhat unlikely.=C2=A0 Registry policy ca= n certainly be tweaked
to "expert review" or some= thing so that a dictionary attack on .alt
fails.

But that's a good bit further along than we are.

regards,

Ted=E2=80=8B

=C2=A0
It seems safer to keep .home as defined= by
draft-cheshire-homenet-dot-home-02, and let .alt develop
independently. In the goodness of time resource assessments
and related risks assessments can then be made.



=C2=A0<= /div>
Small home CPE devices offer limited storage and need
simplistic access methods to limit vulnerabilities and
coding complexity. As such, offering a highly extensible
resolution structure as a first step seems ill considered.
Otherwise, assessing security risks will provide resulting
extensibility APIs likely to make Java and Flash defense
seem trivial in comparison and will do nothing to limit the
leakage of .home.

Regards,
Douglas Otis



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


--001a114a7974de5b45052af9ea20-- From nobody Thu Feb 4 20:39:40 2016 Return-Path: X-Original-To: arcing@ietfa.amsl.com Delivered-To: arcing@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665981B34FA for ; Thu, 4 Feb 2016 20:39:39 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 2JX042YQd5Vo for ; Thu, 4 Feb 2016 20:39:37 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 918EB1B34FB for ; Thu, 4 Feb 2016 20:39:37 -0800 (PST) Received: by mail-pa0-x236.google.com with SMTP id ho8so27426906pac.2 for ; Thu, 04 Feb 2016 20:39:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=+5/EwDAm3jjqytZ6zniCQwrecJ1+/Lhygz1nCxBFD9M=; b=PckUKE/xfyiX213iTAJYcUctKtVn76ts08CmSw4vrPfTgmBJymcgz1KESdrXvyLtOh utrG82zbHvsdXzjm0oXTggU8KUAoDWJk+Uquas/CBxtPp3Qxm+08FHxloZZyH4FG7YCA Q/5heP3ewKCikUBdnI0A92b+qXe+zFrHMQt/P3EcPXu1n8uXpuTRWfJ6bNn9aNvwCOBs 8zAA3u+gtaT3fiUWVnax4m3Qg0ViGKQH4++MCeujhrfMYREEf2eDn6JBtj1Sn7DnTJE0 8mF9lDS9RqeZrc/OgpIiW0GcNNhmw82YlmhCFaRsCQffhjrs7XJ2Z+Fj8NatdKU2KKWU E9Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=+5/EwDAm3jjqytZ6zniCQwrecJ1+/Lhygz1nCxBFD9M=; b=irCuLl9oWuBJqBd1YVlwCJ4vYs8iCasK/mlj2e8T518sBSPxI+Z+iZ7uwSEufeKbKC DsYooL5m9CFYGNGyvA7isTzkqwj1uS1If3WO2/Q8OVKIzIpYTMFM4yjuh1K3rWQ1l2pt vbxrfhdXxP0A7joKT+2p82dtqAZ4oX4KuvVHwWXxFoyNL0fgC5DxH6By6TVMporUHbvh mme1KxA6vrs/EBDDSfZLh+4lFBPJSNmeuRR6rhEh8ODGqxd8xDMm2BCCDlNnrK2GUzkm 0OWtLLvszTkvRxyTxzrFNSwpSkL0IXn8X7c3AtKmG8Etu4daqJJzvM0uAMWud/cRsCPe kG6g== X-Gm-Message-State: AG10YOTr7JT51vT47bpc6JcIuuiYpwgUvwhTE/3yUTKctgnYF6LPchgor/B/R0DWF4OqGg== X-Received: by 10.66.90.133 with SMTP id bw5mr16743131pab.22.1454647177255; Thu, 04 Feb 2016 20:39:37 -0800 (PST) Received: from US-DOUGO-MAC.local (c-76-21-122-217.hsd1.ca.comcast.net. [76.21.122.217]) by smtp.googlemail.com with ESMTPSA id z3sm20641979par.17.2016.02.04.20.39.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 20:39:36 -0800 (PST) To: Ted Hardie References: <524E4EBB-DB02-4091-9F5D-14F103A81178@mnot.net> <56B3D81C.9050609@gmail.com> From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <56B427FD.8050400@gmail.com> Date: Thu, 4 Feb 2016 20:41:33 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: arcing@ietf.org Subject: Re: [Arcing] A bit more on the problem statement X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 04:39:39 -0000 On 2/4/16 3:15 PM, Ted Hardie wrote: > For what it is worth, I think you missed the fact I was > citing someone else's work, not advocating .alt myself. > That said, I believe the draft you cite has a method that > covers this: Dear Ted, The draft https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02 describes a Special-Use domain but it does not overcome the need for a domain. There are no valid justifications not to allow .home as a Special-Use domain. Homenet protocols require a domain to publish DNS-SD resources to avoid multicast normally blocked by typical router bridges. To avoid multicast, DNS-SD resources must not be published below the Special-Use domain .local. Unfortunately, there are no Special-Use local non-multicast defined domains where access can be safely constrained. The alternative use of an Internet domain necessitates administration of services exposed to the Internet. Such exposure will necessitate far greater resources defending against Internet access. Such increased exposure may also cause private and possibly critical resources needed locally to become compromised or made inaccessible. >> Open-ended FCFS registration will encourage an >> explosion of variant namespaces having any number of >> resolution methods and context. > > ​This is possible, but unless these are deemed a valuable > commodity, it seems somewhat unlikely. Registry policy > can certainly be tweaked to "expert review" or something > so that a dictionary attack on .alt fails. Why impose the burden of needing to support public domains on home networks as an aspect of an array of .alt definitions? A direct singular definition prefaced at the outset as offering only a private namespace greatly simplifies and advances homenet development. This is not advocating for a new TLD. Rather this is advocating for the elimination of a Special-Use TLD from DNS altogether to simplify much needed protection of information. Regards, Douglas Otis From nobody Sat Feb 13 12:31:40 2016 Return-Path: X-Original-To: arcing@ietfa.amsl.com Delivered-To: arcing@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D511A70FD for ; Sat, 13 Feb 2016 12:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 QigZdPMQe2gA for ; Sat, 13 Feb 2016 12:31:37 -0800 (PST) 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 9A9AF1A7034 for ; Sat, 13 Feb 2016 12:31:37 -0800 (PST) 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.1130.7; Sat, 13 Feb 2016 12:31:34 -0800 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.1130.005; Sat, 13 Feb 2016 12:31:34 -0800 From: Edward Lewis To: "arcing@ietf.org" Thread-Topic: [Arcing] A bit more on the problem statement Thread-Index: AQHRXrSospMxlWD/SE6NYkDkHw/LNp8qfaAA Date: Sat, 13 Feb 2016 20:31:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.236] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3538211490_34123425" MIME-Version: 1.0 Archived-At: Cc: Ted Hardie Subject: Re: [Arcing] A bit more on the problem statement X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 20:31:39 -0000 --B_3538211490_34123425 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Replying to this, having at least skimmed, if not read the followups... On 2/3/16, 13:56, "Arcing on behalf of Ted Hardie" wrote: >My first question to this group is: do folks agree with this >characterization? If not, what's wrong? I agree fully, FWIW. >If they do agree with the characterization of the problem, does this >sketch of solution spaces look right? Yep. >And, most importantly, which level of the problem do we think we can >solve: the multiple namespaces one or the unitary namespace/multiple >resolution contexts one? One solution is to define a single namespace, complimentary to as much de-jure use that now exists. Defining what protocols "support" the namespace can be left to the protocol's discretion. What I mean is, I tried for a while to define the scope of protocols that I wanted to have Domain Names apply to, but calling the set something like "IETF protocols" turned out to be inaccurate. So I began to think of - just define a name space and see what protocols "come" to it. There's a lot to discuss. I think markers approach is currently the most appealing, but, you never can tell at this stage. --B_3538211490_34123425 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRUtoF35Wg93VQZDoTA 18J2xYgUxDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAy MTMyMDMxMzBaMA0GCSqGSIb3DQEBAQUABIIBAFtPB/tE/gF61kmU27ZmLTNOfbenUST8Bb9y XJbZlS9DlglBsDdt/6OkM6SBM03h47A8NgIt3q/XfjNoAd5ZwpFnpMD6Pq95OSB3Ba8f1K+T R7Q5SeQnIXmb9bJIw/U2Eny1x2wTF4CA9kv5pR7rxOscqFQ0ozjF8ZJ+YZav0xvcDeWhsFaS mI+5FuPjJrS4lJzyM9cP9PJSN+Y+vWfFKOU51yQPIwJOVrjVVRMudmfsRaIp5Wii+nOMJ/3y zuKwzkwY8+nhTjR1vOBnReEzh//srMXsR8GmcIJLgUBOdRLlnocfH4jHnJ3xQNdeG3pk3W/O pOqFZ/XYV5YSWQphaOU= --B_3538211490_34123425-- From nobody Fri Feb 19 16:21:55 2016 Return-Path: X-Original-To: arcing@ietfa.amsl.com Delivered-To: arcing@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E521ACE2C for ; Fri, 19 Feb 2016 16:21:53 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 z7zzxMLMTX76 for ; Fri, 19 Feb 2016 16:21:52 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 AB99C1B2D51 for ; Fri, 19 Feb 2016 16:21:51 -0800 (PST) Received: by mail-ob0-x22d.google.com with SMTP id xk3so124884652obc.2 for ; Fri, 19 Feb 2016 16:21:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=nLdcz1S9Nd+w1WBvcYPQkes8ZAiPpBZU3DizOIJNNYs=; b=1DKvZ5/vscjV0kFquS9SF/Zkel0tPGiXLAlqIWJXvqA72a/MJrQA/S6A+fNWXWQ464 x7FCDaorKIcPeFhBB7qAEklycnYnV6A4VtMiRXuFEXsKT0JvhwD/joXZaioj/dHALW40 pSCX/ssMXPTWEJ72puZFCgtlx5RRx/jQ95QAS5qD6pi98rOn9t1jPH5i71c3+zx8KPct c6ezc69Yhvl5s3BYLabqjg7ymCbNzKcco97amDMME1uncr/LWMLp0YejsyaiLXltdpNV yf4Dr3LzyM+PMroNtUu85qoGPMXeCq1qwLkadxiGVjazZPCaB9P5wFnVkGIKP+6UpnL9 Y+Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=nLdcz1S9Nd+w1WBvcYPQkes8ZAiPpBZU3DizOIJNNYs=; b=EgxZ0OyzsaEenrJyf1ED0GGgwdyTvfemUzI9Lvcoi8sNwyJR4vLJfiFiFMguz9xxeh 3JrDX3Q6+iEtNf0L/8FlYzvvTzwuQIuY+efI/bjUl27iMKNAag3UmRPcPI58XZN414/U wJZf6o4Igol0MUBHP9YXTi1o9pDq0bkflmqVsG/nwFmwTWmoH/s3aVZHlb4tJmpzD5n0 8asJqLPCwtQJFESWvlH9un8ufiF3cJhk/OmoCzQo1UvXcc2KhStJM7s0m2OZZ1W4wMHx SKjL0hTshmUg7g+S458LC2VvXlVhaNncy/6Dukp7LpOgqS3fb/FdFIxiFo/WajwGw+5T hGCg== X-Gm-Message-State: AG10YOT9mC5utzU32o3RTo6soNTPhuZcNItLLuZdecuH8raR0ckbw/2iW7erPEV6UkJeag== X-Received: by 10.60.97.233 with SMTP id ed9mr13794851oeb.17.1455927710956; Fri, 19 Feb 2016 16:21:50 -0800 (PST) Received: from US-DOUGO-MAC.local ([2601:647:4280:238b:acd2:2449:3d16:7bff]) by smtp.googlemail.com with ESMTPSA id k5sm8724925oed.1.2016.02.19.16.21.49 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Feb 2016 16:21:50 -0800 (PST) To: arcing@ietf.org References: From: Douglas Otis X-Enigmail-Draft-Status: N1110 Message-ID: <56C7B243.3020004@gmail.com> Date: Fri, 19 Feb 2016 16:24:35 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Arcing] A bit more on the problem statement X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 00:21:53 -0000 On 2/13/16 12:31 PM, Edward Lewis wrote: > Replying to this, having at least skimmed, if not read > the followups... > > On 2/3/16, 13:56, "Arcing on behalf of Ted Hardie" > > wrote: > > >> My first question to this group is: do folks agree >> with this characterization? If not, what's wrong? > > I agree fully, FWIW. > >> If they do agree with the characterization of the >> problem, does this sketch of solution spaces look >> right? > > Yep. > >> And, most importantly, which level of the problem do we >> think we can solve: the multiple namespaces one or the >> unitary namespace/multiple resolution contexts one? > > One solution is to define a single namespace, > complimentary to as much de-jure use that now exists. > Defining what protocols "support" the namespace can be > left to the protocol's discretion. What I mean is, I > tried for a while to define the scope of protocols that I > wanted to have Domain Names apply to, but calling the set > something like "IETF protocols" turned out to be > inaccurate. So I began to think of - just define a name > space and see what protocols "come" to it. > > There's a lot to discuss. I think markers approach is > currently the most appealing, but, you never can tell at > this stage. Dear Edward, This is likely my last comment. Developing a grand scheme to identify how future namespace resolution is to be handled should be balanced against the specific solution of a non-global .home TLD offering a concise and safe method made available early in the homenet process as a means to avoid delay and security risks incumbent with any future grand multipurpose scheme. Homenet offers homes multi-router environments based on IPv6 with services found using DNS-SD. In nearly every possible deployment of typical home networks generally lacking key security components, publishing DNS-SD within global DNS namespace will expose a tremendous level of device vulnerabilities likely to include those discovered over the last few years or more. Don't insist adoption of draft-cheshire-homenet-dot-home-02 must follow some grander scheme that might make use of an alternate root or URL modification. Any such approach doubtlessly precludes essential compatibilities needing consideration for Homenet deployment. Regards, Douglas Otis From nobody Fri Feb 19 18:44:02 2016 Return-Path: X-Original-To: arcing@ietfa.amsl.com Delivered-To: arcing@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657DB1B37DA for ; Fri, 19 Feb 2016 18:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 IWI9nRpk9V_Z for ; Fri, 19 Feb 2016 18:43:58 -0800 (PST) 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 92BC31B37E7 for ; Fri, 19 Feb 2016 18:43:58 -0800 (PST) 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.1130.7; Fri, 19 Feb 2016 18:43:56 -0800 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.1130.005; Fri, 19 Feb 2016 18:43:56 -0800 From: Edward Lewis To: Douglas Otis Thread-Topic: [Arcing] A bit more on the problem statement Thread-Index: AQHRXrSospMxlWD/SE6NYkDkHw/LNp8qfaAAgAo1OYCAAQDXgA== Date: Sat, 20 Feb 2016 02:43:56 +0000 Message-ID: References: <56C7B243.3020004@gmail.com> In-Reply-To: <56C7B243.3020004@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.236] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3538827831_1353339" MIME-Version: 1.0 Archived-At: Cc: "arcing@ietf.org" Subject: Re: [Arcing] A bit more on the problem statement X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 02:44:00 -0000 --B_3538827831_1353339 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 2/20/16, 13:24, "Arcing on behalf of Douglas Otis" wrote: >This is likely my last comment. Apparently something said touched a nerve. If it's frustration over repeatedly making a point, I'll use this old reply of mine: It might be the 10th time you've said "it" but this is the first time I've heard "it." If there's something else, I'll just state that I haven't been closely following the homenet wg in the past few years, nor the dnssd wg for that matter, so perhaps there's a boatload of context buried in mail archives. >Don't insist adoption of draft-cheshire-homenet-dot-home-02 >must follow some grander scheme that might make use of an >alternate root or URL modification. Any such approach >doubtlessly precludes essential compatibilities needing >consideration for Homenet deployment. Due to what I read as exasperation, I looked at previous messages on the mail list and see you've mentioned this draft in each of your posts. So, I looked it up and gave a quick scan. Before I'd comment on it, I would need to read it more thoroughly and I'm not sure this mail list is the appropriate place to make comments. (Perhaps it is, it's not a draft-ietf-homenet-...) You mention "Don't insist adoption of" - what does that mean? E.g., Adoption as a WG item in homenet, adoption as an IETF standard, adoption by the ARCING mail list, or something else? Still, the use case raised seems rather significant, obviously akin to the IPv4 address ranges that by convention are not advertised to the open Internet (inter-enterprise is the term used in "Address Allocation for Private Internets"). The trouble is that unlike routers, DNS elements don't have an innate notion of "internal" and "external" interfaces. (There are de jure definitions of "views", multiple implementations of the concept but no protocol standards-track document has ever been produced.) So, we can't straight up look to how IPv4 addressing and routing for a solution to the use case covered in the draft cited. Beyond that I do see that this use case is interesting to bring into any discussion on the nature of Domain Names or a general namespace. The string "home" could qualify as a resolution switch. Like "onion" the process for resolving is different from traditional means. Unlike onion, the process for "home" uses the protocol already spoken over port 53 (i.e., the DNS protocol). I can see this as fertile ground for work. --B_3538827831_1353339 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSIVm+8csil90ume7Gz 053s7oasVDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAy MjAwMjQzNTFaMA0GCSqGSIb3DQEBAQUABIIBABr+ZCG4S582oppLn57RqCCYRWiIxvk7NII2 n3ipDquyTee9Hx5VQwUBpJD9Hvz1Cm+l3WVkfe2xSMJyTMZCCyNzcO3adExQjz6eyQFmwizf AEC6zaD83F+ZenDUY1izc3JOiLf/o62N/GO4ZEK4/RU+5dMDpSNQ2QZ2NlFun/9/J27M1M8T OeG1zvikksf8aGtg/dL/IBUeaXugwCPdlV549z62GFL3hhyDSNWEnRrifwD85sBUGiVXPxcP VeRFr2bLnk91jICGvF/pEuWRguuwNpswS0ELuXZVsp1VML0B2D26xCb4V9FdTTeQ8ICdJVzm XvHXBShrVPgk/qbcYcI= --B_3538827831_1353339-- From nobody Fri Feb 26 12:10:09 2016 Return-Path: X-Original-To: arcing@ietf.org Delivered-To: arcing@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B73591B2F48; Fri, 26 Feb 2016 11:49:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160226194955.23064.53842.idtracker@ietfa.amsl.com> Date: Fri, 26 Feb 2016 11:49:55 -0800 Archived-At: X-Mailman-Approved-At: Fri, 26 Feb 2016 12:10:08 -0800 Cc: brian@innovationslab.net, arcing@ietf.org, smccammon@amsl.com, arcing-chairs@ietf.org Subject: [Arcing] arcing - New Meeting Session Request for IETF 95 X-BeenThere: arcing@ietf.org X-Mailman-Version: 2.1.15 List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 19:49:55 -0000 A new meeting session request has just been submitted by Stephanie McCammon, on behalf of the arcing working group. --------------------------------------------------------- Working Group Name: Alternative Resolution Contexts for Internet Naming Area Name: Internet Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: intarea dprive dnsop saag rtcweb acme maprg stir tcpinc accord homenet dnssd dispatch ippm taps lurk Special Requests: ---------------------------------------------------------