Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

神明達哉 <> Fri, 14 July 2017 18:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4916129B64 for <>; Fri, 14 Jul 2017 11:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9ucYfHH90Eyl for <>; Fri, 14 Jul 2017 11:12:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 71FCE128B8F for <>; Fri, 14 Jul 2017 11:12:33 -0700 (PDT)
Received: by with SMTP id v17so75815692qka.3 for <>; Fri, 14 Jul 2017 11:12:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=w/u2iJonSngrr3JidQS2smeSEgf+w688inZjpxLuFuc=; b=AJhQt5tpqC8fVrY1oaZxQfi4/LtKemaADskd49I/MonRRQHyVuc9zUfyW+hmvfrP7+ 8qoDyk8Sxjg7z7oJn/xuHKma/7JnTJ6bJaOfNc/YgGZrqHyNtd/g8aS62xH40IxR7Gs3 4rnBpZzwMDmPnf8kkO/tbvoUASshunOPQkfQ0ZkZ2QWRIBHwdXK2xEPShnFi7xYN9uVJ y+DbRxtuwo6IrfRulxybzFBtuZ74B2hHq60p2lba+ephsw23grB4VebZtgiuL7kFVHg/ a8iBjkUPuJCMtuUBIJ2gE3B2klPwV+S58zZI5/P9+I3KUnQnv0oEL2kXFkwwSNuz0CWR ZaLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=w/u2iJonSngrr3JidQS2smeSEgf+w688inZjpxLuFuc=; b=Zn3ao/a9jMhY6Cuc8OaZGLdoLX3pD00NZ5/ROL/8HUOMsCwzFMPBx+4QpcO5Tlq7Lh WlKjbfk251bgzBELn6HmRk7SAfsw1cU8YRdJkR6x8RcxYfilhDowc9/XvF77OTBzFeF5 eFFGhaUgTL+9ewhZrDLKQQ8pNp6gT5q5djSpOb+exvUs+erFwlYDM/yIsua/sp+W0RpB 5aMRE9g0OMD01fMzcZYbG0FzPWQ/+c/NbzAsXmx7403pvPggt8YcK+aLUZz7LYiMY3px 2N358bH5yUo7/mH6V+nFPm8UfpO/4Lz08fJ0q0B3Mc/TLBg3wB9UdyiUTK1+gu7/ejiw dw4w==
X-Gm-Message-State: AIVw112jVwIGeSgmgVtBUBBLd3Cwkk77D3zT3OtTIAZaMHFgk43KplmD jGP8bRlzt0PhOtuozu1aCdsW4zZgSAX+9zk=
X-Received: by with SMTP id y128mr13208082qkd.29.1500055952402; Fri, 14 Jul 2017 11:12:32 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 14 Jul 2017 11:12:31 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 14 Jul 2017 11:12:31 -0700
X-Google-Sender-Auth: mrVwE0YJZ71tMnj64BHnX9y22nM
Message-ID: <>
To: Peter van Dijk <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Jul 2017 18:12:35 -0000

At Mon, 03 Jul 2017 11:23:01 +0200,
"Peter van Dijk" <> wrote:

> > In that sense I see some disparity with the
> > ALIAS record of Amazon Route53, one of the earliest (and probably
> > largest) players of the idea:
> > - Supporting other types of records than AAAA and A
> > - Allowing different target names for different types
> As I replied to John Levine, we do not feel this is prudent at this
> stage. Operational experience with ANAME, once standardised and
> deployed, would be a good basis for another draft that is more
> extensive, like having a type bitmap - this would support both these
> features.
> > I don't know how critical these are for existing R53 ALIAS users, but
> > depending on that ANAME may not be able to be successful in practice.
> Outside of R53, most implementations appear to be similar. That’s a
> pretty decent installed base that we can try to convert!

I'm no by means an advocate of R53-ALIAS, but I suspect its deployment
base as an ALIAS variant is too big to ignore.  If we just keep
ignoring them with the wish of eventual conversion, I'm afraid it's
quite possible that we'll end up having two (or more) incompatible
variants, each has a non-negligible size of deployment.  IMO we should
more explicitly try to avoid that situation.  In that sense I'd like
to suggest contacting someone at Amazon to see if they are interested
in developing an interoperable standard version of ALIAS.

With such efforts and hopefully some hope to have the possibility of
having more compatible deployments, I have no problem with deferring
extensions itself.

JINMEI, Tatuya