Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information

神明達哉 <jinmei@wide.ad.jp> Mon, 01 July 2019 23:11 UTC

Return-Path: <jinmei.tatuya@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 AD05F12018B for <dnsop@ietfa.amsl.com>; Mon, 1 Jul 2019 16:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oniw1GndoUVR for <dnsop@ietfa.amsl.com>; Mon, 1 Jul 2019 16:11:28 -0700 (PDT)
Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 385C21200CE for <dnsop@ietf.org>; Mon, 1 Jul 2019 16:11:28 -0700 (PDT)
Received: by mail-wm1-f45.google.com with SMTP id z23so1193691wma.4 for <dnsop@ietf.org>; Mon, 01 Jul 2019 16:11:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4D6zoTva1knptxmXTwu1EyDWFwJJ+PNb9jd5pnwjvEo=; b=PPROAqYxCXKctnbjxXpxnLACo9t73htIFd1CwzOu+ae1kXQKb9k4lWVQ9JNwFBnuyf Q8zYeXSzYRVhnOUDiaSUwLtU83aY9w5AE8UaE+I03bQJCg4axRc6DYdd43eGfC+Xo16U o+OZqF9dffGSk5fHzCnLImMefK/a8vAnGs/VxqdzOzh2ThGoroIR1QQgzIJ7OVnzC/mz 3mq/KFa7U5RU/n8x9sqoSVrWm4u+PfrVLuv38UkTWBPosH4+RxHAt2LDXJmobTeFvTOk 8Td30pBv5KJaj4KlaFa0tV0rZ4XAocJJXViHKht7ECjORyms8UxcJM6f4qf+W1hPCXe0 q2hg==
X-Gm-Message-State: APjAAAUP3GW3xL5XTWAO7/t4RQyI/+GJNKmt7NqLnc2CauF7LPg/K7Pn 0zMaQf11s7yl/T0gxUY2tXglB+VXMF3N/fXlhbJQUQIp
X-Google-Smtp-Source: APXvYqwZQ7d8bMZA2ZsWYSmq7m7CA3cuXRwEoG9f32AaL8XyTRkaik0SReEX0w3viuvXjau09fKnoGiHHZ+NUHbR1Rc=
X-Received: by 2002:a7b:c383:: with SMTP id s3mr849560wmj.44.1562022686231; Mon, 01 Jul 2019 16:11:26 -0700 (PDT)
MIME-Version: 1.0
References: <F00B09EC-24D8-40C1-8A6C-86C2FD63A062@icann.org> <CAJE_bqeHakEshSvfsAo9yyf6ZA+aZCL=Qy-FsZAD5-D+mXC2zQ@mail.gmail.com> <2B5F83C8-2353-4181-8080-AFC1121EDFE4@icann.org>
In-Reply-To: <2B5F83C8-2353-4181-8080-AFC1121EDFE4@icann.org>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Mon, 01 Jul 2019 16:11:14 -0700
Message-ID: <CAJE_bqfvUy7YtE6oQjLNdhwjZURuODnk=QwxfUqkq4fVuU1VSg@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000581038058ca6bf80"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PvDdW7lqK6db7H6N5rOJ_E2Fh7Q>
Subject: Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 01 Jul 2019 23:11:31 -0000

At Sat, 29 Jun 2019 22:55:07 +0000,
Paul Hoffman <paul.hoffman@icann.org> wrote:

> > - I think the RESINFO RDATA specification (at least its wire format,
> >   and preferably also the presentation format) should be more clearly
> >   specified.  At least to me it was not very clear, and I'm afraid
> >   this can lead to interoperability problems.
>
> It is a JSON object. What beyond that description would help?

For example, if it can be a part of a standard zone file, what's the
expected presentation format?  Is it a la TXT character string (but
there's no length limitation) or something special?  How do we handle
non-ascii characters?

Also, how do we compare RESINFO RDATAs?  Should they be compared as
opaque binary, or should two semantically identical JSON objects
considered equal as RESINFO RDATA too (even if, for example, they are
different regarding white spaces)?

> > - The last sentence of Section 2 doesn't make sense to me:
> >
> >    they only need code to handle the RESINFO RRtype that is not in
> >    <reverse-ip>.{in-addr,ip6}.arpa/IN or a subdomain of <reverse-
> >    ip>.{in-addr,ip6}.arpa/IN .
> >
> >   Should it actually be "that is in" instead of "that is not in"?  If
> >   it's really "not in", I don't know how to interpret this in this
> >   context...
>
> The whole sentence is confusing, and we can remove it. Thus, that whole
paragraph can go away.

It may depend on the original intent of the NODATA/NXDOMAIN
restriction, but I'm personally fine with that.

--
JINMEI, Tatuya