Re: [DNSOP] Terminology issue #8: context

Ralph Droms <rdroms.ietf@gmail.com> Sun, 29 January 2017 13:26 UTC

Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF716129A1F for <dnsop@ietfa.amsl.com>; Sun, 29 Jan 2017 05:26:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjRzoQa_TxgH for <dnsop@ietfa.amsl.com>; Sun, 29 Jan 2017 05:26:24 -0800 (PST)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 521EF129A14 for <dnsop@ietf.org>; Sun, 29 Jan 2017 05:26:24 -0800 (PST)
Received: by mail-qk0-x22b.google.com with SMTP id u25so105578019qki.2 for <dnsop@ietf.org>; Sun, 29 Jan 2017 05:26:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WN4sn7o16tQ9khHOjdm6UWR9FKJmVKiqr3yHZEIqKHY=; b=gJCnchmsIYTWpvUKNbUc4WFqT12nmiRxTubNNIdZsLt75JUTmzXKkuCeG/Uzki+qKz KDPnuWTUzmgxH/2aFGw2g9sJWF82ZdN843Uf7cp8nCf7Y2M+LHHiTvPwE+TfjXJTlYyM RILcjIFwQgFcCiHCw3ol3wI0UdnoqJJBD0B4NfZVK+vntrBuKAR/YC12pPBtdHgC4gmh X4wzCsr0tQlOHE3zk+BTHgYr30ZUja3s9Tj8JJMmlLC5lAeQ6iVVL4TPOjhUlVpC1uJb sZtJuZkZR16d1eXDix/f9aZPrljMoP9WZRVpsY1IiAZdvB5jZSa24g1aF8RGq1ayg3bj B1iA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WN4sn7o16tQ9khHOjdm6UWR9FKJmVKiqr3yHZEIqKHY=; b=nVsK9Rpjr5rTq2ZMUlT0dhS3j7k3pGySwvgurOStdhj8HcmHKH9/NtPdkSBObqIIgM UTXlHF7nEWynC/St7RKvjaxd+Ef0/xzSLjmr53sdbmRl74r8mK92lBLHHtNa4ha5329I qkTYZ5KLwCuCN8Nxg7szS18ugHRctQVSS5aCYwxxVJVDsI7TJpCL13Da6Xx6728LpcjT 6iCQKv8gVeRtbUH307yyXN52E5U6ODR88EnjBhB3tzH1odJxJQlAMHRWEae868xzHne+ KNblf5kxj3C45WZ7v9tBMCROhiRD2WjVPJcUDgTm5UvKJX2XFHxdL6FetxuXiqWJi4TV oh+A==
X-Gm-Message-State: AIkVDXJrzCd6XU9XrNrG5qy+I4g2R4z7j4G6msmDCT9I5Kbl/tAIKrNlNYvTSrzLEZPUJQ==
X-Received: by 10.55.212.22 with SMTP id l22mr16388552qki.48.1485696383321; Sun, 29 Jan 2017 05:26:23 -0800 (PST)
Received: from ?IPv6:2601:18f:801:600:f5d5:7879:99a8:b2dc? ([2601:18f:801:600:f5d5:7879:99a8:b2dc]) by smtp.gmail.com with ESMTPSA id b190sm9349131qkg.32.2017.01.29.05.26.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jan 2017 05:26:22 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <0C46C00E-B040-4D49-8032-424187491C7B@vpnc.org>
Date: Sun, 29 Jan 2017 08:26:24 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <C6938B18-7CF0-4CB3-9AFE-915E74388252@gmail.com>
References: <0C46C00E-B040-4D49-8032-424187491C7B@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sXuBhKCUi1dH9pYnrAXP_6xQUFI>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Terminology issue #8: context
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Jan 2017 13:26:26 -0000

> On Jan 28, 2017, at 4:22 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 
> On 28 Jan 2017, at 12:28, Ralph Droms wrote:
> 
>> I've submitted three issues to the doc repo:
>> 
>> Issue #8: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8 <https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8>
>> 
>> Add "context" as a facet in the definition of a naming system.  A naming system needs a context in which to perform resolution of a name.  As an example, "locally served DNS zones" (see Issue #10) use the DNS resolution mechanism through a local context rather than through the global root.
> 
> Is that "context" or "possible contexts"? That is, if you consider 1034/1035 as a naming scheme, it seems like there could be "the global context" (the root servers that everyone assumed then) and "a local context" (hosts.txt) or even a mixed context ("first try to resolve in hosts.txt but then go to the root servers if you get an NXDOMAIN", or even the reverse of that). Some naming schemes might have other interesting mixes of context.
> 
> But I agree that something like this is a common, and commonly-ignored, facet that would be useful to list.

I see your point about "possible contexts".  I was thinking of what's needed for the evaluation of one specific name.  Another way to describe the facet is what are the possible contexts.

How about:

* Contexts that can be used for resolving a name and obtaining its associated data, and the way in which a context is specified for resolution of a name

I'd like to discuss your example a little.  In my opinion, hosts.txt lookup and DNS are two different naming systems.  They happen to share the same name syntax but use different resolution methods.  The client name resolution code gets handed a name from an app, and then uses one or more naming systems - in sequence, if more than one - to resolve the name.  In your example, the client code might go to the hosts.txt naming system first and then the DNS naming system.

But I'm quite naive about the details and it may be common practice to consider both hosts.txt and DNS server resolution part of the DNS naming system.

- Ralph

> 
> --Paul Hoffman