Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

Dick Franks <rwfranks@acm.org> Wed, 27 June 2018 19:57 UTC

Return-Path: <rwfranks@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 50D4F130EA7 for <dnsop@ietfa.amsl.com>; Wed, 27 Jun 2018 12:57:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.093
X-Spam-Level:
X-Spam-Status: No, score=-0.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no 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 hdEsi2rCH8Bp for <dnsop@ietfa.amsl.com>; Wed, 27 Jun 2018 12:56:59 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369D2130EA0 for <dnsop@ietf.org>; Wed, 27 Jun 2018 12:56:59 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id e18-v6so3196735wrs.5 for <dnsop@ietf.org>; Wed, 27 Jun 2018 12:56:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RNPGtBcl4zbXPRaRWYIKoBBBj7MR3vJkEo4btluXA9M=; b=a+vjvMgo/6zskvCGe5dsqWFeEgwOOS3H2jc/l1U3yg+/JA+d2rtNTLv3IH3z84P2OA +kYwtaNy993m46Z41h2wmOcdeubAE8Wky6lIefNQIfW1j4fRzorGeHzi+HfyuPT++Ye0 VIFKAd8b65KHeE9GfBTNfndfRyKrxs2cvBn50P6Us+kJdEFCUheoyTAvDjyjhzuMLZdK ggLv30bCgAA+4b4UWRJWeJX6a2IClV9QHDDsDObwAVQ74yl6MDAaJOpbpgd9teCr5wcY +qten2djLL74qKVcXoj6WrUsVW/35NrmoHLjp6hwqS0apag0JxbH9BcAPzDbq7fqEqbY q8TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RNPGtBcl4zbXPRaRWYIKoBBBj7MR3vJkEo4btluXA9M=; b=iNdVsTxzlvkWshd+XWW+zzY7vhTXF8+TH1RcdT4anqh4uTH6FFdrFKakOlQFWbMegQ 3oegUEuN+I7sgJwnBlXaVanb/ZERX1t+EzZRQfkvYmt7eMnMEI2Z2+CIammr4B5thwh8 +PVG2Mj+9lbTUqDNSOiJpFYRNsi22Ca8YeXKiEf04Ej5nvuog8MLT45mFbaC5qoMuqH6 ZLP9bgdJwGzQlGA/m7nAf+BQK8iaudbeBfEqcI7MKnw/2xMX5k+BxZZOj25E59J5pMMV eXiZRI76dPQbi4eurgf2DYtieK8uoB13mFL64aLpyRj3OVyxZ2wYYxCCZunV8P8lRSgG n8vQ==
X-Gm-Message-State: APt69E1Zt4oiN4zhQ2yBK7POwVkOPxCv/qCsMn/Z4jK5lCisU8YjTr4i XoPCPNJhpzw/SXXmCjnhRr4txcUQfb5XOk5ueYdDsA==
X-Google-Smtp-Source: AAOMgpevh/ePItZEQ8SFPQYq9+xD74+8EJTaSr3jHU/HNBqXc0C5w62K+gkOkSGqqE/hSLAes2FL+lDFHxf1uVRlgpI=
X-Received: by 2002:adf:93c6:: with SMTP id 64-v6mr6278892wrp.119.1530129417508; Wed, 27 Jun 2018 12:56:57 -0700 (PDT)
MIME-Version: 1.0
Sender: rwfranks@gmail.com
Received: by 2002:adf:fb45:0:0:0:0:0 with HTTP; Wed, 27 Jun 2018 12:56:16 -0700 (PDT)
In-Reply-To: <17A1E6A9-E43F-41AB-B24D-4B29F17FCC07@gmail.com>
References: <17A1E6A9-E43F-41AB-B24D-4B29F17FCC07@gmail.com>
From: Dick Franks <rwfranks@acm.org>
Date: Wed, 27 Jun 2018 20:56:16 +0100
X-Google-Sender-Auth: dsT1bsNOxH8bimtNu-nqVF6M6lg
Message-ID: <CAKW6Ri7y4K6Aj570GKOJB3p-kiWrWMSx++YrAHf5gq1DQgeSKQ@mail.gmail.com>
To: IETF DNSOP WG <dnsop@ietf.org>
Cc: Suzanne Woolf <suzworldwide@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000641d18056fa5049c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JfFFaRxZC4zYQcnAB4sb5FMhzD4>
Subject: Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 27 Jun 2018 19:57:02 -0000

The document appears to be in good shape.

However, I have some difficulty with the wording of these two paragraphs in
section 2.

      The basic wire format for names in the global DNS is a list of
      labels ordered by decreasing distance from the root, with the root
      label last.  Each label is preceded by a length octet.  [RFC1035]
      also defines a compression scheme that modifies this format.

      The presentation format for names in the global DNS is a list of
      labels ordered by decreasing distance from the root, encoded as
      ASCII, with a "." character between each label.  In presentation
      format, a fully-qualified domain name includes the root label and
      the associated separator dot.  For example, in presentation
      format, a fully-qualified domain name with two non-root labels is
      always shown as "example.tld." instead of "example.tld".
      [RFC1035] defines a method for showing octets that do not display
      in ASCII.

The character encoding of "presentation format" depends on the context in
which it is used. The protocol mandates ASCII encoding of labels on the
wire.
It cannot say anything about the internal character encoding conventions of
application programs or related master files, which can, in the general
case,
be different.

Consider the following perl fragment:

    use Net::DNS 1.11;

    my $resolver = new Net::DNS::Resolver();

    my ($rr) = $resolver->query( 'www.example.com.', 'A' )->answer;

    $rr->print;
    print unpack( 'H*', $rr->string ), "\n";

executed in an ASCII-based environment:

  www.example.com.    600    IN    A    93.184.216.34

7777772e6578616d706c652e636f6d2e0936303009494e09410939332e3138342e3231362e3334

in an OS390 EBCDIC environment:

  www.example.com.    600    IN    A    93.184.216.34

a6a6a64b85a781949793854b8396944b05f6f0f005c9d505c105f9f34bf1f8f44bf2f1f64bf3f4

(output converted to ASCII to preserve your sanity)


Suggested replacement text:

      The basic wire format for names in the global DNS is a list of
      labels ordered by decreasing distance from the root, with the root
      label last.  Each label is ASCII encoded and preceded by a single
length octet.  [RFC1035]
      also defines a compression scheme that modifies this format.

      The presentation format for names in the global DNS is a list of
      labels ordered by decreasing distance from the root, represented by
      printable characters from the ASCII repertoire, irrespective of the
local
      character encoding used to represent them.
      The component labels are separated by a single "." character.
      In presentation format, a fully-qualified domain name includes the
root label and
      the associated separator dot.  For example, in presentation
      format, a fully-qualified domain name with two non-root labels is
      always shown as "example.tld." instead of "example.tld".
      [RFC1035] defines a numerical representation that may be used to
display
      octets for which there is no corresponding ASCII printable character.





Dick Franks
________________________


On 22 June 2018 at 21:01, Suzanne Woolf <suzworldwide@gmail.com> wrote:

> Colleagues,
>
> This begins the working group last call for draft-ietf-dnsop-terminology-bis-10,
> "DNS Terminology”. The document has gotten significant feedback and the
> editors have worked hard to document current terminology usage, both among
> practitioners and for broader audiences; we’d like to advance it.
>
> We’re seeking consensus to advance it to the IESG with an intended status
> of Best Current Practice. Note that it’s intended to obsolete RFC 7719 (
> the earlier “DNS Terminology” document).
>
> If you support it, please say so. If you don’t, please say why.
>
> The current version is at: https://datatracker.ietf.org/
> doc/draft-ietf-dnsop-terminology-bis/
>
> Last Call will run for two weeks, closing on Friday July 6. This will
> allow for discussion of any major outstanding issues at IETF 102.
>
>
> thanks,
> Suzanne, Tim, & Benno
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>